dm-integrity standalone - lack of metadata
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:
- Integrity algorithm
The algorithm is not stored in the superblock and so I have to use crc32 hard-coded in my udev rule. This is of course no general solution. I don't quite understand why it is not stored in the superblock. Is there a technical reason for that?
- Journal mode
I open the integrity devices without journaling. But again, that's hard-coded and it would a be problem if I had other devices, where I actually want journaling. It would be nice, if the superblock contained a use_journal flag so the default could be configured on the device itself.
- UUID/label support
Not strictly required for my use case, but would be nice for persistent naming.
While playing around with that, I also noticed that integritysetup format is extremly slow (this is on an HDD):
integritysetup format /dev/sdb2 -v --integrity crc32c --sector-size 4096
=> 39.6 MiB/s
Format with --no-wipe, open the target and use dd:
dd if=/dev/zero of=/dev/mapper/int bs=1M => 63 MiB/s
Same as above, but opening without journal (which really isn't required for that step, even if the final target should be journaled):
=> 135 MiB/s
I have absolutely no problem with using the dd method, but it kind of makes the built-in format method redundant.
Best regards
harry
/etc/udev/rules.d/70-dm-integrity.rules:
ACTION!="add", GOTO="dm_integrity_end" SUBSYSTEM!="block", GOTO="dm_integrity_end" ENV{ID_FS_TYPE}!="DM_integrity", GOTO="dm_integrity_end"
RUN+="/sbin/integritysetup open $devnode $kernel-integrity --integrity crc32c --integrity-no-journal"
LABEL="dm_integrity_end"
(added cc to dm-devel annd Mikulas)
Hi,
Quoted 9 lines · Harald Braumann
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).
At least for the algorithm I mention this idea several times ;-)
There are some patches for dm-integrity targeted to 4.19 floating around, so let's add these ideas to the mix.
Quoted 17 lines
- Integrity algorithm
The algorithm is not stored in the superblock and so I have to use crc32 hard-coded in my udev rule. This is of course no general solution. I don't quite understand why it is not stored in the superblock. Is there a technical reason for that?- Journal mode
I open the integrity devices without journaling. But again, that's hard-coded and it would a be problem if I had other devices, where I actually want journaling. It would be nice, if the superblock contained ause_journalflag so the default could be configured on the device itself.- UUID/label support
Not strictly required for my use case, but would be nice for persistent naming.
Quoted 6 lines
While playing around with that, I also noticed that integritysetup format is extremly slow (this is on an HDD):
integritysetup format
/dev/sdb2-v --integrity crc32c --sector-size 4096
=> 39.6 MiB/s
This can be perhaps fine-tuned, but for standalone integrity I expect we will use internal wipe, so this will be just fallback. See https://www.redhat.com/archives/dm-devel/2018-June/msg00089.html
Quoted 7 lines
Format with --no-wipe, open the target and use dd:
dd if=/dev/zero of=/dev/mapper/int bs=1M => 63 MiB/sSame as above, but opening without journal (which really isn't required for that step, even if the final target should be journaled):
=> 135 MiB/s
Internal wipe also uses activation without journal, it is slow probably because we use direct-io (can you add oflag=direct to your dd command? Is it the same speed as integritysetup wipe?)
Quoted 8 lines
I have absolutely no problem with using the dd method, but it kind of makes the built-in format method redundant.
Best regards
harry
/etc/udev/rules.d/70-dm-integrity.rules:
Quoted 7 lines
ACTION!="add", GOTO="dm_integrity_end" SUBSYSTEM!="block", GOTO="dm_integrity_end" ENV{ID_FS_TYPE}!="DM_integrity", GOTO="dm_integrity_end"
RUN+="/sbin/integritysetup open $devnode $kernel-integrity --integrity crc32c --integrity-no-journal"
LABEL="dm_integrity_end"
This is not the best way - integritysetup itself need udev synchronization, so it will race here with udev.
I think we need similar system like /etc/crypttab (or extend crypttab of integrity targets).
Milan
Mikulas Patocka
maintainerQuoted 16 lines · Milan Broz
(added cc to dm-devel annd Mikulas)
Hi,
Quoted 9 lines · Harald Braumann
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:
Quoted 7 lines
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.
Mikulas
Quoted 22 lines · Mikulas Patocka
Quoted 20 lines · Milan Broz
(added cc to dm-devel annd Mikulas)
Hi,
Quoted 9 lines · Harald Braumann
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.
Quoted 7 lines
Quoted 3 lines
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
Mikulas Patocka
maintainerQuoted 27 lines · Milan Broz
Quoted 26 lines · Mikulas Patocka
Quoted 23 lines · Milan Broz
(added cc to dm-devel annd Mikulas)
Hi,
Quoted 9 lines · Harald Braumann
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).
Quoted 5 lines
Quoted 3 lines
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.
Quoted 9 lines
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
Quoted 8 lines · Milan Broz
(added cc to dm-devel annd Mikulas)
Quoted 1 line · Harald Braumann
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.
I understand.
Quoted 5 lines
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).
At least for the algorithm I mention this idea several times ;-)
OK, good. I was just afraid that there might be some technical reason and this was out of the question.
Quoted 8 lines
Quoted 8 lines
integritysetup format
/dev/sdb2-v --integrity crc32c --sector-size 4096
=> 39.6 MiB/sFormat with --no-wipe, open the target and use dd:
dd if=/dev/zero of=/dev/mapper/int bs=1M => 63 MiB/s
Quoted 7 lines
Quoted 3 lines
Same as above, but opening without journal (which really isn't required for that step, even if the final target should be journaled):
=> 135 MiB/sInternal wipe also uses activation without journal, it is slow probably because we use direct-io (can you add oflag=direct to your dd command? Is it the same speed as integritysetup wipe?)
Sorry, I haven't gotten around to it, yet.
Quoted 6 lines
Quoted 6 lines
/etc/udev/rules.d/70-dm-integrity.rules:ACTION!="add", GOTO="dm_integrity_end" SUBSYSTEM!="block", GOTO="dm_integrity_end" ENV{ID_FS_TYPE}!="DM_integrity", GOTO="dm_integrity_end"
Quoted 8 lines
Quoted 1 line
RUN+="/sbin/integritysetup open $devnode $kernel-integrity
--integrity crc32c --integrity-no-journal"
Quoted 2 lines
LABEL="dm_integrity_end"
This is not the best way - integritysetup itself need udev synchronization, so it will
race here with udev.
Could you elaborate on that? How does it need udev and could I add anything to the rules to ensure proper synchronization?
Quoted 2 lines
I think we need similar system like
/etc/crypttab(or extend crypttab of integrity targets).
Thats what I wanted to avoid. I would like it to work like LVM where volumes can be set up automatically with just metadata stored on the device itself.
Best regards
harry
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt