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!
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.
Hmm, sorry for closing this so fast, perhaps it would be good to look at the issue in detail.
Dave, can you look at this please? Thanks, David
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.
Alan, my intention is to remove the patch that uses puts 'sync' in for removable and hotpluggable media < 2GB. Do you concur?
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
OK, this should be fixed in tomorrows Rawhide.