Das Dilemma mit den Disknamen in Linux/ Proxmox ec

gea

Urgestein
Thread Starter
Mitglied seit
16.11.2010
Beiträge
6.032
Macht Management größerer ZFS Systeme richtig aufwändig.

Um nicht alles nochmal zu schreiben:
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Naja, das ist eher ein Problem von Proxmox. Da gabs vor gut 8-10Jahren ja schon eine hitzige Diskussion mit dem DRDB Team warum man nicht udev nutzt. Der Kram ist immerhin schon über 20 Jahre alt und bei rhel/suse Storage Produkten ja auch schon ewig "Standard".
 
Nein, das ist ein Problem jeder Linux Distribution. Linux erkennt Blockdevices dynamisch und nummeriert die dann durch z.B. sda, sdb, Diese Devices kann man problemlos für ein Raid-Array wie ZFS nutzen. Entfernt man aber eine Platte oder fügt eine hinzu, so ändern sich die device Namen mit dem Ergebnis dass ZFS die Platten eines Pools erst nach einem erneuten Pool > Import findet, da dabei die Labels aller Platten gelesen werden. Daher fast die Pflicht bei ZFS dev by-id Namen zu nutzen die außerhalb eines ZFS Pools eher lästig sind.

Solaris hat das Problem bereits vor 15 Jahren erkannt und beseitigt und die komplette Plattenverwaltung auschließlich auf eindeutige WWN Namen wie c0t5000CCA0BBE3CF1Cd0 statt auf Ports wie sda (erste Platte an einem der Sata Ports, aufsteigende Nummerierung) umgestellt hat. Das Problem bei Linux sind blockdevicenamen wie sdf die nach reboot plötzlich sde sein können.
 
Zuletzt bearbeitet:
Darum nutzt man doch unter linux einfach dev by uuid? damit sollte es keine probleme geben oder hab ichs falsch im kopf ?
 
Für ZFS ist by-id sogar die einzig sinnvolle Option damit ZFS die Platten im Pool auch dann noch findet, wenn man irgendeine Platte ein oder aussteckt. Beim Pool > Import kann zudem wöhlen, ob man device Namen oder by-id als Poolmember nutzen möchte.

Das Problem ist doch dass das wichtigste Tool lsblk nur Controllerport device Namen wie sda ausgibt und andere Tools ebenfalls device Namen möchten. Man kommt an denen daher nicht vorbei. Auch kann man Pools haben, bei denen vdevs mit device Namen und by-id Namen angelegt wurden.

Will man jetzt scriptgesteuert Platteneigenschaften verarbeiten muss man das beachten. Ich habe das so gelöst, dass ich by-id nur für die ZFS Pool Membereigenschaft auswerte und ansonst alle Platten-Eigenschaften auf die device Namen zurückführe.

Schade ist halt, dass der Primärname der device Name ist und nicht der platteneindeutige by-id Name, so wie bei Solaris, macht scriptbasiertes Platten-Management unter Linux eben aufwändig da man immer mit beiden klarkommen muss.
 
Solaris hat das Problem bereits vor 15 Jahren erkannt und beseitigt und die komplette Plattenverwaltung auschließlich auf eindeutige WWN Namen wie c0t5000CCA0BBE3CF1Cd0 statt auf Ports wie sda (erste Platte an einem der Sata Ports, aufsteigende Nummerierung) umgestellt hat. Das Problem bei Linux sind blockdevicenamen wie sdf die nach reboot plötzlich sde sein können.

kurzum, by-id kam mit udev vor über 20 Jahren und rhel/suse/xxx nutzen es auch entsprechend in ihren Lösungen. Es ist kein "Linux" Problem.
 
Und was bringt mir das beim Erfassen der wichtigsten Platteneigenschaften, solange zpool mit beiden arbeiten könnte auch gleichzeitig und das zentrale Tool lsblk nur device Namen liefert und nicht auch by-id, ich daher immer beide betrachten und mit weiteren Tools syncronisieren muss?

Das Problem ist wie gesagt nicht by-id sondern dass es mindestens zwei Möglichkeiten gibt, Platten zu benennen und nicht nur eine wie bei Solaris und dass man keine der beiden Optionen ignorieren kann.

ps
Ein "Problem" ist es lediglich dahingehend dass es im Vergleich zu Solaris den Aufwand erheblich vergrößert (von dem ich die napp-it web-gui portiert habe), Storage Management zu machen.
 
Zuletzt bearbeitet:
Ich lese hier Gejammer, doch scheint es mir ohne guten Grund! ;)

Code:
ls -1d /dev/disk/by-*

Diese Wege kriegst du auf jedem System mit udev heute zum eindeutigen (wieder-)Identifizieren deiner Block Storage geboten. Der EINZIG WAHRE WEG des guten Solaris mit der WWN ist spatestens dann nimmer optimal, wenn zwei Geraete aus Chinesium einfach mal fesch einen identischen WWN haben, weil manchen Herstellern wirklich alles egal ist.

Zu deinem `lsblk`-Problem: `lsblk -o name,uuid,wwn` bzw. `lsblk -O` wollen dir dabei gerne helfen. Bitte lass es zu! ;)


Wenn du was zum Administrieren von Block Storage unter Linux entwickelst, solltest du dich vielleicht besser gleich mit der udisks2-API auf dem system-dbus auseinandersetzen, oder aber zumindest mithilfe von `lsblk --json` arbeiten, damit das Parsen leichter wird.


Hth!
 
Ich übersetze ja bereits die device und by-id Namen und parse mit json und will auch garnicht jammern.
Ich muss halt immer damit rechnen dass ein ZFS Pool die einen oder anderen Namen nutzt, gerne auch gemischt,

ps: KI Erklärung
lsblk -o WWN liefert nicht immer den "by-id" Plattennamen.

Hier ist der Unterschied und warum das so ist:
  • WWN (World Wide Name): Dies ist eine globally unique ID, die der Hardware-Hersteller der Festplatte zuweist. Sie ist fest in der Firmware der Platte verankert und ändert sich nicht, selbst wenn die Platte an einen anderen Port angeschlossen oder in ein anderes System verschoben wird. lsblk -o WWN zeigt genau diesen WWN an.
  • /dev/disk/by-id/ Plattennamen: Die Namen in /dev/disk/by-id/ sind symbolische Links, die von udev erstellt werden. Diese Links verwenden verschiedene eindeutige Identifikatoren, um eine stabile Benennung für Festplatten bereitzustellen, die sich nicht ändert, wenn sich die sda, sdb, etc. Benennung (die nicht stabil ist) ändert. Einige dieser by-id Namen basieren auf dem WWN, andere auf der Seriennummer des Geräts, dem Modell oder sogar auf Kombinationen davon, je nach Gerätetyp und wie udev konfiguriert ist.
Im Ergebnis macht es das nur schlimmer wenn ich mit lsblk und wwn oder uuid arbeite, dann habe ich statt zwei nun vier Varianten.
Da bleibe ich bei device Namen als Basis und by-id mittels ls -l /dev/disk/by-id Übersetzung (egal welcher eindeitige Name dann damit verknüpft wird)

Solaris hatte halt nur und ausschließlich wwn
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh