From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: How can need dm use limits.max_hw_sectors from the bdev? Date: Mon, 18 Jan 2016 10:56:53 -0500 Message-ID: <20160118155652.GA2483@redhat.com> References: Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Eric Wheeler Cc: dm-devel@redhat.com List-Id: dm-devel.ids On Sun, Jan 17 2016 at 1:34am -0500, Eric Wheeler wrote: > Hello all, > > I'm writing a trivial dm target and hitting errors like this: > io too big device loop0 (2048 > 255) > > which looks like the problem described here: > https://bugzilla.kernel.org/show_bug.cgi?id=9401#c3 > > and is is consistent: > cat /sys/block/loop0/queue/max_hw_sectors_kb > 127 > # cat /sys/block/dm-4/queue/max_hw_sectors_kb > 2147483647 > > By tracing from sysfs it looks like I need to do something like this when > called from the target constructor (dm_ctr_fn target_type.ctr) function: > > target->table->md->queue->limits.max_hw_sectors = > priv->dm_dev_bdev->bdev->bd_queue->limits.max_hw_sectors; > > but I cannot because `struct md` and `struct mapped_device` are opaque > which makes me think there is a better (correct) way to do this. Is there a way > to change my target device's max_hw_sectors value to 127? > > Is there some other generic solution? You'll first want to implement the .iterate_devices hook. This alone should enable DM core to leverage the block layer's blk_stack_limits() infrastructure to stack up your top-level device's queue_limits. And if you'd like to override your device's queue_limits beyond what is stacked up from the underlying device(s) you can implement the .io_hints hook in your target. > Would late bio splitting solve this? Maybe, if by solve this you mean: the block core won't error any more. But you're better off stacking underlying devices' queue_limits like I detailed above. Mike