3

I have a 10-years old 320 Gb HDD which I've used as an external drive, and it traveled with me for much of those 10 years. Needless to say, it survived more than a few falls (including those while in operation), and got some bad sectors. When I actually started to get read errors, not just SMART sector relocation warnings, I moved away everything important from it (using ddrescue for some files). Sure I can't trust this drive anymore, but I still want to use it to copy once and keep some movies/FLACs, to free some space on laptop's SSD+HDD, as long as the external drive still works. I don't care losing some or all of these files, as I either have backups at home and/or can re-download easily.

The problem is, if I format this drive and start copying the files there, somewhere around 25% I get a write failure, necessitating USB cable unplug (^C is not enough!), same happens with badblocks both in read and write mode. After playing a bit with badblocks' "from" and "to" parameters, I've found that 90%+ of the drive is OK, and there are basically 3 bad block areas. A short script and I got a text file with block numbers (yes I didn't forget -b 4096 for badblocks) covering these areas and lots of extra space around to be safe. But when I did e2fsck -l badblocks.txt, it still hangs! seems like it's trying to read those bad blocks anyway, not just to mark as bad and forget. Is there any other way to get around this? Or maybe other filesystem (thought about FAT, but I don't see any way to feed badblocks.txt to fsck.vfat)? Or 4 separate partitions covering the "good" areas is the best solution for this case?

Update: some quotes from man to make the case more clear

man e2fsck:

-i input_file Read a list of already existing known bad blocks. Badblocks will skip testing these blocks since they are known to be bad.

thus, badblocks promises to skip the blocks listed (and it does, as it doesn't hang with all the suspicious ranges in badblocks.txt!)

man badblocks:

-l filename Add the block numbers listed in the file specified by filename to the list of bad blocks. The format of this file is the same as the one generated by the badblocks(8) program.

there's no promise it will not try to access these blocks, though. But why the hell it may want to access them?

Note that the block numbers are based on the blocksize of the filesystem. Hence, badblocks(8) must be given the blocksize of the filesys‐ tem in order to obtain correct results. As a result, it is much simpler and safer to use the -c option to e2fsck, since it will assure that the correct parameters are passed to the badblocks program.

I'd be happy but it hangs on a first bad block. Plus, -c is incompatible with -l - thus, I either scan the disk or manually mark the bad sectors. But why, if I choose the latter option, it still wants to access these supposedly "bad" sectors is beyond my understanding...

pazhosch
  • 51
  • 2
  • 9

1 Answers1

4

The proper way to badblock your disk is either:

sudo e2fsck -fck /dev/sdc1 # read-only test

or

sudo e2fsck -fcck /dev/sdc1 # non-destructive read/write test (recommended)

The -k is important, because it saves the previous bad block table, and adds any new bad blocks to that table. Without -k, you loose all of the prior bad block information.

The -fcck parameter...

   -f     Force checking even if the file system seems clean.

   -c     This option causes e2fsck to use badblocks(8) program  to  do  a
          read-only  scan  of  the device in order to find any bad blocks.
          If any bad blocks are found, they are added  to  the  bad  block
          inode  to  prevent them from being allocated to a file or direc‐
          tory.  If this option is specified twice,  then  the  bad  block
          scan will be done using a non-destructive read-write test.

   -k     When combined with the -c option, any existing bad blocks in the
          bad blocks list are preserved, and any new bad blocks  found  by
          running  badblocks(8)  will  be added to the existing bad blocks
          list.
heynnema
  • 68,647
  • 15
  • 124
  • 180
  • Well, I've started from that before. Both command hang on unreadable/unwritable sectors, as internally `e2fsck -c /dev/sdc1` and `e2fsck -cc /dev/sdc1` call `badblocks /dev/sdc1` and `badblocks -n /dev/sdc1`, respectively (with some extra parameters like block size (`-b`) etc.). That's why I resorted to a lower level utility, that is `badblocks`, which has the parameters for the first and last block tested, so once it did hang on a block, I could try and guess where the "bad range" could end (typically I added 100k blocks, adding more if not enough) and then test the blocks past that range. – pazhosch Mar 23 '19 at 07:07
  • That's how I ended up with 4 areas of completely writable and readable (I did first a destructive test by -w as it's much faster than -n or `badblocks`' -cc, then checked the "writable" areas by a read test, which found a few errors too, shrinking the "good" range found) blocks, separated by 3 "areas containing some bad blocks". I then just wrote these areas' block numbers to a text file using `seq`. A test using `badblock -s -v -n -i badblocks.txt` does pass. But `e2fsck -l badblocks.txt' (`-c` is incompatible with `-l` btw) still tries to access some of the blocks listed there, and hangs :( – pazhosch Mar 23 '19 at 07:16
  • Just face the fact that your 10-years old 320 Gb HDD is bad. Why try and force it? For $20 you can replace it, if you can still find one that size. – heynnema Mar 23 '19 at 13:12
  • 1
    Sure I can buy and not too expensive (and will buy if the drive fails), it's more like a challenge. And well, if buying new drive right now, I'd rather "splurge" on something big (that's how I bought 320gb back in 2008). The best value for money right now seems to be either 2 TB 2.5" or 3 TB 3.5" and I'm more inclined for the latter option (extra terabyte for basically the same). As for the laptop, both SSD and HDD are about 75% full - I don't need 2 TB yet clearly, I just do not want to deal with nearly-full drive (wear for (f2fs for both / and /home, btw) SSD, degraded performance for HDD). – pazhosch Mar 23 '19 at 15:01
  • "and will buy if the drive fails"... it's failed. – heynnema Mar 23 '19 at 15:26
  • ok "if the drive will trash more and more files regularly, or dies completely" ) It will, most likely, the question is will it take days, months, or years(?). Well, if no other ideas soon, I'll try my own idea with 4 partitions - I symlinked to it from the main SSD anyway, so does it really matter the symlinks target one partition or four. – pazhosch Mar 23 '19 at 15:32
  • @pazhosch re: "if the drive will trash more and more files regularly"... how will you know? – heynnema Mar 24 '19 at 14:21
  • well as long as `e2fsck -c` works on all 4 e2fsck partitions, I'm ok. if it hangs on one (and probably I'll initiate that due to some file being unreadable), I've got a warning (will move the the file into `.unreadable` folder, add it again if there's space, and check what's up on HDD market today). When I'll get errors on all partitions with a few rotten files on each, probably it's truly a "Computer Components garbage" box time, where a few other parts are waiting when the recycling place will be close comfortably enough for me :) – pazhosch Mar 24 '19 at 20:14