0

The Title pretty much says it all.

Turn off mount count fsck seems to succeed:

tune2fs -c 0 /dev/sda1
tune2fs -c 1 /dev/md0

But listing out via

tune2fs -l /dev/sda1 shows mount count is set back to 1 for /dev/sda1 and /dev/md0.

i only want automatic file system checks on the software raid device, not the member drives, but it keeps going back on for the member drives.

3 Answers 3

0

Automatic file system checks at boot time are based on the information you have in the fstab.

This means either you have a problem in the /etc/fstab configuration or if you are using LABEL or UUID you have a problem how those block devices are configured. I suspect it it a problem related to udev, or udev configuration.

2
  • The member drives are definitely not in /etc/fstab. Should the member drives in a RAID1 have the same UUID as the /dev/md0?
    – rjt
    Mar 11, 2015 at 20:41
  • No, the UUID should be different. Could you please add the output of lsblk --output NAME,KNAME,MAJ:MIN,FSTYPE,UUID Mar 12, 2015 at 15:46
0

My member drives and the RAID1 drive all have the same UUID. Will change the member UUIDs via:

tune2fs -U time /dev/sda1

but now i have second thoughts because there seems to be conflicting views on whether the member drive UUIDs should equal the RAID UUID?

# for fs in md1 sda2 sdb2; do tune2fs -l /dev/${fs} | egrep -i '(UUID|Hash Seed)'; done;
Filesystem UUID: 0de026e2-a1ce-461c-bb3f-c3982b064b4c Directory Hash Seed: 0a5f8be8-965c-48b2-a0c6-3c1cd314a12f Filesystem UUID: 0de026e2-a1ce-461c-bb3f-c3982b064b4c Directory Hash Seed: 0a5f8be8-965c-48b2-a0c6-3c1cd314a12f Filesystem UUID: 0de026e2-a1ce-461c-bb3f-c3982b064b4c Directory Hash Seed: 0a5f8be8-965c-48b2-a0c6-3c1cd314a12f

7
  • i don't thing is good idea work with raid member diveces "tune2fs -l /dev/sda1 tune2fs 1.42.5 (29-Jul-2012) tune2fs: Bad magic number in super-block while trying to open /dev/sda1 Couldn't find valid filesystem superblock. "
    – c4f4t0r
    Mar 11, 2015 at 19:50
  • @c4f4t0r, maybe you need to sudo up to root to get permissions to read the superblock. tune2fs -l /dev/sda1 provides the exact same output as tune2fs -l /dev/md0 and that is why i have the problem - same UUIDs.
    – rjt
    Mar 11, 2015 at 20:01
  • i'm using the root user.
    – c4f4t0r
    Mar 11, 2015 at 20:42
  • @c4f4t0r, i am no expert, but i bet there is a problem with your drive. Does cat /proc/mdstat say its UP and ok? Maybe echo check > /sys/block/md0/md/sync_action Consider repair as well.
    – rjt
    Mar 11, 2015 at 20:56
  • @c4f4t0r, could you have the RAID member drive be the whole drive such as /dev/sda instead of a partition? Try tune2fs -l /dev/sda
    – rjt
    Mar 11, 2015 at 21:01
0

/dev/md0 is a device on top of /dev/sda1 and /dev/sdX1, the member drives of a RAID 1 array. This means that all changes that you make to a filesystem on /dev/md0 will be propagated to both member drives. This is the answer to your question in the title.

It also means that the filesystem UUID is exactly the same on both /dev/sdX1 and /dev/mdo.

Once you have set up RAID 1 with member devices, you should not make any changes to the member drives directly (including tune2fs etc.), because that might disturb the RAID operation.

What is the original problem you are trying to solve here?

3
  • One problem is that e2fsck will possibly be performed directly against a member drive and it can't be turned off unless I A.remove the drive from the array, B.set a different GUID, then C. disable auto fsck, D. set GUID back to original Raid1 UUID and then. E. rejoin to array.UUID
    – rjt
    Mar 11, 2015 at 21:55
  • What exactly would perform the e2fsck directly against a member drive? There is something wrong in the OS if this happens. Mar 11, 2015 at 23:49
  • my other Raid1 has different UUIDs for each member and different again for the md disk.
    – rjt
    Mar 12, 2015 at 23:20

You must log in to answer this question.

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