Re: DM-Integrity Under RAID Without Journalling

(re-sending in plain-text so it gets accepted by the list)

On Wed, May 31, 2023 at 3:45 AM Milan Broz <[email protected]> wrote:
>
> 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).

RAID supports its own journal (see "DIRTY STRIPE JOURNAL" in md(4))
that I plan on using.
> > 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