Re: commit 6d2a78e783416ba99e36beb1d4395b785b34e867 avoids dm integrity support

["Martin K. Petersen" <martin.petersen@oracle.com>]

>>>>> "Jens" == Jens Axboe <jens.axboe@oracle.com> writes:

Jens> The forward progress reference failed to take stacked drivers into
Jens> account, I didn't realize that they need to allocate integrity
Jens> data again as well.

Yup.  We need a bio integrity struct as well as a vector to describe the
integrity pages.

Ideally I'd like to avoid cloning the integrity bio_vec altogether.  The
only reason I do it now is because I have to keep the integrity vector
in sync with the data vector when that gets sliced and diced.  Plus
there's the suck of partial completion.

If we never changed bio_vecs this wouldn't be an issue.  One option
would be to add an offset parameter to the bio.  That way we could
completely avoid cloning bio_vecs.  That would mean a bit more
complexity in building scatterlists at the bottom of the pile but we'd
do fewer memory allocations.

I've been tinkering with that approach this evening.  I almost have it
working for the integrity vector.  Doing it for bios is obviously a much
bigger task.


Jens> Perhaps it would be cleaner to make the integrity allocation more
Jens> explicit in the supported paths, instead of hiding it in bio_set?
Jens> Dunno, haven't thought much about it, just an alternative approach

DM is the only subsystem that manually clones things.  MD uses bio_clone
and has no idea that the integrity fluff is there.  In any case I really
think the bio_set approach is a nicer interface than making every
stacking driver special-case integrity allocations.

-- 
Martin K. Petersen	Oracle Linux Engineering