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

Helge Hafting
2004-07-13T22:27:20Z

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