ошибки ext4 с dm-crypt/LUKS поверх устройства iSCSI

У меня есть два старых устройства «NAS», в частности Buffalo TeraStation Rackmount iSCSI («TS-RIXL/R5»). В основном это встроенные компьютеры под управлением Linux с четырьмя слотами SATA и двумя портами Ethernet с прошивкой, которая отображается как цель iSCSI.

С обоими устройствами я сделал следующее:

Я установил четыре новых диска Seagate Exos X16 емкостью 16 ТБ, использовал инструмент Buffalo Windows «Обновление прошивки» для установки на них последней (1.66) прошивки и создал массив RAID5.

Затем на машине amd64 с Debian Buster со стандартным ядром и инструментами я попытался настроить зашифрованную файловую систему:

# найти устройство
iscsiadm -m discovery -t st -p <ip_address>:3260
# подключить его к подсистеме SCSI инициатора
iscsiadm -m node --targetname "iqn.2004-08.jp.buffalo:<device_id>:vol1" --portal <ip_address>:3260,1" --login
# это привело к появлению /dev/sda

# создать зашифрованное устройство
cryptsetup luksFormat /dev/sda
cryptsetup открыть /dev/sda nas

# создаем файловую систему и монтируем ее
mke2fs -t ext4 /dev/mapper/nas
смонтировать /dev/mapper/nas /mnt/nas/

# создаем каталог
mkdir/мнт/нас/магазин

Это, казалось, работало нормально, но сразу же появилось следующее сообщение об ошибке в dmesg и syslog:

Ошибка EXT4-fs (устройство dm-0): ext4_validate_block_bitmap: 384: comm mkdir: bg 18736: неверная контрольная сумма растрового изображения блока

При копировании нескольких гигабайт данных на устройство также появляются ошибки, такие как

EXT4-fs (dm-0): сбой отложенного выделения блока для инода 479102523 по логическому смещению 8708096 с максимальным количеством блоков 128 с ошибкой 74
EXT4-fs (dm-0): Этого не должно происходить!! Данные будут потеряны

Это воспроизводимо с обоими устройствами NAS, что исключает аппаратную неисправность.

Устройства годами работают безупречно (с iSCSI, без шифрования).

Если я сделаю то же самое сейчас без часть «cryptsetup», создайте файловую систему на /dev/sda напрямую и смонтируйте ее, я могу работать с несколькими гигабайтами данных без появления ошибок в системном журнале и без какого-либо повреждения данных.

С другой стороны, использование той же процедуры на машине Debian, настройка зашифрованной файловой системы на жестком диске, подключенном через USB (вместо iSCSI), также работает нормально.

Так:

ext4 => dm-crypt => iSCSI => Buffalo NAS: "Этого не должно происходить!! Данные будут потеряны"

ext4 => iSCSI => Buffalo NAS: работает

ext4 => dm-crypt => внешний USB-диск: работает

(где «работает» означает: я скопировал около 10 000 файлов размером около 48 ГБ и проверил с помощью md5sum, что все файлы были на месте и не были повреждены)

Затем я повторил тесты на машине под управлением Ubuntu hirsute (21.04) и получил те же результаты.

Есть ли известная проблема с запуском dm-crypt поверх iSCSI? Возможно, мне нужна специальная конфигурация для части iSCSI, например, какая-то конфигурация для кэширования или размера блока?

Итак, оказывается, проблема была не в комбинации dm-crypt поверх iSCSI, а в ограничении/ошибке прошивки TeraStation.

С дисками на 4 ТБ вместо 16 ТБ проблема не проявляется.

При предоставлении дисков емкостью 16 ТБ в качестве отдельных логических устройств iSCSI и тогда запустить поверх них линуксовый программный RAID, проблема так же не проявляется.

Я оставляю это здесь на случай, если кто-то погуглит.

Я не подумал об этом, потому что я знал, что на TeraStation работает версия Linux, и ни в одной из установок Linux диск на 16 ТБ не вел себя иначе, чем диск на 4 ТБ, поэтому я не думал об этом. столкнется с таким ограничением — и, кроме того, я полагал, что если возникнет проблема с размером дисков, TeraStation выдаст какое-то сообщение об ошибке и не будет действовать таким странным образом, каким-то образом искажающим данные.