Внешнее хранилище на rpi2 перестает работать раз в неделю или около того

474
eli

У меня есть распбиан на rpi2 с внешним жестким диском, подключенным к нему через USB. Жесткий диск Seagate 1 ТБ со своим собственным источником питания.

Жесткий диск монтируется локально и доступен через nfs.

Проблема в том, что время от времени (раз в неделю или около того) жесткий диск перестает отвечать на запросы. Когда это происходит, я вижу на своем главном компьютере (kubuntu 18.04), что ресурс nfs больше не отвечает. когда я ssh к rpi-машине, я вижу, что там также я не могу получить доступ к жесткому диску.

Я должен выключить / включить жесткий диск и перезагрузить компьютер rpi, чтобы все снова заработало.

У меня вопрос, как решить эту проблему? Какой метод для обнаружения того, что происходит?

ОБНОВИТЬ:

так что теперь, когда это случилось снова, я запускаю dmesg, и вот что я нашел (жесткий диск sda):

[ 19.565607] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [42530.347552] usb 1-1.2: reset high-speed USB device number 4 using dwc_otg [51845.323983] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 [51845.324002] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x2 [current]  [51845.324012] sd 0:0:0:0: [sda] tag#0 ASC=0x4 ASCQ=0x2  [51845.324026] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 38 c0 09 08 00 00 08 00 [51845.324037] print_req_error: I/O error, dev sda, sector 952109320 [71399.355286] usb 1-1.2: reset high-speed USB device number 4 using dwc_otg [77157.409748] usb 1-1.2: reset high-speed USB device number 4 using dwc_otg [77289.129226] INFO: task usb-storage:69 blocked for more than 120 seconds. [77289.129242] Tainted: G C 4.14.62-v7+ #1134 [77289.129248] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [77289.129257] usb-storage D 0 69 2 0x00000000 [77289.129312] [<8079d258>] (__schedule) from [<8079d8c0>] (schedule+0x50/0xa8) [77289.129337] [<8079d8c0>] (schedule) from [<807a14a4>] (schedule_timeout+0x1d0/0x3f4) [77289.129359] [<807a14a4>] (schedule_timeout) from [<8079e544>] (wait_for_common+0xc0/0x184) [77289.129378] [<8079e544>] (wait_for_common) from [<8079e628>] (wait_for_completion+0x20/0x24) [77289.129398] [<8079e628>] (wait_for_completion) from [<805b5724>] (usb_sg_wait+0x174/0x188) [77289.129424] [<805b5724>] (usb_sg_wait) from [<805ed43c>] (usb_stor_bulk_transfer_sglist.part.2+0x88/0xec) [77289.129448] [<805ed43c>] (usb_stor_bulk_transfer_sglist.part.2) from [<805ed4fc>] (usb_stor_bulk_srb+0x5c/0x64) [77289.129470] [<805ed4fc>] (usb_stor_bulk_srb) from [<805ed628>] (usb_stor_Bulk_transport+0x124/0x370) [77289.129492] [<805ed628>] (usb_stor_Bulk_transport) from [<805edeec>] (usb_stor_invoke_transport+0x30/0x4bc) [77289.129514] [<805edeec>] (usb_stor_invoke_transport) from [<805ecbf0>] (usb_stor_transparent_scsi_command+0x18/0x1c) [77289.129534] [<805ecbf0>] (usb_stor_transparent_scsi_command) from [<805ef3bc>] (usb_stor_control_thread+0x198/0x2a0) [77289.129554] [<805ef3bc>] (usb_stor_control_thread) from [<8013d99c>] (kthread+0x13c/0x16c) [77289.129576] [<8013d99c>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28) [77289.129644] INFO: task jbd2/sda1-8:644 blocked for more than 120 seconds. [77289.129652] Tainted: G C 4.14.62-v7+ #1134 [77289.129657] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [77289.129663] jbd2/sda1-8 D 0 644 2 0x00000000 [77289.129691] [<8079d258>] (__schedule) from [<8079d8c0>] (schedule+0x50/0xa8) [77289.129711] [<8079d8c0>] (schedule) from [<8014b284>] (io_schedule+0x20/0x40) [77289.129730] [<8014b284>] (io_schedule) from [<8079e230>] (bit_wait_io+0x1c/0x70) [77289.129749] [<8079e230>] (bit_wait_io) from [<8079dec0>] (__wait_on_bit+0x94/0xd0) [77289.129768] [<8079dec0>] (__wait_on_bit) from [<8079df84>] (out_of_line_wait_on_bit+0x88/0x90) [77289.129792] [<8079df84>] (out_of_line_wait_on_bit) from [<802c2eb8>] (__wait_on_buffer+0x40/0x44) [77289.129818] [<802c2eb8>] (__wait_on_buffer) from [<8037b24c>] (jbd2_journal_commit_transaction+0xdb0/0x17f0) [77289.129842] [<8037b24c>] (jbd2_journal_commit_transaction) from [<80380d9c>] (kjournald2+0x110/0x2c0) [77289.129863] [<80380d9c>] (kjournald2) from [<8013d99c>] (kthread+0x13c/0x16c) [77289.129883] [<8013d99c>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28) 

Я запускаю fsck -fcv на диске, и он не обнаружил ошибок и плохих блоков.

0
Вы проверяли журналы на RPi? `dmesg` после того, как диск перестает отвечать на запросы и перед перезагрузкой? bertieb 5 лет назад 0
Я сделал, но я не мог понять вывод. Я попробую еще раз, когда это произойдет. eli 5 лет назад 0
Не волнуйтесь! Когда вы это сделаете, [отредактируйте свой пост] (https://superuser.com/posts/1358115/edit), чтобы включить информацию. Самые последние вещи *, вероятно, * самые релевантные, все, что ссылается на USB, `sdb` или` sdc` (или подобное), все, что говорится о SMART bertieb 5 лет назад 0

0 ответов на вопрос

Похожие вопросы