reiserfs3 rebuild-tree successful but no files

reiserfs3 rebuild-tree successful but no files

[Christian Placzek]

Hello,

a friend of mine shredded his data (70GB) when he tried to undelete an
accidentally deleted file. He normally works with windoze. Therefore he
didn't know he couldn't undelete a file on a reiserfs partition with ext2
undelete tool %-(
When he called me it was already too late. He had overwritten the
superblock :-(

I'm still trying to rescue the data. I can see them in the image using grep
 or hexedit. But nothing I tried has been successful. My first steps were
 unmounting the partition, taking an image and working with a copy of this
 image using a loop back device.

All files have been retrieved but were removed by reiserfsck --check although
the last output says that directories and files have been linked (see below).
I tried with many combinations nearly all parameters of reiserfsck:
--fix-fixable --no-journal-available -S ...


I mounted the image after each operation, but all I can see is:

root@marvin:/home/kris 0$ # mount -o ro /dev/loop/0 /mnt/temp1/
root@marvin:/home/kris 0$ # ls -la /mnt/temp1/
total 21
drwxr-xr-x   3 root root  4096 Jan 20 11:36 .
drwxr-xr-x  39 root root   968 Feb  6 14:12 ..
drwx------   2 root root 16384 Jan 20 11:36 lost+found
root@marvin:/home/kris 0$ # ls -la /mnt/temp1/lost+found/
total 20
drwx------  2 root root 16384 Jan 20 11:36 .
drwxr-xr-x  3 root root  4096 Jan 20 11:36 ..
root@marvin:/home/kris 0$ #


Do you have any suggestions how to rescue the data?

Regards
  Kris



Here you see a typical output:

root@marvin:/home/kris 0$ # losetup /dev/loop/0 /mnt/temp/data.x.dd
root@marvin:/home/kris 0$ # reiserfsck /dev/loop/0 --rebuild-tree
reiserfsck 3.6.19 (2003 www.namesys.com)

<snip>

Will rebuild the filesystem (/dev/loop/0) tree
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.

root@marvin:/home/kris 8$ # reiserfsck /dev/loop/0 --rebuild-sb
reiserfsck 3.6.19 (2003 www.namesys.com)

<snip>

Will check superblock and rebuild it if needed
Will put log info to 'stdout'

reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.

what the version of ReiserFS do you use[1-4]
        (1)   3.6.x
        (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2,
choose this one)
        (3) < 3.5.9 converted to new format (don't choose if unsure)
        (4) < 3.5.9 (this is very old format, don't choose if unsure)
        (X)   exit
1

Enter block size [4096]:


No journal device was specified. (If journal is not available, re-run with
--no-journal-available option specified).
Is journal default? (y/n)[y]:

Did you use resizer(y/n)[n]:
rebuild-sb: no uuid found, a new uuid was generated
(7e253707-4fef-42aa-9785-b1cd079851af)

rebuild-sb: You either have a corrupted journal or have just changed
the start of the partition with some partition table editor. If you are
sure that the start of the partition is ok, rebuild the journal header.
Do you want to rebuild the journal header? (y/n)[n]: y
Reiserfs super block in block 16 on 0x700 of format 3.6 with standard journal
Count of blocks on the device: 17659440
Number of bitmaps: 539
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
blocks): 0
Root block: 0
Filesystem is NOT clean
Tree height: 0
Hash function used to sort names: not set
Objectid map size 0, 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: 0x1:
         some corruptions exist.
sb_version: 2
inode generation number: 0
UUID: 7e253707-4fef-42aa-9785-b1cd079851af
LABEL:
Set flags in SB:
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.

root@marvin:/home/kris 1$ # reiserfsck /dev/loop/0 --check
reiserfsck 3.6.19 (2003 www.namesys.com)

<snip>

Will read-only check consistency of the filesystem on /dev/loop/0
Will put log info to 'stdout'
###########
reiserfsck --check started at Tue Feb  8 17:17:31 2005
###########
Replaying journal..
Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions replayed
Zero bit found in on-disk bitmap after the last valid bit.
Checking internal tree..

Bad root block 0. (--rebuild-tree did not complete)

Aborted
root@marvin:/home/kris 134$ # reiserfsck /dev/loop/0 -y --rebuild-tree
reiserfsck 3.6.19 (2003 www.namesys.com)

<snip>

Will rebuild the filesystem (/dev/loop/0) tree
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal..
Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions replayed
Zero bit found in on-disk bitmap after the last valid bit. Fixed.
###########
reiserfsck --rebuild-tree started at Tue Feb  8 17:37:56 2005
###########

Pass 0:
####### Pass 0 #######
Loading on-disk bitmap .. ok, 559628 blocks marked used
init_source_bitmap: Bitmap 0 (of 32768 bits) is wrong - mark all blocks [0 -
32768] as used
init_source_bitmap: Bitmap 1 (of 32768 bits) is wrong - mark all blocks
 [32768 - 65536] as used
init_source_bitmap: Bitmap 3 (of 32768 bits) is wrong - mark all blocks
 [98304 - 131072] as used
init_source_bitmap: Bitmap 5 (of 32768 bits) is wrong - mark all blocks
[163840 - 196608] as used
init_source_bitmap: Bitmap 7 (of 32768 bits) is wrong - mark all blocks
[229376 - 262144] as used
init_source_bitmap: Bitmap 9 (of 32768 bits) is wrong - mark all blocks
[294912 - 327680] as used
init_source_bitmap: Bitmap 25 (of 32768 bits) is wrong - mark all blocks
[819200 - 851968] as used
init_source_bitmap: Bitmap 27 (of 32768 bits) is wrong - mark all blocks
[884736 - 917504] as used
init_source_bitmap: Bitmap 49 (of 32768 bits) is wrong - mark all blocks
[1605632 - 1638400] as used
init_source_bitmap: Bitmap 81 (of 32768 bits) is wrong - mark all blocks
[2654208 - 2686976] as used
init_source_bitmap: Bitmap 125 (of 32768 bits) is wrong - mark all blocks
[4096000 - 4128768] as used
init_source_bitmap: Bitmap 243 (of 32768 bits) is wrong - mark all blocks
[7962624 - 7995392] as used
init_source_bitmap: Bitmap 343 (of 32768 bits) is wrong - mark all blocks
[11239424 - 11272192] as used
Skipping 8749 blocks (super block, journal, bitmaps) 687599 blocks will be
read
0%....20%....40%....60%....80%....100%                        left 0,
9549 /sec
103101 directory entries were hashed with "r5" hash.
Selected hash ("r5") does not match to the hash set in the super block (not
set).
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 687599
                Leaves among those 20621
                Objectids found 114185

Pass 1 (will try to insert 20621 leaves):
####### Pass 1 #######
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%....100%                        left 0,
1718 /sec
Flushing..finished
        20621 leaves read
                20524 inserted
                        - pointers in indirect items pointing to metadata 3
(zeroed)
                97 not inserted
        non-unique pointers in indirect items (zeroed) 1075
####### Pass 2 #######

Pass 2:
0%....20%....40%....60%vpf-10260: The file we are inserting the new item
(69291 69327 0x1 DRCT (2), len 216, location 3880 entry count 65535, fsck
need 0, format new) into has no StatData, insertion was skipped
....vpf-10260: The file we are inserting the new item (240148 240150 0x1 IND
(1), len 1844, location 2252 entry count 0, fsck need 0, format new) into has
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (241304 319211 0x43001 IND
(1), len 492, location 3604 entry count 0, fsck need 0, format new) into has
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (737518 739813 0xe6001 IND
(1), len 688, location 3408 entry count 0, fsck need 0, format new) into has
no StatData, insertion was skipped
80%vpf-10260: The file we are inserting the new item (737518 739813 0xe6001
IND (1), len 688, location 3408 entry count 0, fsck need 0, format new) into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (25 93014 0x1e1 DRCT (2),
len 1408, location 2688 entry count 65535, fsck need 0, format new) intohas
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (238343 319306 0x3f4001 IND
(1), len 136, location 3960 entry count 0, fsck need 0, format new) into has
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (94077 119920 0x1 DRCT (2),
len 456, location 3640 entry count 65535, fsck need 0, format new) into has
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (102491 220397 0x179 DRCT
(2), len 1264, location 2832 entry count 65535, fsck need 0, format new)into
has no StatData, insertion was skipped
.vpf-10260: The file we are inserting the new item (642448 771721 0xcc1 DRCT
(2), len 520, location 3576 entry count 65535, fsck need 0, format new)into
has no StatData, insertion was skipped
.vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new)into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
has no StatData, insertion was skipped
.vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new)into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
has no StatData, insertion was skipped
.vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new)into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
has no StatData, insertion was skipped
100%                           left 0, 0 /sec
Flushing..finished
        Leaves inserted item by item 97
Pass 3 (semantic):
####### Pass 3 #########
/binrebuild_semantic_pass: The entry [3636 189939] ("ls") in directory [2
3636] points to nowhere - is removed
/javarebuild_semantic_pass: The entry [107571 597512] ("jre") in directory
[3636 107571] points to nowhere - is removed
vpf-10650: The directory [3636 107571] has the wrong size in the StatData
 (72) - corrected to (48)
vpf-10650: The directory [2 3636] has the wrong size in the StatData (2920) -
corrected to (2896)
/devrebuild_semantic_pass: The entry [6 554632] ("lvm") in directory [2 6]
points to nowhere - is removed
rebuild_semantic_pass: The entry [6 52003] ("lirc") in directory [2 6] points
to nowhere - is removed
rebuild_semantic_pass: The entry [6 72207] ("scsi") in directory [2 6] points
to nowhere - is removed
rebuild_semantic_pass: The entry [6 50738] ("xdb5") in directory [2 6] points
to nowhere - is removed
rebuild_semantic_pass: The entry [6 50739] ("xdb6") in directory [2 6] points
to nowhere - is removed
rebuild_semantic_pass: The entry [6 50740] ("xdb7") in directory [2 6] points
to nowhere - is removed
rebuild_semantic_pass: The entry [6 50741] ("xdb8") in directory [2 6] points
to nowhere - is removed
...
... (here follow hundreds of directories and thousends of files, too,
...  which I removed)
...
The entry [994339 994340] ("Entries") in directory [994335 19] updated to
point to [994339 49]
/Entries.Extra.Oldrewrite_file: 1 items of file [994339 994343] moved to
[994339 50]
The entry [994339 994343] ("Entries.Extra.Old") in directory [994335 19]
updated to point to [994339 50]
relocate_dir: Moving [994350 994773 0x0 SD (0)] to [994350 51 0x0 SD (0)]
relocate_dir: Moving [994350 994773 0x1 DIR (3)] to [994350 51 0x1 DIR (3)]
/994350_51get_next_directory_item: The entry ".." of the directory [994350
 51] pointes to [285394 994350], instead of [2 18] - corrected
rebuild_semantic_pass: The entry [994773 994783] ("Root") in directory
 [994350 51] points to nowhere - is removed
rebuild_semantic_pass: The entry [994773 994776] ("Entries.Extra") in
directory [994350 51] points to nowhere - is removed
rebuild_semantic_pass: The entry [994773 994782] ("Repository") in directory
[994350 51] points to nowhere - is removed
rebuild_semantic_pass: The entry [994773 994779] ("Entries.Extra.Old.bak") in
directory [994350 51] points to nowhere - is removed
rebuild_semantic_pass: The entry [994773 994784] ("Root.bak") in directory
[994350 51] points to nowhere - is removed
rebuild_semantic_pass: The entry [994773 994780] ("Entries.Old") in directory
[994350 51] points to nowhere - is removed
rebuild_semantic_pass: The entry [994773 994775] ("Entries.bak") in directory
[994350 51] points to nowhere - is removed
rebuild_semantic_pass: The entry [994773 994781] ("Entries.Old.bak") in
directory [994350 51] points to nowhere - is removed
rebuild_semantic_pass: The entry [994773 994778] ("Entries.Extra.Old") in
directory [994350 51] points to nowhere - is removed
rebuild_semantic_pass: The entry [994773 994777] ("Entries.Extra.bak") in
directory [994350 51] points to nowhere - is removed
vpf-10650: The directory [994350 51] has the wrong size in the StatData (400)
- corrected to (72)
/994395_994396get_next_directory_item: The entry ".." of the directory
 [994395 994396] pointes to [684030 994395], instead of [2 18] - corrected
/994415_994416get_next_directory_item: The entry ".." of the directory
 [994415 994416] pointes to [684030 994415], instead of [2 18] - corrected
/994529_994754get_next_directory_item: The entry ".." of the directory
 [994529 994754] pointes to [984867 994529], instead of [2 18] - corrected
Looking for lost files:
vpf-10670: The file [25 93091] has the wrong size in the StatData (30352) -
corrected to (36864)
vpf-10680: The file [25 93091] has the wrong block count in the StatData (64)
- corrected to (72)
vpf-10680: The file [25 111982] has the wrong block count in the StatData
(75408) - corrected to (16872)
vpf-10680: The file [3127 59061] has the wrong block count in the StatData
 (8) - corrected to (0)
vpf-10680: The file [3128 72300] has the wrong block count in the StatData
 (8) - corrected to (0)
vpf-10680: The file [3620 18950] has the wrong block count in the StatData
 (8) - corrected to (0)
...
...
...
rewrite_file: 2 items of file [994350 994764] moved to [994350 3108]
rewrite_file: 2 items of file [994350 994765] moved to [994350 3109]
rewrite_file: 2 items of file [994350 994766] moved to [994350 3110]
Flushing..finished
        Objects without names 18403
        Empty lost dirs removed 384
        Dirs linked to /lost+found: 2174
                Dirs without stat data found 83
        Files linked to /lost+found 16229
        Objects having used objectids: 49
                files fixed 47
                dirs fixed 2
Pass 4 - finished   done 1476, 37 /sec
        Deleted unreachable items 716
Flushing..finished
Syncing..finished
###########
reiserfsck finished at Tue Feb  8 17:40:05 2005
###########

Re: reiserfs3 rebuild-tree successful but no files

[Vladimir Saveliev]

Hello

On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> Hello,
> 
> a friend of mine shredded his data (70GB) when he tried to undelete an
> accidentally deleted file. He normally works with windoze. Therefore he
> didn't know he couldn't undelete a file on a reiserfs partition with ext2
> undelete tool %-(
> When he called me it was already too late. He had overwritten the
> superblock :-(
> 
> I'm still trying to rescue the data. I can see them in the image using grep
>  or hexedit. But nothing I tried has been successful. My first steps were
>  unmounting the partition, taking an image and working with a copy of this
>  image using a loop back device.
> 
> All files have been retrieved but were removed by reiserfsck --check although
> the last output says that directories and files have been linked (see below).
> I tried with many combinations nearly all parameters of reiserfsck:
> --fix-fixable --no-journal-available -S ...
> 

have you tried
reiserfsck --rebuild-tree -S
?
If not, run it on newly created copy of shredded device.

Did you look at lost+found?

> 
> I mounted the image after each operation, but all I can see is:
> 
> root@marvin:/home/kris 0$ # mount -o ro /dev/loop/0 /mnt/temp1/
> root@marvin:/home/kris 0$ # ls -la /mnt/temp1/
> total 21
> drwxr-xr-x   3 root root  4096 Jan 20 11:36 .
> drwxr-xr-x  39 root root   968 Feb  6 14:12 ..
> drwx------   2 root root 16384 Jan 20 11:36 lost+found
> root@marvin:/home/kris 0$ # ls -la /mnt/temp1/lost+found/
> total 20
> drwx------  2 root root 16384 Jan 20 11:36 .
> drwxr-xr-x  3 root root  4096 Jan 20 11:36 ..
> root@marvin:/home/kris 0$ #
> 
> 
> Do you have any suggestions how to rescue the data?
> 
> Regards
>   Kris
> 
> 
> 
> Here you see a typical output:
> 
> root@marvin:/home/kris 0$ # losetup /dev/loop/0 /mnt/temp/data.x.dd
> root@marvin:/home/kris 0$ # reiserfsck /dev/loop/0 --rebuild-tree
> reiserfsck 3.6.19 (2003 www.namesys.com)
> 
> <snip>
> 
> Will rebuild the filesystem (/dev/loop/0) tree
> Will put log info to 'stdout'
> 
> Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
> 
> reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
> Failed to open the filesystem.
> 
> If the partition table has not been changed, and the partition is
> valid  and  it really  contains  a reiserfs  partition,  then the
> superblock  is corrupted and you need to run this utility with
> --rebuild-sb.
> 
> root@marvin:/home/kris 8$ # reiserfsck /dev/loop/0 --rebuild-sb
> reiserfsck 3.6.19 (2003 www.namesys.com)
> 
> <snip>
> 
> Will check superblock and rebuild it if needed
> Will put log info to 'stdout'
> 
> reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
> 
> what the version of ReiserFS do you use[1-4]
>         (1)   3.6.x
>         (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2,
> choose this one)
>         (3) < 3.5.9 converted to new format (don't choose if unsure)
>         (4) < 3.5.9 (this is very old format, don't choose if unsure)
>         (X)   exit
> 1
> 
> Enter block size [4096]:
> 
> 
> No journal device was specified. (If journal is not available, re-run with
> --no-journal-available option specified).
> Is journal default? (y/n)[y]:
> 
> Did you use resizer(y/n)[n]:
> rebuild-sb: no uuid found, a new uuid was generated
> (7e253707-4fef-42aa-9785-b1cd079851af)
> 
> rebuild-sb: You either have a corrupted journal or have just changed
> the start of the partition with some partition table editor. If you are
> sure that the start of the partition is ok, rebuild the journal header.
> Do you want to rebuild the journal header? (y/n)[n]: y
> Reiserfs super block in block 16 on 0x700 of format 3.6 with standard journal
> Count of blocks on the device: 17659440
> Number of bitmaps: 539
> Blocksize: 4096
> Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
> blocks): 0
> Root block: 0
> Filesystem is NOT clean
> Tree height: 0
> Hash function used to sort names: not set
> Objectid map size 0, 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: 0x1:
>          some corruptions exist.
> sb_version: 2
> inode generation number: 0
> UUID: 7e253707-4fef-42aa-9785-b1cd079851af
> LABEL:
> Set flags in SB:
> Is this ok ? (y/n)[n]: y
> The fs may still be unconsistent. Run reiserfsck --check.
> 
> root@marvin:/home/kris 1$ # reiserfsck /dev/loop/0 --check
> reiserfsck 3.6.19 (2003 www.namesys.com)
> 
> <snip>
> 
> Will read-only check consistency of the filesystem on /dev/loop/0
> Will put log info to 'stdout'
> ###########
> reiserfsck --check started at Tue Feb  8 17:17:31 2005
> ###########
> Replaying journal..
> Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions replayed
> Zero bit found in on-disk bitmap after the last valid bit.
> Checking internal tree..
> 
> Bad root block 0. (--rebuild-tree did not complete)
> 
> Aborted
> root@marvin:/home/kris 134$ # reiserfsck /dev/loop/0 -y --rebuild-tree
> reiserfsck 3.6.19 (2003 www.namesys.com)
> 
> <snip>
> 
> Will rebuild the filesystem (/dev/loop/0) tree
> Will put log info to 'stdout'
> 
> Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
> Replaying journal..
> Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions replayed
> Zero bit found in on-disk bitmap after the last valid bit. Fixed.
> ###########
> reiserfsck --rebuild-tree started at Tue Feb  8 17:37:56 2005
> ###########
> 
> Pass 0:
> ####### Pass 0 #######
> Loading on-disk bitmap .. ok, 559628 blocks marked used
> init_source_bitmap: Bitmap 0 (of 32768 bits) is wrong - mark all blocks [0 -
> 32768] as used
> init_source_bitmap: Bitmap 1 (of 32768 bits) is wrong - mark all blocks
>  [32768 - 65536] as used
> init_source_bitmap: Bitmap 3 (of 32768 bits) is wrong - mark all blocks
>  [98304 - 131072] as used
> init_source_bitmap: Bitmap 5 (of 32768 bits) is wrong - mark all blocks
> [163840 - 196608] as used
> init_source_bitmap: Bitmap 7 (of 32768 bits) is wrong - mark all blocks
> [229376 - 262144] as used
> init_source_bitmap: Bitmap 9 (of 32768 bits) is wrong - mark all blocks
> [294912 - 327680] as used
> init_source_bitmap: Bitmap 25 (of 32768 bits) is wrong - mark all blocks
> [819200 - 851968] as used
> init_source_bitmap: Bitmap 27 (of 32768 bits) is wrong - mark all blocks
> [884736 - 917504] as used
> init_source_bitmap: Bitmap 49 (of 32768 bits) is wrong - mark all blocks
> [1605632 - 1638400] as used
> init_source_bitmap: Bitmap 81 (of 32768 bits) is wrong - mark all blocks
> [2654208 - 2686976] as used
> init_source_bitmap: Bitmap 125 (of 32768 bits) is wrong - mark all blocks
> [4096000 - 4128768] as used
> init_source_bitmap: Bitmap 243 (of 32768 bits) is wrong - mark all blocks
> [7962624 - 7995392] as used
> init_source_bitmap: Bitmap 343 (of 32768 bits) is wrong - mark all blocks
> [11239424 - 11272192] as used
> Skipping 8749 blocks (super block, journal, bitmaps) 687599 blocks will be
> read
> 0%....20%....40%....60%....80%....100%                        left 0,
> 9549 /sec
> 103101 directory entries were hashed with "r5" hash.
> Selected hash ("r5") does not match to the hash set in the super block (not
> set).
>         "r5" hash is selected
> Flushing..finished
>         Read blocks (but not data blocks) 687599
>                 Leaves among those 20621
>                 Objectids found 114185
> 
> Pass 1 (will try to insert 20621 leaves):
> ####### Pass 1 #######
> Looking for allocable blocks .. finished
> 0%....20%....40%....60%....80%....100%                        left 0,
> 1718 /sec
> Flushing..finished
>         20621 leaves read
>                 20524 inserted
>                         - pointers in indirect items pointing to metadata 3
> (zeroed)
>                 97 not inserted
>         non-unique pointers in indirect items (zeroed) 1075
> ####### Pass 2 #######
> 
> Pass 2:
> 0%....20%....40%....60%vpf-10260: The file we are inserting the new item
> (69291 69327 0x1 DRCT (2), len 216, location 3880 entry count 65535, fsck
> need 0, format new) into has no StatData, insertion was skipped
> ....vpf-10260: The file we are inserting the new item (240148 240150 0x1 IND
> (1), len 1844, location 2252 entry count 0, fsck need 0, format new) into has
> no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (241304 319211 0x43001 IND
> (1), len 492, location 3604 entry count 0, fsck need 0, format new) into has
> no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (737518 739813 0xe6001 IND
> (1), len 688, location 3408 entry count 0, fsck need 0, format new) into has
> no StatData, insertion was skipped
> 80%vpf-10260: The file we are inserting the new item (737518 739813 0xe6001
> IND (1), len 688, location 3408 entry count 0, fsck need 0, format new) into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (25 93014 0x1e1 DRCT (2),
> len 1408, location 2688 entry count 65535, fsck need 0, format new) intohas
> no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (238343 319306 0x3f4001 IND
> (1), len 136, location 3960 entry count 0, fsck need 0, format new) into has
> no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (94077 119920 0x1 DRCT (2),
> len 456, location 3640 entry count 65535, fsck need 0, format new) into has
> no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (102491 220397 0x179 DRCT
> (2), len 1264, location 2832 entry count 65535, fsck need 0, format new)into
> has no StatData, insertion was skipped
> .vpf-10260: The file we are inserting the new item (642448 771721 0xcc1 DRCT
> (2), len 520, location 3576 entry count 65535, fsck need 0, format new)into
> has no StatData, insertion was skipped
> .vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new)into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
> has no StatData, insertion was skipped
> .vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new)into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
> has no StatData, insertion was skipped
> .vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new)into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
> has no StatData, insertion was skipped
> vpf-10260: The file we are inserting the new item (294390 692752 0x129 DRCT
> (2), len 296, location 3800 entry count 65535, fsck need 0, format new) into
> has no StatData, insertion was skipped
> 100%                           left 0, 0 /sec
> Flushing..finished
>         Leaves inserted item by item 97
> Pass 3 (semantic):
> ####### Pass 3 #########
> /binrebuild_semantic_pass: The entry [3636 189939] ("ls") in directory [2
> 3636] points to nowhere - is removed
> /javarebuild_semantic_pass: The entry [107571 597512] ("jre") in directory
> [3636 107571] points to nowhere - is removed
> vpf-10650: The directory [3636 107571] has the wrong size in the StatData
>  (72) - corrected to (48)
> vpf-10650: The directory [2 3636] has the wrong size in the StatData (2920) -
> corrected to (2896)
> /devrebuild_semantic_pass: The entry [6 554632] ("lvm") in directory [2 6]
> points to nowhere - is removed
> rebuild_semantic_pass: The entry [6 52003] ("lirc") in directory [2 6] points
> to nowhere - is removed
> rebuild_semantic_pass: The entry [6 72207] ("scsi") in directory [2 6] points
> to nowhere - is removed
> rebuild_semantic_pass: The entry [6 50738] ("xdb5") in directory [2 6] points
> to nowhere - is removed
> rebuild_semantic_pass: The entry [6 50739] ("xdb6") in directory [2 6] points
> to nowhere - is removed
> rebuild_semantic_pass: The entry [6 50740] ("xdb7") in directory [2 6] points
> to nowhere - is removed
> rebuild_semantic_pass: The entry [6 50741] ("xdb8") in directory [2 6] points
> to nowhere - is removed
> ...
> ... (here follow hundreds of directories and thousends of files, too,
> ...  which I removed)
> ...
> The entry [994339 994340] ("Entries") in directory [994335 19] updated to
> point to [994339 49]
> /Entries.Extra.Oldrewrite_file: 1 items of file [994339 994343] moved to
> [994339 50]
> The entry [994339 994343] ("Entries.Extra.Old") in directory [994335 19]
> updated to point to [994339 50]
> relocate_dir: Moving [994350 994773 0x0 SD (0)] to [994350 51 0x0 SD (0)]
> relocate_dir: Moving [994350 994773 0x1 DIR (3)] to [994350 51 0x1 DIR (3)]
> /994350_51get_next_directory_item: The entry ".." of the directory [994350
>  51] pointes to [285394 994350], instead of [2 18] - corrected
> rebuild_semantic_pass: The entry [994773 994783] ("Root") in directory
>  [994350 51] points to nowhere - is removed
> rebuild_semantic_pass: The entry [994773 994776] ("Entries.Extra") in
> directory [994350 51] points to nowhere - is removed
> rebuild_semantic_pass: The entry [994773 994782] ("Repository") in directory
> [994350 51] points to nowhere - is removed
> rebuild_semantic_pass: The entry [994773 994779] ("Entries.Extra.Old.bak") in
> directory [994350 51] points to nowhere - is removed
> rebuild_semantic_pass: The entry [994773 994784] ("Root.bak") in directory
> [994350 51] points to nowhere - is removed
> rebuild_semantic_pass: The entry [994773 994780] ("Entries.Old") in directory
> [994350 51] points to nowhere - is removed
> rebuild_semantic_pass: The entry [994773 994775] ("Entries.bak") in directory
> [994350 51] points to nowhere - is removed
> rebuild_semantic_pass: The entry [994773 994781] ("Entries.Old.bak") in
> directory [994350 51] points to nowhere - is removed
> rebuild_semantic_pass: The entry [994773 994778] ("Entries.Extra.Old") in
> directory [994350 51] points to nowhere - is removed
> rebuild_semantic_pass: The entry [994773 994777] ("Entries.Extra.bak") in
> directory [994350 51] points to nowhere - is removed
> vpf-10650: The directory [994350 51] has the wrong size in the StatData (400)
> - corrected to (72)
> /994395_994396get_next_directory_item: The entry ".." of the directory
>  [994395 994396] pointes to [684030 994395], instead of [2 18] - corrected
> /994415_994416get_next_directory_item: The entry ".." of the directory
>  [994415 994416] pointes to [684030 994415], instead of [2 18] - corrected
> /994529_994754get_next_directory_item: The entry ".." of the directory
>  [994529 994754] pointes to [984867 994529], instead of [2 18] - corrected
> Looking for lost files:
> vpf-10670: The file [25 93091] has the wrong size in the StatData (30352) -
> corrected to (36864)
> vpf-10680: The file [25 93091] has the wrong block count in the StatData (64)
> - corrected to (72)
> vpf-10680: The file [25 111982] has the wrong block count in the StatData
> (75408) - corrected to (16872)
> vpf-10680: The file [3127 59061] has the wrong block count in the StatData
>  (8) - corrected to (0)
> vpf-10680: The file [3128 72300] has the wrong block count in the StatData
>  (8) - corrected to (0)
> vpf-10680: The file [3620 18950] has the wrong block count in the StatData
>  (8) - corrected to (0)
> ...
> ...
> ...
> rewrite_file: 2 items of file [994350 994764] moved to [994350 3108]
> rewrite_file: 2 items of file [994350 994765] moved to [994350 3109]
> rewrite_file: 2 items of file [994350 994766] moved to [994350 3110]
> Flushing..finished
>         Objects without names 18403
>         Empty lost dirs removed 384
>         Dirs linked to /lost+found: 2174
>                 Dirs without stat data found 83
>         Files linked to /lost+found 16229
>         Objects having used objectids: 49
>                 files fixed 47
>                 dirs fixed 2
> Pass 4 - finished   done 1476, 37 /sec
>         Deleted unreachable items 716
> Flushing..finished
> Syncing..finished
> ###########
> reiserfsck finished at Tue Feb  8 17:40:05 2005
> ###########
> 

Re: reiserfs3 rebuild-tree successful but no files

[Christian Placzek]

On Wednesday 09 February 2005 09:47, you wrote:
> Hello
>
> On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> > Hello,
> >
> > a friend of mine shredded his data (70GB) when he tried to undelete an
> > accidentally deleted file. He normally works with windoze. Therefore he
> > didn't know he couldn't undelete a file on a reiserfs partition with ext2
> > undelete tool %-(
> > When he called me it was already too late. He had overwritten the
> > superblock :-(
> >
> > I'm still trying to rescue the data. I can see them in the image using
> > grep or hexedit. But nothing I tried has been successful. My first steps
> > were unmounting the partition, taking an image and working with a copy of
> > this image using a loop back device.
> >
> > All files have been retrieved but were removed by reiserfsck --check
> > although the last output says that directories and files have been linked
> > (see below). I tried with many combinations nearly all parameters of
> > reiserfsck: --fix-fixable --no-journal-available -S ...
>
> have you tried
> reiserfsck --rebuild-tree -S
> ?
> If not, run it on newly created copy of shredded device.
>
Yes, I did. The output of reiserfsck --rebuild-tree gave other numbers of 
linked directories/files. But I can't see them.

> Did you look at lost+found?
Shure, see below.



>
> > I mounted the image after each operation, but all I can see is:
> >
> > root@marvin:/home/kris 0$ # mount -o ro /dev/loop/0 /mnt/temp1/
> > root@marvin:/home/kris 0$ # ls -la /mnt/temp1/
> > total 21
> > drwxr-xr-x   3 root root  4096 Jan 20 11:36 .
> > drwxr-xr-x  39 root root   968 Feb  6 14:12 ..
> > drwx------   2 root root 16384 Jan 20 11:36 lost+found
> > root@marvin:/home/kris 0$ # ls -la /mnt/temp1/lost+found/
> > total 20
> > drwx------  2 root root 16384 Jan 20 11:36 .
> > drwxr-xr-x  3 root root  4096 Jan 20 11:36 ..
> > root@marvin:/home/kris 0$ #
> >
> >
> > Do you have any suggestions how to rescue the data?
> >
> > Regards
> >   Kris
> >
> >
> >
> > Here you see a typical output:
> >
> > root@marvin:/home/kris 0$ # losetup /dev/loop/0 /mnt/temp/data.x.dd
> > root@marvin:/home/kris 0$ # reiserfsck /dev/loop/0 --rebuild-tree
> > reiserfsck 3.6.19 (2003 www.namesys.com)
> >
> > <snip>
> >
> > Will rebuild the filesystem (/dev/loop/0) tree
> > Will put log info to 'stdout'
> >
> > Do you want to run this program?[N/Yes] (note need to type Yes if you
> > do):Yes
> >
> > reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
> > Failed to open the filesystem.
> >
> > If the partition table has not been changed, and the partition is
> > valid  and  it really  contains  a reiserfs  partition,  then the
> > superblock  is corrupted and you need to run this utility with
> > --rebuild-sb.
> >
> > root@marvin:/home/kris 8$ # reiserfsck /dev/loop/0 --rebuild-sb
> > reiserfsck 3.6.19 (2003 www.namesys.com)
> >
> > <snip>
> >
> > Will check superblock and rebuild it if needed
> > Will put log info to 'stdout'
> >
> > reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
> >
> > what the version of ReiserFS do you use[1-4]
> >         (1)   3.6.x
> >         (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux
> > 2.2, choose this one)
> >         (3) < 3.5.9 converted to new format (don't choose if unsure)
> >         (4) < 3.5.9 (this is very old format, don't choose if unsure)
> >         (X)   exit
> > 1
> >
> > Enter block size [4096]:
> >
> >
> > No journal device was specified. (If journal is not available, re-run
> > with --no-journal-available option specified).
> > Is journal default? (y/n)[y]:
> >
> > Did you use resizer(y/n)[n]:
> > rebuild-sb: no uuid found, a new uuid was generated
> > (7e253707-4fef-42aa-9785-b1cd079851af)
> >
> > rebuild-sb: You either have a corrupted journal or have just changed
> > the start of the partition with some partition table editor. If you are
> > sure that the start of the partition is ok, rebuild the journal header.
> > Do you want to rebuild the journal header? (y/n)[n]: y
> > Reiserfs super block in block 16 on 0x700 of format 3.6 with standard
> > journal Count of blocks on the device: 17659440
> > Number of bitmaps: 539
> > Blocksize: 4096
> > Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
> > blocks): 0
> > Root block: 0
> > Filesystem is NOT clean
> > Tree height: 0
> > Hash function used to sort names: not set
> > Objectid map size 0, 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: 0x1:
> >          some corruptions exist.
> > sb_version: 2
> > inode generation number: 0
> > UUID: 7e253707-4fef-42aa-9785-b1cd079851af
> > LABEL:
> > Set flags in SB:
> > Is this ok ? (y/n)[n]: y
> > The fs may still be unconsistent. Run reiserfsck --check.
> >
> > root@marvin:/home/kris 1$ # reiserfsck /dev/loop/0 --check
> > reiserfsck 3.6.19 (2003 www.namesys.com)
> >
> > <snip>
> >
> > Will read-only check consistency of the filesystem on /dev/loop/0
> > Will put log info to 'stdout'
> > ###########
> > reiserfsck --check started at Tue Feb  8 17:17:31 2005
> > ###########
> > Replaying journal..
> > Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> > replayed Zero bit found in on-disk bitmap after the last valid bit.
> > Checking internal tree..
> >
> > Bad root block 0. (--rebuild-tree did not complete)
> >
> > Aborted
> > root@marvin:/home/kris 134$ # reiserfsck /dev/loop/0 -y --rebuild-tree
> > reiserfsck 3.6.19 (2003 www.namesys.com)
> >
> > <snip>
> >
> > Will rebuild the filesystem (/dev/loop/0) tree
> > Will put log info to 'stdout'
> >
> > Do you want to run this program?[N/Yes] (note need to type Yes if you
> > do):Yes Replaying journal..
> > Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> > replayed Zero bit found in on-disk bitmap after the last valid bit.
> > Fixed. ###########
> > reiserfsck --rebuild-tree started at Tue Feb  8 17:37:56 2005
> > ###########
> >
> > Pass 0:
> > ####### Pass 0 #######
> > Loading on-disk bitmap .. ok, 559628 blocks marked used
> > init_source_bitmap: Bitmap 0 (of 32768 bits) is wrong - mark all blocks
> > [0 - 32768] as used
> > init_source_bitmap: Bitmap 1 (of 32768 bits) is wrong - mark all blocks
> >  [32768 - 65536] as used
> > init_source_bitmap: Bitmap 3 (of 32768 bits) is wrong - mark all blocks
> >  [98304 - 131072] as used
> > init_source_bitmap: Bitmap 5 (of 32768 bits) is wrong - mark all blocks
> > [163840 - 196608] as used
> > init_source_bitmap: Bitmap 7 (of 32768 bits) is wrong - mark all blocks
> > [229376 - 262144] as used
> > init_source_bitmap: Bitmap 9 (of 32768 bits) is wrong - mark all blocks
> > [294912 - 327680] as used
> > init_source_bitmap: Bitmap 25 (of 32768 bits) is wrong - mark all blocks
> > [819200 - 851968] as used
> > init_source_bitmap: Bitmap 27 (of 32768 bits) is wrong - mark all blocks
> > [884736 - 917504] as used
> > init_source_bitmap: Bitmap 49 (of 32768 bits) is wrong - mark all blocks
> > [1605632 - 1638400] as used
> > init_source_bitmap: Bitmap 81 (of 32768 bits) is wrong - mark all blocks
> > [2654208 - 2686976] as used
> > init_source_bitmap: Bitmap 125 (of 32768 bits) is wrong - mark all blocks
> > [4096000 - 4128768] as used
> > init_source_bitmap: Bitmap 243 (of 32768 bits) is wrong - mark all blocks
> > [7962624 - 7995392] as used
> > init_source_bitmap: Bitmap 343 (of 32768 bits) is wrong - mark all blocks
> > [11239424 - 11272192] as used
> > Skipping 8749 blocks (super block, journal, bitmaps) 687599 blocks will
> > be read
> > 0%....20%....40%....60%....80%....100%                        left 0,
> > 9549 /sec
> > 103101 directory entries were hashed with "r5" hash.
> > Selected hash ("r5") does not match to the hash set in the super block
> > (not set).
> >         "r5" hash is selected
> > Flushing..finished
> >         Read blocks (but not data blocks) 687599
> >                 Leaves among those 20621
> >                 Objectids found 114185
> >
> > Pass 1 (will try to insert 20621 leaves):
> > ####### Pass 1 #######
> > Looking for allocable blocks .. finished
> > 0%....20%....40%....60%....80%....100%                        left 0,
> > 1718 /sec
> > Flushing..finished
> >         20621 leaves read
> >                 20524 inserted
> >                         - pointers in indirect items pointing to metadata
> > 3 (zeroed)
> >                 97 not inserted
> >         non-unique pointers in indirect items (zeroed) 1075
> > ####### Pass 2 #######
> >
> > Pass 2:
> > 0%....20%....40%....60%vpf-10260: The file we are inserting the new item
> > (69291 69327 0x1 DRCT (2), len 216, location 3880 entry count 65535, fsck
> > need 0, format new) into has no StatData, insertion was skipped
> > ....vpf-10260: The file we are inserting the new item (240148 240150 0x1
> > IND (1), len 1844, location 2252 entry count 0, fsck need 0, format new)
> > into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (241304 319211 0x43001
> > IND (1), len 492, location 3604 entry count 0, fsck need 0, format new)
> > into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (737518 739813 0xe6001
> > IND (1), len 688, location 3408 entry count 0, fsck need 0, format new)
> > into has no StatData, insertion was skipped
> > 80%vpf-10260: The file we are inserting the new item (737518 739813
> > 0xe6001 IND (1), len 688, location 3408 entry count 0, fsck need 0,
> > format new) into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (25 93014 0x1e1 DRCT
> > (2), len 1408, location 2688 entry count 65535, fsck need 0, format new)
> > intohas no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (238343 319306 0x3f4001
> > IND (1), len 136, location 3960 entry count 0, fsck need 0, format new)
> > into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (94077 119920 0x1 DRCT
> > (2), len 456, location 3640 entry count 65535, fsck need 0, format new)
> > into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (102491 220397 0x179
> > DRCT (2), len 1264, location 2832 entry count 65535, fsck need 0, format
> > new)into has no StatData, insertion was skipped
> > .vpf-10260: The file we are inserting the new item (642448 771721 0xcc1
> > DRCT (2), len 520, location 3576 entry count 65535, fsck need 0, format
> > new)into has no StatData, insertion was skipped
> > .vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new)into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new) into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new) into has no StatData, insertion was skipped
> > .vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new)into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new) into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new) into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new) into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new) into has no StatData, insertion was skipped
> > .vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new)into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new) into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new) into has no StatData, insertion was skipped
> > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > new) into has no StatData, insertion was skipped
> > 100%                           left 0, 0 /sec
> > Flushing..finished
> >         Leaves inserted item by item 97
> > Pass 3 (semantic):
> > ####### Pass 3 #########
> > /binrebuild_semantic_pass: The entry [3636 189939] ("ls") in directory [2
> > 3636] points to nowhere - is removed
> > /javarebuild_semantic_pass: The entry [107571 597512] ("jre") in
> > directory [3636 107571] points to nowhere - is removed
> > vpf-10650: The directory [3636 107571] has the wrong size in the StatData
> >  (72) - corrected to (48)
> > vpf-10650: The directory [2 3636] has the wrong size in the StatData
> > (2920) - corrected to (2896)
> > /devrebuild_semantic_pass: The entry [6 554632] ("lvm") in directory [2
> > 6] points to nowhere - is removed
> > rebuild_semantic_pass: The entry [6 52003] ("lirc") in directory [2 6]
> > points to nowhere - is removed
> > rebuild_semantic_pass: The entry [6 72207] ("scsi") in directory [2 6]
> > points to nowhere - is removed
> > rebuild_semantic_pass: The entry [6 50738] ("xdb5") in directory [2 6]
> > points to nowhere - is removed
> > rebuild_semantic_pass: The entry [6 50739] ("xdb6") in directory [2 6]
> > points to nowhere - is removed
> > rebuild_semantic_pass: The entry [6 50740] ("xdb7") in directory [2 6]
> > points to nowhere - is removed
> > rebuild_semantic_pass: The entry [6 50741] ("xdb8") in directory [2 6]
> > points to nowhere - is removed
> > ...
> > ... (here follow hundreds of directories and thousends of files, too,
> > ...  which I removed)
> > ...
> > The entry [994339 994340] ("Entries") in directory [994335 19] updated to
> > point to [994339 49]
> > /Entries.Extra.Oldrewrite_file: 1 items of file [994339 994343] moved to
> > [994339 50]
> > The entry [994339 994343] ("Entries.Extra.Old") in directory [994335 19]
> > updated to point to [994339 50]
> > relocate_dir: Moving [994350 994773 0x0 SD (0)] to [994350 51 0x0 SD (0)]
> > relocate_dir: Moving [994350 994773 0x1 DIR (3)] to [994350 51 0x1 DIR
> > (3)] /994350_51get_next_directory_item: The entry ".." of the directory
> > [994350 51] pointes to [285394 994350], instead of [2 18] - corrected
> > rebuild_semantic_pass: The entry [994773 994783] ("Root") in directory
> >  [994350 51] points to nowhere - is removed
> > rebuild_semantic_pass: The entry [994773 994776] ("Entries.Extra") in
> > directory [994350 51] points to nowhere - is removed
> > rebuild_semantic_pass: The entry [994773 994782] ("Repository") in
> > directory [994350 51] points to nowhere - is removed
> > rebuild_semantic_pass: The entry [994773 994779]
> > ("Entries.Extra.Old.bak") in directory [994350 51] points to nowhere - is
> > removed
> > rebuild_semantic_pass: The entry [994773 994784] ("Root.bak") in
> > directory [994350 51] points to nowhere - is removed
> > rebuild_semantic_pass: The entry [994773 994780] ("Entries.Old") in
> > directory [994350 51] points to nowhere - is removed
> > rebuild_semantic_pass: The entry [994773 994775] ("Entries.bak") in
> > directory [994350 51] points to nowhere - is removed
> > rebuild_semantic_pass: The entry [994773 994781] ("Entries.Old.bak") in
> > directory [994350 51] points to nowhere - is removed
> > rebuild_semantic_pass: The entry [994773 994778] ("Entries.Extra.Old") in
> > directory [994350 51] points to nowhere - is removed
> > rebuild_semantic_pass: The entry [994773 994777] ("Entries.Extra.bak") in
> > directory [994350 51] points to nowhere - is removed
> > vpf-10650: The directory [994350 51] has the wrong size in the StatData
> > (400) - corrected to (72)
> > /994395_994396get_next_directory_item: The entry ".." of the directory
> >  [994395 994396] pointes to [684030 994395], instead of [2 18] -
> > corrected /994415_994416get_next_directory_item: The entry ".." of the
> > directory [994415 994416] pointes to [684030 994415], instead of [2 18] -
> > corrected /994529_994754get_next_directory_item: The entry ".." of the
> > directory [994529 994754] pointes to [984867 994529], instead of [2 18] -
> > corrected Looking for lost files:
> > vpf-10670: The file [25 93091] has the wrong size in the StatData (30352)
> > - corrected to (36864)
> > vpf-10680: The file [25 93091] has the wrong block count in the StatData
> > (64) - corrected to (72)
> > vpf-10680: The file [25 111982] has the wrong block count in the StatData
> > (75408) - corrected to (16872)
> > vpf-10680: The file [3127 59061] has the wrong block count in the
> > StatData (8) - corrected to (0)
> > vpf-10680: The file [3128 72300] has the wrong block count in the
> > StatData (8) - corrected to (0)
> > vpf-10680: The file [3620 18950] has the wrong block count in the
> > StatData (8) - corrected to (0)
> > ...
> > ...
> > ...
> > rewrite_file: 2 items of file [994350 994764] moved to [994350 3108]
> > rewrite_file: 2 items of file [994350 994765] moved to [994350 3109]
> > rewrite_file: 2 items of file [994350 994766] moved to [994350 3110]
> > Flushing..finished
> >         Objects without names 18403
> >         Empty lost dirs removed 384
> >         Dirs linked to /lost+found: 2174
> >                 Dirs without stat data found 83
> >         Files linked to /lost+found 16229
> >         Objects having used objectids: 49
> >                 files fixed 47
> >                 dirs fixed 2
> > Pass 4 - finished   done 1476, 37 /sec
> >         Deleted unreachable items 716
> > Flushing..finished
> > Syncing..finished
> > ###########
> > reiserfsck finished at Tue Feb  8 17:40:05 2005
> > ###########

-- 

Mit freundlichen Grüßen

C. Placzek

----------------------------------------------
Dipl.-Ing. Christian Placzek

Email: kris@cp-data.de    
   
Anschrift:    
Von-Görschen-Str. 19   
52066 Aachen    
   
Tel.: +49 241 9964681
Fax:  +49 241 514388    
Mobil:+49 179 1083808    

Re: reiserfs3 rebuild-tree successful but no files

[Christian Placzek]

On Wednesday 09 February 2005 10:34, you wrote:
> Christian Placzek wrote:
> >On Wednesday 09 February 2005 09:47, you wrote:
> >>Hello
> >>
> >>On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> >>>Hello,
> >>>
> >>>a friend of mine shredded his data (70GB) when he tried to undelete an
> >>>accidentally deleted file. He normally works with windoze. Therefore he
> >>>didn't know he couldn't undelete a file on a reiserfs partition with
> >>> ext2 undelete tool %-(
> >>>When he called me it was already too late. He had overwritten the
> >>>superblock :-(
> >>>
> >>>I'm still trying to rescue the data. I can see them in the image using
> >>>grep or hexedit. But nothing I tried has been successful. My first steps
> >>>were unmounting the partition, taking an image and working with a copy
> >>> of this image using a loop back device.
> >>>
> >>>All files have been retrieved but were removed by reiserfsck --check
> >>>although the last output says that directories and files have been
> >>> linked (see below). I tried with many combinations nearly all
> >>> parameters of reiserfsck: --fix-fixable --no-journal-available -S ...
> >>
> >>have you tried
> >>reiserfsck --rebuild-tree -S
> >>?
> >>If not, run it on newly created copy of shredded device.
> >
> >Yes, I did. The output of reiserfsck --rebuild-tree gave other numbers of
> >linked directories/files. But I can't see them.
> >
> >>Did you look at lost+found?
> >
> >Shure, see below.
>
> Sorry, but what does df  -T say?
> Does it say that  reiserfs filesystem is mounted on /mnt/temp1?
No, it replied:
# /dev/loop/0   ext2    69529276        20  65997368   1% /mnt/temp1

If I force mount with -t reiserfs it says:
root@marvin:/home/kris 0$ # mount -o ro -t reiserfs /dev/loop/0 /mnt/temp1/
mount: wrong fs type, bad option, bad superblock on /dev/loop/0,
       or too many mounted file systems

Thanks, this is a good hint, but I don't know how to change the identifier of 
the filesystem. I know that normally mkfs.* does this task, but my friend's 
overwriting of the superblock probably has changed the identifier of the 
filesystem. Is it possible to apply mkreiserfs on the image whithout running 
the risk to lose any data?

Thanks
Kris


>
> Thanks,
> Lena.
>
> >>>I mounted the image after each operation, but all I can see is:
> >>>
> >>>root@marvin:/home/kris 0$ # mount -o ro /dev/loop/0 /mnt/temp1/
> >>>root@marvin:/home/kris 0$ # ls -la /mnt/temp1/
> >>>total 21
> >>>drwxr-xr-x   3 root root  4096 Jan 20 11:36 .
> >>>drwxr-xr-x  39 root root   968 Feb  6 14:12 ..
> >>>drwx------   2 root root 16384 Jan 20 11:36 lost+found
> >>>root@marvin:/home/kris 0$ # ls -la /mnt/temp1/lost+found/
> >>>total 20
> >>>drwx------  2 root root 16384 Jan 20 11:36 .
> >>>drwxr-xr-x  3 root root  4096 Jan 20 11:36 ..
> >>>root@marvin:/home/kris 0$ #
> >>>
> >>>
> >>>Do you have any suggestions how to rescue the data?
> >>>
> >>>Regards
> >>>  Kris
> >>>
> >>>
> >>>
> >>>Here you see a typical output:
> >>>
> >>>root@marvin:/home/kris 0$ # losetup /dev/loop/0 /mnt/temp/data.x.dd
> >>>root@marvin:/home/kris 0$ # reiserfsck /dev/loop/0 --rebuild-tree
> >>>reiserfsck 3.6.19 (2003 www.namesys.com)
> >>>
> >>><snip>
> >>>
> >>>Will rebuild the filesystem (/dev/loop/0) tree
> >>>Will put log info to 'stdout'
> >>>
> >>>Do you want to run this program?[N/Yes] (note need to type Yes if you
> >>>do):Yes
> >>>
> >>>reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
> >>>Failed to open the filesystem.
> >>>
> >>>If the partition table has not been changed, and the partition is
> >>>valid  and  it really  contains  a reiserfs  partition,  then the
> >>>superblock  is corrupted and you need to run this utility with
> >>>--rebuild-sb.
> >>>
> >>>root@marvin:/home/kris 8$ # reiserfsck /dev/loop/0 --rebuild-sb
> >>>reiserfsck 3.6.19 (2003 www.namesys.com)
> >>>
> >>><snip>
> >>>
> >>>Will check superblock and rebuild it if needed
> >>>Will put log info to 'stdout'
> >>>
> >>>reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
> >>>
> >>>what the version of ReiserFS do you use[1-4]
> >>>        (1)   3.6.x
> >>>        (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux
> >>>2.2, choose this one)
> >>>        (3) < 3.5.9 converted to new format (don't choose if unsure)
> >>>        (4) < 3.5.9 (this is very old format, don't choose if unsure)
> >>>        (X)   exit
> >>>1
> >>>
> >>>Enter block size [4096]:
> >>>
> >>>
> >>>No journal device was specified. (If journal is not available, re-run
> >>>with --no-journal-available option specified).
> >>>Is journal default? (y/n)[y]:
> >>>
> >>>Did you use resizer(y/n)[n]:
> >>>rebuild-sb: no uuid found, a new uuid was generated
> >>>(7e253707-4fef-42aa-9785-b1cd079851af)
> >>>
> >>>rebuild-sb: You either have a corrupted journal or have just changed
> >>>the start of the partition with some partition table editor. If you are
> >>>sure that the start of the partition is ok, rebuild the journal header.
> >>>Do you want to rebuild the journal header? (y/n)[n]: y
> >>>Reiserfs super block in block 16 on 0x700 of format 3.6 with standard
> >>>journal Count of blocks on the device: 17659440
> >>>Number of bitmaps: 539
> >>>Blocksize: 4096
> >>>Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
> >>>blocks): 0
> >>>Root block: 0
> >>>Filesystem is NOT clean
> >>>Tree height: 0
> >>>Hash function used to sort names: not set
> >>>Objectid map size 0, 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: 0x1:
> >>>         some corruptions exist.
> >>>sb_version: 2
> >>>inode generation number: 0
> >>>UUID: 7e253707-4fef-42aa-9785-b1cd079851af
> >>>LABEL:
> >>>Set flags in SB:
> >>>Is this ok ? (y/n)[n]: y
> >>>The fs may still be unconsistent. Run reiserfsck --check.
> >>>
> >>>root@marvin:/home/kris 1$ # reiserfsck /dev/loop/0 --check
> >>>reiserfsck 3.6.19 (2003 www.namesys.com)
> >>>
> >>><snip>
> >>>
> >>>Will read-only check consistency of the filesystem on /dev/loop/0
> >>>Will put log info to 'stdout'
> >>>###########
> >>>reiserfsck --check started at Tue Feb  8 17:17:31 2005
> >>>###########
> >>>Replaying journal..
> >>>Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> >>>replayed Zero bit found in on-disk bitmap after the last valid bit.
> >>>Checking internal tree..
> >>>
> >>>Bad root block 0. (--rebuild-tree did not complete)
> >>>
> >>>Aborted
> >>>root@marvin:/home/kris 134$ # reiserfsck /dev/loop/0 -y --rebuild-tree
> >>>reiserfsck 3.6.19 (2003 www.namesys.com)
> >>>
> >>><snip>
> >>>
> >>>Will rebuild the filesystem (/dev/loop/0) tree
> >>>Will put log info to 'stdout'
> >>>
> >>>Do you want to run this program?[N/Yes] (note need to type Yes if you
> >>>do):Yes Replaying journal..
> >>>Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> >>>replayed Zero bit found in on-disk bitmap after the last valid bit.
> >>>Fixed. ###########
> >>>reiserfsck --rebuild-tree started at Tue Feb  8 17:37:56 2005
> >>>###########
> >>>
> >>>Pass 0:
> >>>####### Pass 0 #######
> >>>Loading on-disk bitmap .. ok, 559628 blocks marked used
> >>>init_source_bitmap: Bitmap 0 (of 32768 bits) is wrong - mark all blocks
> >>>[0 - 32768] as used
> >>>init_source_bitmap: Bitmap 1 (of 32768 bits) is wrong - mark all blocks
> >>> [32768 - 65536] as used
> >>>init_source_bitmap: Bitmap 3 (of 32768 bits) is wrong - mark all blocks
> >>> [98304 - 131072] as used
> >>>init_source_bitmap: Bitmap 5 (of 32768 bits) is wrong - mark all blocks
> >>>[163840 - 196608] as used
> >>>init_source_bitmap: Bitmap 7 (of 32768 bits) is wrong - mark all blocks
> >>>[229376 - 262144] as used
> >>>init_source_bitmap: Bitmap 9 (of 32768 bits) is wrong - mark all blocks
> >>>[294912 - 327680] as used
> >>>init_source_bitmap: Bitmap 25 (of 32768 bits) is wrong - mark all blocks
> >>>[819200 - 851968] as used
> >>>init_source_bitmap: Bitmap 27 (of 32768 bits) is wrong - mark all blocks
> >>>[884736 - 917504] as used
> >>>init_source_bitmap: Bitmap 49 (of 32768 bits) is wrong - mark all blocks
> >>>[1605632 - 1638400] as used
> >>>init_source_bitmap: Bitmap 81 (of 32768 bits) is wrong - mark all blocks
> >>>[2654208 - 2686976] as used
> >>>init_source_bitmap: Bitmap 125 (of 32768 bits) is wrong - mark all
> >>> blocks [4096000 - 4128768] as used
> >>>init_source_bitmap: Bitmap 243 (of 32768 bits) is wrong - mark all
> >>> blocks [7962624 - 7995392] as used
> >>>init_source_bitmap: Bitmap 343 (of 32768 bits) is wrong - mark all
> >>> blocks [11239424 - 11272192] as used
> >>>Skipping 8749 blocks (super block, journal, bitmaps) 687599 blocks will
> >>>be read
> >>>0%....20%....40%....60%....80%....100%                        left 0,
> >>>9549 /sec
> >>>103101 directory entries were hashed with "r5" hash.
> >>>Selected hash ("r5") does not match to the hash set in the super block
> >>>(not set).
> >>>        "r5" hash is selected
> >>>Flushing..finished
> >>>        Read blocks (but not data blocks) 687599
> >>>                Leaves among those 20621
> >>>                Objectids found 114185
> >>>
> >>>Pass 1 (will try to insert 20621 leaves):
> >>>####### Pass 1 #######
> >>>Looking for allocable blocks .. finished
> >>>0%....20%....40%....60%....80%....100%                        left 0,
> >>>1718 /sec
> >>>Flushing..finished
> >>>        20621 leaves read
> >>>                20524 inserted
> >>>                        - pointers in indirect items pointing to
> >>> metadata 3 (zeroed)
> >>>                97 not inserted
> >>>        non-unique pointers in indirect items (zeroed) 1075
> >>>####### Pass 2 #######
> >>>
> >>>Pass 2:
> >>>0%....20%....40%....60%vpf-10260: The file we are inserting the new item
> >>>(69291 69327 0x1 DRCT (2), len 216, location 3880 entry count 65535,
> >>> fsck need 0, format new) into has no StatData, insertion was skipped
> >>> ....vpf-10260: The file we are inserting the new item (240148 240150
> >>> 0x1 IND (1), len 1844, location 2252 entry count 0, fsck need 0, format
> >>> new) into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (241304 319211 0x43001
> >>>IND (1), len 492, location 3604 entry count 0, fsck need 0, format new)
> >>>into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (737518 739813 0xe6001
> >>>IND (1), len 688, location 3408 entry count 0, fsck need 0, format new)
> >>>into has no StatData, insertion was skipped
> >>>80%vpf-10260: The file we are inserting the new item (737518 739813
> >>>0xe6001 IND (1), len 688, location 3408 entry count 0, fsck need 0,
> >>>format new) into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (25 93014 0x1e1 DRCT
> >>>(2), len 1408, location 2688 entry count 65535, fsck need 0, format new)
> >>>intohas no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (238343 319306
> >>> 0x3f4001 IND (1), len 136, location 3960 entry count 0, fsck need 0,
> >>> format new) into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (94077 119920 0x1 DRCT
> >>>(2), len 456, location 3640 entry count 65535, fsck need 0, format new)
> >>>into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (102491 220397 0x179
> >>>DRCT (2), len 1264, location 2832 entry count 65535, fsck need 0, format
> >>>new)into has no StatData, insertion was skipped
> >>>.vpf-10260: The file we are inserting the new item (642448 771721 0xcc1
> >>>DRCT (2), len 520, location 3576 entry count 65535, fsck need 0, format
> >>>new)into has no StatData, insertion was skipped
> >>>.vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new)into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new) into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new) into has no StatData, insertion was skipped
> >>>.vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new)into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new) into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new) into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new) into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new) into has no StatData, insertion was skipped
> >>>.vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new)into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new) into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new) into has no StatData, insertion was skipped
> >>>vpf-10260: The file we are inserting the new item (294390 692752 0x129
> >>>DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> >>>new) into has no StatData, insertion was skipped
> >>>100%                           left 0, 0 /sec
> >>>Flushing..finished
> >>>        Leaves inserted item by item 97
> >>>Pass 3 (semantic):
> >>>####### Pass 3 #########
> >>>/binrebuild_semantic_pass: The entry [3636 189939] ("ls") in directory
> >>> [2 3636] points to nowhere - is removed
> >>>/javarebuild_semantic_pass: The entry [107571 597512] ("jre") in
> >>>directory [3636 107571] points to nowhere - is removed
> >>>vpf-10650: The directory [3636 107571] has the wrong size in the
> >>> StatData (72) - corrected to (48)
> >>>vpf-10650: The directory [2 3636] has the wrong size in the StatData
> >>>(2920) - corrected to (2896)
> >>>/devrebuild_semantic_pass: The entry [6 554632] ("lvm") in directory [2
> >>>6] points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [6 52003] ("lirc") in directory [2 6]
> >>>points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [6 72207] ("scsi") in directory [2 6]
> >>>points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [6 50738] ("xdb5") in directory [2 6]
> >>>points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [6 50739] ("xdb6") in directory [2 6]
> >>>points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [6 50740] ("xdb7") in directory [2 6]
> >>>points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [6 50741] ("xdb8") in directory [2 6]
> >>>points to nowhere - is removed
> >>>...
> >>>... (here follow hundreds of directories and thousends of files, too,
> >>>...  which I removed)
> >>>...
> >>>The entry [994339 994340] ("Entries") in directory [994335 19] updated
> >>> to point to [994339 49]
> >>>/Entries.Extra.Oldrewrite_file: 1 items of file [994339 994343] moved to
> >>>[994339 50]
> >>>The entry [994339 994343] ("Entries.Extra.Old") in directory [994335 19]
> >>>updated to point to [994339 50]
> >>>relocate_dir: Moving [994350 994773 0x0 SD (0)] to [994350 51 0x0 SD
> >>> (0)] relocate_dir: Moving [994350 994773 0x1 DIR (3)] to [994350 51 0x1
> >>> DIR (3)] /994350_51get_next_directory_item: The entry ".." of the
> >>> directory [994350 51] pointes to [285394 994350], instead of [2 18] -
> >>> corrected rebuild_semantic_pass: The entry [994773 994783] ("Root") in
> >>> directory [994350 51] points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [994773 994776] ("Entries.Extra") in
> >>>directory [994350 51] points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [994773 994782] ("Repository") in
> >>>directory [994350 51] points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [994773 994779]
> >>>("Entries.Extra.Old.bak") in directory [994350 51] points to nowhere -
> >>> is removed
> >>>rebuild_semantic_pass: The entry [994773 994784] ("Root.bak") in
> >>>directory [994350 51] points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [994773 994780] ("Entries.Old") in
> >>>directory [994350 51] points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [994773 994775] ("Entries.bak") in
> >>>directory [994350 51] points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [994773 994781] ("Entries.Old.bak") in
> >>>directory [994350 51] points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [994773 994778] ("Entries.Extra.Old")
> >>> in directory [994350 51] points to nowhere - is removed
> >>>rebuild_semantic_pass: The entry [994773 994777] ("Entries.Extra.bak")
> >>> in directory [994350 51] points to nowhere - is removed
> >>>vpf-10650: The directory [994350 51] has the wrong size in the StatData
> >>>(400) - corrected to (72)
> >>>/994395_994396get_next_directory_item: The entry ".." of the directory
> >>> [994395 994396] pointes to [684030 994395], instead of [2 18] -
> >>>corrected /994415_994416get_next_directory_item: The entry ".." of the
> >>>directory [994415 994416] pointes to [684030 994415], instead of [2 18]
> >>> - corrected /994529_994754get_next_directory_item: The entry ".." of
> >>> the directory [994529 994754] pointes to [984867 994529], instead of [2
> >>> 18] - corrected Looking for lost files:
> >>>vpf-10670: The file [25 93091] has the wrong size in the StatData
> >>> (30352) - corrected to (36864)
> >>>vpf-10680: The file [25 93091] has the wrong block count in the StatData
> >>>(64) - corrected to (72)
> >>>vpf-10680: The file [25 111982] has the wrong block count in the
> >>> StatData (75408) - corrected to (16872)
> >>>vpf-10680: The file [3127 59061] has the wrong block count in the
> >>>StatData (8) - corrected to (0)
> >>>vpf-10680: The file [3128 72300] has the wrong block count in the
> >>>StatData (8) - corrected to (0)
> >>>vpf-10680: The file [3620 18950] has the wrong block count in the
> >>>StatData (8) - corrected to (0)
> >>>...
> >>>...
> >>>...
> >>>rewrite_file: 2 items of file [994350 994764] moved to [994350 3108]
> >>>rewrite_file: 2 items of file [994350 994765] moved to [994350 3109]
> >>>rewrite_file: 2 items of file [994350 994766] moved to [994350 3110]
> >>>Flushing..finished
> >>>        Objects without names 18403
> >>>        Empty lost dirs removed 384
> >>>        Dirs linked to /lost+found: 2174
> >>>                Dirs without stat data found 83
> >>>        Files linked to /lost+found 16229
> >>>        Objects having used objectids: 49
> >>>                files fixed 47
> >>>                dirs fixed 2
> >>>Pass 4 - finished   done 1476, 37 /sec
> >>>        Deleted unreachable items 716
> >>>Flushing..finished
> >>>Syncing..finished
> >>>###########
> >>>reiserfsck finished at Tue Feb  8 17:40:05 2005
> >>>###########

-- 

Mit freundlichen Grüßen

C. Placzek

----------------------------------------------
Dipl.-Ing. Christian Placzek

Email: kris@cp-data.de    
   
Anschrift:    
Von-Görschen-Str. 19   
52066 Aachen    
   
Tel.: +49 241 9964681
Fax:  +49 241 514388    
Mobil:+49 179 1083808    

Re: reiserfs3 rebuild-tree successful but no files

[Vladimir Saveliev]

Hello

On Wed, 2005-02-09 at 14:56, Christian Placzek wrote:
> On Wednesday 09 February 2005 10:34, you wrote:
> >
> > Sorry, but what does df  -T say?
> > Does it say that  reiserfs filesystem is mounted on /mnt/temp1?
> No, it replied:
> # /dev/loop/0   ext2    69529276        20  65997368   1% /mnt/temp1
> 
> If I force mount with -t reiserfs it says:
> root@marvin:/home/kris 0$ # mount -o ro -t reiserfs /dev/loop/0 /mnt/temp1/
> mount: wrong fs type, bad option, bad superblock on /dev/loop/0,
>        or too many mounted file systems
> 

what does dmesg say after mount attempt?

> Thanks, this is a good hint, but I don't know how to change the identifier of 
> the filesystem. I know that normally mkfs.* does this task, but my friend's 
> overwriting of the superblock probably has changed the identifier of the 
> filesystem. Is it possible to apply mkreiserfs on the image whithout running 
> the risk to lose any data?
> 

Re: reiserfs3 rebuild-tree successful but no files

[Vladimir Saveliev]

Hello

On Wed, 2005-02-09 at 12:04, Christian Placzek wrote:
> On Wednesday 09 February 2005 09:47, you wrote:
> > Hello
> >
> > On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> > > Hello,
> > >
> > > a friend of mine shredded his data (70GB) when he tried to undelete an
> > > accidentally deleted file. He normally works with windoze. Therefore he
> > > didn't know he couldn't undelete a file on a reiserfs partition with ext2
> > > undelete tool %-(
> > > When he called me it was already too late. He had overwritten the
> > > superblock :-(
> > >
> > > I'm still trying to rescue the data. I can see them in the image using
> > > grep or hexedit. But nothing I tried has been successful. My first steps
> > > were unmounting the partition, taking an image and working with a copy of
> > > this image using a loop back device.
> > >
> > > All files have been retrieved but were removed by reiserfsck --check
> > > although the last output says that directories and files have been linked
> > > (see below). I tried with many combinations nearly all parameters of
> > > reiserfsck: --fix-fixable --no-journal-available -S ...
> >
> > have you tried
> > reiserfsck --rebuild-tree -S
> > ?
> > If not, run it on newly created copy of shredded device.
> >
> Yes, I did. The output of reiserfsck --rebuild-tree gave other numbers of 
> linked directories/files. But I can't see them.
> 
> > Did you look at lost+found?
> Shure, see below.
> 

can you do
debugreiserfs -p -S /dev/shredded | bzip2 -c > meta.bz2

and let us to download meta.bz2 so that we can take a look why
lost+found gets emptied.
> 
> 
> >
> > > I mounted the image after each operation, but all I can see is:
> > >
> > > root@marvin:/home/kris 0$ # mount -o ro /dev/loop/0 /mnt/temp1/
> > > root@marvin:/home/kris 0$ # ls -la /mnt/temp1/
> > > total 21
> > > drwxr-xr-x   3 root root  4096 Jan 20 11:36 .
> > > drwxr-xr-x  39 root root   968 Feb  6 14:12 ..
> > > drwx------   2 root root 16384 Jan 20 11:36 lost+found
> > > root@marvin:/home/kris 0$ # ls -la /mnt/temp1/lost+found/
> > > total 20
> > > drwx------  2 root root 16384 Jan 20 11:36 .
> > > drwxr-xr-x  3 root root  4096 Jan 20 11:36 ..
> > > root@marvin:/home/kris 0$ #
> > >
> > >
> > > Do you have any suggestions how to rescue the data?
> > >
> > > Regards
> > >   Kris
> > >
> > >
> > >
> > > Here you see a typical output:
> > >
> > > root@marvin:/home/kris 0$ # losetup /dev/loop/0 /mnt/temp/data.x.dd
> > > root@marvin:/home/kris 0$ # reiserfsck /dev/loop/0 --rebuild-tree
> > > reiserfsck 3.6.19 (2003 www.namesys.com)
> > >
> > > <snip>
> > >
> > > Will rebuild the filesystem (/dev/loop/0) tree
> > > Will put log info to 'stdout'
> > >
> > > Do you want to run this program?[N/Yes] (note need to type Yes if you
> > > do):Yes
> > >
> > > reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
> > > Failed to open the filesystem.
> > >
> > > If the partition table has not been changed, and the partition is
> > > valid  and  it really  contains  a reiserfs  partition,  then the
> > > superblock  is corrupted and you need to run this utility with
> > > --rebuild-sb.
> > >
> > > root@marvin:/home/kris 8$ # reiserfsck /dev/loop/0 --rebuild-sb
> > > reiserfsck 3.6.19 (2003 www.namesys.com)
> > >
> > > <snip>
> > >
> > > Will check superblock and rebuild it if needed
> > > Will put log info to 'stdout'
> > >
> > > reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
> > >
> > > what the version of ReiserFS do you use[1-4]
> > >         (1)   3.6.x
> > >         (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux
> > > 2.2, choose this one)
> > >         (3) < 3.5.9 converted to new format (don't choose if unsure)
> > >         (4) < 3.5.9 (this is very old format, don't choose if unsure)
> > >         (X)   exit
> > > 1
> > >
> > > Enter block size [4096]:
> > >
> > >
> > > No journal device was specified. (If journal is not available, re-run
> > > with --no-journal-available option specified).
> > > Is journal default? (y/n)[y]:
> > >
> > > Did you use resizer(y/n)[n]:
> > > rebuild-sb: no uuid found, a new uuid was generated
> > > (7e253707-4fef-42aa-9785-b1cd079851af)
> > >
> > > rebuild-sb: You either have a corrupted journal or have just changed
> > > the start of the partition with some partition table editor. If you are
> > > sure that the start of the partition is ok, rebuild the journal header.
> > > Do you want to rebuild the journal header? (y/n)[n]: y
> > > Reiserfs super block in block 16 on 0x700 of format 3.6 with standard
> > > journal Count of blocks on the device: 17659440
> > > Number of bitmaps: 539
> > > Blocksize: 4096
> > > Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
> > > blocks): 0
> > > Root block: 0
> > > Filesystem is NOT clean
> > > Tree height: 0
> > > Hash function used to sort names: not set
> > > Objectid map size 0, 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: 0x1:
> > >          some corruptions exist.
> > > sb_version: 2
> > > inode generation number: 0
> > > UUID: 7e253707-4fef-42aa-9785-b1cd079851af
> > > LABEL:
> > > Set flags in SB:
> > > Is this ok ? (y/n)[n]: y
> > > The fs may still be unconsistent. Run reiserfsck --check.
> > >
> > > root@marvin:/home/kris 1$ # reiserfsck /dev/loop/0 --check
> > > reiserfsck 3.6.19 (2003 www.namesys.com)
> > >
> > > <snip>
> > >
> > > Will read-only check consistency of the filesystem on /dev/loop/0
> > > Will put log info to 'stdout'
> > > ###########
> > > reiserfsck --check started at Tue Feb  8 17:17:31 2005
> > > ###########
> > > Replaying journal..
> > > Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> > > replayed Zero bit found in on-disk bitmap after the last valid bit.
> > > Checking internal tree..
> > >
> > > Bad root block 0. (--rebuild-tree did not complete)
> > >
> > > Aborted
> > > root@marvin:/home/kris 134$ # reiserfsck /dev/loop/0 -y --rebuild-tree
> > > reiserfsck 3.6.19 (2003 www.namesys.com)
> > >
> > > <snip>
> > >
> > > Will rebuild the filesystem (/dev/loop/0) tree
> > > Will put log info to 'stdout'
> > >
> > > Do you want to run this program?[N/Yes] (note need to type Yes if you
> > > do):Yes Replaying journal..
> > > Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> > > replayed Zero bit found in on-disk bitmap after the last valid bit.
> > > Fixed. ###########
> > > reiserfsck --rebuild-tree started at Tue Feb  8 17:37:56 2005
> > > ###########
> > >
> > > Pass 0:
> > > ####### Pass 0 #######
> > > Loading on-disk bitmap .. ok, 559628 blocks marked used
> > > init_source_bitmap: Bitmap 0 (of 32768 bits) is wrong - mark all blocks
> > > [0 - 32768] as used
> > > init_source_bitmap: Bitmap 1 (of 32768 bits) is wrong - mark all blocks
> > >  [32768 - 65536] as used
> > > init_source_bitmap: Bitmap 3 (of 32768 bits) is wrong - mark all blocks
> > >  [98304 - 131072] as used
> > > init_source_bitmap: Bitmap 5 (of 32768 bits) is wrong - mark all blocks
> > > [163840 - 196608] as used
> > > init_source_bitmap: Bitmap 7 (of 32768 bits) is wrong - mark all blocks
> > > [229376 - 262144] as used
> > > init_source_bitmap: Bitmap 9 (of 32768 bits) is wrong - mark all blocks
> > > [294912 - 327680] as used
> > > init_source_bitmap: Bitmap 25 (of 32768 bits) is wrong - mark all blocks
> > > [819200 - 851968] as used
> > > init_source_bitmap: Bitmap 27 (of 32768 bits) is wrong - mark all blocks
> > > [884736 - 917504] as used
> > > init_source_bitmap: Bitmap 49 (of 32768 bits) is wrong - mark all blocks
> > > [1605632 - 1638400] as used
> > > init_source_bitmap: Bitmap 81 (of 32768 bits) is wrong - mark all blocks
> > > [2654208 - 2686976] as used
> > > init_source_bitmap: Bitmap 125 (of 32768 bits) is wrong - mark all blocks
> > > [4096000 - 4128768] as used
> > > init_source_bitmap: Bitmap 243 (of 32768 bits) is wrong - mark all blocks
> > > [7962624 - 7995392] as used
> > > init_source_bitmap: Bitmap 343 (of 32768 bits) is wrong - mark all blocks
> > > [11239424 - 11272192] as used
> > > Skipping 8749 blocks (super block, journal, bitmaps) 687599 blocks will
> > > be read
> > > 0%....20%....40%....60%....80%....100%                        left 0,
> > > 9549 /sec
> > > 103101 directory entries were hashed with "r5" hash.
> > > Selected hash ("r5") does not match to the hash set in the super block
> > > (not set).
> > >         "r5" hash is selected
> > > Flushing..finished
> > >         Read blocks (but not data blocks) 687599
> > >                 Leaves among those 20621
> > >                 Objectids found 114185
> > >
> > > Pass 1 (will try to insert 20621 leaves):
> > > ####### Pass 1 #######
> > > Looking for allocable blocks .. finished
> > > 0%....20%....40%....60%....80%....100%                        left 0,
> > > 1718 /sec
> > > Flushing..finished
> > >         20621 leaves read
> > >                 20524 inserted
> > >                         - pointers in indirect items pointing to metadata
> > > 3 (zeroed)
> > >                 97 not inserted
> > >         non-unique pointers in indirect items (zeroed) 1075
> > > ####### Pass 2 #######
> > >
> > > Pass 2:
> > > 0%....20%....40%....60%vpf-10260: The file we are inserting the new item
> > > (69291 69327 0x1 DRCT (2), len 216, location 3880 entry count 65535, fsck
> > > need 0, format new) into has no StatData, insertion was skipped
> > > ....vpf-10260: The file we are inserting the new item (240148 240150 0x1
> > > IND (1), len 1844, location 2252 entry count 0, fsck need 0, format new)
> > > into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (241304 319211 0x43001
> > > IND (1), len 492, location 3604 entry count 0, fsck need 0, format new)
> > > into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (737518 739813 0xe6001
> > > IND (1), len 688, location 3408 entry count 0, fsck need 0, format new)
> > > into has no StatData, insertion was skipped
> > > 80%vpf-10260: The file we are inserting the new item (737518 739813
> > > 0xe6001 IND (1), len 688, location 3408 entry count 0, fsck need 0,
> > > format new) into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (25 93014 0x1e1 DRCT
> > > (2), len 1408, location 2688 entry count 65535, fsck need 0, format new)
> > > intohas no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (238343 319306 0x3f4001
> > > IND (1), len 136, location 3960 entry count 0, fsck need 0, format new)
> > > into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (94077 119920 0x1 DRCT
> > > (2), len 456, location 3640 entry count 65535, fsck need 0, format new)
> > > into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (102491 220397 0x179
> > > DRCT (2), len 1264, location 2832 entry count 65535, fsck need 0, format
> > > new)into has no StatData, insertion was skipped
> > > .vpf-10260: The file we are inserting the new item (642448 771721 0xcc1
> > > DRCT (2), len 520, location 3576 entry count 65535, fsck need 0, format
> > > new)into has no StatData, insertion was skipped
> > > .vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new)into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new) into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new) into has no StatData, insertion was skipped
> > > .vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new)into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new) into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new) into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new) into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new) into has no StatData, insertion was skipped
> > > .vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new)into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new) into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new) into has no StatData, insertion was skipped
> > > vpf-10260: The file we are inserting the new item (294390 692752 0x129
> > > DRCT (2), len 296, location 3800 entry count 65535, fsck need 0, format
> > > new) into has no StatData, insertion was skipped
> > > 100%                           left 0, 0 /sec
> > > Flushing..finished
> > >         Leaves inserted item by item 97
> > > Pass 3 (semantic):
> > > ####### Pass 3 #########
> > > /binrebuild_semantic_pass: The entry [3636 189939] ("ls") in directory [2
> > > 3636] points to nowhere - is removed
> > > /javarebuild_semantic_pass: The entry [107571 597512] ("jre") in
> > > directory [3636 107571] points to nowhere - is removed
> > > vpf-10650: The directory [3636 107571] has the wrong size in the StatData
> > >  (72) - corrected to (48)
> > > vpf-10650: The directory [2 3636] has the wrong size in the StatData
> > > (2920) - corrected to (2896)
> > > /devrebuild_semantic_pass: The entry [6 554632] ("lvm") in directory [2
> > > 6] points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [6 52003] ("lirc") in directory [2 6]
> > > points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [6 72207] ("scsi") in directory [2 6]
> > > points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [6 50738] ("xdb5") in directory [2 6]
> > > points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [6 50739] ("xdb6") in directory [2 6]
> > > points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [6 50740] ("xdb7") in directory [2 6]
> > > points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [6 50741] ("xdb8") in directory [2 6]
> > > points to nowhere - is removed
> > > ...
> > > ... (here follow hundreds of directories and thousends of files, too,
> > > ...  which I removed)
> > > ...
> > > The entry [994339 994340] ("Entries") in directory [994335 19] updated to
> > > point to [994339 49]
> > > /Entries.Extra.Oldrewrite_file: 1 items of file [994339 994343] moved to
> > > [994339 50]
> > > The entry [994339 994343] ("Entries.Extra.Old") in directory [994335 19]
> > > updated to point to [994339 50]
> > > relocate_dir: Moving [994350 994773 0x0 SD (0)] to [994350 51 0x0 SD (0)]
> > > relocate_dir: Moving [994350 994773 0x1 DIR (3)] to [994350 51 0x1 DIR
> > > (3)] /994350_51get_next_directory_item: The entry ".." of the directory
> > > [994350 51] pointes to [285394 994350], instead of [2 18] - corrected
> > > rebuild_semantic_pass: The entry [994773 994783] ("Root") in directory
> > >  [994350 51] points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [994773 994776] ("Entries.Extra") in
> > > directory [994350 51] points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [994773 994782] ("Repository") in
> > > directory [994350 51] points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [994773 994779]
> > > ("Entries.Extra.Old.bak") in directory [994350 51] points to nowhere - is
> > > removed
> > > rebuild_semantic_pass: The entry [994773 994784] ("Root.bak") in
> > > directory [994350 51] points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [994773 994780] ("Entries.Old") in
> > > directory [994350 51] points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [994773 994775] ("Entries.bak") in
> > > directory [994350 51] points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [994773 994781] ("Entries.Old.bak") in
> > > directory [994350 51] points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [994773 994778] ("Entries.Extra.Old") in
> > > directory [994350 51] points to nowhere - is removed
> > > rebuild_semantic_pass: The entry [994773 994777] ("Entries.Extra.bak") in
> > > directory [994350 51] points to nowhere - is removed
> > > vpf-10650: The directory [994350 51] has the wrong size in the StatData
> > > (400) - corrected to (72)
> > > /994395_994396get_next_directory_item: The entry ".." of the directory
> > >  [994395 994396] pointes to [684030 994395], instead of [2 18] -
> > > corrected /994415_994416get_next_directory_item: The entry ".." of the
> > > directory [994415 994416] pointes to [684030 994415], instead of [2 18] -
> > > corrected /994529_994754get_next_directory_item: The entry ".." of the
> > > directory [994529 994754] pointes to [984867 994529], instead of [2 18] -
> > > corrected Looking for lost files:
> > > vpf-10670: The file [25 93091] has the wrong size in the StatData (30352)
> > > - corrected to (36864)
> > > vpf-10680: The file [25 93091] has the wrong block count in the StatData
> > > (64) - corrected to (72)
> > > vpf-10680: The file [25 111982] has the wrong block count in the StatData
> > > (75408) - corrected to (16872)
> > > vpf-10680: The file [3127 59061] has the wrong block count in the
> > > StatData (8) - corrected to (0)
> > > vpf-10680: The file [3128 72300] has the wrong block count in the
> > > StatData (8) - corrected to (0)
> > > vpf-10680: The file [3620 18950] has the wrong block count in the
> > > StatData (8) - corrected to (0)
> > > ...
> > > ...
> > > ...
> > > rewrite_file: 2 items of file [994350 994764] moved to [994350 3108]
> > > rewrite_file: 2 items of file [994350 994765] moved to [994350 3109]
> > > rewrite_file: 2 items of file [994350 994766] moved to [994350 3110]
> > > Flushing..finished
> > >         Objects without names 18403
> > >         Empty lost dirs removed 384
> > >         Dirs linked to /lost+found: 2174
> > >                 Dirs without stat data found 83
> > >         Files linked to /lost+found 16229
> > >         Objects having used objectids: 49
> > >                 files fixed 47
> > >                 dirs fixed 2
> > > Pass 4 - finished   done 1476, 37 /sec
> > >         Deleted unreachable items 716
> > > Flushing..finished
> > > Syncing..finished
> > > ###########
> > > reiserfsck finished at Tue Feb  8 17:40:05 2005
> > > ###########

Re: reiserfs3 rebuild-tree successful but no files

[Christian Placzek]

On Wednesday 09 February 2005 13:01, Vladimir Saveliev wrote:
> Hello
>
> On Wed, 2005-02-09 at 12:04, Christian Placzek wrote:
> > On Wednesday 09 February 2005 09:47, you wrote:
> > > Hello
> > >
> > > On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> > > > Hello,
> > > >
> > > > a friend of mine shredded his data (70GB) when he tried to undelete
> > > > an accidentally deleted file. He normally works with windoze.
> > > > Therefore he didn't know he couldn't undelete a file on a reiserfs
> > > > partition with ext2 undelete tool %-(
> > > > When he called me it was already too late. He had overwritten the
> > > > superblock :-(
> > > >
> > > > I'm still trying to rescue the data. I can see them in the image
> > > > using grep or hexedit. But nothing I tried has been successful. My
> > > > first steps were unmounting the partition, taking an image and
> > > > working with a copy of this image using a loop back device.
> > > >
> > > > All files have been retrieved but were removed by reiserfsck --check
> > > > although the last output says that directories and files have been
> > > > linked (see below). I tried with many combinations nearly all
> > > > parameters of reiserfsck: --fix-fixable --no-journal-available -S ...
> > >
> > > have you tried
> > > reiserfsck --rebuild-tree -S
> > > ?
> > > If not, run it on newly created copy of shredded device.
> >
> > Yes, I did. The output of reiserfsck --rebuild-tree gave other numbers of
> > linked directories/files. But I can't see them.
> >
> > > Did you look at lost+found?
> >
> > Shure, see below.
>
> can you do
> debugreiserfs -p -S /dev/shredded | bzip2 -c > meta.bz2
Okay, I've done two versions, one with and one without '-S'. I applied the 
following commands to the image copy (the image itself is untouched, I always 
worked with fresh copies):

# reiserfsck -y /dev/loop/0 --rebuild-sb
# reiserfsck -y /dev/loop/0 --check
# reiserfsck -y /dev/loop/0 --rebuild-tree
# debugreiserfs -p /dev/loop/0 | bzip2 -c > meta.bz2
# reiserfsck -y /dev/loop/0 --rebuild-tree -S
# debugreiserfs -p /dev/loop/0 | bzip2 -c > meta-S.bz2

Use ftp://80.133.138.104:12121 user: marc pw: tukli

Lena gave me another hint:
>> Sorry, but what does df  -T say?
>> Does it say that  reiserfs filesystem is mounted on /mnt/temp1?
>>
>> Thanks,
>> Lena.
> No, it replied:
> # /dev/loop/0   ext2    69529276        20  65997368   1% /mnt/temp1
>
> If I force mount with -t reiserfs it says:
> root@marvin:/home/kris 0$ # mount -o ro -t reiserfs /dev/loop/0 /mnt/temp1/
> mount: wrong fs type, bad option, bad superblock on /dev/loop/0,
>       or too many mounted file systems
>
> Thanks, this is a good hint, but I don't know how to change the identifier 
of 
> the filesystem. I know that normally mkfs.* does this task, but my friend's 
> overwriting of the superblock probably has changed the identifier of the 
> filesystem. Is it possible to apply mkreiserfs on the image whithout running 
> the risk to lose any data?



Thanks
  Kris

>
> and let us to download meta.bz2 so that we can take a look why
> lost+found gets emptied.


>
> > > > I mounted the image after each operation, but all I can see is:
> > > >
> > > > root@marvin:/home/kris 0$ # mount -o ro /dev/loop/0 /mnt/temp1/
> > > > root@marvin:/home/kris 0$ # ls -la /mnt/temp1/
> > > > total 21
> > > > drwxr-xr-x   3 root root  4096 Jan 20 11:36 .
> > > > drwxr-xr-x  39 root root   968 Feb  6 14:12 ..
> > > > drwx------   2 root root 16384 Jan 20 11:36 lost+found
> > > > root@marvin:/home/kris 0$ # ls -la /mnt/temp1/lost+found/
> > > > total 20
> > > > drwx------  2 root root 16384 Jan 20 11:36 .
> > > > drwxr-xr-x  3 root root  4096 Jan 20 11:36 ..
> > > > root@marvin:/home/kris 0$ #
> > > >
> > > >
> > > > Do you have any suggestions how to rescue the data?
> > > >
> > > > Regards
> > > >   Kris
> > > >
> > > >
> > > >
> > > > Here you see a typical output:
> > > >
> > > > root@marvin:/home/kris 0$ # losetup /dev/loop/0 /mnt/temp/data.x.dd
> > > > root@marvin:/home/kris 0$ # reiserfsck /dev/loop/0 --rebuild-tree
> > > > reiserfsck 3.6.19 (2003 www.namesys.com)
> > > >
> > > > <snip>
> > > >
> > > > Will rebuild the filesystem (/dev/loop/0) tree
> > > > Will put log info to 'stdout'
> > > >
> > > > Do you want to run this program?[N/Yes] (note need to type Yes if you
> > > > do):Yes
> > > >
> > > > reiserfs_open: the reiserfs superblock cannot be found on
> > > > /dev/loop/0. Failed to open the filesystem.
> > > >
> > > > If the partition table has not been changed, and the partition is
> > > > valid  and  it really  contains  a reiserfs  partition,  then the
> > > > superblock  is corrupted and you need to run this utility with
> > > > --rebuild-sb.
> > > >
> > > > root@marvin:/home/kris 8$ # reiserfsck /dev/loop/0 --rebuild-sb
> > > > reiserfsck 3.6.19 (2003 www.namesys.com)
> > > >
> > > > <snip>
> > > >
> > > > Will check superblock and rebuild it if needed
> > > > Will put log info to 'stdout'
> > > >
> > > > reiserfs_open: the reiserfs superblock cannot be found on
> > > > /dev/loop/0.
> > > >
> > > > what the version of ReiserFS do you use[1-4]
> > > >         (1)   3.6.x
> > > >         (2) >=3.5.9 (introduced in the middle of 1999) (if you use
> > > > linux 2.2, choose this one)
> > > >         (3) < 3.5.9 converted to new format (don't choose if unsure)
> > > >         (4) < 3.5.9 (this is very old format, don't choose if unsure)
> > > >         (X)   exit
> > > > 1
> > > >
> > > > Enter block size [4096]:
> > > >
> > > >
> > > > No journal device was specified. (If journal is not available, re-run
> > > > with --no-journal-available option specified).
> > > > Is journal default? (y/n)[y]:
> > > >
> > > > Did you use resizer(y/n)[n]:
> > > > rebuild-sb: no uuid found, a new uuid was generated
> > > > (7e253707-4fef-42aa-9785-b1cd079851af)
> > > >
> > > > rebuild-sb: You either have a corrupted journal or have just changed
> > > > the start of the partition with some partition table editor. If you
> > > > are sure that the start of the partition is ok, rebuild the journal
> > > > header. Do you want to rebuild the journal header? (y/n)[n]: y
> > > > Reiserfs super block in block 16 on 0x700 of format 3.6 with standard
> > > > journal Count of blocks on the device: 17659440
> > > > Number of bitmaps: 539
> > > > Blocksize: 4096
> > > > Free blocks (count of blocks - used [journal, bitmaps, data,
> > > > reserved] blocks): 0
> > > > Root block: 0
> > > > Filesystem is NOT clean
> > > > Tree height: 0
> > > > Hash function used to sort names: not set
> > > > Objectid map size 0, 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: 0x1:
> > > >          some corruptions exist.
> > > > sb_version: 2
> > > > inode generation number: 0
> > > > UUID: 7e253707-4fef-42aa-9785-b1cd079851af
> > > > LABEL:
> > > > Set flags in SB:
> > > > Is this ok ? (y/n)[n]: y
> > > > The fs may still be unconsistent. Run reiserfsck --check.
> > > >
> > > > root@marvin:/home/kris 1$ # reiserfsck /dev/loop/0 --check
> > > > reiserfsck 3.6.19 (2003 www.namesys.com)
> > > >
> > > > <snip>
> > > >
> > > > Will read-only check consistency of the filesystem on /dev/loop/0
> > > > Will put log info to 'stdout'
> > > > ###########
> > > > reiserfsck --check started at Tue Feb  8 17:17:31 2005
> > > > ###########
> > > > Replaying journal..
> > > > Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> > > > replayed Zero bit found in on-disk bitmap after the last valid bit.
> > > > Checking internal tree..
> > > >
> > > > Bad root block 0. (--rebuild-tree did not complete)
> > > >
> > > > Aborted
> > > > root@marvin:/home/kris 134$ # reiserfsck /dev/loop/0 -y
> > > > --rebuild-tree reiserfsck 3.6.19 (2003 www.namesys.com)
> > > >
> > > > <snip>
> > > >
> > > > Will rebuild the filesystem (/dev/loop/0) tree
> > > > Will put log info to 'stdout'
> > > >
> > > > Do you want to run this program?[N/Yes] (note need to type Yes if you
> > > > do):Yes Replaying journal..
> > > > Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> > > > replayed Zero bit found in on-disk bitmap after the last valid bit.
> > > > Fixed. ###########
> > > > reiserfsck --rebuild-tree started at Tue Feb  8 17:37:56 2005
> > > > ###########
> > > >
> > > > Pass 0:
> > > > ####### Pass 0 #######
> > > > Loading on-disk bitmap .. ok, 559628 blocks marked used
> > > > init_source_bitmap: Bitmap 0 (of 32768 bits) is wrong - mark all
> > > > blocks [0 - 32768] as used
> > > > init_source_bitmap: Bitmap 1 (of 32768 bits) is wrong - mark all
> > > > blocks [32768 - 65536] as used
> > > > init_source_bitmap: Bitmap 3 (of 32768 bits) is wrong - mark all
> > > > blocks [98304 - 131072] as used
> > > > init_source_bitmap: Bitmap 5 (of 32768 bits) is wrong - mark all
> > > > blocks [163840 - 196608] as used
> > > > init_source_bitmap: Bitmap 7 (of 32768 bits) is wrong - mark all
> > > > blocks [229376 - 262144] as used
> > > > init_source_bitmap: Bitmap 9 (of 32768 bits) is wrong - mark all
> > > > blocks [294912 - 327680] as used
> > > > init_source_bitmap: Bitmap 25 (of 32768 bits) is wrong - mark all
> > > > blocks [819200 - 851968] as used
> > > > init_source_bitmap: Bitmap 27 (of 32768 bits) is wrong - mark all
> > > > blocks [884736 - 917504] as used
> > > > init_source_bitmap: Bitmap 49 (of 32768 bits) is wrong - mark all
> > > > blocks [1605632 - 1638400] as used
> > > > init_source_bitmap: Bitmap 81 (of 32768 bits) is wrong - mark all
> > > > blocks [2654208 - 2686976] as used
> > > > init_source_bitmap: Bitmap 125 (of 32768 bits) is wrong - mark all
> > > > blocks [4096000 - 4128768] as used
> > > > init_source_bitmap: Bitmap 243 (of 32768 bits) is wrong - mark all
> > > > blocks [7962624 - 7995392] as used
> > > > init_source_bitmap: Bitmap 343 (of 32768 bits) is wrong - mark all
> > > > blocks [11239424 - 11272192] as used
> > > > Skipping 8749 blocks (super block, journal, bitmaps) 687599 blocks
> > > > will be read
> > > > 0%....20%....40%....60%....80%....100%                        left 0,
> > > > 9549 /sec
> > > > 103101 directory entries were hashed with "r5" hash.
> > > > Selected hash ("r5") does not match to the hash set in the super
> > > > block (not set).
> > > >         "r5" hash is selected
> > > > Flushing..finished
> > > >         Read blocks (but not data blocks) 687599
> > > >                 Leaves among those 20621
> > > >                 Objectids found 114185
> > > >
> > > > Pass 1 (will try to insert 20621 leaves):
> > > > ####### Pass 1 #######
> > > > Looking for allocable blocks .. finished
> > > > 0%....20%....40%....60%....80%....100%                        left 0,
> > > > 1718 /sec
> > > > Flushing..finished
> > > >         20621 leaves read
> > > >                 20524 inserted
> > > >                         - pointers in indirect items pointing to
> > > > metadata 3 (zeroed)
> > > >                 97 not inserted
> > > >         non-unique pointers in indirect items (zeroed) 1075
> > > > ####### Pass 2 #######
> > > >
> > > > Pass 2:
> > > > 0%....20%....40%....60%vpf-10260: The file we are inserting the new
> > > > item (69291 69327 0x1 DRCT (2), len 216, location 3880 entry count
> > > > 65535, fsck need 0, format new) into has no StatData, insertion was
> > > > skipped ....vpf-10260: The file we are inserting the new item (240148
> > > > 240150 0x1 IND (1), len 1844, location 2252 entry count 0, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (241304 319211
> > > > 0x43001 IND (1), len 492, location 3604 entry count 0, fsck need 0,
> > > > format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (737518 739813
> > > > 0xe6001 IND (1), len 688, location 3408 entry count 0, fsck need 0,
> > > > format new) into has no StatData, insertion was skipped
> > > > 80%vpf-10260: The file we are inserting the new item (737518 739813
> > > > 0xe6001 IND (1), len 688, location 3408 entry count 0, fsck need 0,
> > > > format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (25 93014 0x1e1
> > > > DRCT (2), len 1408, location 2688 entry count 65535, fsck need 0,
> > > > format new) intohas no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (238343 319306
> > > > 0x3f4001 IND (1), len 136, location 3960 entry count 0, fsck need 0,
> > > > format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (94077 119920 0x1
> > > > DRCT (2), len 456, location 3640 entry count 65535, fsck need 0,
> > > > format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (102491 220397
> > > > 0x179 DRCT (2), len 1264, location 2832 entry count 65535, fsck need
> > > > 0, format new)into has no StatData, insertion was skipped
> > > > .vpf-10260: The file we are inserting the new item (642448 771721
> > > > 0xcc1 DRCT (2), len 520, location 3576 entry count 65535, fsck need
> > > > 0, format new)into has no StatData, insertion was skipped
> > > > .vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new)into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > .vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new)into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > .vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new)into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > vpf-10260: The file we are inserting the new item (294390 692752
> > > > 0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> > > > 0, format new) into has no StatData, insertion was skipped
> > > > 100%                           left 0, 0 /sec
> > > > Flushing..finished
> > > >         Leaves inserted item by item 97
> > > > Pass 3 (semantic):
> > > > ####### Pass 3 #########
> > > > /binrebuild_semantic_pass: The entry [3636 189939] ("ls") in
> > > > directory [2 3636] points to nowhere - is removed
> > > > /javarebuild_semantic_pass: The entry [107571 597512] ("jre") in
> > > > directory [3636 107571] points to nowhere - is removed
> > > > vpf-10650: The directory [3636 107571] has the wrong size in the
> > > > StatData (72) - corrected to (48)
> > > > vpf-10650: The directory [2 3636] has the wrong size in the StatData
> > > > (2920) - corrected to (2896)
> > > > /devrebuild_semantic_pass: The entry [6 554632] ("lvm") in directory
> > > > [2 6] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [6 52003] ("lirc") in directory [2
> > > > 6] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [6 72207] ("scsi") in directory [2
> > > > 6] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [6 50738] ("xdb5") in directory [2
> > > > 6] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [6 50739] ("xdb6") in directory [2
> > > > 6] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [6 50740] ("xdb7") in directory [2
> > > > 6] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [6 50741] ("xdb8") in directory [2
> > > > 6] points to nowhere - is removed
> > > > ...
> > > > ... (here follow hundreds of directories and thousends of files, too,
> > > > ...  which I removed)
> > > > ...
> > > > The entry [994339 994340] ("Entries") in directory [994335 19]
> > > > updated to point to [994339 49]
> > > > /Entries.Extra.Oldrewrite_file: 1 items of file [994339 994343] moved
> > > > to [994339 50]
> > > > The entry [994339 994343] ("Entries.Extra.Old") in directory [994335
> > > > 19] updated to point to [994339 50]
> > > > relocate_dir: Moving [994350 994773 0x0 SD (0)] to [994350 51 0x0 SD
> > > > (0)] relocate_dir: Moving [994350 994773 0x1 DIR (3)] to [994350 51
> > > > 0x1 DIR (3)] /994350_51get_next_directory_item: The entry ".." of the
> > > > directory [994350 51] pointes to [285394 994350], instead of [2 18] -
> > > > corrected rebuild_semantic_pass: The entry [994773 994783] ("Root")
> > > > in directory [994350 51] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [994773 994776] ("Entries.Extra") in
> > > > directory [994350 51] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [994773 994782] ("Repository") in
> > > > directory [994350 51] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [994773 994779]
> > > > ("Entries.Extra.Old.bak") in directory [994350 51] points to nowhere
> > > > - is removed
> > > > rebuild_semantic_pass: The entry [994773 994784] ("Root.bak") in
> > > > directory [994350 51] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [994773 994780] ("Entries.Old") in
> > > > directory [994350 51] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [994773 994775] ("Entries.bak") in
> > > > directory [994350 51] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [994773 994781] ("Entries.Old.bak")
> > > > in directory [994350 51] points to nowhere - is removed
> > > > rebuild_semantic_pass: The entry [994773 994778]
> > > > ("Entries.Extra.Old") in directory [994350 51] points to nowhere - is
> > > > removed
> > > > rebuild_semantic_pass: The entry [994773 994777]
> > > > ("Entries.Extra.bak") in directory [994350 51] points to nowhere - is
> > > > removed
> > > > vpf-10650: The directory [994350 51] has the wrong size in the
> > > > StatData (400) - corrected to (72)
> > > > /994395_994396get_next_directory_item: The entry ".." of the
> > > > directory [994395 994396] pointes to [684030 994395], instead of [2
> > > > 18] - corrected /994415_994416get_next_directory_item: The entry ".."
> > > > of the directory [994415 994416] pointes to [684030 994415], instead
> > > > of [2 18] - corrected /994529_994754get_next_directory_item: The
> > > > entry ".." of the directory [994529 994754] pointes to [984867
> > > > 994529], instead of [2 18] - corrected Looking for lost files:
> > > > vpf-10670: The file [25 93091] has the wrong size in the StatData
> > > > (30352) - corrected to (36864)
> > > > vpf-10680: The file [25 93091] has the wrong block count in the
> > > > StatData (64) - corrected to (72)
> > > > vpf-10680: The file [25 111982] has the wrong block count in the
> > > > StatData (75408) - corrected to (16872)
> > > > vpf-10680: The file [3127 59061] has the wrong block count in the
> > > > StatData (8) - corrected to (0)
> > > > vpf-10680: The file [3128 72300] has the wrong block count in the
> > > > StatData (8) - corrected to (0)
> > > > vpf-10680: The file [3620 18950] has the wrong block count in the
> > > > StatData (8) - corrected to (0)
> > > > ...
> > > > ...
> > > > ...
> > > > rewrite_file: 2 items of file [994350 994764] moved to [994350 3108]
> > > > rewrite_file: 2 items of file [994350 994765] moved to [994350 3109]
> > > > rewrite_file: 2 items of file [994350 994766] moved to [994350 3110]
> > > > Flushing..finished
> > > >         Objects without names 18403
> > > >         Empty lost dirs removed 384
> > > >         Dirs linked to /lost+found: 2174
> > > >                 Dirs without stat data found 83
> > > >         Files linked to /lost+found 16229
> > > >         Objects having used objectids: 49
> > > >                 files fixed 47
> > > >                 dirs fixed 2
> > > > Pass 4 - finished   done 1476, 37 /sec
> > > >         Deleted unreachable items 716
> > > > Flushing..finished
> > > > Syncing..finished
> > > > ###########
> > > > reiserfsck finished at Tue Feb  8 17:40:05 2005
> > > > ###########

-- 

Mit freundlichen Grüßen

C. Placzek

----------------------------------------------
Dipl.-Ing. Christian Placzek

Email: kris@cp-data.de    
   
Anschrift:    
Von-Görschen-Str. 19   
52066 Aachen    
   
Tel.: +49 241 9964681
Fax:  +49 241 514388    
Mobil:+49 179 1083808    

Re: reiserfs3 rebuild-tree successful but no files

[Vladimir Saveliev]

Hello

On Thu, 2005-02-10 at 09:54, Christian Placzek wrote:
> On Wednesday 09 February 2005 13:01, Vladimir Saveliev wrote:
> > Hello
> >
> > On Wed, 2005-02-09 at 12:04, Christian Placzek wrote:
> > > On Wednesday 09 February 2005 09:47, you wrote:
> > > > Hello
> > > >
> > > > On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> > > > > Hello,
> > > > >
> > > > > a friend of mine shredded his data (70GB) when he tried to undelete
> > > > > an accidentally deleted file. He normally works with windoze.
> > > > > Therefore he didn't know he couldn't undelete a file on a reiserfs
> > > > > partition with ext2 undelete tool %-(
> > > > > When he called me it was already too late. He had overwritten the
> > > > > superblock :-(
> > > > >
> > > > > I'm still trying to rescue the data. I can see them in the image
> > > > > using grep or hexedit. But nothing I tried has been successful. My
> > > > > first steps were unmounting the partition, taking an image and
> > > > > working with a copy of this image using a loop back device.
> > > > >
> > > > > All files have been retrieved but were removed by reiserfsck --check
> > > > > although the last output says that directories and files have been
> > > > > linked (see below). I tried with many combinations nearly all
> > > > > parameters of reiserfsck: --fix-fixable --no-journal-available -S ...
> > > >
> > > > have you tried
> > > > reiserfsck --rebuild-tree -S
> > > > ?
> > > > If not, run it on newly created copy of shredded device.
> > >
> > > Yes, I did. The output of reiserfsck --rebuild-tree gave other numbers of
> > > linked directories/files. But I can't see them.
> > >
> > > > Did you look at lost+found?
> > >
> > > Shure, see below.
> >
> > can you do
> > debugreiserfs -p -S /dev/shredded | bzip2 -c > meta.bz2
> Okay, I've done two versions, one with and one without '-S'. I applied the 
> following commands to the image copy (the image itself is untouched, I always 
> worked with fresh copies):
> 
> # reiserfsck -y /dev/loop/0 --rebuild-sb
> # reiserfsck -y /dev/loop/0 --check
> # reiserfsck -y /dev/loop/0 --rebuild-tree
> # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta.bz2
> # reiserfsck -y /dev/loop/0 --rebuild-tree -S
> # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta-S.bz2
> 
> Use ftp://80.133.138.104:12121 user: marc pw: tukli
> 
ok.

> Lena gave me another hint:
> >> Sorry, but what does df  -T say?
> >> Does it say that  reiserfs filesystem is mounted on /mnt/temp1?
> >>
> >> Thanks,
> >> Lena.
> > No, it replied:
> > # /dev/loop/0   ext2    69529276        20  65997368   1% /mnt/temp1
> >
> > If I force mount with -t reiserfs it says:
> > root@marvin:/home/kris 0$ # mount -o ro -t reiserfs /dev/loop/0 /mnt/temp1/
> > mount: wrong fs type, bad option, bad superblock on /dev/loop/0,
> >       or too many mounted file systems
> >

Yes, so, were you able to mount the filesystem eventually?

Re: reiserfs3 rebuild-tree successful but no files

[Christian Placzek]

On Thursday 10 February 2005 09:50, you wrote:
> Hello
>
> On Thu, 2005-02-10 at 09:54, Christian Placzek wrote:
> > On Wednesday 09 February 2005 13:01, Vladimir Saveliev wrote:
> > > Hello
> > >
> > > On Wed, 2005-02-09 at 12:04, Christian Placzek wrote:
> > > > On Wednesday 09 February 2005 09:47, you wrote:
> > > > > Hello
> > > > >
> > > > > On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> > > > > > Hello,
> > > > > >
> > > > > > a friend of mine shredded his data (70GB) when he tried to
> > > > > > undelete an accidentally deleted file. He normally works with
> > > > > > windoze. Therefore he didn't know he couldn't undelete a file on
> > > > > > a reiserfs partition with ext2 undelete tool %-(
> > > > > > When he called me it was already too late. He had overwritten the
> > > > > > superblock :-(
> > > > > >
> > > > > > I'm still trying to rescue the data. I can see them in the image
> > > > > > using grep or hexedit. But nothing I tried has been successful.
> > > > > > My first steps were unmounting the partition, taking an image and
> > > > > > working with a copy of this image using a loop back device.
> > > > > >
> > > > > > All files have been retrieved but were removed by reiserfsck
> > > > > > --check although the last output says that directories and files
> > > > > > have been linked (see below). I tried with many combinations
> > > > > > nearly all parameters of reiserfsck: --fix-fixable
> > > > > > --no-journal-available -S ...
> > > > >
> > > > > have you tried
> > > > > reiserfsck --rebuild-tree -S
> > > > > ?
> > > > > If not, run it on newly created copy of shredded device.
> > > >
> > > > Yes, I did. The output of reiserfsck --rebuild-tree gave other
> > > > numbers of linked directories/files. But I can't see them.
> > > >
> > > > > Did you look at lost+found?
> > > >
> > > > Shure, see below.
> > >
> > > can you do
> > > debugreiserfs -p -S /dev/shredded | bzip2 -c > meta.bz2
> >
> > Okay, I've done two versions, one with and one without '-S'. I applied
> > the following commands to the image copy (the image itself is untouched,
> > I always worked with fresh copies):
> >
> > # reiserfsck -y /dev/loop/0 --rebuild-sb
> > # reiserfsck -y /dev/loop/0 --check
> > # reiserfsck -y /dev/loop/0 --rebuild-tree
> > # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta.bz2
> > # reiserfsck -y /dev/loop/0 --rebuild-tree -S
> > # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta-S.bz2
> >
> > Use ftp://80.133.138.104:12121 user: marc pw: tukli
>
> ok.
>
> > Lena gave me another hint:
> > >> Sorry, but what does df  -T say?
> > >> Does it say that  reiserfs filesystem is mounted on /mnt/temp1?
> > >>
> > >> Thanks,
> > >> Lena.
> > >
> > > No, it replied:
> > > # /dev/loop/0   ext2    69529276        20  65997368   1% /mnt/temp1
> > >
> > > If I force mount with -t reiserfs it says:
> > > root@marvin:/home/kris 0$ # mount -o ro -t reiserfs /dev/loop/0
> > > /mnt/temp1/ mount: wrong fs type, bad option, bad superblock on
> > > /dev/loop/0, or too many mounted file systems
>
> Yes, so, were you able to mount the filesystem eventually?

No, I wasn't. It seems mount doesn't recognize the true file system, although 
the magic exists.

<snip>
00010000 30 76 0D 01  00 00 00 00  00 00 00 00  12 00 00 00 0v..............
         00 00 00 00  00 20 00 00  00 04 00 00  00 00 00 00 ..... ..........
00010020 84 03 00 00  1E 00 00 00  00 00 00 00  00 10 CC 03 ................
         00 00 02 00  52 65 49 73  45 72 32 46  73 00 01 00 ....ReIsEr2Fs...
00010040 00 00 00 00  00 00 1B 02  02 00 00 00  00 00 00 00 ................
         00 00 00 00  CF DC 6B 1C  3E 77 48 3C  A7 4E 6E 84 ......k.>wH<.Nn.
00010060 6E 8E E3 EE  00 00 00 00  00 00 00 00  00 00 00 00 n...............
         00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 ................
<snip>


Maybe the following output is the key. I did this with a fresh copy. Note the 
number before the '$' sign in the command prompt. It's the error status of 
the previous command.



root@marvin:/home/kris 0$ # reiserfsck -y /dev/loop/0 --rebuild-sb
reiserfsck 3.6.19 (2003 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will check superblock and rebuild it if needed
Will put log info to 'stdout'

reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.

what the version of ReiserFS do you use[1-4]
        (1)   3.6.x
        (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, 
choose this one)
        (3) < 3.5.9 converted to new format (don't choose if unsure)
        (4) < 3.5.9 (this is very old format, don't choose if unsure)
        (X)   exit
1

Enter block size [4096]:


No journal device was specified. (If journal is not available, re-run with 
--no-journal-available option specified).
Is journal default? (y/n)[y]:

Did you use resizer(y/n)[n]:
rebuild-sb: no uuid found, a new uuid was generated 
(cfdc6b1c-3e77-483c-a74e-6e846e8ee3ee)

rebuild-sb: You either have a corrupted journal or have just changed
the start of the partition with some partition table editor. If you are
sure that the start of the partition is ok, rebuild the journal header.
Do you want to rebuild the journal header? (y/n)[n]: y
Reiserfs super block in block 16 on 0x700 of format 3.6 with standard journal
Count of blocks on the device: 17659440
Number of bitmaps: 539
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] 
blocks): 0
Root block: 0
Filesystem is NOT clean
Tree height: 0
Hash function used to sort names: not set
Objectid map size 0, 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: 0x1:
         some corruptions exist.
sb_version: 2
inode generation number: 0
UUID: cfdc6b1c-3e77-483c-a74e-6e846e8ee3ee
LABEL:
Set flags in SB:
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.

root@marvin:/home/kris 1$ # reiserfsck -y /dev/loop/0 --check
reiserfsck 3.6.19 (2003 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will read-only check consistency of the filesystem on /dev/loop/0
Will put log info to 'stdout'
###########
reiserfsck --check started at Thu Feb 10 13:16:29 2005
###########
Replaying journal..
Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions replayed
Zero bit found in on-disk bitmap after the last valid bit.
Checking internal tree..

Bad root block 0. (--rebuild-tree did not complete)

Aborted
root@marvin:/home/kris 134$ #

Re: reiserfs3 rebuild-tree successful but no files

[Vladimir Saveliev]

Hello

On Thu, 2005-02-10 at 15:50, Christian Placzek wrote:

> No, I wasn't. It seems mount doesn't recognize the true file system, although 
> the magic exists.
> 
> <snip>
> 00010000 30 76 0D 01  00 00 00 00  00 00 00 00  12 00 00 00 0v..............
>          00 00 00 00  00 20 00 00  00 04 00 00  00 00 00 00 ..... ..........
> 00010020 84 03 00 00  1E 00 00 00  00 00 00 00  00 10 CC 03 ................
>          00 00 02 00  52 65 49 73  45 72 32 46  73 00 01 00 ....ReIsEr2Fs...
> 00010040 00 00 00 00  00 00 1B 02  02 00 00 00  00 00 00 00 ................
>          00 00 00 00  CF DC 6B 1C  3E 77 48 3C  A7 4E 6E 84 ......k.>wH<.Nn.
> 00010060 6E 8E E3 EE  00 00 00 00  00 00 00 00  00 00 00 00 n...............
>          00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 ................
> <snip>
> 
> 
> Maybe the following output is the key. I did this with a fresh copy. Note the 
> number before the '$' sign in the command prompt. It's the error status of 
> the previous command.
> 
> 

Sorry, I am confused.
You had to do:
dd if=/dev/shreded of=/dev/spare
reiserfsck --rebuild-sb /dev/spare
reiserfsck --rebuild-tree -S /dev/spare
mount /dev/spare /mnt

Would you try that and let us know the result?

> 
> root@marvin:/home/kris 0$ # reiserfsck -y /dev/loop/0 --rebuild-sb
> reiserfsck 3.6.19 (2003 www.namesys.com)
> 
> *************************************************************
> ** If you are using the latest reiserfsprogs and  it fails **
> ** please  email bug reports to reiserfs-list@namesys.com, **
> ** providing  as  much  information  as  possible --  your **
> ** hardware,  kernel,  patches,  settings,  all reiserfsck **
> ** messages  (including version),  the reiserfsck logfile, **
> ** check  the  syslog file  for  any  related information. **
> ** If you would like advice on using this program, support **
> ** is available  for $25 at  www.namesys.com/support.html. **
> *************************************************************
> 
> Will check superblock and rebuild it if needed
> Will put log info to 'stdout'
> 
> reiserfs_open: the reiserfs superblock cannot be found on /dev/loop/0.
> 
> what the version of ReiserFS do you use[1-4]
>         (1)   3.6.x
>         (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, 
> choose this one)
>         (3) < 3.5.9 converted to new format (don't choose if unsure)
>         (4) < 3.5.9 (this is very old format, don't choose if unsure)
>         (X)   exit
> 1
> 
> Enter block size [4096]:
> 
> 
> No journal device was specified. (If journal is not available, re-run with 
> --no-journal-available option specified).
> Is journal default? (y/n)[y]:
> 
> Did you use resizer(y/n)[n]:
> rebuild-sb: no uuid found, a new uuid was generated 
> (cfdc6b1c-3e77-483c-a74e-6e846e8ee3ee)
> 
> rebuild-sb: You either have a corrupted journal or have just changed
> the start of the partition with some partition table editor. If you are
> sure that the start of the partition is ok, rebuild the journal header.
> Do you want to rebuild the journal header? (y/n)[n]: y
> Reiserfs super block in block 16 on 0x700 of format 3.6 with standard journal
> Count of blocks on the device: 17659440
> Number of bitmaps: 539
> Blocksize: 4096
> Free blocks (count of blocks - used [journal, bitmaps, data, reserved] 
> blocks): 0
> Root block: 0
> Filesystem is NOT clean
> Tree height: 0
> Hash function used to sort names: not set
> Objectid map size 0, 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: 0x1:
>          some corruptions exist.
> sb_version: 2
> inode generation number: 0
> UUID: cfdc6b1c-3e77-483c-a74e-6e846e8ee3ee
> LABEL:
> Set flags in SB:
> Is this ok ? (y/n)[n]: y
> The fs may still be unconsistent. Run reiserfsck --check.
> 
> root@marvin:/home/kris 1$ # reiserfsck -y /dev/loop/0 --check
> reiserfsck 3.6.19 (2003 www.namesys.com)
> 
> *************************************************************
> ** If you are using the latest reiserfsprogs and  it fails **
> ** please  email bug reports to reiserfs-list@namesys.com, **
> ** providing  as  much  information  as  possible --  your **
> ** hardware,  kernel,  patches,  settings,  all reiserfsck **
> ** messages  (including version),  the reiserfsck logfile, **
> ** check  the  syslog file  for  any  related information. **
> ** If you would like advice on using this program, support **
> ** is available  for $25 at  www.namesys.com/support.html. **
> *************************************************************
> 
> Will read-only check consistency of the filesystem on /dev/loop/0
> Will put log info to 'stdout'
> ###########
> reiserfsck --check started at Thu Feb 10 13:16:29 2005
> ###########
> Replaying journal..
> Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions replayed
> Zero bit found in on-disk bitmap after the last valid bit.
> Checking internal tree..
> 
> Bad root block 0. (--rebuild-tree did not complete)
> 
> Aborted
> root@marvin:/home/kris 134$ #
> 

Re: reiserfs3 rebuild-tree successful but no files

[Christian Placzek]

On Thursday 10 February 2005 15:52, you wrote:
> Hello
>
> On Thu, 2005-02-10 at 15:50, Christian Placzek wrote:
> > No, I wasn't. It seems mount doesn't recognize the true file system,
> > although the magic exists.
> >
> > <snip>
> > 00010000 30 76 0D 01  00 00 00 00  00 00 00 00  12 00 00 00
> > 0v.............. 00 00 00 00  00 20 00 00  00 04 00 00  00 00 00 00 .....
> > .......... 00010020 84 03 00 00  1E 00 00 00  00 00 00 00  00 10 CC 03
> > ................ 00 00 02 00  52 65 49 73  45 72 32 46  73 00 01 00
> > ....ReIsEr2Fs... 00010040 00 00 00 00  00 00 1B 02  02 00 00 00  00 00 00
> > 00 ................ 00 00 00 00  CF DC 6B 1C  3E 77 48 3C  A7 4E 6E 84
> > ......k.>wH<.Nn. 00010060 6E 8E E3 EE  00 00 00 00  00 00 00 00  00 00 00
> > 00 n............... 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
> > ................ <snip>
> >
> >
> > Maybe the following output is the key. I did this with a fresh copy. Note
> > the number before the '$' sign in the command prompt. It's the error
> > status of the previous command.
>
> Sorry, I am confused.
> You had to do:
> dd if=/dev/shreded of=/dev/spare
> reiserfsck --rebuild-sb /dev/spare
> reiserfsck --rebuild-tree -S /dev/spare
> mount /dev/spare /mnt
Okay, done. No output of 'mount' in 'dmesg'.
>
> Would you try that and let us know the result?
Here it is, but not in full length (28000 lines):

root@marvin:/home/kris 0$ # reiserfsck --rebuild-sb /dev/sdc5
reiserfsck 3.6.19 (2003 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will check superblock and rebuild it if needed
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /dev/sdc5.

what the version of ReiserFS do you use[1-4]
        (1)   3.6.x
        (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, 
choose this one)
        (3) < 3.5.9 converted to new format (don't choose if unsure)
        (4) < 3.5.9 (this is very old format, don't choose if unsure)
        (X)   exit
1

Enter block size [4096]:


No journal device was specified. (If journal is not available, re-run with 
--no-journal-available option specified).
Is journal default? (y/n)[y]:

Did you use resizer(y/n)[n]:
rebuild-sb: no uuid found, a new uuid was generated 
(bff1c11a-ba70-4f9e-851d-a81d10b388b9)

rebuild-sb: You either have a corrupted journal or have just changed
the start of the partition with some partition table editor. If you are
sure that the start of the partition is ok, rebuild the journal header.
Do you want to rebuild the journal header? (y/n)[n]: y
Reiserfs super block in block 16 on 0x825 of format 3.6 with standard journal
Count of blocks on the device: 27453056
Number of bitmaps: 838
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] 
blocks): 0
Root block: 0
Filesystem is NOT clean
Tree height: 0
Hash function used to sort names: not set
Objectid map size 0, 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: 0x1:
         some corruptions exist.
sb_version: 2
inode generation number: 0
UUID: bff1c11a-ba70-4f9e-851d-a81d10b388b9
LABEL:
Set flags in SB:
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.

root@marvin:/home/kris 1$ # reiserfsck --rebuild-tree -S /dev/sdc5
reiserfsck 3.6.19 (2003 www.namesys.com)

*************************************************************
** Do not  run  the  program  with  --rebuild-tree  unless **
** something is broken and MAKE A BACKUP  before using it. **
** If you have bad sectors on a drive  it is usually a bad **
** idea to continue using it. Then you probably should get **
** a working hard drive, copy the file system from the bad **
** drive  to the good one -- dd_rescue is  a good tool for **
** that -- and only then run this program.                 **
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will rebuild the filesystem (/dev/sdc5) tree
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal..
Reiserfs journal '/dev/sdc5' in blocks [18..8211]: 0 transactions replayed
Zero bit found in on-disk bitmap after the last valid bit. Fixed.
###########
reiserfsck --rebuild-tree started at Thu Feb 10 22:19:12 2005
###########

Pass 0:
####### Pass 0 #######
The whole partition (27453056 blocks) is to be scanned
Skipping 9048 blocks (super block, journal, bitmaps) 27444008 blocks will be 
read
0%block 945510: The number of items (12) is incorrect, should be (1) - 
corrected
block 945510: The free space (1) is incorrect, should be (976) - corrected
pass0: vpf-10110: block 945510, item (0): Unknown item type found [436207872 
50333952 0x1000172d2000000 ??? (13)] - deleted
...block 3519623: The number of items (64768) is incorrect, should be (1) - 
corrected
block 3519623: The free space (2560) is incorrect, should be (208) - corrected
pass0: vpf-10110: block 3519623, item (0): Unknown item type found [16781056 
255904190 0xc7fb8100 ??? (15)] - deleted
block 3904473: The number of items (64768) is incorrect, should be (1) - 
corrected
block 3904473: The free space (2560) is incorrect, should be (208) - corrected
pass0: vpf-10110: block 3904473, item (0): Unknown item type found [16781056 
255901224 0xbd590100 ??? (15)] - deleted
block 3908406: The number of items (64768) is incorrect, should be (1) - 
corrected
block 3908406: The free space (2560) is incorrect, should be (208) - corrected
pass0: vpf-10110: block 3908406, item (0): Unknown item type found [16781056 
255901416 0xbe770100 ??? (15)] - deleted
.20%block 5654267: The number of items (6144) is incorrect, should be (1) - 
corrected
block 5654267: The free space (65280) is incorrect, should be (208) - 
corrected
pass0: vpf-10110: block 5654267, item (0): Unknown item type found [65280 0 
0x1000902040dd401 ??? (14)] - deleted
.block 7061833: The number of items (8) is incorrect, should be (1) - 
corrected
block 7061833: The free space (519) is incorrect, should be (1744) - corrected
pass0: vpf-10110: block 7061833, item (0): Unknown item type found [179306496 
4294903918 0x50008 ??? (15)] - deleted
.block 8763031: The free space (1) is incorrect, should be (3792) - corrected
pass0: vpf-10110: block 8763031, item (0): Unknown item type found [65537 
65541 0x1000385 ??? (15)] - deleted
..block 10833304: The number of items (6144) is incorrect, should be (1) - 
corrected
block 10833304: The free space (65280) is incorrect, should be (208) - 
corrected
pass0: vpf-10110: block 10833304, item (0): Unknown item type found [65280 0 
0x1000902040dd401 ??? (14)] - deleted
40%block 11827048: The number of items (64768) is incorrect, should be (1) - 
corrected
block 11827048: The free space (2560) is incorrect, should be (208) - 
corrected
pass0: vpf-10110: block 11827048, item (0): Unknown item type found 
[2533363456 2675698929 0x3000e02033feaad ??? (4)] - deleted
block 11827165: The number of items (64768) is incorrect, should be (1) - 
corrected
block 11827165: The free space (2560) is incorrect, should be (208) - 
corrected
pass0: vpf-10110: block 11827165, item (0): Unknown item type found 
[2248150784 3026506910 0x7000e02033fed78 ??? (12)] - deleted
..block 14201002: The number of items (21) is incorrect, should be (1) - 
corrected
block 14201002: The free space (3) is incorrect, should be (208) - corrected
pass0: vpf-10110: block 14201002, item (0): Unknown item type found [587661575 
118031107 0x7270001 ??? (15)] - deleted
..60%block 17556778: The number of items (52686) is incorrect, should be (1) - 
corrected
block 17556778: The free space (1) is incorrect, should be (4048) - corrected
pass0: vpf-10110: block 17556778, item (0): Unknown item type found [655372 
3452371000 0xcdcf0001 ??? (15)] - deleted
....80%....100%                        left 0, 6293 /sec
656016 directory entries were hashed with "r5" hash.
Selected hash ("r5") does not match to the hash set in the super block (not 
set).
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 27444008
                Leaves among those 131577
                        - leaves all contents of which could not be saved and 
deleted 22
                Objectids found 572033

Pass 1 (will try to insert 131555 leaves):
####### Pass 1 #######
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%....100%                         left 0, 
265 /sec
Flushing..finished
        131555 leaves read
                127311 inserted
                        - pointers in indirect items pointing to metadata 2064 
(zeroed)
                4244 not inserted
        non-unique pointers in indirect items (zeroed) 436534
####### Pass 2 #######

Pass 2:
0%rewrite_file: 2 items of file [564389 598696] moved to [564389 3086], 
40 /sec
...rewrite_file: 2 items of file [996458 996461] moved to [996458 3089]7 /sec
rewrite_file: 2 items of file [996482 996485] moved to [996482 3092]
.rewrite_file: 2 items of file [998913 998916] moved to [998913 3101] /sec
20%....40%..vpf-10260: The file we are inserting the new item (93570 691287 
0x1 DRCT (2), len 208, location 3888 entry count 65535, fsck need 0, format 
new) into has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (94064 269765 0x1 DRCT (2), 
len 408, location 3688 entry count 65535, fsck need 0, format new) into has 
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (105546 881824 0xb4001 IND 
(1), len 680, location 3416 entry count 0, fsck need 0, format new) into has 
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (93946 740012 0x11 DRCT (2), 
len 768, location 3328 entry count 65535, fsck need 0, format new) into has 
no StatData, insertion was skipped
.vpf-10260: The file we are inserting the new item (95418 950003 0x1 DRCT (2), 
len 272, location 3824 entry count 65535, fsck need 0, format new) into has 
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (94104 656463 0xa1 DRCT (2), 
len 520, location 3576 entry count 65535, fsck need 0, format new) into has 
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (95302 609146 0x1 DRCT (2), 
len 744, location 3352 entry count 65535, fsck need 0, format new) into has 
no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (94104 709993 0x1e9 DRCT 
(2), len 296, location 3800 entry count 65535, fsck need 0, format new) into 
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (93912 919878 0x131 DRCT 
(2), len 176, location 3920 entry count 65535, fsck need 0, format new) into 
has no StatData, insertion was skipped
vpf-10260: The file we are inserting the new item (94163 662251 0x211 DRCT 
(2), len 104, location 3992 entry count 65535, fsck need 0, format new) into 
has no StatData, insertion was skipped
.vpf-10260: The file we are inserting the new item (282820 112803 0x27f001 IND 
(1), len 4048, location 48 entry count 0, fsck need 0, format new) into has 
no StatData, insertion was skipped
...
...
... (here follow thousends of lines, which I removed)
...
...
rewrite_file: 2 items of file [1022678 1042260] moved to [1022678 241698]
rewrite_file: 2 items of file [1022712 1026510] moved to [1022712 241699]
rewrite_file: 2 items of file [1026066 1042203] moved to [1026066 241700]
rewrite_file: 2 items of file [1031541 999149] moved to [1031541 241709]
rewrite_file: 2 items of file [1031544 1031454] moved to [1031544 241713]
rewrite_file: 2 items of file [1033597 711929] moved to [1033597 241714]
vpf-10680: The file [1039539 1039546] has the wrong block count in the 
StatData (10576) - corrected to (9272)
rewrite_file: 2 items of file [1040370 1027097] moved to [1040370 241716]
rewrite_file: 2 items of file [1040371 1027102] moved to [1040371 241719]
rewrite_file: 2 items of file [1041147 1022968] moved to [1041147 241720]
rewrite_file: 2 items of file [1041147 1022969] moved to [1041147 241721]
Flushing..finished99, 80 /sec
        Objects without names 13893
        Empty lost dirs removed 96
        Dirs linked to /lost+found: 1410
                Dirs without stat data found 51
        Files linked to /lost+found 12483
        Objects having used objectids: 2327
                files fixed 2248
                dirs fixed 79
Pass 4 - finished done 129646, 61 /sec
        Deleted unreachable items 1587
Flushing..finished
Syncing..finished
###########
reiserfsck finished at Fri Feb 11 00:15:28 2005
###########
root@marvin:/home/kris 1$ # mount /dev/sdc5 /mnt/temp1
root@marvin:/home/kris 0$ # ls -la /mnt/temp1
total 21
drwxr-xr-x   3 root root  4096 Jan 20 11:36 .
drwxr-xr-x  39 root root   968 Feb  6 14:12 ..
drwx------   2 root root 16384 Jan 20 11:36 lost+found
root@marvin:/home/kris 0$ # ls -la /mnt/temp1/lost+found/
total 20
drwx------  2 root root 16384 Jan 20 11:36 .
drwxr-xr-x  3 root root  4096 Jan 20 11:36 ..
root@marvin:/home/kris 0$ #

Re: reiserfs3 rebuild-tree successful but no files

[Christian Placzek]

On Thursday 10 February 2005 15:09, you wrote:
> Hello.
>
> Christian Placzek wrote:
> >On Wednesday 09 February 2005 13:01, Vladimir Saveliev wrote:
> >>Hello
> >>
> >>On Wed, 2005-02-09 at 12:04, Christian Placzek wrote:
> >>>On Wednesday 09 February 2005 09:47, you wrote:
> >>>>Hello
> >>>>
> >>>>On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> >>>>>Hello,
> >>>>>
> >>>>>a friend of mine shredded his data (70GB) when he tried to undelete
> >>>>>an accidentally deleted file. He normally works with windoze.
> >>>>>Therefore he didn't know he couldn't undelete a file on a reiserfs
> >>>>>partition with ext2 undelete tool %-(
> >>>>>When he called me it was already too late. He had overwritten the
> >>>>>superblock :-(
> >>>>>
> >>>>>I'm still trying to rescue the data. I can see them in the image
> >>>>>using grep or hexedit. But nothing I tried has been successful. My
> >>>>>first steps were unmounting the partition, taking an image and
> >>>>>working with a copy of this image using a loop back device.
> >>>>>
> >>>>>All files have been retrieved but were removed by reiserfsck --check
> >>>>>although the last output says that directories and files have been
> >>>>>linked (see below). I tried with many combinations nearly all
> >>>>>parameters of reiserfsck: --fix-fixable --no-journal-available -S ...
> >>>>
> >>>>have you tried
> >>>>reiserfsck --rebuild-tree -S
> >>>>?
> >>>>If not, run it on newly created copy of shredded device.
> >>>
> >>>Yes, I did. The output of reiserfsck --rebuild-tree gave other numbers
> >>> of linked directories/files. But I can't see them.
> >>>
> >>>>Did you look at lost+found?
> >>>
> >>>Shure, see below.
> >>
> >>can you do
> >>debugreiserfs -p -S /dev/shredded | bzip2 -c > meta.bz2
> >
> >Okay, I've done two versions, one with and one without '-S'. I applied the
> >following commands to the image copy (the image itself is untouched, I
> > always worked with fresh copies):
> >
> ># reiserfsck -y /dev/loop/0 --rebuild-sb
> ># reiserfsck -y /dev/loop/0 --check
> ># reiserfsck -y /dev/loop/0 --rebuild-tree
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Sorry, do I understand correctly that you tried to mount  /dev/loop/0
> with  -t reiserfs option  after __this__ reiserfsck --rebuild-tree? Not
> after the following ones?
Let me explain my mode of operation: I make a copy of the original image taken 
of the harddrive. Then I use 'losetup' or 'mount -o loop' in order to mount 
the image as device. Next I perform different operations using 'reiserfsck'. 
Above you see _one_ possiblity. Then I mount the image as filesystem using 
'mount -o ro /dev/loop/0 /mnt/temp1/', and, as I described below, I get no 
directories or files. Mounting with '-t reiserfs' always result in following 
output:

mount: wrong fs type, bad option, bad superblock on /dev/loop/0,
       or too many mounted file systems


> What kernel do you use?
2.6.10-gentoo-r6


>
> Thanks,
> Lena.
>
> ># debugreiserfs -p /dev/loop/0 | bzip2 -c > meta.bz2
> ># reiserfsck -y /dev/loop/0 --rebuild-tree -S
> ># debugreiserfs -p /dev/loop/0 | bzip2 -c > meta-S.bz2
> >
> >Use ftp://80.133.138.104:12121 user: marc pw: tukli
> >
> >Lena gave me another hint:
> >>>Sorry, but what does df  -T say?
> >>>Does it say that  reiserfs filesystem is mounted on /mnt/temp1?
> >>>
> >>>Thanks,
> >>>Lena.
> >>
> >>No, it replied:
> >># /dev/loop/0   ext2    69529276        20  65997368   1% /mnt/temp1
> >>
> >>If I force mount with -t reiserfs it says:
> >>root@marvin:/home/kris 0$ # mount -o ro -t reiserfs /dev/loop/0
> >> /mnt/temp1/ mount: wrong fs type, bad option, bad superblock on
> >> /dev/loop/0, or too many mounted file systems
> >>
> >>
> >>
> >>Thanks, this is a good hint, but I don't know how to change the
> >> identifier
> >
> >of
> >
> >>the filesystem. I know that normally mkfs.* does this task, but my
> >> friend's overwriting of the superblock probably has changed the
> >> identifier of the filesystem. Is it possible to apply mkreiserfs on the
> >> image whithout running the risk to lose any data?
> >
> >Thanks
> >  Kris
> >
> >>and let us to download meta.bz2 so that we can take a look why
> >>lost+found gets emptied.
> >>
> >>>>>I mounted the image after each operation, but all I can see is:
> >>>>>
> >>>>>root@marvin:/home/kris 0$ # mount -o ro /dev/loop/0 /mnt/temp1/
> >>>>>root@marvin:/home/kris 0$ # ls -la /mnt/temp1/
> >>>>>total 21
> >>>>>drwxr-xr-x   3 root root  4096 Jan 20 11:36 .
> >>>>>drwxr-xr-x  39 root root   968 Feb  6 14:12 ..
> >>>>>drwx------   2 root root 16384 Jan 20 11:36 lost+found
> >>>>>root@marvin:/home/kris 0$ # ls -la /mnt/temp1/lost+found/
> >>>>>total 20
> >>>>>drwx------  2 root root 16384 Jan 20 11:36 .
> >>>>>drwxr-xr-x  3 root root  4096 Jan 20 11:36 ..
> >>>>>root@marvin:/home/kris 0$ #
> >>>>>
> >>>>>
> >>>>>Do you have any suggestions how to rescue the data?
> >>>>>
> >>>>>Regards
> >>>>>  Kris
> >>>>>
> >>>>>
> >>>>>
> >>>>>Here you see a typical output:
> >>>>>
> >>>>>root@marvin:/home/kris 0$ # losetup /dev/loop/0 /mnt/temp/data.x.dd
> >>>>>root@marvin:/home/kris 0$ # reiserfsck /dev/loop/0 --rebuild-tree
> >>>>>reiserfsck 3.6.19 (2003 www.namesys.com)
> >>>>>
> >>>>><snip>
> >>>>>
> >>>>>Will rebuild the filesystem (/dev/loop/0) tree
> >>>>>Will put log info to 'stdout'
> >>>>>
> >>>>>Do you want to run this program?[N/Yes] (note need to type Yes if you
> >>>>>do):Yes
> >>>>>
> >>>>>reiserfs_open: the reiserfs superblock cannot be found on
> >>>>>/dev/loop/0. Failed to open the filesystem.
> >>>>>
> >>>>>If the partition table has not been changed, and the partition is
> >>>>>valid  and  it really  contains  a reiserfs  partition,  then the
> >>>>>superblock  is corrupted and you need to run this utility with
> >>>>>--rebuild-sb.
> >>>>>
> >>>>>root@marvin:/home/kris 8$ # reiserfsck /dev/loop/0 --rebuild-sb
> >>>>>reiserfsck 3.6.19 (2003 www.namesys.com)
> >>>>>
> >>>>><snip>
> >>>>>
> >>>>>Will check superblock and rebuild it if needed
> >>>>>Will put log info to 'stdout'
> >>>>>
> >>>>>reiserfs_open: the reiserfs superblock cannot be found on
> >>>>>/dev/loop/0.
> >>>>>
> >>>>>what the version of ReiserFS do you use[1-4]
> >>>>>        (1)   3.6.x
> >>>>>        (2) >=3.5.9 (introduced in the middle of 1999) (if you use
> >>>>>linux 2.2, choose this one)
> >>>>>        (3) < 3.5.9 converted to new format (don't choose if unsure)
> >>>>>        (4) < 3.5.9 (this is very old format, don't choose if unsure)
> >>>>>        (X)   exit
> >>>>>1
> >>>>>
> >>>>>Enter block size [4096]:
> >>>>>
> >>>>>
> >>>>>No journal device was specified. (If journal is not available, re-run
> >>>>>with --no-journal-available option specified).
> >>>>>Is journal default? (y/n)[y]:
> >>>>>
> >>>>>Did you use resizer(y/n)[n]:
> >>>>>rebuild-sb: no uuid found, a new uuid was generated
> >>>>>(7e253707-4fef-42aa-9785-b1cd079851af)
> >>>>>
> >>>>>rebuild-sb: You either have a corrupted journal or have just changed
> >>>>>the start of the partition with some partition table editor. If you
> >>>>>are sure that the start of the partition is ok, rebuild the journal
> >>>>>header. Do you want to rebuild the journal header? (y/n)[n]: y
> >>>>>Reiserfs super block in block 16 on 0x700 of format 3.6 with standard
> >>>>>journal Count of blocks on the device: 17659440
> >>>>>Number of bitmaps: 539
> >>>>>Blocksize: 4096
> >>>>>Free blocks (count of blocks - used [journal, bitmaps, data,
> >>>>>reserved] blocks): 0
> >>>>>Root block: 0
> >>>>>Filesystem is NOT clean
> >>>>>Tree height: 0
> >>>>>Hash function used to sort names: not set
> >>>>>Objectid map size 0, 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: 0x1:
> >>>>>         some corruptions exist.
> >>>>>sb_version: 2
> >>>>>inode generation number: 0
> >>>>>UUID: 7e253707-4fef-42aa-9785-b1cd079851af
> >>>>>LABEL:
> >>>>>Set flags in SB:
> >>>>>Is this ok ? (y/n)[n]: y
> >>>>>The fs may still be unconsistent. Run reiserfsck --check.
> >>>>>
> >>>>>root@marvin:/home/kris 1$ # reiserfsck /dev/loop/0 --check
> >>>>>reiserfsck 3.6.19 (2003 www.namesys.com)
> >>>>>
> >>>>><snip>
> >>>>>
> >>>>>Will read-only check consistency of the filesystem on /dev/loop/0
> >>>>>Will put log info to 'stdout'
> >>>>>###########
> >>>>>reiserfsck --check started at Tue Feb  8 17:17:31 2005
> >>>>>###########
> >>>>>Replaying journal..
> >>>>>Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> >>>>>replayed Zero bit found in on-disk bitmap after the last valid bit.
> >>>>>Checking internal tree..
> >>>>>
> >>>>>Bad root block 0. (--rebuild-tree did not complete)
> >>>>>
> >>>>>Aborted
> >>>>>root@marvin:/home/kris 134$ # reiserfsck /dev/loop/0 -y
> >>>>>--rebuild-tree reiserfsck 3.6.19 (2003 www.namesys.com)
> >>>>>
> >>>>><snip>
> >>>>>
> >>>>>Will rebuild the filesystem (/dev/loop/0) tree
> >>>>>Will put log info to 'stdout'
> >>>>>
> >>>>>Do you want to run this program?[N/Yes] (note need to type Yes if you
> >>>>>do):Yes Replaying journal..
> >>>>>Reiserfs journal '/dev/loop/0' in blocks [18..8211]: 0 transactions
> >>>>>replayed Zero bit found in on-disk bitmap after the last valid bit.
> >>>>>Fixed. ###########
> >>>>>reiserfsck --rebuild-tree started at Tue Feb  8 17:37:56 2005
> >>>>>###########
> >>>>>
> >>>>>Pass 0:
> >>>>>####### Pass 0 #######
> >>>>>Loading on-disk bitmap .. ok, 559628 blocks marked used
> >>>>>init_source_bitmap: Bitmap 0 (of 32768 bits) is wrong - mark all
> >>>>>blocks [0 - 32768] as used
> >>>>>init_source_bitmap: Bitmap 1 (of 32768 bits) is wrong - mark all
> >>>>>blocks [32768 - 65536] as used
> >>>>>init_source_bitmap: Bitmap 3 (of 32768 bits) is wrong - mark all
> >>>>>blocks [98304 - 131072] as used
> >>>>>init_source_bitmap: Bitmap 5 (of 32768 bits) is wrong - mark all
> >>>>>blocks [163840 - 196608] as used
> >>>>>init_source_bitmap: Bitmap 7 (of 32768 bits) is wrong - mark all
> >>>>>blocks [229376 - 262144] as used
> >>>>>init_source_bitmap: Bitmap 9 (of 32768 bits) is wrong - mark all
> >>>>>blocks [294912 - 327680] as used
> >>>>>init_source_bitmap: Bitmap 25 (of 32768 bits) is wrong - mark all
> >>>>>blocks [819200 - 851968] as used
> >>>>>init_source_bitmap: Bitmap 27 (of 32768 bits) is wrong - mark all
> >>>>>blocks [884736 - 917504] as used
> >>>>>init_source_bitmap: Bitmap 49 (of 32768 bits) is wrong - mark all
> >>>>>blocks [1605632 - 1638400] as used
> >>>>>init_source_bitmap: Bitmap 81 (of 32768 bits) is wrong - mark all
> >>>>>blocks [2654208 - 2686976] as used
> >>>>>init_source_bitmap: Bitmap 125 (of 32768 bits) is wrong - mark all
> >>>>>blocks [4096000 - 4128768] as used
> >>>>>init_source_bitmap: Bitmap 243 (of 32768 bits) is wrong - mark all
> >>>>>blocks [7962624 - 7995392] as used
> >>>>>init_source_bitmap: Bitmap 343 (of 32768 bits) is wrong - mark all
> >>>>>blocks [11239424 - 11272192] as used
> >>>>>Skipping 8749 blocks (super block, journal, bitmaps) 687599 blocks
> >>>>>will be read
> >>>>>0%....20%....40%....60%....80%....100%                        left 0,
> >>>>>9549 /sec
> >>>>>103101 directory entries were hashed with "r5" hash.
> >>>>>Selected hash ("r5") does not match to the hash set in the super
> >>>>>block (not set).
> >>>>>        "r5" hash is selected
> >>>>>Flushing..finished
> >>>>>        Read blocks (but not data blocks) 687599
> >>>>>                Leaves among those 20621
> >>>>>                Objectids found 114185
> >>>>>
> >>>>>Pass 1 (will try to insert 20621 leaves):
> >>>>>####### Pass 1 #######
> >>>>>Looking for allocable blocks .. finished
> >>>>>0%....20%....40%....60%....80%....100%                        left 0,
> >>>>>1718 /sec
> >>>>>Flushing..finished
> >>>>>        20621 leaves read
> >>>>>                20524 inserted
> >>>>>                        - pointers in indirect items pointing to
> >>>>>metadata 3 (zeroed)
> >>>>>                97 not inserted
> >>>>>        non-unique pointers in indirect items (zeroed) 1075
> >>>>>####### Pass 2 #######
> >>>>>
> >>>>>Pass 2:
> >>>>>0%....20%....40%....60%vpf-10260: The file we are inserting the new
> >>>>>item (69291 69327 0x1 DRCT (2), len 216, location 3880 entry count
> >>>>>65535, fsck need 0, format new) into has no StatData, insertion was
> >>>>>skipped ....vpf-10260: The file we are inserting the new item (240148
> >>>>>240150 0x1 IND (1), len 1844, location 2252 entry count 0, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (241304 319211
> >>>>>0x43001 IND (1), len 492, location 3604 entry count 0, fsck need 0,
> >>>>>format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (737518 739813
> >>>>>0xe6001 IND (1), len 688, location 3408 entry count 0, fsck need 0,
> >>>>>format new) into has no StatData, insertion was skipped
> >>>>>80%vpf-10260: The file we are inserting the new item (737518 739813
> >>>>>0xe6001 IND (1), len 688, location 3408 entry count 0, fsck need 0,
> >>>>>format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (25 93014 0x1e1
> >>>>>DRCT (2), len 1408, location 2688 entry count 65535, fsck need 0,
> >>>>>format new) intohas no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (238343 319306
> >>>>>0x3f4001 IND (1), len 136, location 3960 entry count 0, fsck need 0,
> >>>>>format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (94077 119920 0x1
> >>>>>DRCT (2), len 456, location 3640 entry count 65535, fsck need 0,
> >>>>>format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (102491 220397
> >>>>>0x179 DRCT (2), len 1264, location 2832 entry count 65535, fsck need
> >>>>>0, format new)into has no StatData, insertion was skipped
> >>>>>.vpf-10260: The file we are inserting the new item (642448 771721
> >>>>>0xcc1 DRCT (2), len 520, location 3576 entry count 65535, fsck need
> >>>>>0, format new)into has no StatData, insertion was skipped
> >>>>>.vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new)into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>.vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new)into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>.vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new)into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>vpf-10260: The file we are inserting the new item (294390 692752
> >>>>>0x129 DRCT (2), len 296, location 3800 entry count 65535, fsck need
> >>>>>0, format new) into has no StatData, insertion was skipped
> >>>>>100%                           left 0, 0 /sec
> >>>>>Flushing..finished
> >>>>>        Leaves inserted item by item 97
> >>>>>Pass 3 (semantic):
> >>>>>####### Pass 3 #########
> >>>>>/binrebuild_semantic_pass: The entry [3636 189939] ("ls") in
> >>>>>directory [2 3636] points to nowhere - is removed
> >>>>>/javarebuild_semantic_pass: The entry [107571 597512] ("jre") in
> >>>>>directory [3636 107571] points to nowhere - is removed
> >>>>>vpf-10650: The directory [3636 107571] has the wrong size in the
> >>>>>StatData (72) - corrected to (48)
> >>>>>vpf-10650: The directory [2 3636] has the wrong size in the StatData
> >>>>>(2920) - corrected to (2896)
> >>>>>/devrebuild_semantic_pass: The entry [6 554632] ("lvm") in directory
> >>>>>[2 6] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [6 52003] ("lirc") in directory [2
> >>>>>6] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [6 72207] ("scsi") in directory [2
> >>>>>6] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [6 50738] ("xdb5") in directory [2
> >>>>>6] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [6 50739] ("xdb6") in directory [2
> >>>>>6] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [6 50740] ("xdb7") in directory [2
> >>>>>6] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [6 50741] ("xdb8") in directory [2
> >>>>>6] points to nowhere - is removed
> >>>>>...
> >>>>>... (here follow hundreds of directories and thousends of files, too,
> >>>>>...  which I removed)
> >>>>>...
> >>>>>The entry [994339 994340] ("Entries") in directory [994335 19]
> >>>>>updated to point to [994339 49]
> >>>>>/Entries.Extra.Oldrewrite_file: 1 items of file [994339 994343] moved
> >>>>>to [994339 50]
> >>>>>The entry [994339 994343] ("Entries.Extra.Old") in directory [994335
> >>>>>19] updated to point to [994339 50]
> >>>>>relocate_dir: Moving [994350 994773 0x0 SD (0)] to [994350 51 0x0 SD
> >>>>>(0)] relocate_dir: Moving [994350 994773 0x1 DIR (3)] to [994350 51
> >>>>>0x1 DIR (3)] /994350_51get_next_directory_item: The entry ".." of the
> >>>>>directory [994350 51] pointes to [285394 994350], instead of [2 18] -
> >>>>>corrected rebuild_semantic_pass: The entry [994773 994783] ("Root")
> >>>>>in directory [994350 51] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [994773 994776] ("Entries.Extra") in
> >>>>>directory [994350 51] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [994773 994782] ("Repository") in
> >>>>>directory [994350 51] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [994773 994779]
> >>>>>("Entries.Extra.Old.bak") in directory [994350 51] points to nowhere
> >>>>>- is removed
> >>>>>rebuild_semantic_pass: The entry [994773 994784] ("Root.bak") in
> >>>>>directory [994350 51] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [994773 994780] ("Entries.Old") in
> >>>>>directory [994350 51] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [994773 994775] ("Entries.bak") in
> >>>>>directory [994350 51] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [994773 994781] ("Entries.Old.bak")
> >>>>>in directory [994350 51] points to nowhere - is removed
> >>>>>rebuild_semantic_pass: The entry [994773 994778]
> >>>>>("Entries.Extra.Old") in directory [994350 51] points to nowhere - is
> >>>>>removed
> >>>>>rebuild_semantic_pass: The entry [994773 994777]
> >>>>>("Entries.Extra.bak") in directory [994350 51] points to nowhere - is
> >>>>>removed
> >>>>>vpf-10650: The directory [994350 51] has the wrong size in the
> >>>>>StatData (400) - corrected to (72)
> >>>>>/994395_994396get_next_directory_item: The entry ".." of the
> >>>>>directory [994395 994396] pointes to [684030 994395], instead of [2
> >>>>>18] - corrected /994415_994416get_next_directory_item: The entry ".."
> >>>>>of the directory [994415 994416] pointes to [684030 994415], instead
> >>>>>of [2 18] - corrected /994529_994754get_next_directory_item: The
> >>>>>entry ".." of the directory [994529 994754] pointes to [984867
> >>>>>994529], instead of [2 18] - corrected Looking for lost files:
> >>>>>vpf-10670: The file [25 93091] has the wrong size in the StatData
> >>>>>(30352) - corrected to (36864)
> >>>>>vpf-10680: The file [25 93091] has the wrong block count in the
> >>>>>StatData (64) - corrected to (72)
> >>>>>vpf-10680: The file [25 111982] has the wrong block count in the
> >>>>>StatData (75408) - corrected to (16872)
> >>>>>vpf-10680: The file [3127 59061] has the wrong block count in the
> >>>>>StatData (8) - corrected to (0)
> >>>>>vpf-10680: The file [3128 72300] has the wrong block count in the
> >>>>>StatData (8) - corrected to (0)
> >>>>>vpf-10680: The file [3620 18950] has the wrong block count in the
> >>>>>StatData (8) - corrected to (0)
> >>>>>...
> >>>>>...
> >>>>>...
> >>>>>rewrite_file: 2 items of file [994350 994764] moved to [994350 3108]
> >>>>>rewrite_file: 2 items of file [994350 994765] moved to [994350 3109]
> >>>>>rewrite_file: 2 items of file [994350 994766] moved to [994350 3110]
> >>>>>Flushing..finished
> >>>>>        Objects without names 18403
> >>>>>        Empty lost dirs removed 384
> >>>>>        Dirs linked to /lost+found: 2174
> >>>>>                Dirs without stat data found 83
> >>>>>        Files linked to /lost+found 16229
> >>>>>        Objects having used objectids: 49
> >>>>>                files fixed 47
> >>>>>                dirs fixed 2
> >>>>>Pass 4 - finished   done 1476, 37 /sec
> >>>>>        Deleted unreachable items 716
> >>>>>Flushing..finished
> >>>>>Syncing..finished
> >>>>>###########
> >>>>>reiserfsck finished at Tue Feb  8 17:40:05 2005
> >>>>>###########

Re: reiserfs3 rebuild-tree successful but no files

[Vitaly Fertman]

On Thursday 10 February 2005 18:02, Christian Placzek wrote:
> On Thursday 10 February 2005 15:09, you wrote:
> > Hello.
> >
> > Christian Placzek wrote:
> > >On Wednesday 09 February 2005 13:01, Vladimir Saveliev wrote:
> > >>Hello
> > >>
> > >>On Wed, 2005-02-09 at 12:04, Christian Placzek wrote:
> > >>>On Wednesday 09 February 2005 09:47, you wrote:
> > >>>>Hello
> > >>>>
> > >>>>On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> > >>>>>Hello,
> > >>>>>
> > >>>>>a friend of mine shredded his data (70GB) when he tried to undelete
> > >>>>>an accidentally deleted file. He normally works with windoze.
> > >>>>>Therefore he didn't know he couldn't undelete a file on a reiserfs
> > >>>>>partition with ext2 undelete tool %-(
> > >>>>>When he called me it was already too late. He had overwritten the
> > >>>>>superblock :-(
> > >>>>>
> > >>>>>I'm still trying to rescue the data. I can see them in the image
> > >>>>>using grep or hexedit. But nothing I tried has been successful. My
> > >>>>>first steps were unmounting the partition, taking an image and
> > >>>>>working with a copy of this image using a loop back device.
> > >>>>>
> > >>>>>All files have been retrieved but were removed by reiserfsck --check
> > >>>>>although the last output says that directories and files have been
> > >>>>>linked (see below). I tried with many combinations nearly all
> > >>>>>parameters of reiserfsck: --fix-fixable --no-journal-available -S
> > >>>>> ...
> > >>>>
> > >>>>have you tried
> > >>>>reiserfsck --rebuild-tree -S
> > >>>>?
> > >>>>If not, run it on newly created copy of shredded device.
> > >>>
> > >>>Yes, I did. The output of reiserfsck --rebuild-tree gave other numbers
> > >>> of linked directories/files. But I can't see them.
> > >>>
> > >>>>Did you look at lost+found?
> > >>>
> > >>>Shure, see below.
> > >>
> > >>can you do
> > >>debugreiserfs -p -S /dev/shredded | bzip2 -c > meta.bz2
> > >
> > >Okay, I've done two versions, one with and one without '-S'. I applied
> > > the following commands to the image copy (the image itself is
> > > untouched, I always worked with fresh copies):
> > >
> > ># reiserfsck -y /dev/loop/0 --rebuild-sb
> > ># reiserfsck -y /dev/loop/0 --check
> > ># reiserfsck -y /dev/loop/0 --rebuild-tree
> >
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Sorry, do I understand correctly that you tried to mount  /dev/loop/0
> > with  -t reiserfs option  after __this__ reiserfsck --rebuild-tree? Not
> > after the following ones?
>
> Let me explain my mode of operation: I make a copy of the original image
> taken of the harddrive. Then I use 'losetup' or 'mount -o loop' in order to
> mount the image as device. Next I perform different operations using
> 'reiserfsck'. Above you see _one_ possiblity. Then I mount the image as
> filesystem using 'mount -o ro /dev/loop/0 /mnt/temp1/', and, as I described
> below, I get no directories or files. Mounting with '-t reiserfs' always
> result in following output:
>
> mount: wrong fs type, bad option, bad superblock on /dev/loop/0,
>        or too many mounted file systems

after rebuilding the tree, does 'reiserfsck --check <device>' see these files?
do you have a reiserfs support in the kernel?

what if you zero the first 64K with 
	dd conv=notrunc if=/dev/zero of=<device> bs=4096 count=16 
can you mount it now? (rebuild-tree should already complete by the mount time).

do you have anything related in the syslog about the mount time?

-- 
Thanks,
Vitaly Fertman

Re: reiserfs3 rebuild-tree successful but no files

[Christian Placzek]

On Thursday 10 February 2005 16:25, you wrote:
> On Thursday 10 February 2005 18:02, Christian Placzek wrote:
> > On Thursday 10 February 2005 15:09, you wrote:
> > > Hello.
> > >
> > > Christian Placzek wrote:
> > > >On Wednesday 09 February 2005 13:01, Vladimir Saveliev wrote:
> > > >>Hello
> > > >>
> > > >>On Wed, 2005-02-09 at 12:04, Christian Placzek wrote:
> > > >>>On Wednesday 09 February 2005 09:47, you wrote:
> > > >>>>Hello
> > > >>>>
> > > >>>>On Wed, 2005-02-09 at 01:21, Christian Placzek wrote:
> > > >>>>>Hello,
> > > >>>>>
> > > >>>>>a friend of mine shredded his data (70GB) when he tried to
> > > >>>>> undelete an accidentally deleted file. He normally works with
> > > >>>>> windoze. Therefore he didn't know he couldn't undelete a file on
> > > >>>>> a reiserfs partition with ext2 undelete tool %-(
> > > >>>>>When he called me it was already too late. He had overwritten the
> > > >>>>>superblock :-(
> > > >>>>>
> > > >>>>>I'm still trying to rescue the data. I can see them in the image
> > > >>>>>using grep or hexedit. But nothing I tried has been successful. My
> > > >>>>>first steps were unmounting the partition, taking an image and
> > > >>>>>working with a copy of this image using a loop back device.
> > > >>>>>
> > > >>>>>All files have been retrieved but were removed by reiserfsck
> > > >>>>> --check although the last output says that directories and files
> > > >>>>> have been linked (see below). I tried with many combinations
> > > >>>>> nearly all parameters of reiserfsck: --fix-fixable
> > > >>>>> --no-journal-available -S ...
> > > >>>>
> > > >>>>have you tried
> > > >>>>reiserfsck --rebuild-tree -S
> > > >>>>?
> > > >>>>If not, run it on newly created copy of shredded device.
> > > >>>
> > > >>>Yes, I did. The output of reiserfsck --rebuild-tree gave other
> > > >>> numbers of linked directories/files. But I can't see them.
> > > >>>
> > > >>>>Did you look at lost+found?
> > > >>>
> > > >>>Shure, see below.
> > > >>
> > > >>can you do
> > > >>debugreiserfs -p -S /dev/shredded | bzip2 -c > meta.bz2
> > > >
> > > >Okay, I've done two versions, one with and one without '-S'. I applied
> > > > the following commands to the image copy (the image itself is
> > > > untouched, I always worked with fresh copies):
> > > >
> > > ># reiserfsck -y /dev/loop/0 --rebuild-sb
> > > ># reiserfsck -y /dev/loop/0 --check
> > > ># reiserfsck -y /dev/loop/0 --rebuild-tree
> > >
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > Sorry, do I understand correctly that you tried to mount  /dev/loop/0
> > > with  -t reiserfs option  after __this__ reiserfsck --rebuild-tree? Not
> > > after the following ones?
> >
> > Let me explain my mode of operation: I make a copy of the original image
> > taken of the harddrive. Then I use 'losetup' or 'mount -o loop' in order
> > to mount the image as device. Next I perform different operations using
> > 'reiserfsck'. Above you see _one_ possiblity. Then I mount the image as
> > filesystem using 'mount -o ro /dev/loop/0 /mnt/temp1/', and, as I
> > described below, I get no directories or files. Mounting with '-t
> > reiserfs' always result in following output:
> >
> > mount: wrong fs type, bad option, bad superblock on /dev/loop/0,
> >        or too many mounted file systems
>
> after rebuilding the tree, does 'reiserfsck --check <device>' see these
> files? 
Yes, see my original email from 08.02.2005 23:21. The original output has a 
length of about 13000 lines. A extract looks like this:

...
rebuild_semantic_pass: The entry [741258 1025777] ("www.firstname.de.ico") in 
directory [296134 741258] points to nowhere - is removed
rewrite_file: 2 items of file [741258 1041142] moved to [741258 93475]
The entry [741258 1041142] ("deltab.de.ico") in directory [296134 741258] 
updated to point to [741258 93475]
rewrite_file: 2 items of file [741258 1041137] moved to [741258 93569]
The entry [741258 1041137] ("www.bild.t-online.de.ico") in directory [296134 
741258] updated to point to [741258 93569]
...

The last lines:

...
Flushing..finished
        Objects without names 18403
        Empty lost dirs removed 384
        Dirs linked to /lost+found: 2174
                Dirs without stat data found 83
        Files linked to /lost+found 16229
        Objects having used objectids: 49
                files fixed 47
                dirs fixed 2
Pass 4 - finished   done 1476, 37 /sec
        Deleted unreachable items 716
Flushing..finished
Syncing..finished
###########
reiserfsck finished at Tue Feb  8 17:40:05 2005
...

Most of the files were removed by 'reiserfsck --check <device>'. 

> do you have a reiserfs support in the kernel?
Sure, one of my data partition is reiserfs:

...
root@marvin:~ 0$ # debugreiserfs -J /dev/hda7
debugreiserfs 3.6.19 (2003 www.namesys.com)


Filesystem state: consistency is not checked after last mounting

Reiserfs super block in block 16 on 0x307 of format 3.6 with standard journal
Count of blocks on the device: 4393769
...

>
> what if you zero the first 64K with
>  dd conv=notrunc if=/dev/zero of=<device> bs=4096 count=16
> can you mount it now? (rebuild-tree should already complete by the mount
> time).
Hurray, this is the trick! I don't understand why, but I can see hundreds of 
directories and thousends of files. Thanks a lot!!!

>
> do you have anything related in the syslog about the mount time?
This is the first time 'dmesg' gives an output:

ReiserFS: sdc5: found reiserfs format "3.6" with standard journal
ReiserFS: sdc5: using ordered data mode
ReiserFS: sdc5: journal params: device sdc5, size 8192, journal first block 
18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdc5: checking transaction log (sdc5)
ReiserFS: sdc5: Using r5 hash to sort names



Could you give me a technical describtion why this worked?

Again, thank you very much! 

Kris

Re: reiserfs3 rebuild-tree successful but no files

[Vitaly Fertman]

> > after rebuilding the tree, does 'reiserfsck --check <device>' see these
> > files?
>
> Yes, see my original email from 08.02.2005 23:21. The original output has a
> length of about 13000 lines. A extract looks like this:
>
> ...
> rebuild_semantic_pass: The entry [741258 1025777] ("www.firstname.de.ico")
> in directory [296134 741258] points to nowhere - is removed
> rewrite_file: 2 items of file [741258 1041142] moved to [741258 93475]
> The entry [741258 1041142] ("deltab.de.ico") in directory [296134 741258]
> updated to point to [741258 93475]
> rewrite_file: 2 items of file [741258 1041137] moved to [741258 93569]
> The entry [741258 1041137] ("www.bild.t-online.de.ico") in directory
> [296134 741258] updated to point to [741258 93569]
> ...
>
> The last lines:
>
> ...
> Flushing..finished
>         Objects without names 18403
>         Empty lost dirs removed 384
>         Dirs linked to /lost+found: 2174
>                 Dirs without stat data found 83
>         Files linked to /lost+found 16229
>         Objects having used objectids: 49
>                 files fixed 47
>                 dirs fixed 2
> Pass 4 - finished   done 1476, 37 /sec
>         Deleted unreachable items 716
> Flushing..finished
> Syncing..finished
> ###########
> reiserfsck finished at Tue Feb  8 17:40:05 2005
> ...
>
> Most of the files were removed by 'reiserfsck --check <device>'.

besides the journal replay reiserfsck --check does not change 
anything on the partition, RO checks only. 

> > do you have a reiserfs support in the kernel?
>
> Sure, one of my data partition is reiserfs:
>
> ...
> root@marvin:~ 0$ # debugreiserfs -J /dev/hda7
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
>
> Filesystem state: consistency is not checked after last mounting
>
> Reiserfs super block in block 16 on 0x307 of format 3.6 with standard
> journal Count of blocks on the device: 4393769
> ...
>
> > what if you zero the first 64K with
> >  dd conv=notrunc if=/dev/zero of=<device> bs=4096 count=16
> > can you mount it now? (rebuild-tree should already complete by the mount
> > time).
>
> Hurray, this is the trick! I don't understand why, but I can see hundreds
> of directories and thousends of files. Thanks a lot!!!
>
> > do you have anything related in the syslog about the mount time?
>
> This is the first time 'dmesg' gives an output:
>
> ReiserFS: sdc5: found reiserfs format "3.6" with standard journal
> ReiserFS: sdc5: using ordered data mode
> ReiserFS: sdc5: journal params: device sdc5, size 8192, journal first block
> 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
> ReiserFS: sdc5: checking transaction log (sdc5)
> ReiserFS: sdc5: Using r5 hash to sort names
>
> Could you give me a technical describtion why this worked?

the kernel found an ext2 magic somewhere in the first 64K, 
reiserfs keeps the super block on 64K offset, so ext2 one was 
not overwritten by rebuild-sb. this is why it was mounted as ext2.

but why the kernel refused to mount as reiserfs when was explicitely 
specified -- this is a bug.

-- 
Thanks,
Vitaly Fertman

Re: reiserfs3 rebuild-tree successful but no files

[Vitaly Fertman]

> Okay, I've done two versions, one with and one without '-S'. I applied the
> following commands to the image copy (the image itself is untouched, I
> always worked with fresh copies):
>
> # reiserfsck -y /dev/loop/0 --rebuild-sb
> # reiserfsck -y /dev/loop/0 --check
> # reiserfsck -y /dev/loop/0 --rebuild-tree
> # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta.bz2
> # reiserfsck -y /dev/loop/0 --rebuild-tree -S
> # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta-S.bz2
>
> Use ftp://80.133.138.104:12121 

sorry, but I get 'no route to host' every time.

-- 
Thanks,
Vitaly Fertman

Re: reiserfs3 rebuild-tree successful but no files

[Adrian Ulrich]

> > Use ftp://80.133.138.104:12121 
> 
> sorry, but I get 'no route to host' every time.

80.133.138.104 is owned by the 'Deutsche Telekom AG'
(An ISP in Germany).

Looks like a dynamic IP, currently not in use -> No route

 -- Adrian