On Thu, 29 Oct 2015, Felipe Balbi wrote: > >> Moreover, the same way that we can use sysfs to increase max_sectors, we > >> can use it to decrease everytime we find a broken device. I really > >> wonder if they still are available in the market. So, wouldn't a better > >> default be 2048 and we decrease this as quirk flags when people complain > >> about regressions ? I mean, 20~25% improvement is quite considerable > > > > I don't know about current availability. The decision to use 120 KB as > > the default was made a long time ago, but it wouldn't be surprising if > > apparently back in 2003 [1] I found an apparently earlier message in the old usb-storage archives. This was back when the list contents was supposed to be available to subscribers only, but I hope nobody will mind if I copy the message here (it doesn't contain anything confidential): ------------------------------------------------------------------------------ Date: Sun, 2 Nov 2003 11:01:29 -0800 From: Matthew Dharm mdharm-usb@... Subject: [usb-storage] PATCH 2.5/6: limit transfer size for more compatibility This patch limits the amount of data that will be transferred in a single command/data/status exchange to 240 sectors (about 120KB on most devices). This is to increase compatibility with existing devices. Apparently, many of them don't like large transfers. Those devices are broken, but there are enough of them (and they are otherwise impossible to detect) to make this patch valuable. Future versions of the kernel may allow runtime tuning of this parameter for higher performance. Greg, please apply. Matt ------------------------------------------------------------------------------ Here's another related message taken from the archives: ------------------------------------------------------------------------------ Date: Thu, 24 Jul 2003 12:57:16 -0700 (PDT) From: frits <Frits.Vanderlinden@...> Subject: [usb-mass:0500] Maximum transfer size? >>I can impose an artificial limit on this size. However, I'm wondering how >>large a limit I should impose. >> >>Does anyone know what transfer size chipsets are generally tested to? >> we just reduced in Solaris the limit to 124K. around 128K some devices start hanging and choking. requests > 124K are broken up. fritS ------------------------------------------------------------------------------ So Linux wasn't alone. One of the error reports that led to this patch can be found in this thread: http://marc.info/?l=linux-scsi&m=105847048818775&w=2 > > some of the devices available back then are still in use. You wouldn't > > want to cause a regression, would you? :-) > > My point is that it might be better to find out which device(s) is > quirky because that list might be a lot smaller than the list of > non-quirky devices. Looking at the CBW structure, I have 16 bits for > telling the gadget how many sectors I want, when we limit to 240 > sectors, we're only using 8 bits of those :-p > > If I can find one of these old devices, I'd certainly try to, at least, > Document the reasons why we chose this, apparently arbitrary, 240 > sectors limit. In view of Linus's comments, it really seems best to leave the default setting as it is for USB-2 devices. (Even increasing it just for USB-3 devices _might_ lead to occasional trouble, but at least it's a defensible approach.) > >> > In fact, there are quite a few USB storage devices which break if you > >> > try to transfer more than 64 KB at a time. That's what Windows uses by > >> > default (although maybe they use a larger value for USB-3 devices). > >> > >> I have no idea what MS uses as default so I'll just take your word for > >> it, unless you have some evidence of this statement somewhere. > > > > It's easy to prove for yourself. Enable VERBOSE_DEBUG in > > storage_common.h and plug the resulting mass-storage gadget into a > > Windows machine. Then check the kernel log to see how large the read > > /me goes look for a windows machine > > > and write transfers get. That's how I learned about the Windows > > limit. > > and that happened how long ago ? :-) Well, my original tests were probably more than 12 years ago. But I have seen logs taken using Windows-based hosts more recently. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
