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

[Helge Hafting <helgehaf@aitel.hist.no>]

On Tue, Jul 13, 2004 at 07:25:29AM +0000, Anton Ertl wrote:
> Chris Wedgwood <cw@f00f.org> writes:
> >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.
> 
> A secure FS must ensure that other people's deleted data does not end
> up in the file.  AFAIK FSs don't record owners for free blocks, so
> they can only ensure this by zeroing the blocks.  So I doubt that you
> will see any different behaviour from an FS that keeps only meta-data
> consistent and writes meta-data before data.
> 

There is another solution - zero blocks when freeing them. (Or
put them on a list for later zeroing when the fs isn't busy,
in order to kee��p good performance)

With this approach you don't need to zero a half-written
block after a crash, which means you destroy less data.

Helge Hafting