On Wed, Jun 10 2009 at 1:58pm -0400, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > >>>>> "Mike" == Mike Snitzer <snitzer@xxxxxxxxxx> writes: > > Mike> So the question: is _not_ using the blk_queue_*() setters > Mike> perfectly fine? Given that DM has always _not_ used them the > Mike> quick answer is "seems fine". > > Mike> But I need to dig a bit more to understand if the additional logic > Mike> in the blk_queue_*() setters is something DM shouldn't be > Mike> circumventing. > > The original intent was that drivers like DM and MD would seed their > limits using the blk_queue* calls before adding any component devices. > blk_stack_limits() would then scale accordingly for every new device > added. > > Is there any reason in particular that this approach wouldn't work for > DM? I.e. set defaults ahead of time instead of doing it upon table > completion using check_for_valid_limits()? When a table is pushed to DM each target device in the table may have different limits. There is no one-size-fits-all default. With DM, the underlying device that you're sending IO to is a function of offset into the DM device. Therefore, the associated IO limits should really be a function of offset. Understanding that that is a more complicated proposition we're working with the topology infrastructure that you've put together as best we can. That means we use a device's alignment_offset in userland LVM2 to push down a data area whose start+size is aligned. This gives us the guarantee that each device in a given DM table is aligned. From there DM will use blk_stack_limits() to combine all the other topology limits (alignment_offset is no longer an issue; though we could get some warnings.. may look to silence them in dm-table.c). But blk_stack_limits() leads to a situation where the combined limits (io_min, logical_block_size) are not ideal for all offsets into the resulting DM device (e.g. issuing larger IOs to some target devices than would otherwise be needed). This is not new for DM (historically DM stacked hardsect_size and other limits in the same fashion), but it doesn't mean that we aren't keeping in mind that limits as a function of offset would be more appropriate. Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
