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

[Chris Wedgwood <cw@f00f.org>]

On Sat, Jul 10, 2004 at 12:19:14PM -0700, Chris Wedgwood wrote:

> It would be nice for some people to prevent log-replay zeroing files
> but then something would have to be able to determine whether or not
> these blocks were newly allocated (and this might contain
> confidential data and need to be zeroed) or previously part of the
> file in which case we probably would like them left alone.

I told lies.

> I don't know any of the code well enough to know how easy this is or
> even if I'm telling the truth :) Hopefully someone who does can
> speak up on this.

I knew I was completely full of shit.


XFS does *not* zero files, it simply returns zeros for unwritten
extents.  If you open an existing file and scribble all over it, you
might see the old data during a crash, or the new data if it was
flushed.  You shouldn't see zero's though.

What does happen though, is that dotfiles are truncated and rewritten,
if the data blocks aren't flushed you will get zeros back because the
extents were unwritten.  This is really the only sensible thing to do
given the circumstances.

My guess is that with other fs' (when journaling metadata only) the
blocks allocated for the newly written data are *usually* the same as
the recently freed blocks from the truncate so things appear to work
but in reality it's probably mostly luck.  XFS could behave the same
way, but sooner or later you will still loose when you get crap back
instead of old data.

Some applications just need to be fixed.


   --cw