Bug 163661 - Default automount for CF cards in PCMCIA is very, very slow
Default automount for CF cards in PCMCIA is very, very slow
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-07-19 21:39 EDT by Andrew D. Stadler
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-30 06:55:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew D. Stadler 2005-07-19 21:39:48 EDT
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 
test flawed?

Version-Release number of selected component (if applicable):

How reproducible:

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.

Additional info:
Comment 1 Stephen Tweedie 2005-08-30 06:55:38 EDT
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
non-kernel component.

Note You need to log in before you can comment on or make changes to this bug.