Re: DM-Integrity Under RAID Without Journalling

Hi,

On 5/29/23 04:02, Russell Harmon wrote:
> Hey all,
> 
> I'm looking to use dm-integrity with its journal turned off as the
> backing devices for a RAID-6 array. This is with two goals:
> Closing the RAID456 write hole (md.4 section "RAID WRITE HOLE").
> 
> 1. Detecting (other kinds of) silent data corruption coming from the drive.
> 2. The resulting configuration will have no journaling (both for
> dm-integrity and for mdraid).
> 
> If I understand things correctly, it seems like this covers all the
> cases I listed. If there's data corruption (either via the write hole,
> or coming from the drive), periodic scrubs will detect and repair the
> corruption (since mdraid will consider the corrupt data invalid).
> 
> Does this seem like a correct/valid combination to achieve my goals?

The dm-integrity journal ensures that all sectors data + metadata(auth. tags)
are modified as atomic step (it is not stored in one place).
In the case of power fail it uses either old or new versions.
I do not think RAID keeps this relation correct after power fail
(or another abrupt failure like kernel crash that happens during a write operation).

IOW, power fail can create a new corruption (note metadata are updated
in chunks that includes auth. tags for other sectors).

> Aside, I see the value of dm-integrity's journal (in non-RAID
> configurations), but what's the point of the bitmap? It seems like
> that just reintroduces the potential for undiscovered data corruption
> on the drive (e.g. if there's data corruption in an unsynchronized
> region, at the next boot the corrupted data will falsely be considered
> valid).

Well, I would like to know either :-)

There were some plans for dm-integrity bitmap in LVM LVs as some performance
trade-off, but AFAIK it is not implemented yet (?).
I just added support for integritysetup, so we can use all kernel available
features, but I never understood why bitmap mode was implemented in the first place.

Milan