On Sat, 29 Aug 2009, Rob Landley wrote:
On Saturday 29 August 2009 05:05:58 Pavel Machek wrote:
On Fri 2009-08-28 07:49:38, david@xxxxxxx wrote:
On Thu, 27 Aug 2009, Rob Landley wrote:
Pavel's response was to attempt to document this. Not that journaling
is _bad_, but that it doesn't protect against this class of problem.
I don't think anyone is disagreeing with the statement that journaling
doesn't protect against this class of problems, but Pavel's statements
didn't say that. he stated that ext3 is more dangerous than ext2.
Well, if you use 'common' fsck policy, ext3 _is_ more dangerous.
The filesystem itself isn't more dangerous, but it may provide a false sense of
security when used on storage devices it wasn't designed for.
from this discussin (and the similar discussion on lwn.net) there appears
to be confusion/disagreement over what fsck does and what the results of
not running it are.
it has been stated here that fsck cannot fix broken data, all it tries to
do is to clean up metadata, but it would probably help to get a clear
statement of what exactly that means.
I know that it:
finds entries that don't actually have data and deletes them
finds entries where multiple files share data blocks and duplicates the
(bad for one file) data to seperate them
finds blocks that have been orphaned (allocated, but no directory pointer
to them) and creates entries in lost+found
but if a fsck does not get run on a filesystem that has been damaged, what
additional damage can be done?
can it overwrite data that could have been saved?
can it cause new files that are created (or new data written to existing,
but uncorrupted files) to be lost?
or is it just a matter of not knowing about existing corruption?
David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
