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