linux-kernel - Re: [rfc] Ignore Fsync Calls in Laptop

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110526133155.GH9520@thunk.org>
Date:	Thu, 26 May 2011 09:31:55 -0400
From:	Ted Ts'o <tytso@....edu>
To:	"D. Jansen" <d.g.jansen@...glemail.com>
Cc:	Oliver Neukum <oneukum@...e.de>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, Dave Chinner <david@...morbit.com>
Subject: Re: [rfc] Ignore Fsync Calls in Laptop_Mode

On Thu, May 26, 2011 at 01:16:45PM +0200, D. Jansen wrote:
> 
> exactly. so what now?

This needs to be solved at the application level.  So what we need is
a coordinating daemon which sends a message to all applications
saying, "ok, here's an opportunity to flush data to the disk; if you
have dirty files, or databases that has data that needs to be flushed,
send it now", and then a little while later, it sends a message to all
applications, "ok, we're going to let the disk spin down now, hold
your horses and don't send any data to the disk".

If an application has too much data buffered in memory, and either
because (a) it's getting nervous that it doesn't want to lose a huge
amount of critical user data, or (b) it's about to exit, so it really
needs to save its state to disk, or (c) the buffered data is taking up
too much space, so it needs to flush its in-memory buffers, then the
application sends a message to the coordinating daemon, saying,
"please give me permission to write", and then waits for the "ok, you
can write to the disk" message.

That way, if you have multiple database-using applications active on
the system at the same time, they can coordinate their access to the
disk, and in a way such that when they stop writing, the data left in
the application-level database is in a coherent state.

The kernel can't do this by arbitrarily stopping writes from going to
the disk because the kernel doesn't know --- and can't possibly know
--- when it is a safe time to cut off write access to the disk.  It
can try and guess, by stopping write access after an fsync(), but it
has to honor the fsync().  Consider what happens when an SMTP server
sends back a 200 OK message --- that gives permission for its opposite
number at the other end of the connection to delete the e-mail
message, since the local SMTP server has promised that the e-mail has
been saved to stable storage.  It can't make that promise if fsync()
has been rigged to lie.  

That's why at the end of the day, in order for application level data
coherency, the application has to be in control.  If you want to save
power by coordinating access to the disk, that coordination has to
happen at the application level.

						- 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/