Wechselnde Plattenreihenfolge in Hyper-V
Kürzlich ist ein virtualisierter Linux-Server nach dem Desaster-Recovery nicht wieder von selbst hoch gekommen. Er hing im Plattencheck und meinte der Superblock des Filesystems würde fehlen. Der Effekt trat spontan ein, denn die Kiste hatte schon öfter problemlos diese Prozedur überstanden.
Chaos
Auf der Notfallkonsole konnte ich feststellen, dass zwei virtuellen Platten vertauscht waren. Was normalerweise sdb ist, war nun sdc und umgekehrt. Das konnte ganz offensichtlich nichts werden. Einige manuelle Reboots später stand fest, dass die Zuordnung der Platten zu den Devicenamen nicht fest bleibt, sondern sich zufällig ändert.
Wer jetzt den Einwand bringt, dass man doch sowieso auf UUIDs referenziert oder sich mit einer udev-Policy den Namen festnageln kann, hat nicht ganz Unrecht. Allerdings ist das Linux hier etwas, was aus einem Yggdrasil entstand, sich an Slackware orientierte, und heute von Linux from Scratch abschaut. Kurz und gut, es hat kein udev. Davon später mehr.
Aber zuerst einmal gilt es, die Ursache der unterschiedlichen Benennungen zu ermitteln. Ein Blick in die Kernelmeldungen zeigt, dass der Hyper-V Treiber Schuld™ ist.
Der Fall, bei dem die Platte nicht gefunden werden konnte, stellt sich so dar.
scsi 0:0:0:0: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 scsi 0:0:0:1: CD-ROM Msft Virtual DVD-ROM 1.0 PQ: 0 ANSI: 0 scsi 0:0:0:63: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 scsi 0:0:0:2: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:2: [sdc] Attached SCSI disk sd 0:0:0:63: [sdb] Attached SCSI disk
Normalerweise sieht das aber so aus:
scsi 0:0:0:0: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 scsi 0:0:0:1: CD-ROM Msft Virtual DVD-ROM 1.0 PQ: 0 ANSI: 0 scsi 0:0:0:2: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 scsi 0:0:0:63: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 sd 0:0:0:2: [sdb] Attached SCSI disk sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:63: [sdc] Attached SCSI disk
Ganz offensichtlich ist die Reihenfolge, in der die Platten im System angemeldet werden, dem Treiber völlig egal.
Ich habe nun einige Zeit darin investiert, herauszubekommen ob es ein Bug oder ein WontFix ist. Aufgrund der Verbreitung von udev/systemd unter Linux und der eindeutigen Namen bei den BSDs, gibt es aber dafür offenbar keinen Bedarf. Ich habe den Eindruck, Microsoft betrachtet diese Verwürfelung als WontFix.
Was tun?
Die ganz offensichtliche Lösung besteht darin, sich dem Mainstream anzupassen.
Der Wechsel zu udev kommt nicht in Frage. Es müsste während des Bootens schon ein Daemon laufen, der sich um die Dateisysteme kümmert. Das mag ich gar nicht.
Da das schon vor dem Filesystem-Check stattfinden muss, das Dateisystem also noch gar nicht vollständig vorhanden ist, würde das eine initrd erfordern, die bisher unnötig war. Oder man hebt die Trennung von Root und /usr auf. Aber dafür habe ich mit dem Split in Fehlersituationen zu viel positive Erfahrungen gemacht.
Von der Problematik, dass udev inzwischen nur noch schwer aus systemd heraus zu kratzen ist, will ich gar nicht erst anfangen.
Eleganter scheint da die Idee, die Devicenamen im BSD Sinne zu gestalten. Dort enthalten die Namen auch die Channel und Slot-Nummern des Plattenanschlusses. Unter Linux wird dies vom devfs geleistet. Es gibt dann Dateinamen der Art /dev/scsi/host0/bus0/target1/lun0/part6. Das wäre völlig ausreichend. Allerdings wurde devfs zugunsten von udev aufgegeben.
Was bleibt, ist wieder einmal einen Teil von udev nachzubauen.
Hinten den Gardinen
Glücklicherweise sind meine Startscripte (ja, ich habe ein SysV init) leicht zu verstehen.
- Es wird die aktuell read-only gemountete Platte geprüft
- lief das fehlerfrei, dann wird sie read-write geschaltet und mit den Vorbereitungen für den Rest begonnen
- ist alles soweit fertig, werden die restlichen Platten und Partitionen geprüft und eingehängt.
Warum dieses zweistufige Verfahren? Ganz einfach. Wenn die Root-Partition korrigiert werden muss, stimmt das Filesystem auf der Platte nicht mehr mit dem überein, was der Linux-Kernel intern hält. Um diese Diskrepanz zu beseitigen, muss man rebooten, ohne dem Kernel die Chance zu geben, seine inzwischen irrigen Annahmen wieder auf die Platte zu schreiben.
Bei den anderen Partitionen ist es unproblematisch. Zum Zeitpunkt des Checks sind diese ja nicht eingehängt.
Arbeitet man mit einer initrd, kann man die Root-Platte auch vor dem Einhängen prüfen und somit den extra Reboot vermeiden. Aber das ist hier nicht der Fall und soll so bleiben.
In dem mittleren Stück besteht die Möglichkeit, die Plattennamen korrekt herauszufinden. Dazu bedarf es aber der Mitarbeit vom Kernel, der seine Ansichten über die Interna im sysfs nach außen breit tritt.
# Locate the backup disk
mount /sys
( cd /sys/dev/block/
ls -1d */device/scsi_disk/0\:0\:0\:2/uevent | while read a; do (
cd ${a%%/*}
ls -1d sd*1/partition | while read b; do
rm -f /dev/backup
ln -s ${b%%/*} /dev/backup
done
)
done
)Im Prinzip schaut man nach, für an welchem Anschluss eine SCSI-Disk hängt. Der Globbing-Zugriff der Shell ist zuverlässiger, wen man eine Datei angibt. Damit werden tote Links übergangen.
Wenn man das Gerät kennt, schaut man nach, wie der Name der ersten Partition lautet. Selbstverständlich weiß man, wie der Name lauten müsste. Mit dem Globbing auf die Datei parition umgeht man aber das Problem, dass die Namensannahme falsch ist.
Ach ja, die while read Konstrukte funktionieren für alle Fälle von "gar nichts* bis zu "mehr als ein Eintrag". Und die Subshells sind dafür da, die Auswirkungen von Verzeichniswechseln einzufangen. Es ist nämlich nicht zwangsweise sichergestellt, dass man einfach aus einem Link zu einem Verzeichnis wieder zurück kommt.
Das mag man sicher eleganter formulieren können, aber es hat den Charme
- genau das zu tun, was man an dieser Stelle braucht
- ohne zusätzliche Software auszukommen
Problem solved, aber trotzdem irgendwie verärgert.