dynamic inode allocation
tytso at mit.edu
Mon Sep 1 21:23:04 UTC 2008
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. :-)
More information about the Ext3-users