reiserfsck 3.6.11 locks up

reiserfsck 3.6.11 locks up

[David Fendrich]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

I have a disaster on my hands. I have important data on a HD which
crashed a few days ago. It turns out that the back up system has been
down for 1 month, so I really need to recover data from this HD. I used
dd_recover to rescue what I could to a clean drive (very few blocks were
damaged, fortunately).

I then mounted this 200 gig file with losetup and ran reiserfsck --check
on it. Reiserfsck said that I needed to run with --rebuild-tree. So I
did. Pass 0 went fine. Pass 1 locked up everything after 40%. I
downloaded the latest reiserfsck (my first version was 3.6.6 or
something like that) and tried again. Same result at the exakt same
position.

I am almost certain that there is nothing wrong with the new HD, so what
am I to do?

Is is wrong to run from a loopback device? Should I copy the large file
right on to an empty partition with dd if=/dev/loop0 of=/dev/hda1 -bs=1M
? Does it matter on hda1 is larger than the original partition?

If the output from debugreiserfs helps, here it is:
debugreiserfs 3.6.11 (2003 www.namesys.com)


Filesystem state: consistency is not checked after last mounting

Reiserfs super block in block 16 on 0x700 of format 3.6 with standard
journal
Count of blocks on the device: 49520336
Number of bitmaps: 1512
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
blocks): 49520336
Root block: 0
Filesystem is cleanly umounted
Tree height: 65535
Hash function used to sort names: "r5"
Objectid map size 972, max 972
Journal parameters:
Device [0x0]
Magic [0x0]
Size 8193 blocks (including 1 for journal header) (first block 18)
Max transaction length 1024 blocks
Max batch size 900 blocks
Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0xfa02:
FATAL corruptions exist.
sb_version: 2
inode generation number: 1721538
UUID: 68aba5d9-12cf-48f5-aa3e-648bda76c37c
LABEL:
Set flags in SB:
ATTRIBUTES CLEAN

Re: reiserfsck 3.6.11 locks up

[Alex Malinovich]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

On Sun, 2003-12-21 at 07:27, David Fendrich wrote:
> I have a disaster on my hands. I have important data on a HD which
> crashed a few days ago. It turns out that the back up system has been
> down for 1 month, so I really need to recover data from this HD. I used
> dd_recover to rescue what I could to a clean drive (very few blocks were
> damaged, fortunately).
> 
> I then mounted this 200 gig file with losetup and ran reiserfsck --check
> on it. Reiserfsck said that I needed to run with --rebuild-tree. So I
> did. Pass 0 went fine. Pass 1 locked up everything after 40%. I
> downloaded the latest reiserfsck (my first version was 3.6.6 or
> something like that) and tried again. Same result at the exakt same
> position.

I just did this exact thing finishing about half an hour ago. I had a
very badly corrupted RAID 0 array to try and get data from. Using
dd_rescue, each time a read failed the kernel would disconnect the drive
altogether, forcing me to reboot. Altogether I spent about 2 full days
doing nothing but running dd_rescue with various starting points. Here's
my full procedure:

1) run dd_rescue to get the data off the drive and dump it into a file
on another partition. In my case, the file was /backup/sda-rescue

2) Once I had a full backup, I made a copy of sda-rescue on another
drive just in case.

3) I ran the following: reiserfsck --rebuild-tree --logfile
/root/reiserfsck-rebuild-tree.log /backup/sda-rescue

4) This resulted in about 3000 files in lost+found and nothing else. The
original partition had about 130,000 files total. Luckily, I made a copy
of the backup at /other/sda-rescue. :)

5) I re-ran reiserfsck with the --scan-whole-partition option:
reiserfsck --rebuild-tree --scan-whole-partition --logfile
/root/reiserfsck-rebuild-tree.log /other/sda-rescue

6) Once this completed, I mounted the partition with the following
command and got a good chunk of my data back: mount -t reiserfs -o
loop,ro /other/sda-rescue /rescue

Unfortunately, I'm far from being an expert on reiserfs, this just
happened to work for me. Best of luck. :)

-- 
Alex Malinovich
Support Free Software, delete your Windows partition TODAY!
Encrypted mail preferred. You can get my public key from any of the
pgp.net keyservers. Key ID: A6D24837

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: reiserfsck 3.6.11 locks up

[Vitaly Fertman]

Hello, 

On Sunday 21 December 2003 16:27, David Fendrich wrote:
> I have a disaster on my hands. I have important data on a HD which
> crashed a few days ago. It turns out that the back up system has been
> down for 1 month, so I really need to recover data from this HD. I used
> dd_recover to rescue what I could to a clean drive (very few blocks were
> damaged, fortunately).
>
> I then mounted this 200 gig file with losetup and ran reiserfsck --check
> on it. Reiserfsck said that I needed to run with --rebuild-tree. So I
> did. Pass 0 went fine. Pass 1 locked up everything after 40%. I
> downloaded the latest reiserfsck (my first version was 3.6.6 or
> something like that) and tried again. Same result at the exakt same
> position.

So reiserfsck continues to do smth but no progress anymore, right?
Have you built the progs on the same computer where you run it?
Would you check your memory with memtest or similar?
If this is a problem in the reiserfsprogs code I will be able to find 
it if you run 
	debugreiserfs -p /dev/xxx | bzip2 -c > xxx.bz2
and make it available for downloading.

> I am almost certain that there is nothing wrong with the new HD, so what
> am I to do?
>
> Is is wrong to run from a loopback device? Should I copy the large file

this is ok to fsck the loopback device, you can even fsck the file.

> right on to an empty partition with dd if=/dev/loop0 of=/dev/hda1 -bs=1M
> ? Does it matter on hda1 is larger than the original partition?

in this case it would be better to zero the partition first or to be sure that there
were no reiserfs before on hda1 blocks that lie over the fs size.

> If the output from debugreiserfs helps, here it is:
> debugreiserfs 3.6.11 (2003 www.namesys.com)
>
> Count of blocks on the device: 49520336
> Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
> blocks): 49520336

have you rebuilt the super block? 

-- 
Thanks,
Vitaly Fertman

Re: reiserfsck 3.6.11 locks up

[David Fendrich]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

The problem is solved. I used the 3.6.12pre version and everything went
smooth. 


So reiserfsck continues to do smth but no progress anymore, right?
Have you built the progs on the same computer where you run it?
Would you check your memory with memtest or similar?


I don't think that reiserfsck continued to do anything. The whole
computer froze, ssh went down, I couldn't even switch virtual terminals
(I run Gentoo linux 2.4.22-ac, so yes the progs are built on the same
computer with the only optimization being -03), but alt-sysrq worked.
This happened twice at exactly the same place in pass 1, so anyone else
having the same problem should try 3.6.12.

Thanks,
David 

Re: reiserfsck 3.6.11 locks up

[Vitaly Fertman]

On Monday 22 December 2003 15:15, David Fendrich wrote:
> The problem is solved. I used the 3.6.12pre version and everything went
> smooth.
>
>
> So reiserfsck continues to do smth but no progress anymore, right?
> Have you built the progs on the same computer where you run it?
> Would you check your memory with memtest or similar?
>
>
> I don't think that reiserfsck continued to do anything. The whole
> computer froze, ssh went down, I couldn't even switch virtual terminals
> (I run Gentoo linux 2.4.22-ac, so yes the progs are built on the same
> computer with the only optimization being -03), but alt-sysrq worked.
> This happened twice at exactly the same place in pass 1, so anyone else
> having the same problem should try 3.6.12.

a user process should not freeze the system, so it is hard to believe that 
this was a problem in progs, more likely a problem in the hardware or in 
the kernel. Did you use the same kernel as with 3.6.12-pre1? 

-- 
Thanks,
Vitaly Fertman