* reiserfs3 rebuild-tree successful but no files
@ 2005-02-08 22:21 Christian Placzek
2005-02-09 8:47 ` Vladimir Saveliev
0 siblings, 1 reply; 17+ messages in thread
From: Christian Placzek @ 2005-02-08 22:21 UTC (permalink / raw)
To: reiserfs-list
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
###########
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-08 22:21 reiserfs3 rebuild-tree successful but no files Christian Placzek
@ 2005-02-09 8:47 ` Vladimir Saveliev
2005-02-09 9:04 ` Christian Placzek
0 siblings, 1 reply; 17+ messages in thread
From: Vladimir Saveliev @ 2005-02-09 8:47 UTC (permalink / raw)
To: Christian Placzek; +Cc: reiserfs-list
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
> ###########
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-09 8:47 ` Vladimir Saveliev
@ 2005-02-09 9:04 ` Christian Placzek
[not found] ` <4209D935.1060203@namesys.com>
2005-02-09 12:01 ` Vladimir Saveliev
0 siblings, 2 replies; 17+ messages in thread
From: Christian Placzek @ 2005-02-09 9:04 UTC (permalink / raw)
To: Vladimir Saveliev; +Cc: reiserfs-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
[not found] ` <4209D935.1060203@namesys.com>
@ 2005-02-09 11:56 ` Christian Placzek
2005-02-09 12:22 ` Vladimir Saveliev
0 siblings, 1 reply; 17+ messages in thread
From: Christian Placzek @ 2005-02-09 11:56 UTC (permalink / raw)
To: E.Gryaznova; +Cc: reiserfs-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-09 9:04 ` Christian Placzek
[not found] ` <4209D935.1060203@namesys.com>
@ 2005-02-09 12:01 ` Vladimir Saveliev
2005-02-10 6:54 ` Christian Placzek
1 sibling, 1 reply; 17+ messages in thread
From: Vladimir Saveliev @ 2005-02-09 12:01 UTC (permalink / raw)
To: Christian Placzek; +Cc: reiserfs-list
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
> > > ###########
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-09 11:56 ` Christian Placzek
@ 2005-02-09 12:22 ` Vladimir Saveliev
0 siblings, 0 replies; 17+ messages in thread
From: Vladimir Saveliev @ 2005-02-09 12:22 UTC (permalink / raw)
To: Christian Placzek; +Cc: E.Gryaznova, reiserfs-list
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?
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-09 12:01 ` Vladimir Saveliev
@ 2005-02-10 6:54 ` Christian Placzek
2005-02-10 8:50 ` Vladimir Saveliev
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Christian Placzek @ 2005-02-10 6:54 UTC (permalink / raw)
To: reiserfs-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-10 6:54 ` Christian Placzek
@ 2005-02-10 8:50 ` Vladimir Saveliev
2005-02-10 12:50 ` Christian Placzek
[not found] ` <420B6B35.2000607@namesys.com>
2005-02-10 20:54 ` Vitaly Fertman
2 siblings, 1 reply; 17+ messages in thread
From: Vladimir Saveliev @ 2005-02-10 8:50 UTC (permalink / raw)
To: Christian Placzek; +Cc: reiserfs-list
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-10 8:50 ` Vladimir Saveliev
@ 2005-02-10 12:50 ` Christian Placzek
2005-02-10 14:52 ` Vladimir Saveliev
0 siblings, 1 reply; 17+ messages in thread
From: Christian Placzek @ 2005-02-10 12:50 UTC (permalink / raw)
To: Vladimir Saveliev; +Cc: reiserfs-list
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$ #
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-10 12:50 ` Christian Placzek
@ 2005-02-10 14:52 ` Vladimir Saveliev
2005-02-11 7:02 ` Christian Placzek
0 siblings, 1 reply; 17+ messages in thread
From: Vladimir Saveliev @ 2005-02-10 14:52 UTC (permalink / raw)
To: Christian Placzek; +Cc: reiserfs-list
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$ #
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
[not found] ` <420B6B35.2000607@namesys.com>
@ 2005-02-10 15:02 ` Christian Placzek
2005-02-10 15:25 ` Vitaly Fertman
0 siblings, 1 reply; 17+ messages in thread
From: Christian Placzek @ 2005-02-10 15:02 UTC (permalink / raw)
To: E.Gryaznova; +Cc: reiserfs-list
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
> >>>>>###########
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-10 15:02 ` Christian Placzek
@ 2005-02-10 15:25 ` Vitaly Fertman
2005-02-11 7:32 ` Christian Placzek
0 siblings, 1 reply; 17+ messages in thread
From: Vitaly Fertman @ 2005-02-10 15:25 UTC (permalink / raw)
To: Christian Placzek; +Cc: reiserfs-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-10 6:54 ` Christian Placzek
2005-02-10 8:50 ` Vladimir Saveliev
[not found] ` <420B6B35.2000607@namesys.com>
@ 2005-02-10 20:54 ` Vitaly Fertman
2005-02-10 21:59 ` Adrian Ulrich
2 siblings, 1 reply; 17+ messages in thread
From: Vitaly Fertman @ 2005-02-10 20:54 UTC (permalink / raw)
To: Christian Placzek, reiserfs-list
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-10 20:54 ` Vitaly Fertman
@ 2005-02-10 21:59 ` Adrian Ulrich
0 siblings, 0 replies; 17+ messages in thread
From: Adrian Ulrich @ 2005-02-10 21:59 UTC (permalink / raw)
To: Vitaly Fertman; +Cc: kris, reiserfs-list
> > 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-10 14:52 ` Vladimir Saveliev
@ 2005-02-11 7:02 ` Christian Placzek
0 siblings, 0 replies; 17+ messages in thread
From: Christian Placzek @ 2005-02-11 7:02 UTC (permalink / raw)
To: Vladimir Saveliev; +Cc: reiserfs-list
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$ #
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-10 15:25 ` Vitaly Fertman
@ 2005-02-11 7:32 ` Christian Placzek
2005-02-11 10:57 ` Vitaly Fertman
0 siblings, 1 reply; 17+ messages in thread
From: Christian Placzek @ 2005-02-11 7:32 UTC (permalink / raw)
To: Vitaly Fertman; +Cc: reiserfs-list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: reiserfs3 rebuild-tree successful but no files
2005-02-11 7:32 ` Christian Placzek
@ 2005-02-11 10:57 ` Vitaly Fertman
0 siblings, 0 replies; 17+ messages in thread
From: Vitaly Fertman @ 2005-02-11 10:57 UTC (permalink / raw)
To: Christian Placzek; +Cc: reiserfs-list
> > 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
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2005-02-11 10:57 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-08 22:21 reiserfs3 rebuild-tree successful but no files Christian Placzek
2005-02-09 8:47 ` Vladimir Saveliev
2005-02-09 9:04 ` Christian Placzek
[not found] ` <4209D935.1060203@namesys.com>
2005-02-09 11:56 ` Christian Placzek
2005-02-09 12:22 ` Vladimir Saveliev
2005-02-09 12:01 ` Vladimir Saveliev
2005-02-10 6:54 ` Christian Placzek
2005-02-10 8:50 ` Vladimir Saveliev
2005-02-10 12:50 ` Christian Placzek
2005-02-10 14:52 ` Vladimir Saveliev
2005-02-11 7:02 ` Christian Placzek
[not found] ` <420B6B35.2000607@namesys.com>
2005-02-10 15:02 ` Christian Placzek
2005-02-10 15:25 ` Vitaly Fertman
2005-02-11 7:32 ` Christian Placzek
2005-02-11 10:57 ` Vitaly Fertman
2005-02-10 20:54 ` Vitaly Fertman
2005-02-10 21:59 ` Adrian Ulrich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.