I have a partition using ReiserFS and have unfortunately found the need of running reiserfsck --rebuild-tree. I ran --check first and was given that message. I've done this once before (under different circumstances on different hardware) and I seem to recall the entire process taking a couple hours.

Well, reiserfsck has been running, as of this posting, for 29 hours and is not done. Is this normal?

The driver is 250GB and has about 188GB of data on it, which I realize is rather large and may be the entire issue. If so, that's fine. I just wasn't expecting it and so thought I would ask.

Other relevant specs: AMD XP 2600+ (overclocked to 2.1GHz), 1 Gig Corsair XMS memory. Seagate 250GB.

do you have really important/vital information there? I have experienced that issuing a reiserfsck --rebuild-tree command destroys almost everything and yes, it takes too much time.
If your data in that partition is not that important and you don't mind to lose it all, better re-format it.
Remember that when dealing with partitions, your whole disk data is at risk.

I don't remember it taking that long (maybe 4-5 hours?), but also was running it on smaller harddrives. Reiserfsck has always worked for recovering my files, but lost a lot of filenames (same with any other file recovery software, btw).

The file names were the biggest part of the loss. Many directories were still in tact and just required someone to verify the contents and rename them (I found Nautilus from the Dropline Gnome team w/ its ability to detect file types automatically very useful). It will take time :-)

All the data is backed up. It is, for the most part, important data, which is why it is backed up.

I would have re-formatted anyway and restored from backup, if I had known the process was going to take this long, but as I said I've done this before with no issues and far less time involved, less time than it would take to rebuild the drive from backups anyway.

The --rebuild-tree option doesn't destroy anything itself if it completes properly. If it can't fix the problem, then the data is lost, but it was lost anyway. The problem was only with one file, but I wanted to fix the inconsistency rather than deal with the "bin/ls permission denied (filename)" every time I did an ls on that directory. Never good to have a borked tree.

What --rebuild-tree would have done/will do with that one file is store the data it finds in lost+found with basically a gibberish filename. Since I know what the filename is, that's no problem. If it had been dozens or hundreds of files, it would have been more of a problem.

I'm hoping that is the issue. I assume it is, but I wanted to get input. My memories of DOS based apps back in the dark ages was that if something took anywhere near this long, it was caught in a loop and basically destroying everything it touched as efficiently as possible.

Until a year ago, I never owned a hard drive larger than 40Gigs. Now I have about a terrabyte of storage in my system total across four drives, and I have little in the way of personal reference for how long things take. This happened to be the largest partition with a lot of large files, so I guess it was fate. :-)

What happened, in case anyone is interested, is that I was using PAN to download an .ISO from Usenet. It was separated into 10 meg parts. As one of those parts was decoding, PAN got "stuck" decoding it. (Not sure yet whether this was a bug in PAN or a physical defect on the part of the hard drive it was accessing.) PAN itself was still running, but the process that was decoding the file wouldn't finish and close the file. Neither could I kill it, either with signal 15 or 9. I eventually had to take the radical option of forcing an umount so I could reboot. That borked the tree, which I assumed would happen.

Anyway, thanks for the input.

I'd keep an eye on smartd and the BIOS S.M.A.R.T. for the next few days. Last time something like that happened to me it was the harddrive going out. The drive would go from being mounted read-write to being read-only in the middle of a copy command, which confused programs and kernel alike. Hope that isn't the problem :-)

Me too, but thanks for the info. I'll definitely keep an eye on it. PAN had never done that to me before, so I am suspicious anyway of the drive, and the fact I couldn't kill the process was very disturbing. I've had to throw a signal 9 at a few things before, but had never had that fail.

And I was wrong before. This was my Western Digital drive, which is 300 GB and was about 77% full. I forgot I'd swapped it some time ago with the Seagate I mentioned, making the Seagate my /home drive.

But anyway, I got home today, and all seems well. I can't manually check the integrity of all the data with anything like efficiency, but with several random spot checks, all of it seemed good. It rebuilt everything and even restored the filenames properly, which I didn't think would happen. It officially took 31 hours, 57 minutes, 29 seconds to complete.

I've always found that it's very important to first check your drive for damage before attempting to use something like Reiserfsck in one of its lower level repair modes. Most drive manufacturers have drive fitness tests that can be downloaded and burnt to a cdrom or dd'd to a floppy disk.

I recently had an overheating issue on one of my main PCs. The thermal compound on the CPU heatsink had started to dry out. After a few nasty system hangups, I ran Reiserfsck on one of my Seagate Barracudas, and it successfully repaired the data. It did, however, take at least an hour or two to perform this test on the 160 GB drive. 32 hours seems excessive, but I suppose that it could be dependent upon the nature of the damage to the filesystem.

On previous occasions, Reiserfsck has failed on some of my older drives, but those were IBM Desktars and were exhibiting some of the notorious failures that have plagued most Deskstar owners. Thus, this is the reason to check the drive for damage before attempting to repair the filesystem. Reiserfsck will most certainly fail if it is, often causing irreparable damage to even some of the previously usable data.