Re: Ext4 and the "30 second window of death"

[Theodore Tso]

On Fri, Apr 03, 2009 at 02:36:03AM +0100, Matthew Garrett wrote:
> > if spinning down a drive saves so little power that it wouldn't make a 
> > significant difference to battery lift to leave it on, why does anyone 
> > bother to spin the drive down?
> 
> There's various circumstances in which it's beneficial. The difference 
> between an optimal algorithm for typical use and an optimal algorithm 
> for typical use where there's an fsync() every 5 minutes isn't actually 
> that great.

More to the point, if an application is insane enough to push 2.5
megabytes to disk every single time you click on a web page (this is
excluding the cache; I had my firefox cache pointed at /tmp when I did
this measurement), *and* you are running the WiFi for the browser,
*and* the browser is running flash applications, etc., whether you
defer the writes or not, you're going to be burning a lot of power.
Fundamentally, if an application needs to be writing hundreds of files
or hundreds of kilibytes or more of data all the time, there's
something wrong with the application.

If some KDE applications needs to rewrite hundreds of files at desktop
startup, when the user hasn't even changed any configuration options
yet (this is that desktop **startup**, mind you, where this was
reported), then you're going to burning a lot of power.  Anything we
do at the filesystem level is really going to be at the margins.

The annoying thing is the applications programmers aren't willing to
fix their d*mn applications, and instead heap all of the blame on the
filesystem.  I will be the first to admit that filesystem designers
have to do their part, and once I realized how bad and sloppy people
had gotten with fsync(), and needlessly rewriting files, I implemented
the ext4 workaround patches *first*.  I only started talking about how
application programmers might make changes to obey the established
standards and work with other filesystems after I had put my own house
in order.  These are system-wide problems we are talking about, that
will require system-wide solutions.  I can provide workarounds for
existing application behaviours, but claiming that applications can
never change, and we must always accomodate the way applications are
currently working and are designed is going to be a losing strategy
for us all.

    	       	  	      	   - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/