On Tue, 3 Jul 2018, Milan Broz wrote: > 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 :) Then - there's an "offset" argument - you can use it and create your own superblock before the offset. > 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 Mikulas _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
