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

[Sitsofe Wheeler <sitsofe@yahoo.com>]

On Fri, Apr 03, 2009 at 12:54:14AM -0400, Theodore Tso wrote:
> On Fri, Apr 03, 2009 at 02:36:03AM +0100, Matthew Garrett wrote:
> > 
> > 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

I no longer know what is being debated here. Is it one or more of the
following:

a) Laptop mode (as it stands today).
b) Laptop mode with fsync-nop.
c) Apps that should be using fsync.
d) Apps that should not using fsync.
e) Apps writing to the disk too frequently.
f) Apps writing to many files to the disk.
g) Userland constraining kernel changes.
h) Increasing battery life.
i) "Acceptable" chance of new data loss after a crash.
j) "Acceptable" chance of data corruption after a crash.
k) Support for a new filesystem barrier() syscall to indicate the order
that data has to be written.

Note some of the above points are in conflict with each other...

> 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

Isn't this the problem that other systems that place a high value on
backwards compatibly face that the Linux kernel was not supposed to? If
some piece of userland depends on every last bit of behaviour (whether
it was intended/promised or not) then the only way anything can be
changed is with massive effort expended on shims...

-- 
Sitsofe | http://sucs.org/~sits/