On Tue, 2014-12-30 at 10:34 -0500, Alan Stern wrote: > 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. For the device, it's in the Block limits VPD page. However, what the device supports isn't necessarily what the bridge or host bus adapter will support. We need to set the limit to the lowest of what the device, the bridge and the HBA support. We know the device (provided the bridge allows VPD inquiries ... not all do) and host, so we really need to know what the bridge will support. From the error it does look like we're running into a bridge limit. > 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. That's fine, but is there any way in USB to query the bridge to get it's transfer characteristics? > 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? This isn't a transport problem, this is a bridge problem. T10 has always recognised there might be a bridge issue linking two transports, so it did initially come up with a bridge spec (BCC) but it was abandoned a decade ago in favour of transparent bridges (every switch in a FC topology is effectively a transparent bridge) or making them explicit in the standards, like SAS expanders. > Why not have sd always set max_sectors_kb to 32767 if it isn't already > smaller? Would that cause any problems? This wouldn't be sd ... we have lots of requirements for large transfer sizes for efficiency. It has to be the layer that knows there's a bridge, so that would make it usb. James -- 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
