Messages in this thread | | | Date | Thu, 26 May 2011 09:31:55 -0400 | From | Ted Ts'o <> | 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
| |