Слушайте старших — плохого не посоветуют!

[techquisitor]

Когда мне говорили, что device mapper реально бажен — не верил. Сегодня представился случай увидеть собственными глазами такую картину:


Jul 23 16:06:42 database multipathd: sdc: couldn't get asymmetric access state
Jul 23 16:06:43 database iscsid: Kernel reported iSCSI connection 1:0 error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)
Jul 23 16:06:45 database multipathd: mpathc: load table [0 8589934592 multipath 1 queue_if_no_path 0 2 2 service-time 0 1 1 8:32 1 service-time 0 1 1 8:64 1]
Jul 23 16:06:45 database iscsid: connection1:0 is operational after recovery (1 attempts)
Jul 23 16:07:07 database multipathd: mpathc: load table [0 8589934592 multipath 1 queue_if_no_path 0 2 1 service-time 0 1 1 8:32 1 service-time 0 1 1 8:64 1]
Jul 23 17:20:34 database iscsid: Kernel reported iSCSI connection 2:0 error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)
Jul 23 17:20:34 database systemd: Started Session 4234 of user root.
Jul 23 17:20:34 database systemd: Starting Session 4234 of user root.
Jul 23 17:20:35 database iscsid: Kernel reported iSCSI connection 1:0 error (1022 - Invalid or unknown error code) state (3)
Jul 23 17:20:41 database systemd: Deactivating swap /db/swapfile...
Jul 23 17:20:41 database systemd: Stopped target Remote File Systems.
Jul 23 17:20:41 database systemd: Stopping Remote File Systems
Jul 23 17:20:43 database kernel: sd 3:0:0:2: [sdc] killing request
Jul 23 17:20:43 database kernel: sd 3:0:0:2: rejecting I/O to offline device
Jul 23 17:20:43 database kernel: sd 3:0:0:2: [sdc] killing request
Jul 23 17:20:43 database kernel: sd 3:0:0:2: rejecting I/O to offline device
Jul 23 17:20:43 database kernel: sd 3:0:0:2: [sdc] killing request
Jul 23 17:20:43 database kernel: sd 3:0:0:2: [sdc] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Jul 23 17:20:43 database kernel: sd 3:0:0:2: [sdc] CDB: Write(16) 8a 00 00 00 00 01 00 00 57 40 00 00 00 40 00 00
Jul 23 17:20:43 database kernel: blk_update_request: I/O error, dev sdc, sector 4294989632
Jul 23 17:20:43 database kernel: sd 3:0:0:2: [sdc] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Jul 23 17:20:43 database kernel: sd 3:0:0:2: [sdc] CDB: Write(16) 8a 00 00 00 00 01 7c 73 2d 40 00 00 00 10 00 00
Jul 23 17:20:43 database kernel: blk_update_request: I/O error, dev sdc, sector 6382890304
Jul 23 17:20:43 database kernel: sd 3:0:0:2: [sdc] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Jul 23 17:20:43 database kernel: sd 3:0:0:2: [sdc] CDB: Read(16) 88 00 00 00 00 00 75 54 73 00 00 00 01 00 00 00
Jul 23 17:20:43 database kernel: blk_update_request: I/O error, dev sdc, sector 1968468736
Jul 23 17:20:43 database kernel: device-mapper: multipath: Failing path 8:32.
Jul 23 17:20:43 database kernel: sd 4:0:0:2: rejecting I/O to offline device
Jul 23 17:20:43 database kernel: sd 4:0:0:2: rejecting I/O to offline device
Jul 23 17:20:43 database kernel: sd 4:0:0:2: rejecting I/O to offline device
Jul 23 17:20:43 database kernel: device-mapper: multipath: Failing path 8:64.
Jul 23 17:20:43 database kernel: sd 2:0:0:0: [sda] abort
Jul 23 17:20:43 database kernel: sd 2:0:0:0: [sda] abort
Jul 23 17:20:43 database kernel: sd 2:0:0:0: [sda] abort
Jul 23 17:20:43 database kernel: sd 2:0:0:0: [sda] abort
Jul 23 17:20:43 database kernel: sd 2:0:0:0: [sda] abort
Jul 23 17:20:43 database kernel: sd 3:0:0:1: [sdb] FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
Jul 23 17:20:43 database kernel: sd 3:0:0:1: [sdb] CDB: Write(10) 2a 00 06 40 f3 c0 00 00 40 00
Jul 23 17:20:43 database kernel: blk_update_request: I/O error, dev sdb, sector 104920000
Jul 23 17:20:43 database kernel: device-mapper: multipath: Failing path 8:16.

Наше счастье, блочные устройства без резиновых бабLVM собраны и отдельными устройствами, бо это кусок нормальной промышленной СХД. Так что потери данных не случилось. Но fstab слегка переписал.

Comments

[avnik.livejournal.com]

Я вот уже с месяц думаю, а не свалить ли мне с этого ада на ZFS. И как половчее расстаться с этим многообразием без потери данных (у меня щас md1+lvm+xfs и местами btrfs)

[techquisitor.livejournal.com]

Партагеноссе kiltum натрахался на ZFS на петабайтных хранилищах. Очень не советует. Переходи на XFS. Можешь у него в блоге поискать даже. Самое жопное, при заполнении на 85% ФС ZFS деградирует чудовищно по производительности.

[avnik.livejournal.com]

ну у меня петабайтов не будет.
У меня в наличии 2x1T в зеркале.
XFS насколько я знаю начинает плакать от майлдира.

В планах сделать degraded mirror на одном из lvm томов и составить собственное мнение. Если оно "вдругвзлетит" буду думать уже как из под этого лвм выдернуть

[techquisitor.livejournal.com]

>XFS насколько я знаю начинает плакать от майлдира.
Откуда дровишки? Насколько я могу судить по экплутатации, с мелкими файлами всё норм там. У нас массы WAL-логов хватает одних только. Проблем нет.

[avnik.livejournal.com]

где-то выгуглилось.
maildir+filesystem показывает всегда по десятку за и против любой fs

PS +разработчики NixOS агитируют что /nix/store лучше всего держать на zfs (особенно ву момент всяких специфичных вещей типа GC)

[keinkeinkein.livejournal.com]

Я в свое время глянул баг-трекер ZFS on Linux, испугался, увидев такое количество багов, после чего для себя решил, что на десктопе будет только ext4, а ZFS с ее RAID-Z3 будет жить только на домашнем NAS.

Но меня огорчает то, что в ext4 до сих пор нет чек-сумм файлов и прочих айнодов. То есть, ext4 свято верует в то, что контроллер винта не может ошибаться, а ферромагнетик в конкретном секторе винта не может внезапно перемагнититься.

[techquisitor.livejournal.com]

В ext4 хорошо реализован fsck. Для большинства применений, тем паче домашнего — вполне OK. Ну и сломать её достаточно сложно.

Для NAS я бы рекомендовал не ZFS, XFS.

[keinkeinkein.livejournal.com]

Для XFS придется с mdadm возиться, да? Такого RAID-Z3 из коробки там ведь нет?

[techquisitor.livejournal.com]

>Для XFS придется с mdadm возиться, да?
Да.

[keinkeinkein.livejournal.com]

Насчет LVM что скажете? Бажный он или нет?

Могут ли всплывать баги при выполнении примерно такой операции, как по ссылке ниже?

http://keinkeinkein.livejournal.com/83541.html

[techquisitor.livejournal.com]

В такой связке редко видел. Но знакомый народ использовал, вроде не жаловался. Сам LVM хорошо сделан, проблема именно в device mapper. Второй момент, эта проблема у нас вылезла на СХД. С локальными ФС вряд ли что случится.