[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <14586.1306781002@turing-police.cc.vt.edu>
Date: Mon, 30 May 2011 14:43:22 -0400
From: Valdis.Kletnieks@...edu
To: "D. Jansen" <d.g.jansen@...glemail.com>
Cc: david@...g.hm, Theodore Tso <tytso@....edu>,
Oliver Neukum <oneukum@...e.de>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, Dave Chinner <david@...morbit.com>,
njs@...ox.com, bart@...wel.tk
Subject: Re: [rfc] Ignore Fsync Calls in Laptop_Mode
On Mon, 30 May 2011 20:28:24 +0200, "D. Jansen" said:
> I'm not really sure I why shouldn't have that choice as a user. Just
> because someone else could be running a mailserver on his system and
> configure it in a way that it doesn't behave as it should?
It cuts both ways. If a piece of software really wants to be sure that the
fsync() semantics it's expecting are actually adhered to and refuses to run
otherwise, how does it tell that you're lying to it?
> The big problem is that so far only fsync existed and lots of software
> seemingly abuses it as an expensive write barrier. And it would really
> be lovely to have the choice to stop that on an opt-in basis in laptop
> mode.
It's not "seemingly abuses it". That's the existing userspace API for
inserting a barrier. The problem is that as defined, it will wait for the
writeback to actually finish - which is actually as good as you can get without
getting into the async I/O support. If there was a "insert barrier and return"
API, how would it report back that the barrier had failed with EIO after it had
already returned to userspace?
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists