我有两个比较老的“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 会抛出一些错误消息,而不会以这种奇怪的、某种程度上损坏数据的方式行事。