linux-kernel - Re: vfs: Add MS_FLUSHONFSYNC mount flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090222141532.GC1586@ucw.cz>
Date:	Sun, 22 Feb 2009 15:15:33 +0100
From:	Pavel Machek <pavel@....cz>
To:	Theodore Tso <tytso@....edu>, Eric Sandeen <sandeen@...hat.com>,
	Jan Kara <jack@...e.cz>,
	Fernando Luis V?zquez Cao <fernando@....ntt.co.jp>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/