Re: [PATCH v2] dm: Fix alignment stacking on partitioned devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 05 2010 at 11:16pm -0500,
Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote:

> >>>>> "Mike" == Mike Snitzer <snitzer@xxxxxxxxxx> writes:
> 
> Mike> But even with your blk_off_t patch (and prior to it with sector_t)
> Mike> you're mixing int with blk_off_t in blk_stack_limits() by doing:
> 
> Mike>         alignment = queue_limit_alignment_offset(b, offset);
> 
> Mike> This helped motivate my "blind" conversion.
> 
> Yeah.  However, that particular wart is fixed by an unrelated patch in
> my queue wrt. discard alignment.  But I wanted something you guys could
> look at that applied on top of upstream.
> 
> I'm tinkering with a few things on this end to see if I can make
> the distinction between an offset and an alignment obvious.

Sounds good.  Ultimately we're looking to make sure the DM code is using
"obviously correct" types.  So a near-term minimalist type fix for
upstream (2.6.33) would be awesome.

BTW, the other related concern Alasdair had was that DM shouldn't need
to know to add the start of the partition to the 'offset' it passes to
blk_stack_limits() -- sees it as a layering violation.

I went over the fact that the 'struct queue_limits' was added to
abstract out the limit stacking in a way that DM could use too.  Without
passing asymmetric types for the 'top' and 'bottom' device to
blk_stack_limits(), e.g.:

int blk_stack_limits(struct queue_limits *t, struct block_device *bdev,
                     blk_off_t offset)

we're left with blk_stack_limits() callers needing to pass an offset
relative to the start of the disk.  Alasdair would rather that not be
the case but I'll defer to him on whether he'd still like to see
get_start_sect() be pushed out of DM into blk_stack_limits().

Mike

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux