Re: USB flash drives on FC3 are incredibly slow!



On Tue, 29 Aug 2006 12:17:27 +0100, The Natural Philosopher wrote:

Charles Sullivan wrote:
On Mon, 28 Aug 2006 20:42:13 +0000, Allen Kistler wrote:

Bill Marcum wrote:
["Followup-To:" header set to comp.os.linux.setup.]
On Mon, 28 Aug 2006 18:04:29 GMT, Charles Sullivan
<cwsulliv@xxxxxxxxxxxx> wrote:
I have two small USB flash drives, 64 MB and 128 MB, normally used
for temporarily storing a few small files. Today I copied a dozen
files totaling 42 Megabytes to the 64 MB drive on my Fedora Core 3
box and was astounded to find it took around 45 Minutes. I tried
it with the 128 MB drive and the same job took 15 Minutes.

By comparison, the same copy job to the 128 MB drive under either
Windows XP or my old, slow Red Hat 9 box takes about 15-20 Seconds.

What could be wrong on the FC3 box to make it so slow? It's a
3 GHz Pentium 4 system with USB 2 ports. The Red Hat 9 box is only
a 450 MHz Pentium 2 system with USB 1 ports.

On the FC3 system, the flash drive automatically mounts when plugged
in and the entry: /dev/sda1 /media/usbdisk vfat
pamconsole,exec,noauto,iocharset=utf8,noatime,sync,managed 0 0

appears in /etc/fstab.

Try removing 'sync' from the fstab line.
Ditto that suggestion.

... but make sure you always umount the drive or issue the sync command
at the command line before you unplug it.

Bill & Allen,
Your suggestion certainly did the job - 15 Minutes reduced to 11
Seconds (for cp + umount). But I had to hack the fstab-sync default
configuration file to do it (which the fstab-sync man page says _not_
to do). I'll need to research this some more.

It looks like the 'sync' option must have been forcing a write at
every sector. Hopefully there will be a better implementation in
later FCs - I'd just as soon be rid of the automatic mount if I
still have to remember to umount or sync.


Whether or not to sync removable media is a highly debatable point.

One the one hand, it mens the disk always has what you expect it to have
on it.


On the other, it gets far more writes which is not good for flash
memory, and runs far slower than you want...

Hmm... that "not good for flash memory" is something I hadn't thought
about. Thanks.

The optimum is to force a synnc before unmounting..but nothing stops you
from just unplugging it sadly..

I would think there'd be more options available, like sync at the
completion of each file write or at the end of each multifile write,
or sync after so many milliseconds of inactivity. If nothing else,
make it simpler to temporarily disable the automatic sync when you know
you'll be transferring a large amount of data in one fell swoop.

I'll see what the gurus have come up with when I upgrade to FC5.

Regards,
Charles Sullivan



.



Relevant Pages

  • Re: USB flash drives on FC3 are incredibly slow!
    ... On Mon, 28 Aug 2006 18:04:29 GMT, Charles Sullivan wrote: ... for temporarily storing a few small files. ... Try removing 'sync' from the fstab line. ... Your suggestion certainly did the job - 15 Minutes reduced to 11 Seconds (for cp + umount). ...
    (comp.os.linux.setup)
  • Re: Starting a grad project that may change kernel VFS. Early research
    ... You don't need to sync before umount. ... when, eg, setting a 'filesystem is clean' flag. ... have a file living in src/linux/v2.6.29/README, and it is a hard link ...
    (Linux-Kernel)
  • Re: ext3fs: umount+sync not enough to guarantee metadata-on-disk
    ... umount should have failed. ... Shouldn't sync should wait for truncate to finish? ... completes, and drives go idle, but the system remains hung inside ...
    (Linux-Kernel)
  • Re: safely remove USB hard drive
    ... The sync+unmount has to be atomic in order to guarantee that the data buffers are flushed and that nothing else can start a new write. ... There is no documentary evidence that unmount calls sync (contrary to ... If you have evidence that umount alone is not sufficient to flush all pending i/o for the device, then it should be reported as a bug. ... ejectcan safely substitute for umount, because eject is designed to unmount the device. ...
    (Fedora)
  • Re: ext3fs: umount+sync not enough to guarantee metadata-on-disk
    ... umount should have failed. ... Shouldn't sync should wait for truncate to finish? ... inside a transaction and tries to do lock_super... ...
    (Linux-Kernel)