On 08/30/2016 08:15 PM, Martin K. Petersen wrote:
"Andy" == Andy Grover <agrover@xxxxxxxxxx> writes:
Hey Andy,
Andy> ...because limits.max_hw_sectors internally seems to be just the
Andy> controller limit, but what users of queue_max_hw_sectors
Andy> (including sysfs) really want is the lesser of
Andy> limits.max_hw_sectors and limits.max_dev_sectors.
max_dev_sectors is a limit reported by the target device for
READ/WRITE/VERIFY requests. Whereas max_hw_sectors describes the DMA
constraints of the controller.
It is a requirement for SG_IO, firmware updates, tape drives, etc. that
the controller limits are reported correctly since they do I/Os that are
much bigger than typical filesystem requests. When we tried to conflate
the two things broke in interesting ways.
That's crazy. If max_hw_sectors_kb is expected to be the DMA constraint,
then it makes no sense to name it 'sectors'. We currently have the one
exported constraints, and making it anything but the 'this is the
maximum IO size we can support' would be nonsensical.
I can't remember why the max_dev_sectors sysfs export patch didn't go
in. But instead (or in addition) we could entertain having a
max_rw_sectors_kb file that reflects the biggest READ/WRITE/VERIFY
request the device can consume if that's the information you're after?
Which, coincidentally, is what that file already is for most other
devices. It'd make more sense to bring SCSI into this realm, instead of
imposing this weird world view on others. We export max_segments and
max_segments_size, which are basically a window into what the DMA engine
can do.
--
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
