0

In a Linux Software raid, what is the best practice for periodically having the filesystems checked? With single drive or hardware raid, tune2fs -c 5 -i 1w /dev/sda1 means check the filesystem every 5 mounts or if it has been a week or more since the last mount.

But in mdadm land, there are are at least three devices that could be checked in four ways:

  1. echo check > /sys/block/md0/md/sync_action
  2. tune2fs -c 5 -i 1w /dev/md0
  3. tune2fs -c 5 -l 1w /dev/sdal
  4. tune2fs -c 5 -l 1w /dev/sdb1

I am thinking i only want to automatically do #1 and #2. Never ever do check the physical drives directly. man md says it is not always abnormal for the physical drives to have different data because sometimes it does not matter.

A good practice is to stress the bare-metal parts of a harddrive a few times in the first 90 days. The goal is not necessarily a filesystem test, but a hardware stress test, hence e2fsck -v -f -c -c -D -C 0 /dev/md1. This manually run forced fs check reads and writes the entire fs and orders it alphabetically while printing verbose output to stdout. md is smart enough to setup RAID across disparate harddrives, but is it smart enough to manage the badblocks list separately for each drive member? Would doing the above e2fsck upon software raid /dev/md0 mark badblocks on both drives even though a badblock exists on just one drive?

Should the member drives ( /dev/sdX ) have the same or different UUIDs as the RAID drive ( /dev/mdY ) ? If the same, it is easy to find all the members of a raid set. But if the same, tune2fs based e2fsck gets registered for both the physical member drives and software raid.

1
  • p.s. Actually, on SSDs, i have it check every single mount because it is fast and has saved me numerous times.
    – rjt
    Mar 25, 2015 at 10:03

1 Answer 1

3

You're talking about two completely different types of check at different levels of the storage.

  1. The consistency check provoked by echo check > /sys/block/md0/md/sync_action just compares the two sides of the mirror (I'm assuming you're talking about a pair of mirrored drives). It doesn't know anything about the structure of the bits it is comparing so it isn't going to tell you anything about the health of the filesystem.

  2. The settings which control fsck are a property of the filesystem so there's only one of your tunefs options that makes sense - tunefs -i 1w /dev/md0. Unless things have changed significantly since I last looked fsck will only happen just before the filesystem is mounted. Running fsck on a mounted filesystem is generally not recommended (certainly the e2fsck man page still says this). How often filesystems get checked in practive depends on how often the system is rebooted (unless you have special procedures in place to umount and mount the filesystems at regular intervals.

1
  • Good breakdown of the block versus fs layers. Mention echo repair > /sys/block/md0/md/sync_action In what order would you do the block level cc and the fs level check? The UUIDs seem to matter at least according to output from tune2fs -l[serverfault.com/questions/674699/…. What about stressing the hardware itself.
    – rjt
    Mar 25, 2015 at 10:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .