Re: Mentor for a GSoC application wanted (Online ext2/3 filesystem checker)

[Jamie Lokier <jamie@shareable.org>]

Andi Kleen wrote:
> > Is there a reason why this isn't being done other than performance?
> 
> One reason against it is that in many (but not all) setups to guarantee
> reaching the platter you have to disable the write cache, and at least
> for consumer level hard disks disk vendors generally do not recommend
> doing this because it significantly lowers the MTBF of the disk.

I think the MTBF argument is a bit spurious, because guaranteeing it
reaches the platter with all modern disks is possible, with the
appropriate kernel changes, and does not require the write cache to be
disabled.

TBH, I think the reason is it's simply never been implemented.  There
are other strategies for mitigating data loss, after all, and
filesystem structure is not at risk; barriers are fine for that.

Right now, you have the choice of 'disable write cache' or 'fsync
flushes sometimes but not always, depending on lots of factors'.

The option 'fsync flushes always, write cache enabled' isn't
implemented, though most hardware supports it.

Btw, on Darwin (Mac OS X) it _is_ because of performance that fsync()
doesn't issue a flush to platter.  It has an fcntl(F_FULLSYNC) which
is documented to do the latter.

-- Jamie