On Wed, 3 Feb 2016, Marc MERLIN wrote: > On Wed, Feb 03, 2016 at 09:05:26PM -0800, Greg Kroah-Hartman wrote: > > > Still, you're likely on the right track, something seems to wait for > > > each write to proceed before sending the next one. > > > > What are you using to copy files? > > midnight commander, or straight cp, only copying one big file, seeing > how quickly it's being copied. > > > > Is there another option I can try? > > > > Turning off sync is the key thing here, without that on, things "seem" > > to be faster now. The real speed is the same, writes for your device > > And by faster, it's actually instant as long as the file is smaller than > my amount of free RAM :) The sync option really slows things down a lot. That's why you were originally seeing such slow transfers under Linux. > > is slow due to the flash chip, not the USB bandwidth. I'd try a "real" > > True, but it's not that simple. My USB stick actually has a red LED that > flashes when it's working. > When I copy with windows at 20MB/s+, the USB LED stops flashing when > windows says the copy is over, and I can safely eject hardware. > > With linux, I tried this: > bash -c 'time cp /var/local/space/vid/300MB* /mnt/mnt; umount /mnt/mnt' > Sadly, it returns 2s for both, meaning that unmount succeeds before the > data is on the stick. That command will time the cp but not the umount. You should have done: time bash -c 'cp /var/local/space/vid/300MB* /mnt/mnt ; umount /mnt/mnt' to time both the copy and the following unmount. Incidentally, did you do this test within VirtualBox (to match the Windows test) or running on the bare hardware? > If I watch the flashing LED, the copy takes around 15 seconds. This > means my copy speed under linux was about 73MB/s now, but that's based > on an LED flashing. Still, it's a more appropriate value, indicating that the actual transfer speed is reasonably close to what it should be. > > filesystem benchmark tool if you really want to know the speeds it can > > work at (fio is good.) > > There are plenty of FS benchmarks, if you have one specific one with > specific options you'd like me to use, I'm happy to. > > But really a copy of a 300MB file sequentially is the only test I really > care about and that's trivial to reproduce without more complex > benchmark tools. > > If I had to guess, sync causes cp(1) to be very conservative and wait > for a sync after each 4KB block while windows probably blasts all the > data with fewer sync calls in between? > (wild guess at this point) Probably something like that. It doesn't actually change the behavior of the cp program; it changes the behavior of the kernel's filesystem layer. The end effect is the same, though. > But the main point remains that default mount options and default cp > work at horrible speed. That's a new main point. Your original main point was that write transfers under Linux were horribly slow. You now know this was due to the sync option, not any fault in the USB driver stack. The default mount options are a question for another mailing list; they have nothing at all to do with USB. > I'm happy to try stuff to get around that > (nosync might be one, but having my stick write after I unmounted it, > makes me very nervous), so I'd love a solution where cp succeeds when > the data has been synced to flash, and at the very least for unmount not > to return before the data has been committed. cp generally does not wait for data to be written (as far as I know). umount, on the other hand, _is_ supposed to wait. If it doesn't then it's a bug in umount, not a bug in the USB stack. Are you certain that umount doesn't wait for all the data to be transferred? 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