Re: XFS: how to NOT null files on fsck?

[Chris Wedgwood <cw@f00f.org>]

On Tue, Jul 13, 2004 at 11:34:54AM +0200, Anton Ertl wrote:

> It would be the former owner of the block.

there might not be a former owner (in most cases there probably isn't)

> Stale data yes, but probably not stale data from blocks that were
> formerly free (or the file system is insecure).

some, like reiserfs apparently do (or did, it may be different now, if
not used reiserfs for a long time)

> So, how do you tell?

code inspection and/or testing

> Where is data not critical?

that depends on the person and situation, for me personally lots of my
data isn't critical.  certainly it's annoying to loose data but
probably not life threatening

> I had such a problem even with a widely-used application like GNU
> Emacs (many years ago, may be fixed now), casting doubt on your
> claim that fixing the application is easy.

emacs will usually rename the old file so at the very least you have
that

i've had emacs crash and whilst it's frustrating, it certainly isn't
as bad as loosing an email (which may or may not be important, i'll
decide that after i read it)

> ext3 data=ordered will probably also work better in most cases than an
> FS with eager meta-data updates (like, apparently, XFS), but I don't
> think it guarantees in-order semantics.

i thought that was the point of it?  as best as i can tell the
metadata changes will become visible after the data has updated

however, in the case of something like kde/emacs/whatever you can
*still* loose data

consider something like:

	open with truncate
	crash

or more likely:

	open with truncate
	write some data
	crash

there is also an even more common case than either of these:

        open with truncate
	write data, get -ENOSPC
	spplication terminates/aborts

at which point you've stomped on your file.  it's non uncommong for
KDE to do this (even though the window would apparently be very small)



  --cw