0byte files after crash

[Dmitri Nikulin]

On Fri, Mar 20, 2009 at 11:26 AM, Samuel J. Greear <sjg at evilcode.net> wrote:
> Better might be to work toward fixing the applications. ee has bitten
> me a number of times on crash after editing a config file.
>
> One option for ffs might be to have it optimistically flush when load
> is low; but to be honest I think fixing the applications is much more
> important.

I agree, but if it is practical to implement behaviour similar to
ext3's "data=ordered" for UFS soft updates, then that is certainly a
good measure.

The issue with fixing applications is that a user has no idea which
ones are fixed without reading the code themselves. It's not bad to
have a system-wide hack that's almost as good as a per-application
solution. Then when all applications that want the more robust
semantics fix their code, people can more confidently turn off the
heavyweight ordering mode.

The problem many people have with ext3 fsync arises because they have
huge partitions that store everything, and therefore have to wait for
potentially everything when doing an fsync even on a tiny config file.
I for one run dozens of very small (per purpose) partitions on LVM, so
fsync, data=ordered and even the occasional data=journal do not really
impact my performance, because at most I'm only syncing the other
changes to that same partition. I am also much more resistant to write
cache crash when I do run with write cache. This is very similar to
the BSD philosophy of having separate partitions where possible,
though in LVM the limit is much higher. This has its benefits besides
just minimising the cost of poorly written applications, but it does
take far more management effort than one big partition.

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia