Messages in this thread |  | | | Date | Wed, 14 Jul 2004 00:24:11 +0200 | | Subject | Re: XFS: how to NOT null files on fsck? | | From | Helge Hafting <> |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |