From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
To: linux-kernel@vger.kernel.org
Cc: Chris Wedgwood <cw@f00f.org>, Jan Knutar <jk-lkml@sci.fi>,
L A Walsh <lkml@tlinx.org>
Subject: Re: XFS: how to NOT null files on fsck?
Date: Tue, 13 Jul 2004 07:25:29 GMT [thread overview]
Message-ID: <2004Jul13.092529@mips.complang.tuwien.ac.at> (raw)
In-Reply-To: <2hgxc-5x9-9@gated-at.bofh.it>
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.
>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@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
next prev parent reply other threads:[~2004-07-13 8:02 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-05 5:47 XFS: how to NOT null files on fsck? Norberto Bensa
2004-07-09 16:37 ` L A Walsh
2004-07-09 21:59 ` Chris Wedgwood
2004-07-10 18:33 ` L A Walsh
2004-07-10 18:43 ` Chris Wedgwood
2004-07-10 21:24 ` Bernd Eckenfels
2004-07-11 21:54 ` Helge Hafting
2004-07-12 17:56 ` H. Peter Anvin
2004-07-12 19:59 ` Chris Wedgwood
2004-07-12 20:32 ` H. Peter Anvin
2004-07-12 22:29 ` Bernd Eckenfels
2004-07-12 23:03 ` Bernd Eckenfels
2004-07-12 23:14 ` Chris Wedgwood
2004-07-10 18:43 ` Jan Knutar
2004-07-10 18:46 ` Chris Wedgwood
2004-07-10 18:55 ` Norberto Bensa
2004-07-10 19:19 ` Chris Wedgwood
2004-07-12 21:20 ` Chris Wedgwood
2004-07-12 22:40 ` L A Walsh
2004-07-12 22:53 ` Chris Wedgwood
2004-07-13 1:44 ` Bernd Eckenfels
2004-07-13 5:24 ` Chris Wedgwood
[not found] ` <2hgxc-5x9-9@gated-at.bofh.it>
2004-07-13 7:25 ` Anton Ertl [this message]
2004-07-13 8:09 ` Chris Wedgwood
2004-07-13 9:34 ` Anton Ertl
2004-07-13 9:53 ` Chris Wedgwood
2004-07-13 10:27 ` Tim Connors
2004-07-13 10:38 ` ismail dönmez
2004-07-13 11:16 ` Nick Piggin
2004-07-13 12:52 ` ismail dönmez
2004-07-13 10:58 ` Chris Wedgwood
2004-07-13 13:33 ` Anton Ertl
2004-07-13 20:32 ` Chris Wedgwood
2004-07-13 22:42 ` Bernd Eckenfels
2004-07-14 18:49 ` Anton Ertl
2004-07-14 19:00 ` Chris Wedgwood
2004-07-13 22:24 ` Helge Hafting
2004-07-13 22:39 ` Chris Wedgwood
2004-07-13 23:23 ` Bernd Eckenfels
2004-07-14 18:53 ` Anton Ertl
2004-07-10 19:33 ` Andreas Schwab
2004-07-10 19:40 ` Chris Wedgwood
2004-07-10 19:46 ` Norberto Bensa
2004-07-10 20:03 ` Chris Wedgwood
2004-07-11 1:21 ` Gopikrishnan Sidhardhan
2004-07-29 1:30 ` Nathan Scott
2004-08-03 18:31 ` L A Walsh
2004-08-04 0:48 ` Andi Kleen
2004-08-04 6:37 ` L A Walsh
2004-08-05 8:16 ` Helge Hafting
2004-08-06 1:10 ` Nathan Scott
2004-08-06 1:34 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2004Jul13.092529@mips.complang.tuwien.ac.at \
--to=anton@mips.complang.tuwien.ac.at \
--cc=cw@f00f.org \
--cc=jk-lkml@sci.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@tlinx.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.