fsck --run-with-scissors
John-Mark Gurney
gurney_j at resnet.uoregon.edu
Wed Nov 3 22:48:12 PST 2004
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."
More information about the freebsd-current
mailing list