what fsck can (and can't) do was Re: [patch] ext2/3: document conditions when reliable operation is possible
- From: david@xxxxxxx
- Date: Thu, 3 Sep 2009 09:56:48 -0700 (PDT)
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-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/
- Follow-Ups:
- Prev by Date: [tip:perfcounters/core] perf_counter: Fix output-sharing error path
- Next by Date: Re: binfmt_flat.c && bprm->cred (Was: [PATCH 0/1] exec: do not sleep in TASK_TRACED under ->cred_guard_mutex)
- Previous by thread: [tip:perfcounters/core] perf_counter: Fix output-sharing error path
- Next by thread: Re: what fsck can (and can't) do was Re: [patch] ext2/3: document conditions when reliable operation is possible
- Index(es):
Relevant Pages
|
