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

[Anton Ertl]

Chris Wedgwood <cw@xxxxxxxx> 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.

>Some applications just need to be fixed.

It's too hard to fix the applications, since there is no easy way to
test that they are really fixed.  Also, the number of applications is
much higher than the number of file systems.

The way to go is to fix the file system (well, often it means a new
FS).

The file system should provide something that I call in-order
semantics, i.e., that the disk state always represents an existing
(possibly old) logical state of the FS, not some state that never
existed, or some existing state with missing data.

My favourite approach to achieve these semantics is based on
log-structured file systems (see
<http://www.complang.tuwien.ac.at/anton/lfs/> for some ideas and also
a longer description of in-order semantics), but there are also other
approaches: I believe that Soft Updates, when implemented correctly,
provide in-order semantics, and Reiser4 may provide them, too.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@xxxxxxxxxxxxxxxxxxxxxxxxxx Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/