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.

Community
  • 1
rjt
  • 568
  • 5
  • 25

3 Answers3

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

rjt
  • 568
  • 5
  • 25
  • 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 '15 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 '15 at 20:01
  • i'm using the root user. – c4f4t0r Mar 11 '15 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 '15 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 '15 at 21:01
  • tune2fs -l /dev/sda tune2fs 1.42.5 (29-Jul-2012) tune2fs: Bad magic number in super-block while trying to open /dev/sda Couldn't find valid filesystem superblock. – c4f4t0r Mar 11 '15 at 21:14
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/21871/discussion-between-c4f4t0r-and-rjt). – c4f4t0r Mar 11 '15 at 21:32
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.

Mircea Vutcovici
  • 16,706
  • 4
  • 52
  • 80
  • 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 '15 at 20:41
  • No, the UUID should be different. Could you please add the output of `lsblk --output NAME,KNAME,MAJ:MIN,FSTYPE,UUID` – Mircea Vutcovici Mar 12 '15 at 15:46
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?

Tero Kilkanen
  • 34,499
  • 3
  • 38
  • 58
  • 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 '15 at 21:55
  • What exactly would perform the e2fsck directly against a member drive? There is something wrong in the OS if this happens. – Tero Kilkanen Mar 11 '15 at 23:49
  • my other Raid1 has different UUIDs for each member and different again for the md disk. – rjt Mar 12 '15 at 23:20