* Bad block 0 error
@ 2004-06-21 9:27 Alistair McDonald
2004-06-21 11:50 ` Vladimir V. Saveliev
0 siblings, 1 reply; 6+ messages in thread
From: Alistair McDonald @ 2004-06-21 9:27 UTC (permalink / raw)
To: reiserfs-list
I had a hard drive failure. I have replaced the hard drive with a new
software RAID1 setup ( previously, the drive was used as a normal block
device, /dev/hdh1).
I am getting an error running reiserfsck:
=============================reiserfsck output begins
altair root # reiserfsck /dev/md0
reiserfsck 3.6.17 (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/md0
Will put log info to 'stdout'
Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Mon Jun 21 10:03:30 2004
###########
Replaying journal..
Reiserfs journal '/dev/md0' in blocks [18..8211]: 0 transactions replayed
Checking internal tree..
Bad root block 0. (--rebuild-tree did not complete)
Aborted
=============================reiserfsck output ends
A little googling suggsted using the debugreiserfs command, but the output
seems normal to me:
=============================debugreiser output begins
altair root # debugreiserfs /dev/md0
debugreiserfs 3.6.17 (2003 www.namesys.com)
Filesystem state: consistent
Reiserfs super block in block 16 on 0x900 of format 3.6 with standard journal
Count of blocks on the device: 61277904
Number of bitmaps: 1871
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
blocks):
61277904
Root block: 0
Filesystem marked as cleanly umounted
Tree height: 65535
Hash function used to sort names: "r5"
Objectid map size 2, 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: 0x0:
sb_version: 2
inode generation number: 0
UUID: f486260e-f7ca-4bff-a783-63b4bda0b315
LABEL:
Set flags in SB:
=============================debugreiser output ends
Here is the history of the data:
the old partition was on an IDE hard drive. It reported errors after boot
(lost the output, I'm afraid) and reiserfsck could not recover the data.
Not suprising if the hard drive was bad.
I installed linux software RAID-1, using /dev/hde1 and /dev/hdg1 making
/dev/md0, a RAID-1 set. I used dd_rescue to copy all the data from
/dev/hdh to /dev/md0 - only(!) around 150 errors were reported in copying
the whole ~250Gb data. The orignal drive and the new RAID volume are the
same size, using the same drive type, in fact, so I thought that a
straight dd_rescue would be OK.
I then used reiserfsck on /dev/md0, resulting in the above outputs.
So, could I ask for help: (A) was it valid to dd_rescue the old drive (I
still have the old drive and can re-do any retrieval commands) (B) what
are the chances of recovering my data, and (C) how I can go about it?
system details:
2.6.6 kernel from development sources (effectively a vanilla 2.6.6 kernel,
I believe). The system WAS running 2.4.23 until after the disk failure
reiserfstools 3.6.17 (was 3.4.14 until I was unable to recover the data
with reiserfsck).
Alistair
--
Alistair McDonald (+44)(0)7017-467386
http://www.inrevo.com
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Bad block 0 error
2004-06-21 9:27 Bad block 0 error Alistair McDonald
@ 2004-06-21 11:50 ` Vladimir V. Saveliev
2004-06-21 12:10 ` Alistair McDonald
0 siblings, 1 reply; 6+ messages in thread
From: Vladimir V. Saveliev @ 2004-06-21 11:50 UTC (permalink / raw)
To: alistair; +Cc: reiserfs-list
Hello
Alistair McDonald wrote:
> I had a hard drive failure. I have replaced the hard drive with a new
> software RAID1 setup ( previously, the drive was used as a normal block
> device, /dev/hdh1).
>
> I am getting an error running reiserfsck:
>
> =============================reiserfsck output begins
> altair root # reiserfsck /dev/md0
> reiserfsck 3.6.17 (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/md0
> Will put log info to 'stdout'
>
> Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
> ###########
> reiserfsck --check started at Mon Jun 21 10:03:30 2004
> ###########
> Replaying journal..
> Reiserfs journal '/dev/md0' in blocks [18..8211]: 0 transactions replayed
> Checking internal tree..
>
> Bad root block 0. (--rebuild-tree did not complete)
>
> Aborted
>
> =============================reiserfsck output ends
>
>
> A little googling suggsted using the debugreiserfs command, but the output
> seems normal to me:
>
No, it is not. You see: tree height is supposed to be not more than 5.
You have 65535. Root block is block 0 which should never happen. So, you
have to run reiserfsck --rebuild-tree
> =============================debugreiser output begins
> altair root # debugreiserfs /dev/md0
> debugreiserfs 3.6.17 (2003 www.namesys.com)
>
>
> Filesystem state: consistent
>
> Reiserfs super block in block 16 on 0x900 of format 3.6 with standard journal
> Count of blocks on the device: 61277904
> Number of bitmaps: 1871
> Blocksize: 4096
> Free blocks (count of blocks - used [journal, bitmaps, data, reserved]
> blocks):
> 61277904
> Root block: 0
> Filesystem marked as cleanly umounted
> Tree height: 65535
> Hash function used to sort names: "r5"
> Objectid map size 2, 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: 0x0:
> sb_version: 2
> inode generation number: 0
> UUID: f486260e-f7ca-4bff-a783-63b4bda0b315
> LABEL:
> Set flags in SB:
>
> =============================debugreiser output ends
>
>
> Here is the history of the data:
>
> the old partition was on an IDE hard drive. It reported errors after boot
> (lost the output, I'm afraid) and reiserfsck could not recover the data.
> Not suprising if the hard drive was bad.
>
> I installed linux software RAID-1, using /dev/hde1 and /dev/hdg1 making
> /dev/md0, a RAID-1 set. I used dd_rescue to copy all the data from
> /dev/hdh to /dev/md0 - only(!) around 150 errors were reported in copying
> the whole ~250Gb data. The orignal drive and the new RAID volume are the
> same size, using the same drive type, in fact, so I thought that a
> straight dd_rescue would be OK.
>
> I then used reiserfsck on /dev/md0, resulting in the above outputs.
>
> So, could I ask for help: (A) was it valid to dd_rescue the old drive (I
> still have the old drive and can re-do any retrieval commands)
yes. dd_rescue is the right tool.
please keep old drive, until you have have data back
(B) what
> are the chances of recovering my data, and (C) how I can go about it?
>
please try
reiserfsck --rebuild-tree /dev/md0
amd let us know its result
> system details:
> 2.6.6 kernel from development sources (effectively a vanilla 2.6.6 kernel,
> I believe). The system WAS running 2.4.23 until after the disk failure
>
> reiserfstools 3.6.17 (was 3.4.14 until I was unable to recover the data
> with reiserfsck).
>
> Alistair
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bad block 0 error
2004-06-21 11:50 ` Vladimir V. Saveliev
@ 2004-06-21 12:10 ` Alistair McDonald
2004-06-21 12:45 ` Vladimir V. Saveliev
0 siblings, 1 reply; 6+ messages in thread
From: Alistair McDonald @ 2004-06-21 12:10 UTC (permalink / raw)
To: Vladimir V. Saveliev; +Cc: reiserfs-list
Hello, Vladimir
Thanks for replying.
I have run with --rebuild-tree, and the results are below. Thanks for any
further help you can offer.
>>
>> A little googling suggsted using the debugreiserfs command, but the
>> output
>> seems normal to me:
>>
> No, it is not. You see: tree height is supposed to be not more than 5.
> You have 65535. Root block is block 0 which should never happen. So, you
> have to run reiserfsck --rebuild-tree
================================ reiserfsck --rebuild tree output starts
Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal..
Reiserfs journal '/dev/md0' in blocks [18..8211]: 0 transactions replayed
###########
reiserfsck --rebuild-tree started at Mon Jun 21 13:02:36 2004
###########
Pass 0:
####### Pass 0 #######
Loading on-disk bitmap .. ok, 10081 blocks marked used
Skipping 10081 blocks (super block, journal, bitmaps) 0 blocks will be read
Could not find a hash in use. Using "r5"
"r5" hash is selected
Flushing..finished
Read blocks (but not data blocks) 0
Leaves among those 0
Objectids found 2
Pass 1 (will try to insert 0 leaves):
####### Pass 1 #######
Looking for allocable blocks .. finished
Flushing..finished
0 leaves read
0 inserted
####### Pass 2 #######
Flushing..finished
No reiserfs metadata found. If you are sure that you had the reiserfs
on this partition, then the start of the partition might be changed
or all data were wiped out. The start of the partition may get changed
by a partitioner if you have used one. Then you probably rebuilt the
superblock as there was no one. Zero the block at 64K offset from the
start of the partition (a new super block you have just built) and try
to move the start of the partition a few cylinders aside and check if
debugreiserfs /dev/xxx detects a reiserfs super block. If it does this
is likely to be the right super block version.
If this makes you nervous, try www.namesys.com/support.html, and for
$25 the author of fsck, or a colleague if he is out, will step you
through it all.
Aborted
================================ reiserfsck --rebuild tree output ends
>>
>> So, could I ask for help: (A) was it valid to dd_rescue the old drive
>> (I
>> still have the old drive and can re-do any retrieval commands)
>
> yes. dd_rescue is the right tool.
> please keep old drive, until you have have data back
> (B) what
>> are the chances of recovering my data, and (C) how I can go about it?
>>
>
> please try
> reiserfsck --rebuild-tree /dev/md0
> amd let us know its result
>
Many thanks again,
Alistair
--
Alistair McDonald (+44)(0)7017-467386
http://www.inrevo.com
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Bad block 0 error
2004-06-21 12:10 ` Alistair McDonald
@ 2004-06-21 12:45 ` Vladimir V. Saveliev
2004-06-21 15:19 ` Alistair McDonald
0 siblings, 1 reply; 6+ messages in thread
From: Vladimir V. Saveliev @ 2004-06-21 12:45 UTC (permalink / raw)
To: alistair; +Cc: reiserfs-list
Hello
Alistair McDonald wrote:
> Hello, Vladimir
>
> Thanks for replying.
> I have run with --rebuild-tree, and the results are below. Thanks for any
> further help you can offer.
>
>
>>>A little googling suggsted using the debugreiserfs command, but the
>>>output
>>>seems normal to me:
>>>
>>
>>No, it is not. You see: tree height is supposed to be not more than 5.
>>You have 65535. Root block is block 0 which should never happen. So, you
>>have to run reiserfsck --rebuild-tree
>
>
> ================================ reiserfsck --rebuild tree output starts
> Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
> Replaying journal..
> Reiserfs journal '/dev/md0' in blocks [18..8211]: 0 transactions replayed
> ###########
> reiserfsck --rebuild-tree started at Mon Jun 21 13:02:36 2004
> ###########
>
> Pass 0:
> ####### Pass 0 #######
> Loading on-disk bitmap .. ok, 10081 blocks marked used
> Skipping 10081 blocks (super block, journal, bitmaps) 0 blocks will be read
>
> Could not find a hash in use. Using "r5"
> "r5" hash is selected
> Flushing..finished
> Read blocks (but not data blocks) 0
> Leaves among those 0
> Objectids found 2
>
> Pass 1 (will try to insert 0 leaves):
> ####### Pass 1 #######
> Looking for allocable blocks .. finished
>
> Flushing..finished
> 0 leaves read
> 0 inserted
> ####### Pass 2 #######
> Flushing..finished
>
>
> No reiserfs metadata found. If you are sure that you had the reiserfs
> on this partition, then the start of the partition might be changed
Lets try to see if there are reiserfs metadata on /dev/md0:
echo "\n" | 3.6.17/debugreiserfs -k -S -q /dev/md0 | head 10000
It should output something like:
block 17775 is reiserfs leaf node
If you do not see such lines - reiserfsck can not do anything with that
device.
please also run
debugreiserfs -m /dev/md0 > md0.bitmap
and send us md0.bitmap
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bad block 0 error
2004-06-21 12:45 ` Vladimir V. Saveliev
@ 2004-06-21 15:19 ` Alistair McDonald
2004-06-21 15:41 ` Vladimir V. Saveliev
0 siblings, 1 reply; 6+ messages in thread
From: Alistair McDonald @ 2004-06-21 15:19 UTC (permalink / raw)
To: Vladimir V. Saveliev; +Cc: reiserfs-list
Hi,
>
> Lets try to see if there are reiserfs metadata on /dev/md0:
>
> echo "\n" | 3.6.17/debugreiserfs -k -S -q /dev/md0 | head 10000
>
> It should output something like:
> block 17775 is reiserfs leaf node
>
> If you do not see such lines - reiserfsck can not do anything with that
> device.
Well, it took a *long, long* time, but here are the results (the command
changed slightly):
# echo "\n" | debugreiserfs -k -S -q /dev/md0 | head -10000
head: `-10000' option is obsolete; use `-n 10000' since this will be
removed in
the future
debugreiserfs 3.6.17 (2003 www.namesys.com)
Whole device (61277904 blocks) is to be scanned
looking for ([0 0])
0%...\.20%....40%....60%..
Log file 'scan.log' is opened
What key do you want to find: dirid?objectid?block 16 is reiserfs super block
block 18 is journal descriptor
block 19 is reiserfs super block
block 21 is journal descriptor
block 22 is reiserfs super block
block 24 is journal descriptor
block 25 is reiserfs super block
altair root # \
>
> please also run
> debugreiserfs -m /dev/md0 > md0.bitmap
> and send us md0.bitmap
>
I will send the md0.bitmap directly to you (not to the list) once that
command has completed.
Many thanks,
Alistair
--
Alistair McDonald (+44)(0)7017-467386
http://www.inrevo.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bad block 0 error
2004-06-21 15:19 ` Alistair McDonald
@ 2004-06-21 15:41 ` Vladimir V. Saveliev
0 siblings, 0 replies; 6+ messages in thread
From: Vladimir V. Saveliev @ 2004-06-21 15:41 UTC (permalink / raw)
To: alistair; +Cc: reiserfs-list
Hello
Alistair McDonald wrote:
> Hi,
>
>
>>Lets try to see if there are reiserfs metadata on /dev/md0:
>>
>>echo "\n" | 3.6.17/debugreiserfs -k -S -q /dev/md0 | head 10000
>>
>>It should output something like:
>>block 17775 is reiserfs leaf node
>>
>>If you do not see such lines - reiserfsck can not do anything with that
>>device.
>
>
> Well, it took a *long, long* time, but here are the results (the command
> changed slightly):
>
> # echo "\n" | debugreiserfs -k -S -q /dev/md0 | head -10000
> head: `-10000' option is obsolete; use `-n 10000' since this will be
> removed in
> the future
> debugreiserfs 3.6.17 (2003 www.namesys.com)
>
> Whole device (61277904 blocks) is to be scanned
> looking for ([0 0])
> 0%...\.20%....40%....60%..
> Log file 'scan.log' is opened
> What key do you want to find: dirid?objectid?block 16 is reiserfs super block
> block 18 is journal descriptor
> block 19 is reiserfs super block
> block 21 is journal descriptor
> block 22 is reiserfs super block
> block 24 is journal descriptor
> block 25 is reiserfs super block
> altair root # \
>
>
>
>>please also run
>>debugreiserfs -m /dev/md0 > md0.bitmap
>>and send us md0.bitmap
>>
>
>
> I will send the md0.bitmap directly to you (not to the list) once that
> command has completed.
>
Hmm, I am afraid that I will have to disappoint you. /dev/md0 does not
contain reiserfs metadata blocks. Would you make sure once again that
you dd_rescue-ed broken reiserfs filesystem to /dev/md0?
> Many thanks,
>
> Alistair
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-06-21 15:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-21 9:27 Bad block 0 error Alistair McDonald
2004-06-21 11:50 ` Vladimir V. Saveliev
2004-06-21 12:10 ` Alistair McDonald
2004-06-21 12:45 ` Vladimir V. Saveliev
2004-06-21 15:19 ` Alistair McDonald
2004-06-21 15:41 ` Vladimir V. Saveliev
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.