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. I'm still curious if I'll be left with anything > usable. I'm 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 don't have this problem, but given that you mentioned you were waiting for sarge to be released, I'm 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 https://www.redhat.com/mailman/listinfo/ext3-users
