On 06/25/2018 08:05 PM, Mikulas Patocka wrote: > On Sun, 24 Jun 2018, Milan Broz wrote: > >> (added cc to dm-devel annd Mikulas) >> >> Hi, >> >> On 06/24/2018 11:53 AM, Harald Braumann wrote: >>> Hi! >>> >>> I'm using the dm-integrity target standalone with crc32c for component >>> devices of a RAID. I don't use journaling, because the perfomance hit >>> is too big and I don't really need it in that case. >>> >>> I want to automatically activate these targets using udev >>> rules (see below). However, the superblock lacks some crucial >>> information: >> >> >> yes, I agree. The reason is that dm-integrity was in the first >> place designed for authenticated encryption (to store auth tags). >> Then additional metadata ia stored in LUKS2 header. >> >> For the rest I just I have not enough energy (and real-world use cases) >> to convince Mikulas that we need attributes below in superblock (as the dm-integrity >> code is written mostly by him). > > You can write whatever you want to the end of the superblock. If > kernelspace allocates superblock entries from the beginning and userspace > allocates them from the end, they won't cross each other. This is really hackish solution :) I think the superblock should be either maintained inside kernel or in userspace. Or at least kernel superblock should define area reserved for userspace (IOW the area that kernel guarantees to be never overwritten by kernel driver). I really do not want to define any userspace-only attributes until there is some plan how (and if) to integrate plain dm-integrity devices. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
