Systém samozřejmě nenaběhl s hláškou, že mu chybí partition pro swap. Když jsem se probral z mrákot, čekala mě hodina práce s hledáním příčiny a jejím odstraněním. Doteď nevím, proč v grubu byly připojené swap oddíly z obou disků.

Poznámky pro příště:

1. nabootovat live CD
2. přimountovat /dev/sdxx (boot)
3. zeditovat grub2.conf a odmazat z něj nedostupný swap
4. přimountovat /dev/vg_jméno_skupiny/lv_root
5. zeditovat /etc/default/grub.conf a odmazat z něj nedostupný swap, aby při zavedení nebyl další problém
6. restartovat a modlit se
7. po naběhnutí systému přegenerovat menu (cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.20130113; grub2-mkconfig -o /boot/grub2/grub.cfg)

Vytvoření pole

Zpátky k diskovému poli. Na obou discích jsem si vytvořil partition o stejné velikosti (sda1, sdb1, 250 GB). Disky jsem pomocí mdadm spojil do pole:

mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sda1 /dev/sdb1

Systém začal se synchronizací sektorů, což jsem sledoval pomocí opakovaného výpisu:

watch cat /proc/mdstat

Mezitím jsem pole zformátoval a připojil do /media/raid

mkfs.ext4 /dev/md0

Pozn. je to vytváření pole z prázdných oddílů, pokud byste ho chtěli vytvořit nad existujícími daty, je to trochu složitější - musí se nejdřív vytvořit pole s jedním diskem, pak na něj data překopírovat a pak přidat druhý disk.

Nakopírování obsahu a SE Linux

Synchronizaci jsem nechal běžet a druhý den jsem pokračoval zkopírováním /home:

rsync -avx /home/ /media/raid

Pole jsem zase odpojil, slavnostně změnil mountování /home v /etc/fstab na /dev/md0 a restartoval.

Protože jsem na pole přenášel jen /home a ne celý root, nemusel jsem měnit GRUB nebo ramdisk. Až se do takové operace pustím, jestli vůbec, tyhle poznámky rozšířím.

Opět začala legrace, protože SELinux začal křičet snad při všem, nejvíc při pluginech v browseru, ale nebyla to jediná věc. Pořád mlel něco o špatných labelech... Spravil to až relabelling:

restorecon -R /home

Kéž bych věděl, co to vlastně znamená.

Konfigurace zpráv

Po sestavení pole je nutné vytvořit soubor /etc/mdadm.conf s minimálně těmito dvěma řádky:

DEVICE partitions
MAILADDR root

První informuje jádro, že při hledání pole má procházet i partitions a ne jenom disky, druhý kam má posílat maily s informacemi o problémech. Pro optimalizaci je dobré také do souboru přidat řádek s již identifikovaným polem - výstup příkazu mdadm --detail --scan. Jednak se tím dají vynutit pokaždé stejné parametry (číslo device, jméno), jednak se to může hodit i vám samotným při nějakých problémech.

Já to nějak v návodu přehlédl či podcenil, po týdnu od vytvoření pole se podíval na jeho stav a zjistil, že je rozpojené (degradované), že ten týden funguji jen na jednom disku a že větší bezpečí dat byla pouhá iluze.

Urychleně jsem soubor nakonfiguroval včetně parametrů pole a od dalšího restartu už mi varovné maily chodit začaly.

Spojení rozpojeného pole

Pole se mi rozpadlo kvůli změně realokovaných sektorů, disk evidentně začal odcházet (už podruhé, je to vyměněný kus, Seagate si mou důvěru zrovna nezískal). SMART diagnostika ale hlásila stabilizovaný stav, rozhodl jsem se disk znovu do pole vřadit. To se dělá pomocí

mdadm /dev/md0 -a /dev/sdb1

Okamžitě začne synchronizace pole, sledovat se dá opět pomocí watch cat /proc/mdstat.

Spares Missing

Jen jen synchronizace skončila, dal jsem restart, abych se podíval, jak mi pole šlape jaksi od bootu. Ale ouha, po restartu jsem měl dva nové maily. První křičel, že pole je degradované (opět). Pohled na smart diagnostiku:

smartctl -a /dev/sdb | grep Sector

ukázal, že se opět změnil počet pending a realokovaných sektorů. Asi jak během přidávání disku do pole kopíroval sektor po sektoru, objevil další problematické sektory, a to po restartu způsobilo opětovné vyřazení. Tak znovu.

Samozřejmě jsem okamžitě objednal nový disk, tohle není stav, ve kterém bych chtěl zůstávat déle, než je nutné.

Druhý mail byl ještě zajímavější, informoval mě, že chybí spares disk:

This is an automatically generated mail message from mdadm running on machine

A SparesMissing event had been detected on md device /dev/md/0.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid1]
md0 : active raid1 sda1[0]
245628736 blocks super 1.2 [2/1] [U_]

unused devices: <none>

Sapristi, jaký spares disk?? Trápil jsem se s tím poměrně dlouho, než jsem přišel na to, že v tom zatraceném mdadm.conf se mi do definince pole nějak připletlo „spares=1“. Je to nesmysl, žádný rezervní disk nemám - nechápu ale, jak se to tam dostalo, já to ručně rozhodně nepsal. Možná že při generování onoho řádku v degradovaném stavu usoudil mdadm, že mám jeden disk v rezervě... Každopádně odmazat „spares=1“ pomohlo.

Zjišťování informací o polích

To jen pro přehled:

• prohledání polí: mdadm --detail --scan
• Podrobný výpis stavu celého pole: mdadm -D /dev/md0
• Stručný výpis stavu celého pole: cat /proc/mdstat
• Podrobný výpis superbloku na partition: mdadm -Q --examine /dev/sdb1

Vyřazení vadného disku

To jsem dělat nemusel, protože se mi jaksi z pole vyřazoval sám, a superblock jsem také nulovat nepotřeboval, protože jsem před reklamací disk několikrát přejel nulami a náhodnými čísly sakumprásk od začátku do konce, ale raději si to sem poznamenám:

Nejprve se musí označit jako vadný (faulty):

mdadm /dev/md0 -f /dev/sdb1

Pak se z pole vyřadí:

mdadm /dev/md1 -r /dev/sdb1

A nakonec se vynuluje superblock, takže jádro ho už jako součást pole nebude identifikovat:

mdadm --zero-superblock /dev/sdb1

Scrubbing