[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090213022336.GH6922@mini-me.lan>
Date: Thu, 12 Feb 2009 21:23:36 -0500
From: Theodore Tso <tytso@....edu>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Jan Kara <jack@...e.cz>,
Fernando Luis Vázquez Cao
<fernando@....ntt.co.jp>, Alan Cox <alan@...rguk.ukuu.org.uk>,
Pavel Machek <pavel@...e.cz>,
kernel list <linux-kernel@...r.kernel.org>,
Jens Axboe <jens.axboe@...cle.com>, fernando@....ac.jp,
Ric Wheeler <rwheeler@...hat.com>
Subject: Re: vfs: Add MS_FLUSHONFSYNC mount flag
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.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists