Re: o_sync in vfat driver

[Helge Hafting <helge.hafting@aitel.hist.no>]

col-pepper@piments.com wrote:

> On Mon, 27 Feb 2006 15:41:44 +0100, Anton Altaparmakov 
> <aia21@cam.ac.uk>  wrote:
>
> > On Mon, 2006-02-27 at 15:27 +0100, Arjan van de Ven wrote:
> >
> > > On Mon, 2006-02-27 at 14:06 +0000, Anton Altaparmakov wrote:
> > > > On Mon, 2006-02-27 at 14:50 +0100, Arjan van de Ven wrote:
> > > > > On Mon, 2006-02-27 at 08:28 -0500, Lennart Sorensen wrote:
> > > > > > On Sun, Feb 26, 2006 at 11:50:40PM +0100, 
> > > col-pepper@piments.com  wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > OMG what do I have to do to post here? 10th attempt.
> > > > > > > {part2}
> > > > > > >
> > > > > > > Here is a non-exhaustive list of typical devices types  
> > > requiring fat vfat
> > > > > > > support:
> > > > > > >
> > > > > > > fd ide-hd scsi-hd usb-hd cdrom usb-hd usb-handheld (iPod,  
> > > iRiver etc)
> > > > > > > usb-flash (usbsticks, cameras, some music devices.)
> > > > > > >
> > > > > > > IIRC the sync mount option for vfat is ignored for file 
> > > systems  >2G, this
> > > > > > > effectively (and probably intentionally) excludes nearly all 
> > > hd  partitions
> > > > > > > and iPod type devices.
> > > > > >
> > > > > > I think many people wish it was ignored on smaller devices 
> > > too  given
> > > > > > what it does to write performance.
> > > > >
> > > > > well. If you don't want it *DO NOT USE IT AT THE MOUNT COMMAND  
> > > LINE* !!!
> > > >
> > > > That is easy to say when you are using the command line...  Modern
> > > > distros (as you know I am sure) mount all hot-plug devices like usb
> > > > keys, usb hard disks, etc automatically at plug-in time and at least
> > > > some distros use "-o sync"
> > >
> > > that is a bad misdesign of that distro or at least the tool the distro
> > > uses for this (I don't know which it is so I can say that without
> > > sounding partial :)
> > >
> > > the tool that decides to use "sync", or at least the author thereof,
> > > should be aware of what flash is, and that it has a limited lifespan 
> > > etc
> > > etc, and that you thus want maximum caching etc.
> >
> >
> > I agree completely which is why we hack the system to remove the o_sync
> > on our distro derivative.  (-:
> >
> > But my point was that your solution of "don't do that then" is not much
> > use to your average user who sits in front of such distro in graphical
> > desktop as they are not technical enough to find and hack their hotplug
> > system to work properly...
> >
> > Best regards,
> >
> >         Anton
>
>
> > > If you don't want it *DO NOT USE IT AT THE MOUNT COMMAND LINE* !!!
>
> Yeah, cleaver.
> That is not really a constructive responce. I dont use , I do use 
> command  line mount all the time. I never was in danger of damaging my 
> drive with  this new "feature".
>
> Telling a user who has just burnt out a brand new 1GB usb device he 
> should  have RTFM and modified that HAL configuration to insure it did 
> not use  sync it not likely to win much confidence in the linux kernel.

No problem in the kernel.  The system is set up wrong.  A simple user 
may not be able to
figure out his distro's hotplug setup to fix this - but then this problem is
the fault of _the distro_, not the kernel.  Complain to distributors 
instead.

There is no need for the kernel to treat o_sync VFAT in any special 
way.  The users,
or more likely the distros, can skip that o_sync part.

Not all distros have such problems either. On debian, I had to set up 
/etc/fstab myself -
where not specifying sync is easy enough.

> The point of raising this is that the vast majority of linux users 
> have no  awareness of this. If there is a danger of this sync 
> implementation  damaging hardware it should be done differently.

Which is why people is working on the "sync on close" alternative. 

> More importantly this sync strategy is very likely _increasing_ the 
> danger  of data loss that is the core reason for using sync in the 
> first place.
>
> To quote from my earlier post:
>
> The new model attempts to be more rigourous by updating the FAT every 
> time
> a block of data is written. Thus the "hammering" of the physical memory
> hosting the FAT record.
>
> In view of the nature of flash memory this may actually be drastically
> increasing the chance that the whole FAT gets erased.
>
> If a pullout occurs during write , there is now a near 50% chance that
> this takes out the entire FAT.

No, only one FAT entry.  And the users who pull out during writes 
_really_ get
what they deserve anyway.  You don't need deep linux knowledge for that.
In the day of the floppy, people respected the activity light regardless 
of OS.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/