Red Hat Bugzilla – Bug 163661
Default automount for CF cards in PCMCIA is very, very slow
Last modified: 2007-11-30 17:11:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/412.6 (KHTML, like Gecko) Safari/412.2
Description of problem:
If you have a compact flash card (e.g. Crucial, SanDisk) with an ext2 filesystem and you insert it in a
pcmcia reader adapter, and then insert the pcmcia adapter into your laptop, it will helpfully auto-mount
the volume(s) that are found on the flashcard. Of interest, the volumes are mounted with the "sync"
If you do write performance tests you will learn the ugly truth, however, that in this configuration, these
cards have very poor performance.
For example, my 6mb test file took 1-2 minutes to copy.
For reference, you can perform this same copy in about 10 seconds if you make any of these changes:
(1) mount the volume non-sync. Even if you copy the file *and* sync the volume, the total time is
about 10 seconds
(2) format the volume with vfat. even mounted sync, you get a fast copy.
I don't know the exact culprit here. My theory is that ext2 is heavily rewriting the volume bitmap or
some similar structure and depending on a write cache to make that go faster.
I don't know the best fix here- should the automounter not specify sync? Should ext2 be fixed? Is my
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Mount 512mb CF card in PCMCIA adapter and insert in laptop (ibm T30)
2. Format CF card with ext2 (for easier comparisons, you can partition and do ext2 and vfat)
3. Remove/Insert and note (/etc/mtab) that new vol(s) are mounted in ,sync, mode
4. Copy 5-10mb file onto CF volume and note time
5. Repeat with combinations of sync and non-sync; ext2 and vfat
Actual Results: Most combinations have reasonable speed but sync and ext2 are painfully slow.
Expected Results: All combinations should have good performance; If not, bad combinations (e.g. sync and ext2) should not
be selected by automounter.
For various reasons, ext2 will be slower here. I'm slightly surprised at the
size of the difference, but only slightly. ext2 has much more metadata to
maintain on the disk than fat --- it maintains group descriptors, the
superblock, the inode, indirect blocks and bitmaps for every write; and to keep
the fs completely consistent on disk, it _has_ to update all of these after
every write for a sync mount. That's a lot of metadata, and it's not "fixable"
because it's not a bug --- it's just a design property that makes ext2
suboptimal for sync CF mounts.
This isn't something that's going to get any Red Hat engineering attention for
ext2. And I'm not sure that the automounter should get "fixed", either --- it
is dangerous to have non-sync as a default mount option for removable media, as
users who remove the media early can lose data. The best recommendation I can
really give right now is that ext2 is inappropriate if you're going to rely on
automount's default behaviour; either use FAT or explicitly choose non-sync mount.
If you want to debate whether non-sync should be the default for this case,
please feel free to reopen the bug and we can reassign it to the appropriate