> "Mike" == Mike Snitzer writes:
Mike,
>> However, doesn't it make more sense to tweak limits on DM device
>> instead of the underlying ones? It seems a bit counter-intuitive to
>> me to change max_sectors_kb on a different device than the one where
>> the filesystem whose max I/O size you w
On Mon, Nov 07 2016 at 9:46pm -0500,
Martin K. Petersen wrote:
> > "Mike" == Mike Snitzer writes:
>
> Mike,
>
> Mike> You're suggesting that when the DM multipath device's limits are
> Mike> stacked up from the underlying devices: cap the mpath's
> Mike> max_hw_sectors to the underlying d
> "Mike" == Mike Snitzer writes:
Mike,
Mike> You're suggesting that when the DM multipath device's limits are
Mike> stacked up from the underlying devices: cap the mpath's
Mike> max_hw_sectors to the underlying devices' max_sectors?
That will break SG_IO, firmware upgrades, etc. (things you
On Mon, Nov 07 2016 at 2:32pm -0500,
Jens Axboe wrote:
> On 11/07/2016 12:26 PM, Mike Snitzer wrote:
> >Otherwise users can easily shoot themselves in the foot by creating the
> >situation where the top-level stacked device (e.g. DM multipath) has a
> >larger max_sectors_kb than the underlying d
On 11/07/2016 12:26 PM, Mike Snitzer wrote:
Otherwise users can easily shoot themselves in the foot by creating the
situation where the top-level stacked device (e.g. DM multipath) has a
larger max_sectors_kb than the underlying device(s). Which will
certainly lead to IO errors due to the "over
Otherwise users can easily shoot themselves in the foot by creating the
situation where the top-level stacked device (e.g. DM multipath) has a
larger max_sectors_kb than the underlying device(s). Which will
certainly lead to IO errors due to the "over max size limit" check in
blk_cloned_rq_check_l
