Bug 157674

Summary:	sync option on VFAT mount destroys flash drives
Product:	[Fedora] Fedora	Reporter:	Michael H. Warfield <mhw>
Component:	hal	Assignee:	David Zeuthen <davidz>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	rawhide	CC:	abo, alan, davej, d.bz-redhat, mclasen
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	0.5.2-2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-05-23 15:54:47 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:
Bug Depends On:
Bug Blocks:	136450

Description Michael H. Warfield 2005-05-13 16:59:55 UTC

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 17:11:21 UTC

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 17:35:32 UTC

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 17:36:36 UTC

Dave, can you look at this please?

Thanks,
David

Comment 4 David Zeuthen 2005-05-13 19:04:54 UTC

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 17:19:23 UTC

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 18:31:48 UTC

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 15:54:47 UTC

OK, this should be fixed in tomorrows Rawhide.