Messages in this thread | | | Date | Mon, 12 Jul 2004 14:20:20 -0700 | From | Chris Wedgwood <> | Subject | Re: XFS: how to NOT null files on fsck? |
| |
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 - 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/
| |