Re: dm: Fix alignment stacking on partitioned devices

[Mike Snitzer <snitzer@redhat.com>]

On Mon, Dec 21 2009 at 11:27pm -0500,
Martin K. Petersen <martin.petersen@oracle.com> wrote:

> >>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
> 
> Mike> If that is the case then the data "start" should be different for
> Mike> these individual PVs (one following the other).  If not, can you
> Mike> provide the 'dmsetup table' output for the associated DM devices?
> 
> Did some more runs.  It turns out the old stacking algorithm identified
> the two alignments as being incompatible for the wrong reasons.  That's
> why a message was printed with the older kernel.

OK, so is MD somehow getting things wrong?  (You originally said that
with the new stacking function MD resulted in an error but DM did not).
 
> I do find it a bit strange that you pass relative offsets to the
> stacking function and rely on the userland utilities to do the right
> thing, though.  Doesn't that mean that existing misaligned volumes will
> go undetected?  Or do you perform a check when you prepare the table
> before feeding it to the kernel?

"start" isn't a relative offset.  The "start" is absolute from the
beginning of the device.  So for old LVs that are already misaligned
they'll pass down a start that _should_ cause misalignment messages in
the kernel (via the stacking function).  I know I've seen such messages
when LVM doesn't compensate for alignment_offset but I'll revisit this
with your new stacking function.

The justification for relying on userspace to consume and adjust for
alignment_offset is: you're not creating LVM LVs with the kernel.
Metadata that (may) precede the data "start" of a volume gets layed out
(and managed) by userspace (LVM).  Not having the kernel involved in
generating the "correct" offset to data allows such concerns to be
purely in userspace (having the kernel contribute to that calculation
doesn't get us anything other than potential for split brain bugs).

Mike