On Fri, Jun 05 2009 at 12:33am -0400,
Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote:
> >>>>> "Mike" == Mike Snitzer <snitzer@xxxxxxxxxx> writes:
>
> Mike,
>
> + if (blk_stack_limits(&ti->limits, &q->limits, 0) < 0)
> + DMWARN("%s: target device %s is misaligned",
> + dm_device_name(ti->table->md), bdevname(bdev, b));
>
> I did some testing tonight. You're always passing offset 0 into the
> stacking function so things are not working right. This argument should
> contain the offset to the first (data) sector. So you want something
> like get_start_sect(bdev) << 9 for the stacking to do its magic.
I followed your lead :)
http://mkp.net/code/topology/dm-topology.patch
But, yes I became concerned about this just last night myself when I
added yet another call to blk_stack_limits().
I need to continue looking at this problem; particularly as it relates
to the LVM2 userspace's role in seeding the DM layer appropriately.
My initial thinking was that if LVM2 understood how to consume the
alignment_offset when constructing an LV then the alignment_offset
information becomes unnecessary to propagate. Thinking being that
alignment_offset was already accounted for in LVM2 by adjusting each
target devices' 'start' within the DM table (associated with the LV).
So I'm not yet seeing why alignment_offset _should_ matter as you stack
within DM (because of LVM2's role in accounting for it) but...
I'll work through this further; I welcome any ideas/feedback you might
have.
Thanks,
Mike
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
