That's a good point. I tested it, and that is true. Sync completes at the same time as the copy operation. The progress bar tracks the file cache, not the file on the usb device. That seems somewhat misleading, but reasonable enough behavior. However, the real question then becomes why am I getting less than 2mb/s with the usb drive on linux (usb 1.0 speeds) but normal usb 2.0 speeds on windows with the same device? I can't imagine a driver that poorly written as to introduce an order of magnitude overhead to an IO operation, so I think surely it must be mistakenly treating it as a usb 1.0 device?
I checked dmesg but found nothing related at the tail of the log files after plugging in the usb device. I did find this in the sys log, I'm including it in case it's helpful. May 2 14:30:19 UberUbuntu kernel: [170092.062230] usb 2-1.2: USB disconnect, device number 4 May 2 14:30:21 UberUbuntu kernel: [170094.052235] usb 2-1.2: new high-speed USB device number 5 using ehci_hcd May 2 14:30:21 UberUbuntu kernel: [170094.146049] scsi8 : usb-storage 2-1.2:1.0 May 2 14:30:21 UberUbuntu mtp-probe: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2" May 2 14:30:21 UberUbuntu mtp-probe: bus: 2, device: 5 was not an MTP device May 2 14:30:22 UberUbuntu kernel: [170095.145406] scsi 8:0:0:0: Direct-Access SanDisk Cruzer 1.14 PQ: 0 ANSI: 2 May 2 14:30:22 UberUbuntu kernel: [170095.146684] sd 8:0:0:0: Attached scsi generic sg3 type 0 May 2 14:30:22 UberUbuntu kernel: [170095.147730] sd 8:0:0:0: [sdc] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB) May 2 14:30:22 UberUbuntu kernel: [170095.149246] sd 8:0:0:0: [sdc] Write Protect is off May 2 14:30:22 UberUbuntu kernel: [170095.149255] sd 8:0:0:0: [sdc] Mode Sense: 03 00 00 00 May 2 14:30:22 UberUbuntu kernel: [170095.150107] sd 8:0:0:0: [sdc] No Caching mode page present May 2 14:30:22 UberUbuntu kernel: [170095.150114] sd 8:0:0:0: [sdc] Assuming drive cache: write through May 2 14:30:22 UberUbuntu kernel: [170095.153599] sd 8:0:0:0: [sdc] No Caching mode page present May 2 14:30:22 UberUbuntu kernel: [170095.153606] sd 8:0:0:0: [sdc] Assuming drive cache: write through May 2 14:30:22 UberUbuntu kernel: [170095.157656] sdc: sdc1 May 2 14:30:22 UberUbuntu kernel: [170095.161704] sd 8:0:0:0: [sdc] No Caching mode page present May 2 14:30:22 UberUbuntu kernel: [170095.161711] sd 8:0:0:0: [sdc] Assuming drive cache: write through May 2 14:30:22 UberUbuntu kernel: [170095.161716] sd 8:0:0:0: [sdc] Attached SCSI removable disk On Wed, May 2, 2012 at 1:39 PM, Andy Whitcroft <[email protected]> wrote: > @Daniel -- are we sure the copy is actually complete. Just because you > can see the files on there and read the contents only tells you you can > read the contents of the kernel file cache. The copying program is > likely fsync'ing at the end and waiting for the data to actually hit the > USB device, whereas your md5sum is mearly pulling the data out of > memory. How long does 'sync' take in this situation; I am expecting it > to complete at the same time as the copy dialog. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/992968 > > Title: > Large file transfer to Sandisk Cruzer 8GB USB hangs for a long time > > Status in “linux” package in Ubuntu: > Confirmed > > Bug description: > This is only for large files (e.g. movie sized 700-4000 MB) > > The file transfer goes quickly (judging by the progress bar) and then > hangs a couple MB short of completed. > > While it's seemingly stuck on the last few MB I opened a terminal and > confirmed that the files are completely transferred and I can even > md5sum them (which takes seconds) and compare that to the original to > prove that they are bit for bit copied correctly. However the nautilus > progress window stays open with a hung progress bar for several > minutes when it's clearly finished. > > I've observed it to take as long as 20 minutes in this stage (it will > eventually "complete".) The problem does not happen with other USB > storage devices on this computer (using the same USB port.) > > Initially I thought this was a nautilus issue, but it hangs using cp > from the terminal (and again I can confirm that the file is completely > transferred with md5sum.) > > ProblemType: Bug > DistroRelease: Ubuntu 12.10 > Package: nautilus 1:3.4.1-0ubuntu1 > ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14 > Uname: Linux 3.2.0-24-generic x86_64 > NonfreeKernelModules: fglrx > ApportVersion: 2.0.1-0ubuntu7 > Architecture: amd64 > Date: Tue May 1 20:16:48 2012 > GsettingsChanges: > org.gnome.nautilus.window-state geometry '1053x693+1969+24' > org.gnome.nautilus.window-state start-with-sidebar false > InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012) > ProcEnviron: > PATH=(custom, user) > LANG=en_US.UTF-8 > SHELL=/bin/bash > SourcePackage: nautilus > UpgradeStatus: Upgraded to quantal on 2012-04-06 (25 days ago) > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/992968/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/992968 Title: Large file transfer to Sandisk Cruzer 8GB USB hangs for a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/992968/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
