Re: Issues with commit 34b48db6 ("block: remove artifical max_hw_sectors cap")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 30 Dec 2014, Christoph Hellwig wrote:

> > The only limits usb-storage imposes on max_sectors are those needed to
> > work around bugs in the devices' USB bridges.  (Okay, there's also
> > something for tape drive devices, but it probably doesn't belong in
> > usb-storage -- it should be handled by the SCSI tape driver.)
> > 
> > If the ATA layer needs to set a limit on max_sectors, why doesn't it
> > simply go ahead and do so?
> 
> Because the ATA layer doesn't control the device, the bridge does.
> And it seems like it doesn't communicate the maximum transfer size
> properly.

_Is_ there any way to communicate the maximum transfer size?  I'm not
aware of any SCSI command for it.  It isn't part of the USB
mass-storage spec.

usb-storage has no clear idea what sort of device lies on the other
side of the USB bridge.  It might be an ATA drive, it might be a flash
drive, it might not be a disk at all -- usb-storage does its best not
to know or care.

If you think that usb-storage needs to set a maximum transfer size for
disk drives, it won't be hard to write a patch.  But what about all the
other possible transports?  Will they each have to implement the same
transfer limit?  If so, shouldn't the limit be set up from a more
central location, such as the sd driver?

Why not have sd always set max_sectors_kb to 32767 if it isn't already 
smaller?  Would that cause any problems?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux