Bug 157674 - sync option on VFAT mount destroys flash drives
sync option on VFAT mount destroys flash drives
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
rawhide
All Linux
high Severity high
: ---
: ---
Assigned To: David Zeuthen
:
Depends On:
Blocks: FC4Blocker
  Show dependency treegraph
 
Reported: 2005-05-13 12:59 EDT by Michael H. Warfield
Modified: 2013-03-05 22:43 EST (History)
5 users (show)

See Also:
Fixed In Version: 0.5.2-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-23 11:54:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael H. Warfield 2005-05-13 12:59:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050509 Fedora/1.0.3-5 Firefox/1.0.3

Description of problem:
This is a hardware destruction problem do to a bad mount option from hal!

USB keys / drives are being mounted with the "sync" option.  This is in the /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi file.  This option causes the premature failure and destruction of flash memory with the FAT or VFAT file systems due to massive overwriting of the FAT tables.  The man page for "mount" indicates that FAT and VFAT file systems ignore the "sync" option.  This is not true and easy to prove by simply excercising a USB flash device with and without the sync option set.


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

How reproducible:
Sometimes

Steps to Reproduce:
1.Buy a 1GB USB flash drive
2.Insert and let HAL system mount drive
3.Type "mount" and note "sync" option on drive
4.Copy 700 Meg file to drive
5.Come back 30-60 minutes later
6.Unmount and remove drive
7.Remount and attempt to use drive
8.Depending on make and model, drive is probably destroyed
  

Actual Results:  Drive get hard read errors on first few sectors and is unable to read partition table.  Drive is destroyed due to physical destruction of critical sectors.

Expected Results:  Drive should have been readable.

Additional info:

The sync option should not be used with FAT or VFAT file systems!  It causes unnecessary wear and tear on floppy drives and physical drives (magnetic and optical) and can cause the destruction of flash drives through exceeding the maximum write cycles on the FAT tables.

Ideally, the sync option SHOULD be ignored by FAT or VFAT file systems, but that's another problem I'll take up on the kernel mailing list!
Comment 1 David Zeuthen 2005-05-13 13:11:21 EDT
Do you have some hard data to substantiate this claim? It works for me and
several other users since we've used this mount option for a long time.

It also sounds like you should file a bug against the kernel, not hal.
Comment 2 David Zeuthen 2005-05-13 13:35:32 EDT
Hmm, sorry for closing this so fast, perhaps it would be good to look at the
issue in detail.
Comment 3 David Zeuthen 2005-05-13 13:36:36 EDT
Dave, can you look at this please?

Thanks,
David
Comment 4 David Zeuthen 2005-05-13 15:04:54 EDT
I'm raising the priority to high and adding this bug to the FC4Blocker as we
need to resolve this issue for FC4. It might be that using 'sync' is a
showstopper with recent kernels, it might not. Either way we need to look into
the issue. 
Comment 5 David Zeuthen 2005-05-20 13:19:23 EDT
Alan, my intention is to remove the patch that uses puts 'sync' in for removable
and hotpluggable media < 2GB. Do you concur?
Comment 6 Alan Cox 2005-05-21 14:31:48 EDT
The claim has been discredited on the kernel list comprehensively.  The
suggestion that sync should be ignored was also rejected entirely although some
improvements were suggested.

The real problem I think is that we don't want "synchronous" for such media we
want "soon". The "sync" is wrong for all media types in almost all imaginable
cases. Now vfat honours sync properly (it used to be a no-op) it'll destroy
throughput.

And since it used to be a no-op we know it can be removed 8) Then file a kernel
RFE for a "flush regularly" option 

Alan
Comment 7 David Zeuthen 2005-05-23 11:54:47 EDT
OK, this should be fixed in tomorrows Rawhide.

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