Re: reiserfsck --rebuild-tree all-in-one problem.

[Vitaly Fertman <vitaly@namesys.com>]

On Sunday 02 February 2003 21:33, Brian Chu wrote:
> Hello.
>
>     Last friday when I went to upgrade my server, I noticed that there had
> been a lot of kernel messages on my server that were saying that one
> partition was spewing this:
>
> Jan  5 13:48:14 simmy kernel: hde: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Jan  5 13:48:14 simmy kernel: hde: dma_intr: error=0x40 {
> UncorrectableError }, LBAsect=91887, high=0, low=91887, sector=91824
> Jan  5 13:48:14 simmy kernel: end_request: I/O error, dev 21:01 (hde),
> sector 91824
> Jan  5 13:48:14 simmy kernel: vs-13070: reiserfs_read_inode2: i/o failure
> occurred trying to find stat data of [7495 7710 0x0 SD]
>
>     I gave up that night, because running dd once took 7 hours and
> reiserfsck twice took 2 hours each, so the whole day was wasted.  I had
> read on the first time I ran --rebuild-tree that a "dd_rescue" was
> suggested, so I downloaded it, installed it, and ran it again (since I had
> used just plain dd the first time). I'm not sure if that made a difference
> or not.

Right, dd seems to produce an output with just skipped bad blocks not writing 
anything into the output.

>     Today I started again, assuming that with dd_rescue, I would have a
> greater chance of getting the filesystem recovered, but --check told me I
> had to run --rebuild-tree, and this time I just did --logfile /dev/null,
> because screen dumps during the run would make it impossible to see what's
> going on. But again, it stopped again at the same place- Pass 2. Since the
> logfiles spit so much STUFF out, I have none at the moment (I can remake
> them if needed).
>
> Screen dump:
>
> Pass 2:
> 0%....20%....40%..                                              left 36, 0
> /sec
>
>     And it stops there. top indicates reiserfsck is using all of the cpu
> cycles, even after it seemingly freezes.

Looks like you built the reiserfsck on another mashine. Could you rebuild it 
on the same mashine you run it. It is possible to suppress the logfile with 
-n option, but I think the logfile was so big due to this endless loop.

-- 

Thanks,
Vitaly Fertman