On Sat, 6 Jun 2015, Alan Stern wrote: > On Sat, 6 Jun 2015, Mark Hills wrote: > > >Whatever the reason is, it doesn't seem to be connected with the USB > > >stack. > > > > Ok thanks for your assistance. Unless anyone does have any ideas here, > > I suppose my only option is to start tracing the writes up the stack. > > I believe the individual writes are created in the block layer. > > > I recall there's also a verbose/debug kernel config to usb-storage so > > I might try there. But it may be days/weeks before I'm able to do > > this, so any suggestions in the meantime are warmly welcomed. > > Debugging usb-storage won't help. It won't give you any more useful > information than usbmon does already. The usb-storage driver does not > create the commands it sends to devices; it merely relays commands > received from higher up. Ok thanks for the info. This would imply that other devices are affected, and on giving equivalent inspection to internal HDD and SSD it appears they are. The arrival of a new USB drive has drawn this to my attention. So it looks like it is in the block layer, and can safely rule out usb-storage here. Many thanks for your help in doing so. FYI it looks like something odd is going on. It seems any change to /proc/sys/vm/dirty_ratio is crippling the writes in this way. I did a test using the same dd: <system bootup, kernel 4.0.4> # sysctl vm.dirty_ratio vm.dirty_ratio = 20 <all ok; writes at ~150Mbyte/sec> # sysctl vm.dirty_ratio=20 <all continues to be ok> # sysctl vm.dirty_ratio=21 <writes drop to ~5Mbyte/sec> # sysctl vm.dirty_ratio=20 <writes continue to be slow at ~5Mbyte/sec> It's late now and I am tired, so I could be mistaken but it looks like something more sinister is happening here, triggered by the first change to the dirty_ratio. Hopefully I'll be able to look into this and report it if it's a real problem. At least now I have a way to do my backups in reasonable time -- thanks again for your help. -- Mark -- 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
