dm-integrity: estimate the size needed for separate integrity device
Hello,
I'm building a media server where I intend to use RAID10 on top of dm-integrity (and cryptsetup on top of that, but that's not really relevant, AFAIK). I plan to put the integrity tags of dm-integrity on my NVME, to avoid some of the performance penalty.
But I'm not sure what size each "integrity tags" partition should be, depending on the data device.
I'm using this blog [1] as the base for the calculation, but I couldn't find a reference for the calculation in the dm-integrity kernel documentation, in cryptsetup wiki or in the integritysetup man page.
Is there a reference for calculating that size ? I'm fine looking at some code, and it looks like the dm-integrity source[2] has some functions names which could be helpful, but any pointers would help :)
Thanks !
[1]: https://blog.tty8.org/posts/2025-04-02-moving-dm-integrity-tags-off-the-hdd-to-speed-up-raid.html
[2]: https://codebrowser.dev/linux/linux/drivers/md/dm-integrity.c.html
Signature · 1 line
Max Gautier
Hi,
Quoted 7 lines · Max Gautier
I'm building a media server where I intend to use RAID10 on top of dm-integrity (and cryptsetup on top of that, but that's not really relevant, AFAIK). I plan to put the integrity tags of dm-integrity on my NVME, to avoid some of the performance penalty.
But I'm not sure what size each "integrity tags" partition should be, depending on the data device.
Interesting, while we can print information about data size, there is actually no calculation of size in the case of an independent data device. (And even this is post-format, we cannot calculate it in userspace in advance.)
The only place for this is actually kernel dm-integrity, but the code is tricky.
CC to Mikulas - is there a simple way to calculate this size?
Or at least provide userspace with information about the existing meta device size (we send only the meta_device option as part of the mapping table).
Actually, integritysetup should check device size before activation...
(We have such a calculation for dm-verity for hash and FEC device, but not for dm-integrity.)
Milan
Quoted 14 lines
I'm using this blog [1] as the base for the calculation, but I couldn't find a reference for the calculation in the dm-integrity kernel documentation, in cryptsetup wiki or in the integritysetup man page.
Is there a reference for calculating that size ? I'm fine looking at some code, and it looks like the dm-integrity source[2] has some functions names which could be helpful, but any pointers would help :)
Thanks !
[1]: https://blog.tty8.org/posts/2025-04-02-moving-dm-integrity-tags-off-the-hdd-to-speed-up-raid.html
[2]: https://codebrowser.dev/linux/linux/drivers/md/dm-integrity.c.html
Quoted 2 lines · Milan Broz
...
Actually, integritysetup should check device size before activation...
I don't know about activation, but at least format does some kind of check (delegated to the kernel, maybe ?): I used trial and errors to confirm the calculation (running integritysetup format resizing the metadata device between each attempts) and by resizing below a certain threshold, I obtained every time a error.
I did not write it down (the error message) but it didn't hint to the size of the metadata device at all, it was only clear because I only changed the size between two attempts.
Signature · 1 line
Max Gautier
Hi Ma,
Quoted 2 lines
But I'm not sure what size each "integrity tags" partition should be, depending on the data device.
I’ve wondered the same.
I extracted some code from the Linux 5.10 kernel (as that’s what I’m using on bullseye) to estimate that, once for an already created split-setup device (if you create it too large and want to shrink) and once before creating.
It assumes defaults for most parameters, but it does support tag size and sectors per block. Use at your own risk.
https://codeberg.org/mirabilos/useful-scripts/src/branch/master/integritysetup
Thankfully, the kernel refuses to set up the device if the partition is too small, so you can test.
Here’s to hoping newer kernels/cryptsetup versions don’t break it ;)
bye,
//mirabilos
Signature · 4 lines
FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh