我有两个比较老的“NAS”设备，具体来说是 Buffalo TeraStation Rackmount iSCSI（“TS-RIXL/R5”）。它们基本上是运行 Linux 的嵌入式计算机，具有四个 SATA 插槽和两个以太网端口，固件显示为 iSCSI 目标。
对于这两种设备，我做了以下操作：
我放入了四个新的 16TB Seagate Exos X16 硬盘，使用 Buffalo 的 Windows“固件更新”工具在其上安装了最新的（1.66）固件，并创建了一个 RAID5 阵列。
然后，在运行具有标准内核和工具的 Debian Buster 的 amd64 机器上，我尝试设置一个加密文件系统：
# find the device
iscsiadm -m discovery -t st -p <ip_address>:3260
# connect it to the initiator's SCSI subsystem
iscsiadm -m node --targetname "iqn.2004-08.jp.buffalo:<device_id>:vol1" --portal <ip_address>:3260,1" --login
# this made /dev/sda appear
# create an encrypted device
cryptsetup luksFormat /dev/sda
cryptsetup open /dev/sda nas
# create a filesystem and mount it
mke2fs -t ext4 /dev/mapper/nas
mount /dev/mapper/nas /mnt/nas/
# make a directory
mkdir /mnt/nas/store
这似乎工作正常，但立即导致 dmesg 和 syslog 中出现以下错误：
EXT4-fs error (device dm-0): ext4_validate_block_bitmap:384: comm mkdir: bg 18736: bad block bitmap checksum
然后复制几千兆字节的数据到设备也会导致出现错误，例如
EXT4-fs (dm-0): Delayed block allocation failed for inode 479102523 at logical offset 8708096 with max blocks 128 with error 74
EXT4-fs (dm-0): This should not happen!! Data will be lost
这在两个 NAS 设备上均可重现，从而排除了一些硬件故障。
这些设备多年来一直运行正常（使用 iSCSI，未加密）。
如果我现在做同样的事情没有“cryptsetup”部分，直接在 /dev/sda 上创建文件系统并挂载它，我可以处理多 GB 的数据，而不会在系统日志中出现错误，也不会出现任何数据损坏。
另一方面，在 Debian 机器上使用相同的程序，在通过 USB（而不是 iSCSI）连接的硬盘上设置加密文件系统，也可以正常工作。
所以：
ext4 => dm-crypt => iSCSI => Buffalo NAS：“这不应该发生！！数据将丢失”
ext4 => iSCSI => Buffalo NAS：有效
ext4 => dm-crypt => 外部 USB 磁盘：有效
（其中“有效”的意思是：我复制了大约 10,000 个文件，大小约为 48 GB，并使用 md5sum 验证所有文件均存在且未损坏）
然后，我在运行 Ubuntu hirsute (21.04) 的机器上重复了测试，得到了相同的结果。
在 iSCSI 上运行 dm-crypt 是否存在一些已知问题？我是否可能需要对 iSCSI 部分进行特殊配置，例如对缓存或块大小进行一些配置？
答案1
因此，事实证明问题实际上不是出在 iSCSI 上的 dm-crypt 组合，而是 TeraStation 固件中的限制/错误。
使用 4 TB 磁盘而不是 16 TB 磁盘时，问题不会显现。
将 16 TB 磁盘公开为单独的 iSCSI LUN 时，然后在它们上运行 Linux 软件 RAID，问题也不会显现出来。
我把这个留在这里以防有人用谷歌搜索到它。
我没有想到这一点，因为我知道 TeraStation 运行的是 Linux 版本，而且在任何 Linux 安装中，我从未遇到过 16 TB 磁盘与 4 TB 磁盘的行为不同的情况，所以我不认为会遇到这样的限制 - 而且，我认为如果磁盘大小有问题，TeraStation 会抛出一些错误消息，而不会以这种奇怪的、某种程度上损坏数据的方式行事。