Re: dynamic inode allocation

["Mag Gam" <magawake gmail com>]

Thanks!

This has cured my curiosity (for now...)


On Mon, Sep 1, 2008 at 5:23 PM, Theodore Tso <tytso mit edu> wrote:
> On Mon, Sep 01, 2008 at 05:16:01PM -0400, Mag Gam wrote:
>> > If the filesystem is sufficiently damaged such that portions of the
>> > b-tree can't be found, then yes.  Otherwise, the data would be totally
>> > lost.  As you can imagine, scaning every single block on the disk to
>> > see if it looks like filesystem metadata is quite slow, so naturally
>> > the reiserfs's fsck will avoid doing it if at all possible.  But if
>> > the root or top-level nodes of the B-tree is damaged, it doesn't have
>> > much choice.
>> >
>>
>> But, if thats the last and worst case scenario why don't they do the
>> full scan? Sure its going to take a long time if its a big filesystem
>> (there should be no changes since it would be unmounted), but its
>> better than not having any data at all...
>
> As I said, in the worst case, it will do a full scan.  But (a) it
> takes a long time, and (b) if the filesystem has any files that
> contain images of reiserfs filesystem, it will be totally scrambled.
> So it makes sense that the reiserfs fsck would try to avoid this if it
> can (i.e., if the b-tree is only mildly corrupted).
>
> With that said, this is really going out of scope of this mailing
> list.  And I am not an expert on reiserfs's filesystem checker,
> although I have had people confirm to me that indeed, you can lose
> really big if your reiserfs filesystem contains files that have are
> images of other reiserfs filesystems for things like Virtualization.
> This problem is apparently solved in reiser4, it is NOT solved in
> reiserfs (i.e., version 3).  As far as I am concerned, that's ample
> reason not to use reiserfs, but obviously I'm basied.  :-)
>
>                                                - Ted
>
>
>