Re: vfs: Add MS_FLUSHONFSYNC mount flag

[Pavel Machek]

On Thu 2009-02-12 21:23:36, Theodore Tso wrote:
> On Thu, Feb 12, 2009 at 03:30:10PM -0600, Eric Sandeen wrote:
> > >   Yes, but OTOH we should give sysadmin a possibility to enable / disable
> > > it on just some partitions. I don't see a reasonable use for that but people
> > > tend to do strange things ;) and here isn't probably a strong reason to not
> > > allow them.
> > > 
> >
> > But nobody has asked for that, have they?  So why offer it up a this point?
> > 
> > They could use LD_PRELOAD to make fsync a no-op if they really don't
> > care for it, I guess... though that's not easily per-fs either.
> 
> Actually, Bart Samwel at FOSDEM talked to me and asked for something
> similar --- what we came up which meant his request while still being
> standards-compliant was a per-process personality flag which had three
> options:
> 
>      *)  Always honor fsync() calls (the default)
>      *)  Never honor fsync() calls
>      *)  Only honor fsync() calls if a global "honor fsync" flag
>            (which would be manipulated by the laptop mode scripts)
> 	   is set.
> 
> The flag would be reset to the default across a setuid exec, but would
> otherwise be inherited across fork()'s.  It might be possible to
> set/get the flag via a /proc interface.
> 
> The basic idea is that laptop systems where the system administrator
> wants longer battery life (and trusts the battery not to suddenly give
> out) more than they care about fsync() guarantees can set up a pam
> library which sets the flag for at login time so that all of the
> user's processes can be set up not to honor fsync() calls; however,
> all of the system daemons would still function normally.   

Sounds like posix violation to
me... '/sys/fsync_does_not_really_sync'?

Perhaps it is better done at glibc level? Environment variables
already mostly have semantics you want.....

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/