IIRC, the sysfs attribute doesn't exist until after the device is probed, and the SCSI probing might fail (can't read partition tables, leading to errors, catastrophic failure) if the max-sectors is too high during probing. While I agree 20-25% performance gain is significant, a high failure-rate is also significant. And, while it's been many years, do *you* want to field all the e-mails from people who say the device they've been using for years is suddenly dead? I think the best compromise is to only adjust the limit up for USB 3 devices. That pretty much guarantees a "newer" device, which should hopefully behave better. Matt On Thu, Oct 29, 2015 at 1:56 PM, Felipe Balbi <balbi@xxxxxx> wrote: > > Hi, > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: >> On Thu, 29 Oct 2015, Matthew Dharm wrote: >> >>> Uhh... I think this is a bad idea. The 120K limit was chosen based on >>> seeing a lot of devices which broke if you tried to transfer more. At >>> least, that's my memory. Otherwise, it's a really goofy number. >>> >>> I certainly wouldn't mind you increasing it in the case of a USB 3.x >>> device, but not globally. >> >> That's what I remember also. Besides, we have a sysfs interface for >> changing this value, so the number in the driver doesn't have to be >> permanent for every device. > > We can't really expect users to fiddle with sysfs to get better > throughput, right ? :-) > > 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 > >> 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. > > I just tested this with 3 other devices I have around and they behaved > with either setting. I wonder if the original breakage could've been due > to a bug in the SCSI layer which has long been fixed ? I mean, how many > years ago are we talking about here ? 10 ? > > cheers > > -- > balbi -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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
