lkml.org 
[lkml]   [2009]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectwhat fsck can (and can't) do was Re: [patch] ext2/3: document conditions when reliable operation is possible
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@lang.hm 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



\
 
 \ /
  Last update: 2009-09-03 19:01    [W:0.231 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site