Проблемы с диском или матерью?

Question

[Илья Т.]

Всем привет!
Имею ubuntu-сервер, несистемный диск подключен по SATA на нем cryptsetup и BTRFS. Примерно раз в месяц или даже чаще, в логах появляется следующее:

spoiler

Sep 18 00:05:55 white kernel: [265985.854275] BTRFS error (device dm-1): invalid tree nritems, bytenr=4005273206784 nritems=0 expect >0
Sep 18 00:21:43 white kernel: [266934.470251] ata2.00: failed command: WRITE FPDMA QUEUED
Sep 18 00:21:43 white kernel: [266934.470259] ata2.00: cmd 61/80:00:40:db:1b/00:00:5b:01:00/40 tag 0 ncq dma 65536 out
Sep 18 00:21:43 white kernel: [266934.470259] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Sep 18 00:21:43 white kernel: [266934.470267] ata2.00: status: { DRDY }
Sep 18 00:21:43 white kernel: [266934.470270] ata2.00: failed command: WRITE FPDMA QUEUED
Sep 18 00:21:43 white kernel: [266934.470277] ata2.00: cmd 61/20:08:20:dc:1b/00:00:5b:01:00/40 tag 1 ncq dma 16384 out
Sep 18 00:21:43 white kernel: [266934.470277] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Sep 18 00:22:44 white kernel: [266995.066702] ata2: softreset failed (1st FIS failed)
Sep 18 00:22:44 white kernel: [266995.066714] ata2: limiting SATA link speed to 3.0 Gbps
Sep 18 00:22:44 white kernel: [266995.066716] ata2: hard resetting link
Sep 18 00:22:49 white kernel: [267000.067524] ata2: softreset failed (1st FIS failed)
Sep 18 00:22:49 white kernel: [267000.067549] ata2: reset failed, giving up
Sep 18 00:22:49 white kernel: [267000.067560] ata2.00: disabled
Sep 18 00:22:49 white kernel: [267000.067729] ata2: EH complete
Sep 18 00:22:49 white kernel: [267000.067828] sd 1:0:0:0: [sdb] tag#29 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Sep 18 00:22:49 white kernel: [267000.067837] sd 1:0:0:0: [sdb] tag#29 CDB: Write(16) 8a 00 00 00 00 01 5b 1b db 00 00 00 00 20 00 00
Sep 18 00:22:49 white kernel: [267000.067842] print_req_error: I/O error, dev sdb, sector 5823519488
Sep 18 00:22:49 white kernel: [267000.067885] BTRFS error (device dm-1): bdev /dev/mapper/private errs: wr 1, rd 0, flush 0, corrupt 0, gen 0
Sep 18 00:22:49 white kernel: [267000.067955] sd 1:0:0:0: [sdb] tag#30 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Sep 18 00:22:49 white kernel: [267000.067961] sd 1:0:0:0: [sdb] tag#30 CDB: Write(16) 8a 00 00 00 00 01 5b 1b 97 a0 00 00 00 a0 00 00
Sep 18 00:22:49 white kernel: [267000.067964] print_req_error: I/O error, dev sdb, sector 5823502240
Sep 18 00:22:49 white kernel: [267000.067990] BTRFS error (device dm-1): bdev /dev/mapper/private errs: wr 2, rd 0, flush 0, corrupt 0, gen 0

и раздел переходит в режим только чтение.
SMART диска ничего криминального не содержит. Шлейф поменял. BIOS обновил.
Менять материнку? Или диск?

Comments

[zersh]

Смарт тоже приложите

Answer 1

[Сайпутдин Омаров]

А шину подключения менял?

Comments

[Илья Т.]

Прошу прощения. Шина в данном случае это что? У меня только SATA доступно. Да и диск только SATA

[Сайпутдин Омаров]

ну че сразу мамку то менять, можете ведь Pci контролер за 100 найти и попробовать ее
если смарт чист.

Answer 2

[Алексей Харченко]

print_req_error: I/O error, dev sdb,

Указывает что проблема скорее железная. Не в курсе, насколько глубоко задействовано указанный crypt (шифрованный раздел?), но тут слишком много точек отказа - и сам факт того, что шифровано, и btrfs (всё ещё глючная ФС, как ни крути)....
SMART диска сюда, и полную модель. Кстати, ошибки записи SMART не всегда корректно отлавливает, а вот ОС вполне может нарваться на такое. И диски такие мне попадались, что на чтение идеально, а запись с большими проблемами, вплоть до того, что сам диск переходит в режим read-only (не ОС, не драйвер, а сам диск, чаще это на ssd попадается). Попадался диск такой, что всё работает, на него можно писать, читать, но после сброса питания он вновь в том состоянии, как и был - будто на него ничего не писалось. Тогда я не проверял специально тестами его, времени не было, его просто заменили и клиент забрал.

Comments

[Илья Т.]

btrfs (всё ещё глючная ФС, как ни крути) - на каком основании вы так считаете?
уже во многих дистрибутивах она идет как "фс по умолчанию"

Answer 3

[Илья Т.]

Поменял жесткий диск. Наблюдаю. Будут какие-то новости - сообщу здесь.
upd: После замены диска началась какая-то лютая дичь.
Раз в сутки в логах выдает вот такое:

Sep 24 16:03:10 white kernel: [68836.536800] xhci_hcd 0000:00:10.0: WARN Cannot submit Set TR Deq Ptr
Sep 24 16:03:10 white kernel: [68836.536803] xhci_hcd 0000:00:10.0: A Set TR Deq Ptr command is pending.
Sep 24 16:03:10 white kernel: [68836.668526] usb 3-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Sep 24 16:03:41 white kernel: [68867.259600] xhci_hcd 0000:00:10.0: WARN Cannot submit Set TR Deq Ptr
Sep 24 16:03:41 white kernel: [68867.259603] xhci_hcd 0000:00:10.0: A Set TR Deq Ptr command is pending.
Sep 24 16:03:41 white kernel: [68867.388753] usb 3-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Sep 24 16:03:41 white kernel: [68867.411827] sd 9:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
Sep 24 16:03:41 white kernel: [68867.411833] sd 9:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 20 00
Sep 24 16:03:41 white kernel: [68867.411836] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
Sep 24 16:04:12 white kernel: [68897.983997] xhci_hcd 0000:00:10.0: WARN Cannot submit Set TR Deq Ptr
Sep 24 16:04:12 white kernel: [68897.984004] xhci_hcd 0000:00:10.0: A Set TR Deq Ptr command is pending.
Sep 24 16:04:12 white kernel: [68898.113010] usb 3-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Sep 24 16:04:42 white kernel: [68928.696367] xhci_hcd 0000:00:10.0: WARN Cannot submit Set TR Deq Ptr
Sep 24 16:04:42 white kernel: [68928.696369] xhci_hcd 0000:00:10.0: A Set TR Deq Ptr command is pending.
Sep 24 16:04:42 white kernel: [68928.825433] usb 3-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd

После чего LA начинает неконтролируемо расти за счет роста iowait.
В USB при этом вставлена но не примонтирована флэшка (используется при загрузке).