S kámošem jsme narazili na chybu v Debianu Testing (ale podle bugreportů je již v Jessie) související s mdadm raidem.
Bugreporty:
Problém
Mějme existující softwarový raid, na kterém je FS, který se má mountovat po startu OS. Nemusí se jednat o pole na kterém je /boot nebo /, může to být libovolné mdadm pole nesoucí fs, který se má někam připojit. Tedy poměrně běžná a standardní situace.
Problém nastane, pokud stroj vypneme a jedno zařízení z raidu vyjmeme. Debian během bootu nesestaví mdadm raid v degradovaném režimu, jak by se dalo očekávat, nesestaví jej prostě vůbec.
K dovršení tragédie potom systemd čeká 90s na zařízení, které se tam nikdy neobjeví.
Možnosti řešení
Ideální řešení je označení vyměňovaného zařízení jako failed (mdadm /dev/md0 --fail /dev/sdX), což často udělá mdadm sám, pokud usoudí, že disk je už opravdu dost vadný (prostě až se na něj nepodaří něco zapsat, jenže to už je, alespoň pro mě, hodně pozdě).
Jenže toto není vždy možné udělat a někdy je prostě nutné disk vytáhnout, když je zařízení vypnuté a není tak možnost informovat OS a mdadm o tom, že toto zařízení už nikdy neuvidí.
Dále funguje ruční práce v podobě:
mdadm -A --scan mdadm --run mdadm -w (pole se standardně spustí jako auto-read-only) mount
a pole v pořádku v degradovaném režimu najede. Jenže toto řešení není pro každého, ne každému se chce hrabat v --examine, --detail, apod a riskovat, že neopatrným chování zničí pole, které je jinak vlastně zcela v pořádku.
Degradovaný stav nepovažuji za problém, ale za účel raidu. Redundantní pole si stavíme právě proto, aby přežilo výpadek určeného počtu disků a aby bylo dostupné i během výpadku disku. OS by měl s tímto stavem počítat, pole sestavit a příslušným způsobem admina upozornit na tento stav. Považuji za chybu, kdy se během startu OS pole nesestaví, i když to jde.
Příčina tohoto problému je ve změně režimu sestavování pole během bootu, v nově (od Jessie) se prostě čeká na všechna zařízení, která do pole patří. Více se dočtete v bug reportech.