Das Problem
Eine Festplattenpartition wird nach einem Systemstart nicht bereitgestellt, unabhängig davon, ob der Neustart geplant oder ungeplant war. Vor dem Neustart war die Festplattenpartition gemountet und funktionierte ordnungsgemäß. Die Festplatte wurde nach anderen Systemneustarts korrekt gemountet, funktioniert aber nicht mehr.
Dieses Verhalten kann unabhängig vom Typ des Dateisystems auf der Partition auftreten und hat nichts mit dem Dateisystemtyp zu tun. Ausfälle von Festplatten mit EXT4- oder OCFS2-Dateisystemen wurden gemeldet, können aber bei jedem Dateisystemtyp auftreten.
Ein typischer Eintrag in der Datei /etc/fstab könnte wie folgt aussehen:
/dev/sda1 /mydir ext4 defaults 0 0 /dev/mapper/mpath2 /otherdir ocfs2 _netdev 0 0
oder verschiedene Kombinationen davon.
Die Lösung
Laufwerke und Partitionen werden in Linux geografisch adressiert, entsprechend ihrer Busposition und der Erkennungsreihenfolge. SAN-Geräte sind aufgrund unterschiedlicher Neustartzeiten für das SAN oder den Client besonders anfällig für Änderungen in der Erkennungsreihenfolge.
Dateinamen unter Linux, typischerweise im Verzeichnis /dev/, werden bei jedem Systemstart dynamisch zugewiesen. Beim Booten des Kernels wird jedes verfügbare Gerät erkannt und eine Benachrichtigung an das Subsystem UDEV (User-Space Device Management) gesendet. Durch den Vergleich von Informationen in der Geräteidentifikation des Kernels mit den UDEV-Regelsätzen im Verzeichnis /etc/udev/rules.d weist UDEV dem Gerät einen Namen zu und erstellt einen Geräteknoten wie /dev/sda oder /dev/mapper/mpath1 dass Anwendungen auf das Gerät zugreifen können. Wenn das erkannte Gerät ein Gerät mit Blockstruktur ist, hat es oft Partitionen, die Dateisysteme enthalten, die gemäß den Spezifikationen in der Datei /etc/fstab eingehängt werden können.
Obwohl Linux alle Anstrengungen unternimmt, um den gleichen Gerätenamen über Systemneustarts hinweg beizubehalten, können Änderungen in der externen Umgebung die tatsächliche Namenswahl beeinflussen. Beispiel:Dieselbe SAN-Partition könnte /dev/sda auf einem Client sein, aber /dev/sdf auf einem anderen Cluster-Knoten, abhängig von der Reihenfolge, in der jeder Host das Gerät entdeckt hat, oder davon, welche Multipath-Verbindung zuerst online geht. Ein Knoten erkennt seine Geräte normalerweise bei jedem Start in derselben Reihenfolge, aber dies ist nicht garantiert. Es wird eine Methode benötigt, um eine dauerhafte, vorhersagbare Geräteidentifikation zu gewährleisten.
Obwohl Linux versucht, bei jedem Neustart denselben Gerätenamen neu zuzuweisen, gibt es keine solche Koordination über Cluster-Knoten hinweg. Eine Partition, die auf einem Cluster-Knoten zuverlässig als /dev/sda1 angezeigt wird, könnte auf einem anderen Cluster-Knoten problemlos und legitimerweise konsistent als /dev/sdj angezeigt werden. Dies kann die clusterweite Systemadministration schwieriger als nötig machen. Die unten bereitgestellte Lösung gilt auch für Cluster, bei denen dieses Neustartproblem nicht auftritt.
Alternative Techniken sind verfügbar, um einen dauerhaften, vorhersagbaren Gerätenamen zu haben. Sie sind unten in der Reihenfolge ihres Schwierigkeitsgrades aufgeführt.
Montage nach Etikett
Viele Dateisystemtypen unterstützen die Zuordnung einer beliebigen Zeichenfolge oder eines Labels zu jedem Dateisystem. Das EXT3-Dateisystem ist ein Beispiel:
# /sbin/e2label /dev/sda5 /home
Es ist üblich, einen ähnlichen /etc/fstab-Eintrag wie diesen zu sehen:
LABEL=/HOME /home auto defaults 0 0
um die Festplattenpartition mit der Bezeichnung /HOME zu finden, unabhängig davon, auf welchem Gerät sie angezeigt wird.
OCFS2-Dateisysteme bieten auch eine erkennbare Bezeichnung, die ähnlich verwendet werden kann. Sehen Sie sich das OCFS2-Beispiel unten an, um zu erfahren, wie Sie die OCFS2-Bezeichnung bestimmen.
Bereitstellung über UUID
Viele Dateisystemtypen weisen jeder formatierten Festplattenpartition einen Universally Unique Identifier oder UUID zu. Beispiele hierfür sind die Dateisysteme EXT3 und OCFS2. Die UUID wird normalerweise automatisch zugewiesen, und Systemadministratoren wird normalerweise davon abgeraten, den Wert manuell zu ändern.
Verwenden Sie auf EXT3- und anderen Dateisystemen das Dienstprogramm blkid, das als Teil des e2fsprogs-RPM-Pakets bereitgestellt wird. Für unser Beispiel sieht die Ausgabe so aus:
# /sbin/blkid /dev/sda5 /dev/sda5: LABEL="/home" UUID="0c960108-7649-4d8c-a28c-2f75e2f906d3" SEC_TYPE="ext2" TYPE="ext3"
Beachten Sie, dass die UUID streng genommen nur aus hexadezimalen Ziffern besteht. Die „-“-Zeichen sind einfach zu ignorierende Satzzeichen.
Auf einem OCFS2-Dateisystem wird die UUID immer vom Dienstprogramm fsck.ocfs2 gemeldet. Dieses Dienstprogramm kann sicher auf einer gemounteten Festplattenpartition verwendet werden, wenn der Schalter „-n“ verwendet wird, um einen Nur-Lese-Test sicherzustellen:
# /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.
Beachten Sie auch hier, dass die eigentliche UUID eine Zeichenfolge aus Hexadezimalziffern ist. Hier sind sie durch Leerzeichen unterbrochen, aber die eigentliche UUID sind nur die Ziffern. Um nur die UUID zu bekommen, reicht ein kurzes awk(1)-Programm:
# /sbin/fsck.ocfs2 -n /dev/hda1 | /bin/awk '/uuid/ { $1 = ""; gsub( / /, "" ); print }'
bcd0ded058ea4311bda9e066e6cb37b4 Nun, da wir die UUID haben, würde ein /etc/fstab-Eintrag wie dieser entweder die EXT3- oder die OCFS2-Partition einhängen:
UUID=bcd0ded058ea4311bda9e066e6cb37b4 /ocfs2 ocfs2 _netdev 0 2 UUID=0c96010876494d8ca28c2f75e2f906d3 /home ext3 defaults 0 2
Da die UUID in der Festplattenpartition selbst gespeichert ist, spielt es keine Rolle, ob sich der tatsächliche Gerätename ändert, wir haben eine garantiert dauerhafte, vorhersagbare Methode für den Zugriff darauf.
Verwenden von UDEV-Regelsätzen
Eine andere Methode, um dauerhafte, vorhersagbare Gerätenamen zu haben, besteht darin, denselben UDEV-Dienst zu nutzen, den der Kernel verwendet, um die Gerätenamen zuzuweisen. Dazu gehört das Erstellen einer UDEV-Übereinstimmungsregel, die die Geräteattribute verwendet, um das Gerät zu identifizieren und dann einen Geräteknoten dafür zu erstellen. Oft erstellt die Regel nur einen symbolischen Link zu dem eigentlichen Low-Level-Geräteknoten, den der Kernel zuweist.
Dies ist die Technik, die verwendet wird, um die Device-Mapper-Multipath-Geräte zu implementieren. Der Kernel erstellt ein /dev/dm-X-Gerät; dann erstellen die UDEV-Regeln und der Multipathing-Daemon einen /dev/mpath/
Welche Art von /dev/mapper/-Dateinamen erstellt wird, wird durch die user_friendly_names-Einstellung der Datei /etc/multipath.conf gesteuert. Die Standardeinstellung ist:
default {
user_friendly_names yes
}
was seltsamerweise die völlig bedeutungslosen /dev/mapper/mpathN-Namen erzeugt. Indem Sie dies auskommentieren, werden die imposanter aussehenden /dev/mapper/
Nachfolgend finden Sie ein Beispiel für eine UDEV-Übereinstimmungsregel. Die Zeile beginnt mit einer Reihe von Prädikaten oder übereinstimmenden Ausdrücken; diese sind durch die Operatoren „==“ gekennzeichnet. Wenn alle Prädikate mit denen des erkannten Geräts übereinstimmen, werden die durch die „=“-Klauseln gekennzeichneten Aktionen ausgeführt.
SYSFS{vendor}=="iriver" SYSFS{model}=="T10" OWNER="user" MODE="0600" SYMLINK+="iriver%n" Dieses Beispiel erstellt den symbolischen Link /dev/iriver0, wenn der erste IRiver T10-Player an einen USB-Anschluss angeschlossen wird. Das Gerät gehört dem Benutzer mit den Dateizugriffsberechtigungen 0600. Das USB-Subsystem bemerkt, dass das Gerät angeschlossen wurde, und benachrichtigt den Kernel; Über das Gerät entdeckte Attribute werden ebenfalls an den Kernel weitergegeben. Diese Informationen gelangen schließlich zum UDEV-Subsystem, das damit beginnt, die Regelsätze in /etc/udev/rules.d zu lesen und die Geräteattribute den Prädikaten für jede Regel zuzuordnen. Wenn alle Prädikate einer Regel entsprechen, werden alle von dieser Regel angegebenen Aktionen ausgeführt.
Dokumentation über das UDEV-System, einschließlich der Syntax zum Schreiben einer UDEV-Regel, ist online über die udev-Manpage verfügbar.
Der herausfordernde Teil beim Schreiben einer UDEV-Regel besteht darin, zu wissen, welche Attribute verfügbar sind, damit das Gerät von der Regel richtig identifiziert werden kann. Das Dienstprogramm udevinfo zeigt den Gerätenamen und die für die Regel verfügbaren Attribute an. In unserem Beispiel zeigt die Überprüfung von /var/log/messages, dass das IRiver-Gerät als Blockgerät erkannt und der Name /dev/sdb zugewiesen wurde. Jetzt können wir alle Geräteinformationen und -attribute abrufen, indem wir unter den /block/sdb-Systeminformationen nachsehen:
# /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:0Hinweis dass der Pfad relativ zum Verzeichnis /sys/ ist, nicht zum traditionellen Stammverzeichnis. Der vollständige Dateiname wäre /sys/block/sdb, aber udevinfo nimmt den /sys-Teil an.
Die Auswahl des minimalen Satzes von Attributen kann schwierig sein, aber vermeiden Sie die Versuchung, zu viel zu spezifizieren. Unsere Wahl besteht hier darin, den Herstellernamen und den Modellnamen zu verwenden, aber jeder Attributsatz, der das Objektgerät identifiziert, kann verwendet werden. Sobald die Prädikate und Aktionen ausgewählt sind, legen Sie Ihre Regeln in ihren eigenen Dateien im Verzeichnis /etc/udev/rules.d ab. Ändern Sie keinen Regelsatz aus der Distribution oder Ihre Änderungen können verloren gehen, wenn das Paket aktualisiert wird. In unserem Beispiel haben wir /etc/udev/rules.d/49-iriver.rules für den Dateinamen verwendet.
Wenn Ihre UDEV-Regel vorhanden ist, verwenden Sie das Dienstprogramm udevtest, um einen UDEV-Lauf zu simulieren und zu zeigen, was getan werden würde.