strange dm-integrity checksum/buffer space requirements

Hi,

In short:

I suspect there is an issue with the checksum area/journal/buffer size calculation in the kernel code of dm-integrity when using a dedicated metadata device.

It seems to require 641GB of metadata space for a 10TB data device, while I expected it to rquire only ~73GB (2441609216 4k sectors, 256bit checksums).

Long story:

I played around with dm-integrity now quite a bit and it seems to work well when only using a single device (that is checksum+data combined on one drive).

However this give quite poor performance for HDDs and I soon started experimenting with a dedicated checksum device. This also seems to work well for small data devices.

In my target usecase I would like to use it on a 10TB HDD as data device, with 256bit checksums and 4k sectors. In order to roughly calculate the required size of the checksum device I took the 4k sector count of the data device (2441609216) and multplied it by 32. This gave me ~73 GiB for checksums.

I tried various disk sizes (80GB, 128GB, 256GB, 512GB, 600GB, ...). None worked. Only after I increased the checksum device to *** 641GB *** it worked out. This appears a bit too much to me. Hence this bug report.

How to reproduce:

simply build two loop devices with the appropiated sizes and use the following command to format them: integritysetup format /dev/loop1 --no-wipe --batch-mode --tag-size=32 --integrity=sha512 --sector-size=4096 --data-device /dev/loop0 --integrity-no-journal

Versions used:

cryptsetup 2.1.0 (also tried GIT master branch) kernel: 5.0.8-1-default OS: openSuSE Tumbleweed

Many thanks & regards Simon