Failing Disk

[lostincable]

Not looking good 

 

I removed the drive and parity simulated the disk but it shows up as unformatted (this is to be expected)

 

So I ran the reiserfsck command

 

 

reiserfsck --rebuild-tree /dev/md1

 

And this is the response -

 

reiserfsck --rebuild-tree started at Tue Dec 11 17:21:06 2012
###########

Pass 0:
####### Pass 0 #######
Loading on-disk bitmap .. ok, 486978519 blocks marked used
Skipping 23115 blocks (super block, journal, bitmaps) 486955404 blocks will be read
0%block 8867145: The number of items (47) is incorrect, should be (1) - corrected
block 8867145: The free space (816) is incorrect, should be (0) - corrected
                                                   left 478001968, 23499 /sec
The problem has occurred looks like a hardware problem. If you have
bad blocks, we advise you to get a new hard drive, because once you
get one bad block  that the disk  drive internals  cannot hide from
your sight,the chances of getting more are generally said to become
much higher  (precise statistics are unknown to us), and  this disk
drive is probably not expensive enough  for you to you to risk your
time and  data on it.  If you don't want to follow that follow that
advice then  if you have just a few bad blocks,  try writing to the
bad blocks  and see if the drive remaps  the bad blocks (that means
it takes a block  it has  in reserve  and allocates  it for use for
of that block number).  If it cannot remap the block,  use badblock
option (-B) with  reiserfs utils to handle this block correctly.

bread: Cannot read the block (9112578): (Input/output error).

Aborted

 

Looks like I may have lost my data?

[Helmonder]

Your data ahould be aimulated by parity meaning you might have lost the drive but not the data.

[Joe L.]

Not looking good 

 

I removed the drive and parity simulated the disk but it shows up as unformatted (this is to be expected)

 

So I ran the reiserfsck command

 

 

reiserfsck --rebuild-tree /dev/md1

 

And this is the response -

 

reiserfsck --rebuild-tree started at Tue Dec 11 17:21:06 2012
###########

Pass 0:
####### Pass 0 #######
Loading on-disk bitmap .. ok, 486978519 blocks marked used
Skipping 23115 blocks (super block, journal, bitmaps) 486955404 blocks will be read
0%block 8867145: The number of items (47) is incorrect, should be (1) - corrected
block 8867145: The free space (816) is incorrect, should be (0) - corrected
                                                   left 478001968, 23499 /sec
The problem has occurred looks like a hardware problem. If you have
bad blocks, we advise you to get a new hard drive, because once you
get one bad block  that the disk  drive internals  cannot hide from
your sight,the chances of getting more are generally said to become
much higher  (precise statistics are unknown to us), and  this disk
drive is probably not expensive enough  for you to you to risk your
time and  data on it.  If you don't want to follow that follow that
advice then  if you have just a few bad blocks,  try writing to the
bad blocks  and see if the drive remaps  the bad blocks (that means
it takes a block  it has  in reserve  and allocates  it for use for
of that block number).  If it cannot remap the block,  use badblock
option (-B) with  reiserfs utils to handle this block correctly.

bread: Cannot read the block (9112578): (Input/output error).

Aborted

 

Looks like I may have lost my data?

That was not expected...  It looks more like something in the file-system is pointing where it should not, and the reiserfsck is interperting it as a drive error.  It certainly cannot be the same un-readable block when being simulated.

 

At this point, I'd try a rebuild of the superblock (you can even leave the disk disconnected and operate only on the emulated version)  Be aware, there are prompts which will need to be answered when invoked, and the default values for those prompts are NOT the correct ones.  See the wiki for the correct responses.

 

In the  mean-time, you can investigate what you can read under the window's driver.

 

Do you have another spare disk of the same size? and a spare port on your disk controller?  Making a copy of the disk as it is right now allows you to try alternative recovery tools on the copy without risking the original.

 

Joe L.

[Joe L.]

You might try a --fix-fixable, perhaps one of the earlier reiserfsck fixed something.

 

reiserfsck --fix-fixable /dev/md1

 

Another possibility is to run reiserfsck on the actual physical drive "partition" rather than the /dev/"md" device.  This will cause parity to get out of sync if it changes something though.  I'd leave this for last, or do it on a copy of the partition.

[lostincable]

No go on the rebuild tree !

 

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to [email protected], **
** 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 consistency of the filesystem on /dev/md1
and will fix what can be fixed without --rebuild-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
###########
reiserfsck --fix-fixable started at Thu Dec 13 10:51:59 2012
###########
Replaying journal: Done.
Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed
Checking internal tree..

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

Aborted

[lostincable]

Just bumping this thread up...

 

Been offline for a while and have had the server switched of.

 

I have the server back on now but this problem exists.

 

Any ideas or is the data well and truly gone?

 

Thanks!

[Joe L.]

Did you try any of the suggestions I made last? (rebuilding the superblock?)  If not...

 

Let's try something slightly different.  Just to check

 

For the physical disk corresponding to the drive showing as unformatted, type

reiserfsck --check /dev/sdX1

(note the trailing "1" on the device name, denoting the first partition on the drive where the file system resides.)