Expose shost->max_sectors via sysfs

Expose shost->max_sectors via sysfs

[Alan Stern]

I would like to add my voice to the complaint copied below.  Is there any
possibility of having shost->max_sectors exposed and settable via a sysfs
attribute file, so that data transfer sizes can be tuned by the user to
match the capabilities of high-performance devices?

My reason for asking is that a number of USB Mass Storage devices die when
asked to accept a transfer larger than about 128 KB.  But plenty of others
work just fine with transfers of 1 MB or more.  It would be nice to leave
the default limit set at the low value for interoperability but give
people a mechanism for increasing the transfer size limit when they want.

Alan Stern


On 28 Oct 2003, Pat LaVarre wrote:

> > not sure whether it should be applied or not.
> > 
> > Maybe the best solution is start off limiting transfers to 120 KB by 
> > default and asking the SCSI people to expose the max_sectors host field 
> > via sysfs.  That way people could adjust it upward for high-performance 
> > devices that will work with larger transfers.
> 
> Hi, hello, personally I have such a device.
> 
> Via SG_IO I can see my device hints in a number of mmc standard ways
> that my device responds best to large multiples of 64 KiB, aligned. 
> This idea of max 120 KB/cdb sharply conflicts with my mechanical reality
> of prefering aligned 1 MiB/cdb or more
> 
> How do I teach Linux to come to appreciate these standard mmc hints?
> 
> The paused thread:
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106700651518749
> 
> List:     linux-scsi
> Subject:  Re: aligned /dev/scd$n reads less rare how
> Date:     2003-10-24 14:41:16
> 
> shows my device suffering from abuse: 
> 
> $ time sudo dd if=/dev/scd0 bs=1M
> ...
> usb-storage:  x 28 00 00 00 00 00 00 00 20 00
> usb-storage:  x 28 00 00 00 00 20 00 00 24 00
> usb-storage:  x 28 00 00 00 00 44 00 00 40 00
> usb-storage:  x 28 00 00 00 00 84 00 00 40 00
> usb-storage:  x 28 00 00 00 00 C4 00 00 40 00
> ...
> usb-storage:  x 28 00 00 07 FE C4 00 00 40 00
> 
> I had hoped to see something more radically polite, like:
> 
> $ time sudo dd if=/dev/scd0 bs=1M
> ...
> usb-storage:  x 28 00 00 00 00 00 00 02 00 00
> usb-storage:  x 28 00 00 00 02 00 00 02 00 00
> usb-storage:  x 28 00 00 00 04 00 00 02 00 00
> ...
> usb-storage:  x 28 00 00 07 FC 00 00 02 00 00
> ...
> 
> Indeed, personally I so immediately & deeply needed such polite
> consideration that I rolled my own code to get it via SG_IO i.e. I
> reinvented my own dd/ sg_dd:
> http://members.aol.com/plscsi/tools/pldd/
> 
> But I think I gather here the impression that a Linux block device only 
> by default shatters stream into rudely tiny pieces.  Thru a Linux block
> device I can stream as effectively as thru SG_IO, if only I reconfigure
> Linux appropriately?
> 
> Pat LaVarre

Re: Expose shost->max_sectors via sysfs

[Pat LaVarre]

> having shost->max_sectors exposed and settable via a sysfs attribute file,
> so ... can be ... high-performance ...

Have we already exposed via sysfs some other part of shost->?

I ask because, if yes, then out of that precedent I could ignorantly try
to construct a concrete candidate patch.

Pat LaVarre

Re: Expose shost->max_sectors via sysfs

[Mike Anderson]

Alan Stern [stern@rowland.harvard.edu] wrote:
> I would like to add my voice to the complaint copied below.  Is there any
> possibility of having shost->max_sectors exposed and settable via a sysfs
> attribute file, so that data transfer sizes can be tuned by the user to
> match the capabilities of high-performance devices?
> 
> My reason for asking is that a number of USB Mass Storage devices die when
> asked to accept a transfer larger than about 128 KB.  But plenty of others
> work just fine with transfers of 1 MB or more.  It would be nice to leave
> the default limit set at the low value for interoperability but give
> people a mechanism for increasing the transfer size limit when they want.

Well we have a set of host attribute exposed today in scsi_host class.
Ideally the value would be tied to the device and not the host as these
are per queue values (e.g., max_hw_segments, max_phys_segments,
max_sectors). This would suggest that we use the host template attribute
pointers for this.

I believe this capability is what lead to the creation of the host
template shost_attrs and sdev_attrs (which you have already had
experience / cleanup issues with). IIRC while this is our current
interface James had indicated that a better infrastructure was need for
this type of attribute exposing / overriding.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: Expose shost->max_sectors via sysfs

[Alan Stern]

On Tue, 28 Oct 2003, Mike Anderson wrote:

> Alan Stern [stern@rowland.harvard.edu] wrote:
> > I would like to add my voice to the complaint copied below.  Is there any
> > possibility of having shost->max_sectors exposed and settable via a sysfs
> > attribute file, so that data transfer sizes can be tuned by the user to
> > match the capabilities of high-performance devices?
> > 
> > My reason for asking is that a number of USB Mass Storage devices die when
> > asked to accept a transfer larger than about 128 KB.  But plenty of others
> > work just fine with transfers of 1 MB or more.  It would be nice to leave
> > the default limit set at the low value for interoperability but give
> > people a mechanism for increasing the transfer size limit when they want.
> 
> Well we have a set of host attribute exposed today in scsi_host class.
> Ideally the value would be tied to the device and not the host as these
> are per queue values (e.g., max_hw_segments, max_phys_segments,
> max_sectors). This would suggest that we use the host template attribute
> pointers for this.
> 
> I believe this capability is what lead to the creation of the host
> template shost_attrs and sdev_attrs (which you have already had
> experience / cleanup issues with). IIRC while this is our current
> interface James had indicated that a better infrastructure was need for
> this type of attribute exposing / overriding.
> 
> -andmike

I have no objection to making max_sectors a device attribute.  The reason 
I asked about making a host attribute is because the scsi_host structure 
includes a max_sectors member but the scsi_device structure doesn't, so it 
seemed to make more sense that way.

While we could make max_sectors (also max_hw_segments and
max_phys_segments) a USB host-specific attribute, it is applicable to any
SCSI device so it ought to be centralized and available for all.  
However, if the feeling is that it should not be generally exposed, then
I'll implement it just for USB devices.

Alan Stern