dynamic inode allocation
Mag Gam
magawake at gmail.com
Mon Sep 1 21:47:26 UTC 2008
Thanks!
This has cured my curiosity (for now...)
On Mon, Sep 1, 2008 at 5:23 PM, Theodore Tso <tytso at 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
>
>
>
More information about the Ext3-users
mailing list