GNU bug report logs - #45497
Feature Request:dm-integrity mapped devices

Previous Next

To reply to this bug, email your comments to 45497 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: raid5atemyhomework <raid5atemyhomework <at> protonmail.com>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: Feature Request:dm-integrity mapped devices
Date: Mon, 28 Dec 2020 12:29:59 +0000

Frankly, MD RAID is incomplete without checksum.
Checksum is provided in Linux by dm-integrity.

Now, LVM2 can actually set up MD RAID with dm-integrity, however:

* It doesn't expose all options.
  * It doesn't support specifying an MD journal for RAID4/5/6 to close the write hole.
    In addition, such an MD journal, if placed on a RAID1 of SSDs, can be used in `writeback` mode to speed up writes to the array.
  * It doesn't support dm-integrity without journal.
    If you are on RAID4/5/6, the MD journal (if you have one) should also cover incomplete writes at the integrity-level, thus there should not need to be a log in integrity level if you have one to cover the write hole at the MD level.
* The LVM-RAID feature is relatively new, compared to `mdadm`-RAID.
  More guides and expertise are available on how to recover an `mdadm`-RAID failure versus an LVM-RAID failure.

Thus, it would be nice to have a dm-integrity device mapper.

However, some complications exist:

* `integritysetup` defaults to tag size (checksum size) of 4 and using crc32c algorithm.
  However, you might prefer a stronger checksum by specifying a larger tag size and a different checksum algorithm such as "sha256".
  While `integritysetup` allows you to format a disk with your preferred checksum options, it only stores the tag size on the disk.
  Whenever you open the disk, ***you have to re-specify the algorithm*** in the `integritysetup open` command line.
  The same also applies to journal mode --- by default it will always open with full journal.

Thus, I propose:

* Add `arguments` field to `<mapped-device>` record type, default `'()`.
  This is a list, typically containing sequential key-value pairs.
  This field will be applied to the `open`, `close`, and `check` functions of the `<mapped-device-kind>` in addition to their existing arguments.
  * If the `arguments` list is empty, then existing `<mapped-device-kind>` will succeed.
* Create an `integritysetup-static` package for use in `initrd`.
* Create a new ``integrity-device-mapping`  of type `<mapped-device-kind>`, which supports the following keywords in the `<mapped-device>` `arguments` list:
  * `#:algorithm` - a string (default `"crc32c"`) specifying the integrity algorithm.
    This should be the same as what you specified in the `integritysetup format` command in the `-I` option.
  * `#:journal` - one of the following strings: `"journal"` (default)` to indicate a full journal at the integrity level, `"bitmap"` to use a faster "dirty" bitmap, or `"none"` to disable journaling (for example if it already exists for all data at a higher layer).

Thoughts?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.