Re: Linux 2.6.29

Matthew Garrett
2009-03-26T02:11:24Z

On Wed, Mar 25, 2009 at 05:50:16PM -0400, Theodore Tso wrote:

> To be fair, though, one problem which Matthew Garrett has pointed out
> is that if lots of applications issue fsync(), it will have the
> tendency to wake up the hard drive a lot, and do a real number on
> power utilization. I believe the right solution for this is an
> extension to laptop mode which synchronizes the filesystem at a clean
> point, and then which suppresses fsync()'s until the hard drive wakes
> up, at which point it should flush all dirty data to the drive, and
> then freezes writes to the disk again. Presumably that should be OK,
> because who are using laptop mode are inherently trading off a certain
> amount of safety for power savings; but then other people who want to
> run a mysql server on a laptop get cranky, and then if we start
> implementing ways that applications can exempt themselves from the
> fsync() suppression, the complexity level starts rising.

I disagree with this approach. If fsync() means anything other than "Get
my data on disk and then return" then we're breaking guarantees to
applications. The problem is that you're insisting that the only way
applications can ensure that their requests occur in order is to use
fsync(), which will achieve that but also provides guarantees above and
beyond what the majority of applications want.

I've done some benchmarking now and I'm actually fairly happy with the
behaviour of ext4 now - it seems that the real world impact of doing the
block allocation at rename time isn't that significant, and if that's
the only practical way to ensure ordering guarantees in ext4 then fine.
But given that, I don't think there's any reason to try to convince
application authors to use fsync() more.

--
Matthew Garrett | mjg59@srcf.ucam.org