Short description:
reiserfsck --rebuild-tree hangs for over 24 hours while attempting to
repair my filesystem. This happens no matter how many times I run
reiserfsck v3.6.19
Environment:
linux 2.6.10 (debian)
reiserfsck v3.6.19
resize_reiserfs v3.6.19
LVM (v2.6 style)
long description:
I had 3 200GB drives joined together into a single partition via LVM,
with reiserfs on top of that. At the time I was using kernel 2.6.8.1.
Timeline:
First day
-----
* one drive in the LVM began giving me bad sector errors
* bought a new drive to replace it that was 3GB smaller
* attempted to resize the reiser fs, which failed due to bad sectors
* bought a different new drive, used LVM (pvmove) to move the data from the
failing drive to the new one
* verified the disk I took out was bad, got an RMA and shipped it back
* ran reiserfsck, which completed and gave me the "use --rebuild-tree
option" * ran reiserfsck with rebuild-tree, got bad sector errors from
another drive (I've since decided my problem was overheating).
A few days later (and then some)
-----
* got another drive to replace the second failing drive, used LVM (pvmove)
to copy the data from the failing drive to the new one
* ran reiserfsck --rebuild-tree
* about 45% of the way through pass 2, reiserfsck hangs. Random samples
show it using between 40 and 70% of processor time, giving me the
impression it's not really hung (I expect a program that's actually hung to
use either 0% of 100% cpu time). So I left it for about 6 hours, stopped it
and tried again. This time I tried it with the -S switch and it hung, but
in a different spot. At that point I upgraded to linux 2.6.10. I tried it
again and left it for 12 hours before I had to reboot (to take the bad
drive out). I ran it a fourth time, added the -z option, and waited a full
24 hours, after which I've come to the conclusion that it really is hung.
I've attached the logfile from the last run. If you need any more
information or need me to run tests, please let me know. I can send you any
portion of the disk that you need (the data on it is not particularly
sensitive) but of course it's hard to send the full 600GB worth of raw data
:)
Thank you very much for any help you can provide.
