I'm running Ext4 on a harddrive, and to be perfectly honest, I don't really trust the drive because it's old and has a few badblocks. I have nonessential data on the drive, so if it died tomorrow, then no big deal.

However, I would like to know if/when it starts to die, and remount read only. Are there any options that will enable extra file checks on an Ext4 fs? (I don't care if it makes the filesystem slower.)

  • 1
    The hard drive has internal CRC checks, so even if it's failing and/or having pending blocks, it should detect those errors and report them to the operating system. If files become damaged due to damaged hard disk blocks, you will see these damages as IO errors without any special options. – Martin von Wittich Jan 24 '14 at 17:55
  • @MartinvonWittich The drive could, or not but if data get corrupted while being transmitted between the drive and the disk controller, drive internal CRC checks don't buy you anything... So yes, CRC at the FS level is a nice feature to have. – Mathieu May 8 '15 at 22:46

Since the 3.6 kernel ext4 suppports metadata checksumming (you'll also need e2fsprogs 1.43+) but it's not clear just how stable this feature is. Additionally you can mount your ext4 filesystem with the journal_checksum feature but...

...it seems like at some point in the past people wanted to make this a default option but this change didn't happen due to issues.


However, I would like to know if/when it starts to die, and remount read only.

Mounting read-only won't save you anything if the issue is bad blocks -- look at the first paragraph here and note the issues associated with read errors.

There's no way to detect bad blocks without physically reading over the disk, so, like searching for a mouse trap set in a dark room, there are no ways to avoid the potential problems when checking. If you believe the disk is failing, periodically umount and run e2fsck -c on all the partitions; if this is your root filesystem and you need to use, e.g., a liveCD to do this, then do it. As per the man page;

-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 directory.

If the blocks contained data, a salvaged version may end up in the /lost+found directory at some point, I'm not sure.

Note that this may take some time. If there are bad blocks, the scan may trigger I/O issues that lock-up the entire system for hours, so do this when you are comfortable walking away for a while.

  • 1
    "mouse trap set in a dark room". Nice phrase. – Faheem Mitha Jan 24 '14 at 18:17

Also, generally speaking, some utilities can monitor different aspects of the situation and allow you to take appropriate action.

For instance, the smartctl tool from the smartmontools package will give you access to the built in SMART status for some drives.

You can also increase the frequency of filesystem checks on a specific target using the tune2fs command. For instance it seems that tune2fs -c 1 target will make sure the drive is checked pretty much every time before it's mounted on boot.

  • 1
    smartctl can also execute the disk's internal selftest mechanism, for example with smartctl -t long /dev/sdX. – Martin von Wittich Jan 24 '14 at 21:47
  • 1
    @MartinvonWittich The issue with SMART is you need to know what you're looking for backblaze and they don't necessarily tell you much google: "Our analysis identifies several parameters from the drive’s self monitoring facility (SMART) that correlate highly with failures. Despite this high correlation, we conclude that models based on SMART parameters alone are unlikely to be useful for predicting individual drive failures." – Mathieu May 8 '15 at 22:52
  • @Mathieu yeah, that SMART prediction stuff is IMO pretty worthless. But the selftests are in my experience 100% accurate. Most people unfortunately don't know that they exist and therefor they're rarely used. – Martin von Wittich May 20 '15 at 10:53

Good point from illuminÉ. It is good to have the smartd running in backgroud which periodically checks for failures.

Beside of this you can use

e2fsck -fvy -c -c -C0 /dev/sda1

-f    Force checking even if the file system seems clean.
-v    Verbose mode.
-y    Assume an answer of `yes' to all questions
-C0   write  completion  information to stdout
-c -c If this option is specified twice, then the 
      bad block scan  will  be  done  using  a  non-destructive
      read-write test.

This non-destructive read-write test (-c -c), lets you know if there are read failures.
However it takes a lot of time.

So it should be a transit solution before purchasing a new drive.

  • Except you can't do while the FS is mounted and scanning for bad blocks is slow as molasses so it's not really a viable option.... – Mathieu May 8 '15 at 22:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.