Problém
Diskový oddíl se po spuštění systému nepřipojí, ať už byl restart plánovaný nebo neplánovaný. Před restartem byl diskový oddíl připojen a fungoval správně. Disk se po dalších restartech systému správně připojil, ale již nefunguje.
K tomuto chování může dojít bez ohledu na typ systému souborů na oddílu a nesouvisí s typem systému souborů. Byly hlášeny poruchy disků se systémem souborů EXT4 nebo OCFS2, ale může k nim dojít u jakéhokoli typu systému souborů.
Typický záznam v souboru /etc/fstab by mohl být podobný:
/dev/sda1 /mydir ext4 defaults 0 0 /dev/mapper/mpath2 /otherdir ocfs2 _netdev 0 0
nebo různé jejich kombinace.
Řešení
Diskové jednotky a oddíly jsou v Linuxu adresovány geograficky podle pozice sběrnice a pořadí zjišťování. Zařízení SAN jsou zvláště zranitelná vůči změnám v pořadí zjišťování kvůli různému načasování restartu sítě SAN nebo klienta.
Názvy souborů v Linuxu, obvykle v adresáři /dev/, jsou dynamicky přiřazovány každému zavedení systému. Při zavádění jádra je detekováno každé dostupné zařízení a do subsystému UDEV (správa zařízení v uživatelském prostoru) je odesláno upozornění. Porovnáním informací v identifikaci zařízení jádra se sadami pravidel UDEV v adresáři /etc/udev/rules.d UDEV přiřadí název zařízení a vytvoří uzel zařízení, jako je /dev/sda nebo /dev/mapper/mpath1, takže že aplikace mohou k zařízení přistupovat. Pokud je detekované zařízení blokově strukturované zařízení, často má oddíly obsahující souborové systémy, které mohou být připojeny podle specifikací v souboru /etc/fstab.
Přestože Linux vynakládá veškeré úsilí na zachování stejného názvu zařízení při restartování systému, změny v externím prostředí mohou ovlivnit skutečné volby názvu. Například:stejný oddíl SAN může být /dev/sda na jednom klientovi, ale /dev/sdf na jiném uzlu klastru, v závislosti na pořadí, ve kterém každý hostitel objevil zařízení, nebo na kterém vícecestném odkazu je online jako první. Uzel běžně objevuje svá zařízení ve stejném pořadí při každém spuštění, ale to není zaručeno. Je zapotřebí metoda, která zaručí trvalou a předvídatelnou identifikaci zařízení.
Přestože se Linux pokouší při každém restartu znovu přiřadit stejný název zařízení, mezi uzly clusteru taková koordinace neexistuje. Oddíl, který se spolehlivě zobrazuje jako /dev/sda1 na jednom uzlu clusteru, by se mohl snadno a legitimně konzistentně zobrazovat jako /dev/sdj na jiném uzlu clusteru. To může ztížit správu systému v celém clusteru, než by bylo potřeba. Níže uvedené řešení lze použít také na clustery, kde se tento problém s restartováním nevyskytuje.
K dispozici jsou alternativní techniky pro trvalý a předvídatelný název zařízení. Níže jsou uvedeny v pořadí podle obtížnosti.
Montáž podle štítku
Mnoho typů systémů souborů podporuje přiřazení libovolného řetězce nebo štítku ke každému systému souborů. Příkladem je souborový systém EXT3:
# /sbin/e2label /dev/sda5 /home
Je běžné vidět záznam /etc/fstab podobný tomuto:
LABEL=/HOME /home auto defaults 0 0
k vyhledání diskového oddílu označeného /HOME, bez ohledu na to, na kterém zařízení se objeví.
Souborové systémy OCFS2 také poskytují rozpoznatelný štítek, který lze použít podobně. Podívejte se na níže uvedený příklad OCFS2, jak určit štítek OCFS2.
Montáž podle UUID
Mnoho typů souborových systémů přiřazuje každému naformátovanému oddílu disku Universally Unique Identifier neboli UUID. Souborové systémy EXT3 a OCFS2 jsou toho příkladem. UUID je obvykle přiřazeno automaticky a správci systému jsou obvykle odrazováni od ruční změny hodnoty.
Na souborových systémech EXT3 a jiných typů použijte obslužný program blkid poskytovaný jako součást balíčku e2fsprogs RPM. V našem příkladu výstup vypadá takto:
# /sbin/blkid /dev/sda5 /dev/sda5: LABEL="/home" UUID="0c960108-7649-4d8c-a28c-2f75e2f906d3" SEC_TYPE="ext2" TYPE="ext3"
Všimněte si, že UUID jsou přísně vzato pouze hexadecimální číslice. Znaky „-“ jsou jednoduše interpunkční znaménka, kterou je třeba ignorovat.
V systému souborů OCFS2 je UUID vždy hlášeno obslužným programem fsck.ocfs2. Tento nástroj lze bezpečně použít na připojeném diskovém oddílu, pokud je použit přepínač „-n“ k zajištění testu pouze pro čtení:
# /sbin/fsck.ocfs2 -n /dev/hda1 Checking OCFS2 filesystem in /dev/hda1: label: OCFS2 uuid: bc d0 de d0 58 ea 43 11 bd a9 e0 66 e6 cb 37 b4 number of blocks: 209632 bytes per block: 1024 number of clusters: 52408 bytes per cluster: 4096 max slots: 4 /dev/hda1 is clean. It will be checked after 20 additional mounts.
Znovu si všimněte, že vlastní UUID je řetězec hexadecimálních číslic. Zde jsou přerušovány mezerami, ale skutečné UUID jsou pouze číslice. Chcete-li získat pouze UUID, stačí krátký program awk(1):
# /sbin/fsck.ocfs2 -n /dev/hda1 | /bin/awk '/uuid/ { $1 = ""; gsub( / /, "" ); print }'
bcd0ded058ea4311bda9e066e6cb37b4 Nyní, když máme UUID, položka /etc/fstab, jako jsou tyto, připojí buď oddíly EXT3 nebo OCFS2:
UUID=bcd0ded058ea4311bda9e066e6cb37b4 /ocfs2 ocfs2 _netdev 0 2 UUID=0c96010876494d8ca28c2f75e2f906d3 /home ext3 defaults 0 2
Protože je UUID uloženo v samotném diskovém oddílu, nezáleží na tom, zda se skutečný název zařízení změní, máme zaručenou trvalou a předvídatelnou metodu přístupu k němu.
Používání sad pravidel UDEV
Další metodou, jak mít trvalá, předvídatelná jména zařízení, je využít stejnou službu UDEV, kterou jádro používá k přiřazení názvů zařízení. To zahrnuje vytvoření párovacího pravidla UDEV, které používá atributy zařízení k identifikaci zařízení a poté k vytvoření uzlu zařízení pro něj. Pravidlo často pouze vytvoří symbolický odkaz na skutečný uzel zařízení nízké úrovně, který jádro přiřadí.
Toto je technika používaná k implementaci vícecestných zařízení mapovače zařízení. Jádro vytvoří zařízení /dev/dm-X; pak pravidla UDEV a vícecestný démon vytvoří /dev/mpath/
Jaký typ názvu souboru /dev/mapper/ se vytvoří, je řízeno nastavením user_friendly_names souboru /etc/multipath.conf. Výchozí nastavení je:
default {
user_friendly_names yes
}
což kupodivu vytváří naprosto nesmyslná jména /dev/mapper/mpathN. Když to zakomentujete, použijí se impozantněji vypadající názvy formulářů /dev/mapper/
Níže je uveden příklad srovnávacího pravidla UDEV. Řádek začíná řadou predikátů nebo odpovídajících výrazů; ty jsou označeny operátory „==“. Pokud se všechny predikáty shodují s predikáty nalezeného zařízení, provedou se akce označené klauzulemi „=“.
SYSFS{vendor}=="iriver" SYSFS{model}=="T10" OWNER="user" MODE="0600" SYMLINK+="iriver%n" Tento příklad vytvoří symbolický odkaz /dev/iriver0, když je první přehrávač IRiver T10 zapojen do USB portu. Zařízení bude ve vlastnictví uživatele s oprávněním pro přístup k souborům 0600. USB subsystém si všimne, že zařízení bylo připojeno, a upozorní jádro; atributy zjištěné o zařízení jsou také předány jádru. Tyto informace se nakonec dostanou do subsystému UDEV, který začne číst sady pravidel v /etc/udev/rules.d a porovnává atributy zařízení s predikáty pro každé pravidlo. Pokud se všechny predikáty shodují s pravidlem, provedou se všechny akce určené tímto pravidlem.
Dokumentace o systému UDEV, včetně syntaxe pro psaní pravidla UDEV, je dostupná on-line prostřednictvím manuálové stránky udev.
Náročnou částí psaní pravidla UDEV je vědět, jaké atributy jsou k dispozici, aby bylo možné zařízení podle pravidla správně identifikovat. Nástroj udevinfo zobrazí název zařízení a atributy dostupné pro pravidlo. V našem příkladu kontrola /var/log/messages ukazuje, že zařízení IRiver bylo detekováno jako blokové zařízení a bylo mu přiřazeno jméno /dev/sdb. Nyní můžeme získat všechny informace o zařízení a atributy, když se podíváme do systémových informací /block/sdb:
# /usr/bin/udevinfo -q all -p /block/sdb P: /block/sdb N: sdb S: disk/by-id/usb-iriver_T10 S: disk/by-path/pci-0000:00:07.2-usb-0:1:1.0-scsi-0:0:0:0 E: ID_VENDOR=iriver E: ID_MODEL=T10 E: ID_REVISION=1.00 E: ID_SERIAL=iriver_T10 E: ID_TYPE=disk E: ID_BUS=usb E: ID_PATH=pci-0000:00:07.2-usb-0:1:1.0-scsi-0:0:0:0Poznámka že cesta je relativní k adresáři /sys/, nikoli k tradičnímu kořenovému adresáři. Úplný název souboru by byl /sys/block/sdb, ale udevinfo předpokládá část /sys.
Volba minimální sady atributů může být složitá, ale vyhněte se pokušení přehnaně specifikovat. Naší volbou je zde použít název dodavatele a název modelu, ale lze použít jakoukoli sadu atributů, která identifikuje objektové zařízení. Jakmile jsou predikáty a akce vybrány, vložte pravidla do jejich vlastních souborů v adresáři /etc/udev/rules.d. Neupravujte sadu pravidel z distribuce, jinak mohou být vaše změny ztraceny, když se balíček aktualizuje. V našem příkladu jsme jako název souboru použili /etc/udev/rules.d/49-iriver.rules.
Se zavedeným pravidlem UDEV použijte nástroj udevtest k simulaci běhu UDEV a k zobrazení toho, co by se udělalo.