It still weirds me out so much no one had made either a #FUSE filesystem-level or block-device level dm-integrity in the past before #zfs & #btrfs.
Why were storage vendors trusted so much? (RAID relies on the notion that hardware actually properly reports IO errors and failure conditions as well as that it doesn't fail to detect them, this notion does not reflect reality.)
#DMIntegrity #Filesystem #Integrity #DataIntegrity #RAID #BlockDevice #Storage
#dmintegrity
My home NAS runs mdraid RAID1 on top of two HDDs, each of which is covered by dm-integrity to guard against silent data corruption. Due to how dm-integrity lays out its data, the read-write performance is about half of what the hardware is capable of. I moved dm-integrity tags onto a separate disk to improve the situation, and bumped into a few problems along the way. More details in my blog: https://blog.tty8.org/posts/2025-04-02-moving-dm-integrity-tags-off-the-hdd-to-speed-up-raid.html
Turns out, #LVM #RAID-1 with #dmintegrity over two separate physical disks and then putting a #dmcrypt device on top of the RAID is really slow. As in, it's estimating to take a week to do the initial sync on the two 12TB WD Red drives on SATA. (For comparison, zeroing out one of these disks should take 8 hours or something.)
Apparently it's a somewhat-known problem with dm-integrity, related to its journal.
How would you build something bitrot-safe & encrypted with that hardware? #Debian 12.
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst