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 _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
