Vedere la pagina Espansione di un volume virtuale.
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
Con il comando seguente viene creato e immediatamente attivato un volume RAID1 in modalità degradata, cioè con un solo disco attivo:
mdadm --create /dev/md10 --run --level=1 --raid-devices=2 /dev/sdb3 missing
Per aggiungere un componente ad un volume RAID, ad esempio per ripristinare un volume degradato:
mdadm /dev/md0 --add /dev/hdc1
Se non è possibile montare un volume RAID nella sua completezza (ad esempio perché un componente di un RAID1 è guasto), il volume non viene attivato automaticamente. Per forzare l'operazione è necessario passare il parametro --run nel modo assemble oppure nel modo misc:
mdadm --assemble /dev/md0 --run mdadm --misc /dev/md0 --run
Il modo --misc va usato se il device è stato assemblato solo parzialmente (cioè esiste il device, ma non è running, quindi risulta vuoto). Il nome del device. il corrispondente UUID e quindi le partizioni componenti vengono desunte dal file di configurazione /etc/mdadm/mdadm.conf.
È possibile anche forzare il nome del volume da creare e indicare le componenti da assemblare, specificando tutto sulla riga di comando:
mdadm /dev/md17 --assemble /dev/sdc7 --run
Per rimuovere un componente, ad esempio da un volume RAID1, è necessario prima marcarlo come guasto (fail), dopo sarà possibile rimuoverlo dal RAID, che continuerà a lavorare in modalità degradata:
mdadm --manage /dev/md0 --fail /dev/sdb2 mdadm --manage /dev/md0 --remove /dev/sdb2
Per eliminare definitivamente un volume raid è necessario fermarlo, quindi è opportuno azzerare il sperblock di ogni componente, per evitare che l'auto-run dei volumi trovi la signature nelle partizioni e provveda a fare l'assemblaggio al successivo reboot:
mdadm --stop /dev/md4 mdadm --zero-superblock /dev/sda7 mdadm --zero-superblock /dev/sdb7
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.
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
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.
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.
Regression - mdadm in jessie will not boot degraded raid1 array. 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).
To geneate the configuration file /etc/mdadm/mdadm.conf you can use the tool /usr/share/mdadm/mkconf, which gathers information from the existing RAID volumes. The information are read from the superblock of the MD arrays and contains the name and homehost, so the file created contains lines like this:
ARRAY /dev/md/125 metadata=1.2 UUID=d92a8066:fc45b7d3:f916e674:3a695968 name=hostname:125
Editing mdadm.conf to rename a device (e.g. changing from /dev/md/125 to /dev/md/5) will work on the next reboot (remember to update initramfs), but eventually mkconf will restore the name /dev/md/125 on the next run. To change the name permanently you have to stop the RAID device and update the superblock:
mdadm --stop /dev/md/125 mdadm --assemble /dev/md/5 --name=5 --homehost=newhostname --update=name /dev/sda5 /dev/sdb5
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
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
Su un server remoto o privo di monitor/tastiera conviene impostare il fix automatico di eventuali errori nel filesystem, senza richiesta di intervento manuale. Questo soprattutto prima di forzare un fsck al reboot.
Fino a Debian 7 Wheezy era sufficiente impostare in /etc/default/rcS:
FSCKFIX=yes
Da quando si usa il sistema di init systemd (cioè da Debian 8 Jessie) tale file non viene più preso in considerazione, esistono invece le unit chiamate systemd-fsck@.service e systemd-fsck-root.service (vedere man 8 systemd-fsck). Tale servizio riconosce alcuni parametri passati al kernel che si possono aggiungere - eventualmente separata da spazi - in /etc/default/grub (ricordarsi poi di eseguire update-grub):
GRUB_CMDLINE_LINUX="fsck.repair=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
Se ci sono differenze fra il sistema su cui si esegue il mkfs.ext4 e il sistema su cui si esegue il grub-install, si potrebbe incorrere nel seguente errore:
grub-install /dev/sda Auto-detection of a filesystem of /dev/sda2 failed
Il caso visto sopra è dovuto al fatto che il filesystem è stato creato sull'host avviato con S.O. 64bit, mentre il grub-install è stato eseguito in un chroot di un sistema a 32bit.
Con tune2fs -l è possibile vedere le Filesystem features, quindi è possibile creare il filesystem con le opzioni opportune. Ad esempio il nostro problema è stato risolto eseguendo:
mkfs.ext4 -O 'uninit_bg,^64bit,^metadata_csum' /dev/sda2