| title: | Re e2fsck running for hours printing out li |
|
On Thu, Apr 07, 2005 at 11:51:23PM -0400, Allen Ziegenfus wrote:
I am also happy to report that e2fsck has progressed from its number
counting stage and moved on to telling me which files have duplicate
blocks and fixing these. Im still curious if Ill be left with anything
usable.
Im pretty sure what happened to you is that your inode table got
seriously corrupted. Very likely, one or more blocks in the inode
table got written to the wrong location on disk. As a result, a large
number of blocks are claimed by more than one inodes. This triggers
the "pass1b" processing, which tries to deal with this situation.
Unfortunately, the Pass 1b processing code in older versions of
e2fsprogs (1.27 an earlier, such as found in Debian stable) has
several O(n**2) algorithms, as this code was originally designed to
deal with a relatively small number of blocks claimed by multipled
inodes, normally caused by an corrupted block allocation bitmap.
In the case where there are a large number of blocks, typically caused
by hardware failures where disk blocks end up in the wrong location on
disk, the O(n**2) operations mean that e2fsck will take a L-O-N-G time
to complete. More modern e2fsprogs dont have this problem, but given
that you mentioned you were waiting for sarge to be released, Im
guessing you might be running Debian stable, with an old enough
version of e2fsprogs that it would have this problem.
Note that when there is this much damage to the filesystem, the
likelihood that you will suffer severe dataloss is quite large, and
quite real.
- Ted
_______________________________________________
Ext3-users@xxxxxxxxxx
www.redhat.com/mailman/listinfo/ext3-users www.redhat.com/mailman/listinfo/ext3-users
|
