Re: synchronous mounts

[Jeff Garzik]

"Stephen C. Tweedie" wrote:
> It's not clear to me that chattr/mount sync options make _any_ sense
> for regular file metadata.  Rather than tightening up the semantics,
> I'd actually prefer to restrict them so that they only apply to
> directories.  Users who set the sync bits are usually doing so for
> applications like MTAs where it's directory syncing which is
> what matters: the apps typically fsync the files themselves, anyway.

I don't think it is correct to make that assumption.

When working on something likely to crash, I always remount my
filesystems 'sync' with the intention to have the kernel immediately
sync to disk anything and everything it is coded to do.  Since the
kernel is responsible to flushing data to disk, it makes perfect sense
to have an option to sync not only metadata but data to disk
immediately, if the user desires such.

Further, expecting all apps to fsync(2) files under the right
circumstances is not reasonable.  There are "normal" circumstances where
someone expects non-syncing behavior of "cat foo bar > foobar", and then
there are extentuating circumstances where another expects the shell to
sync that command immediately.  Should we rewrite cat/bash/apps to all
fsync, depending on an option?  Should we expect people to modify all
their shell scripts to include "/bin/sync" for those times when they
want data-sync?  Such is not scalable at all.

It would make more sense to me to implement 'sync' as sync-everything,
and add 'dirsync' or 'metasync' for syncing only directories or only
metadata.

As it stands, it seems like redefining 'sync' to sync less data than is
currently done is not only changing current behavior, but providing less
to users overall.

	Jeff

-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno