On 11/04/12 11:38, Tim Connors wrote:
On Wed, 11 Apr 2012, James Harper wrote:
The problem with omitting the fsync in the case of an application is that you are violating your contract with the user. If I save a document then when the application says that the save is complete my document had damn well better be on my memory stick.
That is why there is a manual umount, instead of just "unplug and hope". It is not the application's responsibility to attempt to ensure bits hit non- volatile storage.
Users that expect to be able to just unplug a stick and walk away at any time DESERVE to have that expectation violated.
Windows users have that expectation and have that expectation met. When Windows tells me my copy is done, my copy is done and I can yank the memory stick. Yanking it in the middle of the copy will obviously cause a problem but that's not what we're talking about here.
As far as I'm aware, Windows turns off all write caching on all removalable media to achieve this. It doesn't do the equivalent for internal disks, so you end up with interesting corruption when power fails.
So do user-friendly distributions of Linux. Insert a FAT-formatted USB stick into a modern Ubuntu box, and it'll automount it for you, with the "flush" option set. According to the man page: flush If set, the filesystem will try to flush to disk more early than normal. Not set by default. So, they're still trying to meet users' expectations that if a "copy" command has finished, then it means their data has been copied. Which, really, is quite fair. Although it seems the Linux approach is a compromise -- it's not totally synchronous behaviour, so performance is probably OK, but the window for data loss if a user yanks the stick or kills the power is reduced. I don't understand the protestations against fsync though! Anything else is totally unfair. If you say "Your data is saved/copied/whatever!" when it isn't on disk, they *the operating system is lying to the user*. Why would that be OK?? -Toby