Message-ID: <BANLkTinTzNN2P45tgZAQ9FsL43CqyAJR3Q@mail.gmail.com>
Date:	Thu, 26 May 2011 18:05:43 +0200
From:	"D. Jansen" <d.g.jansen@...glemail.com>
To:	"Ted Ts'o" <tytso@....edu>,
	"D. Jansen" <d.g.jansen@...glemail.com>,
	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, jens.axboe@...cle.com
Subject: Re: [rfc] Ignore Fsync Calls in Laptop_Mode

Problem: any fsync call by any application spins up the hard disk any
time even in laptop_mode

On Thu, May 26, 2011 at 3:31 PM, Ted Ts'o <tytso@....edu> wrote:
> 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".

I'm not sure this approach is straight forward.

Because though there is no possibility to destroy data that is on disk
due to non FIFO flushing of application writes queued in the kernel,
which seems to be the main kernel level problem, yet new problems come
up.

Now there is
1) special support needed on the application side.
2) need for new out-of-kernel buffers.
3) need for inter-application write alignment nightmares. This sort of
structure could cause very uncomfortable bugs that prevent writes from
happening at all in cases that were not foreseen at all.
4) need for resources wasted through yet another daemon.
5) If the _application_, but not the kernel crashes, the data is safe.
In my experience this is the much more likely case than that the mail
server on my netbook optimized for battery time receives an email in
laptop mode, sends the other server "200" and then before the next
commit window my battery slips out and it's all gone.
6) _If_ there would be a special daemon I think it would make sense
for that daemon to provide all the infrastructure, buffering and
manage the fsync calls itself. This shouldn't and wouldn't be
replicated by every single application.

I think the alternative of ensuring the application writes are
committed in order would make more sense:
e..g a _user space library_ disables fsync etc. in laptop_mode if the
user chooses to do so and kernel support for forced FIFO ordering or
writes.
This would fix 1) 2) 3) 4) 5) 6).

Cheers,

Dennis

ps.
So you've re-thought this "All that is necessary is a kernel patch to
allow laptop_mode to disable fsync() calls(...)"
(http://tytso.livejournal.com/2009/03/15/). That post had inspired my
patch.
pps.
I know that an email getting lost is everyone's nightmare. But these
things do happen, anyway. It's not the end of the world if one email
is lost. (There's still a copy in the sent box. People will probably
notice, eventually. I recently found out an email properly sent and
filed in my gmail sent box never arrived for several of the people
without any error reports. If people need to be 100% sure an email
arrived they should ask for a confirmation and/or use a different
medium.) This just makes it much more likely.
--
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