On Wed, Sep 12, 2012 at 03:39:18PM -0400, Martin K. Petersen wrote: > >>>>> "Kent" == Kent Overstreet <koverstreet@xxxxxxxxxx> writes: > > Kent, > > Kent> To fix the bug first, I'd have to reorder struct bio_pair and then > Kent> just delete two lines of code from bio_integrity_split(). But the > Kent> reordering is unnecessary with the refactoring. > > Well, a bug is a bug and the fix needs to go into stable. So we will > need a patch that does not depend on your changes. Alright, good point. > I don't have a problem with adding a pointer so clones can point to the > parent's vector. But embedding the vector into the bip was a feature. > If you check the git log you'll see that originally I did use separate > vector allocations. Looks like that was 7878cba9f0037f5599004b03a1260b32d9050360 - If I follow your commit message your primary goal was to back the bip vecs by a per bio set mempool? I didn't break that (excepting the issue Vivek noted) - but it is true that my patch adds another allocation (when nr_vecs > BIP_INLINE_VECS, anyways). I don't know how big of a deal you think that extra allocation is. If you're against it, this patch isn't really necessary for the immutable bvecs I'm working on - just need it if we want integrity bvecs to be shared like regular bvecs will be. Something else I noticed is bio_integrity_add_page() doesn't merge bvecs when possible, like the regular bio_add_page(). If changing it to merge bvecs wouldn't break anything, then probably most integrity bvecs would be under BIP_INLINE_VECS. Thoughts? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
