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 max size limit" check in blk_cloned_rq_check_limits(). This is a crude, yet effective, solution that forces the use of system software (e.g. udev rules or multipathd) to tweak max_sectors_kb of the underlying devices _before_ a layer like DM multipath is layered ontop.
Maybe I'm missing something, but the code we have in place splits it into max sectors for software and hardware. Shouldn't the stacked devices have max_hw_sectors capped to what the lower levels support? If that was done, we would not have to worry about a user fiddling with max_sectors_kb, since it could only be smaller (or equal to) the max size of the lower level. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
