Bug 163661

Summary: Default automount for CF cards in PCMCIA is very, very slow
Product: [Fedora] Fedora Reporter: Andrew D. Stadler <stadler>
Component: kernelAssignee: Stephen Tweedie <sct>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: davej, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-30 10:55:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrew D. Stadler 2005-07-20 01:39:48 UTC
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" 
option.

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:
Always

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 10:55:38 UTC
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.