User Tools

Site Tools


doc:appunti:linux:sa:raid

This is an old revision of the document!


Gestione dei dischi in Linux

Maneggiare le partizioni

Cambiare dimensione a una partizione ext3

resize2fs -p /dev/hda7 <newsize>

Vedere man resize2fs per come si specifica la size, mi pare che il suffisso s che dovrebbe indicare settori da 512 byte non sia onorato per bene (confusione con i blocchi del filesystem?).

Forse conviene che la partizione non sia montata?

Parametri Boot (per GRUB o LILO) relativi al RAID

Se vogliamo forzare il kernel ad assemblare le partizoini RAID in un determinato modo si possono passare dei parametri al kernel stesso, ad esempio:

raid=noautodetect md=1,/dev/hda5,/dev/hdc5 md=4,/dev/hda2,/dev/hdc2 root=/dev/md4

Gestione volumi RAID

Utilizzo di mdadm

Invece dei vecchi raidtools si usa il nuovo mdadm.

Aggiungere una partizione ad un volume RAID

mdadm /dev/md0 --add /dev/hdc1

Checking health of a RAID volume

A disk can degrade (some bits get altered) without that hardware errors are detected, in this case the Linux md subsystem (cat /proc/mdstat) does not display any error. Fortunately - with recent Linux kernels (>= 2.6.17?) - we can force a check of the whole volume consistency. Say we want to check /dev/md0:

echo check >> /sys/block/md0/md/sync_action

Mismatches found are not repaired, but a count is displayed by:

cat /sys/block/md0/md/mismatch_cnt

The counter is reset at the start of the check, increased for each mismatch found, and then stored permanently (also across reboot?). It seems that each mismatch counts as 128 (may be this is the number of tries attempted before the mismatch is acknowledged?).

Unfortunately I have not yet found a way to know the exact filesystem block with the mismatch. If we could know the block number we could use debugfs(8) to discover the actual file using the mismatching block. Attempting to repair the mismatch is done by:

echo repair >> /sys/block/md0/md/sync_action

At the end of the repair we can read the mismatches found (and hoply repaired) via the mismatch_cnt. A new run of the check action should end with a zero mismatch_cnt.

I encountered a case where - for unknow reasons - the reapir did not work: the mismatch_cnt did not reset to zero. Fortunately it was a swap partition, so I solved the mismatch rewriting the partition entirely:

swapoff /dev/md1
dd if=/dev/zero of=/dev/md1
mkswap /dev/md1
swapon /dev/md1

Read also man md(4) and /usr/src/linux/Documentation/md.txt.

Managing bad blocks

resync=PENDING

If a volume remains in a resync=PENDING state (eg. a swap file which is in auto-read-only), you can force the resync with:

mdadm --readwrite /dev/md1

GRUB savedefault and RAID mismatches

The GRUB boot loader has the savedefault option which is used to remember the chosen boot entry. The information is saved into the /boot/grub/stage2 file (at least with GRUB 0.97). This is a problem if the file resides on a RAID volume, because GRUB is not aware of RAID and it writes on the underlying component device. For a RAID1 volume this means that only one component will be written, creating a RAID mismatch.

This problem can cause false alarms on systems that perform periodic RAID checks (a default setup on a Debian box), this is the warning found in /var/log/syslog:

mdadm: RebuildStarted event detected on md device /dev/md0
mdadm: Rebuild80 event detected on md device /dev/md0
mdadm: RebuildFinished event detected on md device /dev/md0, component device  mismatches found: 128

I think that savedefault option should be avoided when using Linux software RAID on the boot partition.

RAID in auto-read-only mode

You may find that a RAID array was assembled in auto-read-only mode, like this one:

md1 : active(auto-read-only) raid1 sda5[0] sdb5[1]
      1951744 blocks [2/2] [UU]

It seems a normal behaviour in newer Linux kernels (2.6.22). The read-only status is removed automatically as soon as something is written to the device. I did not find much info about this.

If you want to control this feature, check the state of the start_ro module parameter and eventually change it:

cat /sys/module/md_mod/parameters/start_ro
1
echo 0 > /sys/module/md_mod/parameters/start_ro

Obviously you need to change this parameter before the md kernel subsystem assembles the RAID volumes.

Mdadm problem with Debian Jessie and degraded raid1

See Debian bug #784823. This is a workaround, as suggested by this post:

cd /etc/initramfs-tools/scripts/local-top
cp /usr/share/initramfs-tools/scripts/local-top/mdadm .
patch --verbose --ignore-whitespace <<'EndOfPatch'
--- mdadm
+++ mdadm
@@ -76,7 +76,15 @@
   if $MDADM --assemble --scan --run --auto=yes${extra_args:+ $extra_args}; then
     verbose && log_success_msg "assembled all arrays."
   else
-    log_failure_msg "failed to assemble all arrays."
+    log_warning_msg "failed to assemble all arrays, attempting individual starts..."
+    for dev in $(cat /proc/mdstat | grep '^md' | cut -d ' ' -f 1); do
+      log_begin_msg "attempting mdadm --run $dev"
+      if $MDADM --run $dev; then
+        verbose && log_success_msg "started $dev"
+      else
+        log_failure_msg "failed to start $dev"
+      fi
+    done
   fi
   verbose && log_end_msg

EndOfPatch
update-initramfs -u

Somewhere on the net there is a suggestion to use the md-mod.start_dirty_degraded=1 kernel command line, but this is not the case, because it is used to force starting degraded and dirty RAID5 and RAID6 volumes. Another hint about a BOOT_DEGRADED=true options in initramfs config seems to be Ubuntu specific.

The problem is that the initramfs hook script provided by the mdadm package does:

mdadm --assemble --scan --run --auto=yes

which actually does not run the array if it is degraded (where the previous start was not).

Filesystem has unsupported feature(s)

Può capitare che un filesystem abbia errori.

Può capitare che qualche insano di mente cerchi di riparare questi errori avviando il computer con una versione diversa del sistema operativo in uso. Il risultato può essere un filesystem che il sistema operativo originale non riesce più ad usare:

fsck.ext3 -f -y /dev/hda1
e2fsck 1.27 (8-Mar-2002)
fsck.ext3: Filesystem has unsupported feature(s) (/dev/hda1)
e2fsck: Get a newer version of e2fsck!

Scartiamo l'ipotesi che qualche altro insano di mente innesti una versione di e2fsck diversa da quella fornita col sistema operativo, possiamo usare debugfs per rimettere a posto le cose. Basta scoprire quali sono le features supportate e rimuovere quelle di troppo:

debugfs -w /dev/hda1
debugfs 1.27 (8-Mar-2002)
debugfs:  features
Filesystem features: resize_inode dir_index filetype sparse_super
debugfs:  feature -resize_inode
Filesystem features: dir_index filetype sparse_super
debugfs:  feature -dir_index
Filesystem features: filetype sparse_super
debugfs:  quit

Passaggio da ext3 a ext2

Per convertire un filesystem ext3 in ext2 si deve rimuovere il journal, per tornare ad ext3 basta ricrearlo (tutte qui le differenze?). Il filesystem deve essere smontato. Maggiori informazioni qui: Converting Ext2 Filesystems to Ext3.

tune2fs -O ^has_journal /dev/md3

Per creare nuovamente il journal:

tune2fs -j /dev/md3

Forzare fsck al reboot

Prima di forzare il fsck conviene controllare in /etc/default/rcS che il fix di eventuali errori avvenga in automatico, senza richiesta di intervento manuale:

FSCKFIX=yes

Controllare anche in /etc/fstab che il sesto campo sia diverso da zero: 1 per il rootfs, 2 per gli altri.

Con tune2fs è possibile verificare ogni quanti reboot viene fatto il check e quando è stato fatto l'ultimo:

tune2fs -l /dev/sda3
...
Mount count:              18
Maximum mount count:      38
Last checked:             Wed May  9 18:57:29 2012
...

Un metodo di forzare il check è aumentare artificialmente il Mount count:

tune2fs -C 100 /dev/sda3

Oppure creare il file

touch /forcefsck

Un altro sistema è forzare il check sulla richiesta di reboot:

shutdown -rF now
doc/appunti/linux/sa/raid.1442475811.txt.gz · Last modified: 2015/09/17 09:43 by niccolo