Re: fsck --run-with-scissors

From: John-Mark Gurney <gurney_j_at_resnet.uoregon.edu>
Date: Wed, 3 Nov 2004 22:48:03 -0800
David Gilbert wrote this message on Mon, Nov 01, 2004 at 14:28 -0500:
> You know... I've had a number of unrelated disk failures in the last 7 
> days.  In general, we have backups.  Some of the failures are such that 
> I can still mount the fs readonly and avoid the dead area and get the 
> last iota of data off, but some are not.
> 
> It would be really useful if fsck_ffs had a --run-with-scissors mode.  
> Meaning a mode of last resort that may or may not make the disk work and 
> may or may not totally screw with the disk.
> 
> As an example, my laptop drive died.  I don't really care about the data 
> on disk because it's backed up.  However, it will be another day before 
> Dell shows up with a new drive... meaning that now I'm suffering in XP.  
> In many cases, if the block-in-question was written to (even though it 
> can't be read), it would be reallocated by the drive logic.  Run with 
> scissors should write all zeros to a block it can't read.

dd will do this...

dd if=/dev/zero of=/dev/diskdev oseek=<blknum> bs=512 count=1

I've done this before..  Though you have to make sure you're using the
correct block number which can be verified with:
dd if=/dev/diskdev iseek=<blknum> bs=512 count=1 of=/dev/null

Just as a little bit of fun, even if the bad block is in the primary
super block, and you can successfully use fsck -b <secondsb>, you can
copy one of the secondary superblocks back over the primary, but be
VERY careful when doing this...  (I've successfully recovered a bad disk
this way once..)

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
Received on Thu Nov 04 2004 - 05:48:12 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:20 UTC