sda und sdb tauschen
Clemens Schueller
Ich hab hier einen Dual Opteron Server stehen:
Wenn ich nun die Server Edition von ubuntu 10.04 installieren will,
erkennt der Installer
den onboard SATA Controller als sdb und den Intel Hardware RAID
Controller als sda.
Was muss ich machen, dass es genau umgekehrt ist, sprich onboard --> sda
und Intel --> sdb?
GreetinX & Danke
Clemens Schueller
Diedrich Ehlerding
> Wenn ich nun die Server Edition von ubuntu 10.04 installieren will,
> erkennt der Installer
>
> den onboard SATA Controller als sdb und den Intel Hardware RAID
> Controller als sda.
>
> Was muss ich machen, dass es genau umgekehrt ist, sprich onboard --> sda
> und Intel --> sdb?
Du müsstest die Reihenfolge ändern, in der in der initrd bzw. im initramfs
die Treiber für die Controller geladen werden. Leider habe ich kein Ubuntu
und auch kein Debian, kann dir also nicht genau sagen, wie das dort geht.
Und auch darauf würde ich mich nicht verlassen; möglicherweise werden die
beiden Treiber vom Bootmechanismus mehr oder weniger parallel geladen, und
dann sieht es schlecht aus. Und auf den Installer-Kernel kannst du
vermutlich gar nicht Einfluss nehmen. Außerdem ist nicht sicher, dass das
installierte System die Treiber in der Reiihenfolge lädt wie der
Installer-kernel.
Ganz eigentlich musst du dich also von der Idee verabschieden, dass die
sdX-Namen rebootfest sind. Selbst wenn du den Installer oder die initrd
bzw. das installierte initramfs verbiegst: Falls dein Server zB eine
eSATA-Schnitsstelle hat, kann es dir passieren, dass du nach einem Reboot
mit eingestöpselter externer Platte wieder die sd-Namen
durcheinandergewürfelt bekommst. Dito, wenn du mit eingestöpselter
USB-Platte oder Speicherkarte bootest.
Sorg also dafür, dass du nicht die sdX-Namen benutzt. Sowohl in der fstab
als auch an ein paar anderen Stellen (grub zB). Möglichkeiten dafür gibt
es viele:
- udev-Namen (/dev/disk/by-id/<Seriennummer>); ja, ich weiß, über udev
gibt es hier Glaubenskriege; hier ist aber udev eine sehr geeignete
Methode. (Suse und Redhat verwenden die standardmäßig)
- System auf LVM installieren (hat Ubuntus „Server Edition“ LVM?).
- Filesysteme über Labels mounten (Achtung: nicht für grub).
- u.a.m (etwa md, aber nur in Spezialfällen).
Diedrich
--
pgp-Key (RSA) 1024/09B8C0BD
fingerprint = 2C 49 FF B2 C4 66 2D 93 6F A1 FF 10 16 59 96 F3
HTML-Mail wird ungeleſen entſorgt.
Helmut Hullen
Du meintest am 06.02.11:
> Ich hab hier einen Dual Opteron Server stehen:
> Wenn ich nun die Server Edition von ubuntu 10.04 installieren will,
> erkennt der Installer
> den onboard SATA Controller als sdb und den Intel Hardware RAID
> Controller als sda.
> Was muss ich machen, dass es genau umgekehrt ist, sprich onboard -->
> sda und Intel --> sdb?
"udev" abschalten ...
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Diedrich Ehlerding
>> Was muss ich machen, dass es genau umgekehrt ist, sprich onboard -->
>> sda und Intel --> sdb?
>
> "udev" abschalten ...
... würde dem Fragesteller genau gar nicht weiterhelfen.
Ja, wir wissen, dass du udev abgrundtief hasst, aber was hat dir der
Fragesteller getan, dass du ihn derart in die Irre führen willst?
Helmut Hullen
Du meintest am 06.02.11:
>>> Was muss ich machen, dass es genau umgekehrt ist, sprich onboard
>>> --> sda und Intel --> sdb?
>>
>> "udev" abschalten ...
> ... würde dem Fragesteller genau gar nicht weiterhelfen.
> Ja, wir wissen, dass du udev abgrundtief hasst,
Da interpretierst Du meine Gefühlswelt falsch. Ich hasse keine Software.
Ich hasse nicht mal Menschen.
Diedrich Ehlerding
>>> "udev" abschalten ...
>
>> ... würde dem Fragesteller genau gar nicht weiterhelfen.
>
>> Ja, wir wissen, dass du udev abgrundtief hasst,
>
> Da interpretierst Du meine Gefühlswelt falsch. Ich hasse keine Software.
> Ich hasse nicht mal Menschen.
Und doch muss Clemens dir irgendwas getan haben, dass du ihn derart in die
Irre leiten willst.
Thomas Bächler
Dein Wunsch gehï¿œrt der Vergangenheit an. Es ist nicht vorgesehen diese
Namen zu beeinflussen, noch ist es notwendig. In den Fï¿œllen, die ich
gesehen habe, vertauschten diese Namen sogar willkï¿œrlich mit jedem Start
des Systems.
Helmut Hullen
Du meintest am 06.02.11:
>>>> "udev" abschalten ...
>>> ... würde dem Fragesteller genau gar nicht weiterhelfen.
>>> Ja, wir wissen, dass du udev abgrundtief hasst,
>> Da interpretierst Du meine Gefühlswelt falsch. Ich hasse keine
>> Software. Ich hasse nicht mal Menschen.
> Und doch muss Clemens dir irgendwas getan haben, dass du ihn derart
> in die Irre leiten willst.
Nein - er ist nur eines der Opfer, die die "udev"-Bastler verschuldet
haben. Die leiten ihn in die Irre. Ich überbringe nur die Nachricht.
Helmut Hullen
Du meintest am 06.02.11:
>> Wenn ich nun die Server Edition von ubuntu 10.04 installieren will,
>> erkennt der Installer den onboard SATA Controller als sdb und den
>> Intel Hardware RAID Controller als sda.
>>
>> Was muss ich machen, dass es genau umgekehrt ist, sprich onboard -->
>> sda und Intel --> sdb?
> Dein Wunsch gehört der Vergangenheit an. Es ist nicht vorgesehen
> diese Namen zu beeinflussen, noch ist es notwendig.
Sagt "udev". Aber "udev" lässt sich (wenn auch nicht kinderleicht)
abschalten, und dann bestimme ich wieder, welcher Kontroller wann dran
ist.
Ok - eventuell muss ich ein wenig mit den Kernelkonfigurations-Optionen
spielen. Nachzuvollziehen beim Werkeln mit verschiedenen Live-CDs - die
zeigen (unfreiwillig) die Varianten.
Diedrich Ehlerding
>> Und doch muss Clemens dir irgendwas getan haben, dass du ihn derart
>> in die Irre leiten willst.
>
> Nein - er ist nur eines der Opfer, die die "udev"-Bastler verschuldet
> haben. Die leiten ihn in die Irre. Ich überbringe nur die Nachricht.
Du überbringst vor allem die falsche Nachricht, er könne sein Problem
lösen, wenn er denn nur auf udev verzichte. Dem ist aber nicht so. Und
udev leitet ihn nicht in die Irre, sondern ganz allein du mit deinem hier
zu Gruppe inzwischen sattsam bekannten udev-Bashing.
Auch vor udev (wann war das eigentlich - kernel 2.4 oder so? Irgendwann in
der Steinzeit ...) gab es keine Möglichkeit, bei wechselnden
Hardwarekonfigurationen die Namen /dev/sd* bzw. die Zuordnung von
sd-Instanz zur tatsächlich damit bezeichneten Platte rebootfest zu machen
(natürlich gab es immer /dev/sda und /dev/sdb mit entsprechenden Major-
und Minornummern, wie heute auch; aber welche Platte die bezeichnen, ist
heute und war auch früher schon unvorhersehbar, sobald die
Hardwarekonfiguration nicht statisch ist (d.h. u.a., dass auch niemals
eine Platte ausfällt ...).
Erstens fallen aber Platten manchmal aus. Und wenn man dann mit sd-Namen
arbeitet, dann hat man auch dann mit Zitronen gehandelt, wenn man darüber
ein software-Raid gebaut hat. Zweitens sind Hardwarekonfigurationen nicht
statisch; wechselnde Hardwarekonfigurationen sind in Zeiten von
USB-Platten, CF-Karten, eSata-Anschlüssen schon im bei Privatanwendern
etwas, mit dem man rechnen muss; bei Servern und in Clemens' Fall sowieso
(spätestens wenn er eine eSata-Platte anstöpselt und/oder in seinem
Raidcontroller was umkonfiguriert oder da weitere Platten dransteckt
und/oder an irgendeinem weiteren Anschluss seines SATA-Controllers eine
weitere Platte einbaut, werden die sd-Namen durcheinandergewürfelt und
wären auch schon vor udev durcheinandergewürfelt worden). Schon gar nicht
rebootfest sind die sd-Namen in Zeiten, in denen die Treiber beim Booten
des Systems dynamisch geladen werden (und ggf. unterschiedliche Timeouts
abwarten ...).
udev ist nicht die Ursache von Clemens' Problem, sondern eine inzwischen
mögliche Lösung dieses auch vor udev schon bestehenden Problems. Gelabelte
Filesysteme sind eine andere Lösung, LVM ist ebenfalls eine Lösung - und
zwar deshalb, weil es dann auf die sd-Benamsung nicht mehr ankommt. M.a.W.
es gibt auch Lösungen ohne udev, aber sein eigentlicher Wunsch, die
Plattennamen festzuzurren und selbst zu definieren, ist nicht erfüllbar.
Das ist alles aber nix Neues. Hier eine ca. 3 Jahre alte Meinung von
Leuten, die auch vom Serverbetrieb was verstehen und nicht nur von
angeblich absolut statischen Heimanwender-PCs (die letztlich dann doch
nicht statisch bleiben):
| Never, ever use /dev/sdX
| ● /dev/sdX names are generated dynamically when
| devices are scanned by the SCSI mid-layer, in the order
| in which devices are discovered
| ● device discovery order is unpredictable, can be done in
| parallel.
| ● If you add one device and remove another, it is unlikely
| that on the next reboot the device you added will be
| assigned the same name.
(http://www.redhat.com/promo/summit/2008/downloads/pdf/Chip_Coldwell_update.pdf;
Seite 18)
Diedrich Ehlerding
> Sagt "udev". Aber "udev" lässt sich (wenn auch nicht kinderleicht)
> abschalten, und dann bestimme ich wieder, welcher Kontroller wann dran
> ist.
Spätestens wenn du mehrere Platten am selben SCSI-Bus hast (oder mehrere
SATA-Ports mit Platten belegt hast) hast du verloren, weil du nicht weißt,
welche als erste antwortet.
Henning Paul
> Du meintest am 06.02.11:
>> Was muss ich machen, dass es genau umgekehrt ist, sprich onboard -->
>> sda und Intel --> sdb?
>
> "udev" abschalten ...
Lieber Helmut, eigentlich sollte es mittlerweile bei Dir angekommen sein,
dass udev _nicht_ für die Zuordnung der sdX-Deviceknoten zu den Geräten
verantwortlich ist, sondern das allein von der Lade- und
Erkennungsreihenfolge der Kernelmodule abhängt.
Gruß
Henning
--
henning paul home: http://home.arcor.de/henning.paul
PM: henni...@gmx.de , ICQ: 111044613
Helmut Hullen
Du meintest am 06.02.11:
>> Sagt "udev". Aber "udev" l�sst sich (wenn auch nicht kinderleicht)
>> abschalten, und dann bestimme ich wieder, welcher Kontroller wann
>> dran ist.
> Sp�testens wenn du mehrere Platten am selben SCSI-Bus hast (oder
> mehrere SATA-Ports mit Platten belegt hast) hast du verloren, weil du
> nicht wei�t, welche als erste antwortet.
Noch mal: Ausgangs-Problem war (in diesem Fall) die Reihenfolge, in der
die Kontroller befragt werden.
Helmut Hullen
Du meintest am 06.02.11:
> Das ist alles aber nix Neues. Hier eine ca. 3 Jahre alte Meinung von
> Leuten, die auch vom Serverbetrieb was verstehen und nicht nur von
> angeblich absolut statischen Heimanwender-PCs (die letztlich dann
> doch nicht statisch bleiben):
> | Never, ever use /dev/sdX
> | ? /dev/sdX names are generated dynamically when
> | devices are scanned by the SCSI mid-layer, in the order
> | in which devices are discovered
> | ? device discovery order is unpredictable, can be done in
> | parallel.
> | ? If you add one device and remove another, it is unlikely
> | that on the next reboot the device you added will be
> | assigned the same name.
> (http://www.redhat.com/promo/summit/2008/downloads/pdf/Chip_Coldwell_
> update.pdf; Seite 18)
Soweit zwar in sich richtig, hat aber nichts mit dem Ausgangsproblem zu
tun. Das bestand/besteht vor allem darin, in welcher Reihenfolge die
Kontroller befragt werden.
Henning Paul
> Soweit zwar in sich richtig, hat aber nichts mit dem Ausgangsproblem zu
> tun. Das bestand/besteht vor allem darin, in welcher Reihenfolge die
> Kontroller befragt werden.
Und die lässt sich nicht durch Deinstallation von udev beeinflussen.
Diedrich Ehlerding
> Soweit zwar in sich richtig, hat aber nichts mit dem Ausgangsproblem zu
> tun. Das bestand/besteht vor allem darin, in welcher Reihenfolge die
> Kontroller befragt werden.
Ja - und in welcher Reihenfolge die Platten an einem Controller antworten,
wenn da mehrere dranhängen. Schon wenn du zwei SATA-Ports belegt hast und
eine Platte schneller antwortet als die andere, hast du verloren; ebenso,
wenn du drei SATA-Ports belegt hast und eine davon fällt aus (zB die, die
vorher als zweite geantwortet hat; danach ist dann die ehemals sdc
genannte Platte beim nächsten Boot plötzlich sdb). Auch dann, wenn du
keine allgemein nutzbare initrd deiner Distribution, sondern eine
handgeschnitzte verwendest.
Kurz: es gibt keine feste Zuordnung von /dev/sdX zu Platten.
Und das Ausgangsproblem (mit dem das Zitat sehr wohl was zu tun hat; es
sagt nämlich „das, was du willst, solltest du nicht wollen und schon gar
nicht tun“) besteht vor allen darin, dass Clemens das nicht bewusst war,
und dass er sowohl in den Installationsvorgang, nämlich den Bootprozess
des kernels auf der Ubuntu-CD, eingreifen müsste, als auch in das dann
installierte System (von dem wir ja nicht wissen, ob es die Platten
genauso benamst wie die Installations-CD). Selbst wenn man beides
hinbekäme, wäre es um Faktoren komplizierter als mit udev oder eben
Filesystem-Labeln oder LVM zu arbeiten - und es würde spätestens dann
nichts mehr nützen, wenn sich die Hardwarekonfiguration ändert.
Zusammengefasst: deine udev-lose Arbeitsweise macht selbst dann, wenn sie
ausnahmsweise mal funktioniert, viel mehr Mühe; sie ist anfällig gegen das
Timingverhalten einzelner Platten; und sie ist in gar keiner Weise
hardwareumbau- oder fehlertolerant. Du kannst ja gern so weitermachen,
aber sowas anderen zu raten, die ganz offenbar schon das zugrundeliegende
Problem noch nicht durchschaut haben, ist in meinen Augen ziemlich
böswillig.
Diedrich Ehlerding
> Noch mal: Ausgangs-Problem war (in diesem Fall) die Reihenfolge, in der
> die Kontroller befragt werden.
Ausgangsproblem war, dass Clemens nicht bewusst war, dass er die sd-Knoten
sinnvollerweise niemals in keinem Fall nicht benutzt, wenn ihm ein
einigermaßen wartungsarmes System am Herzen liegt. Dein privates Problem
ist dein blinder Hass auf udev, der dich dazu bringt, Leuten wie Clemens
völlig danebenliegende Ratschläge zu geben.
Michael Baeuerle
> Helmut Hullen meinte:
> >
> > Sagt "udev". Aber "udev" lässt sich (wenn auch nicht kinderleicht)
> > abschalten, und dann bestimme ich wieder, welcher Kontroller wann dran
> > ist.
>
> Spätestens wenn du mehrere Platten am selben SCSI-Bus hast (oder mehrere
> SATA-Ports mit Platten belegt hast) hast du verloren, weil du nicht weißt,
> welche als erste antwortet.
Also soweit geht die Sache nun aber auch wieder nicht! Ich betreibe noch
einige Rechner mit statischer Konfiguration (auch alte Linux-Maschinen
die noch kein udev unterstuetzen), die duerften demnach ja gar nicht
funktionieren. Die SCSI-Platten da drin antworten (genau wie heute) dann
wenn sie gefragt werden. D.h. als erstes antwortet immer die Platte die
als erstes abgefragt wird. Dabei ist es auch voellig egal ob die am
gleichen Bus haengen oder auf x Busse verteilt sind, fuer den PCI wo die
HAs drinstecken gilt naemlich das gleiche wie fuer SCSI.
Man kann jetzt mit Upstart natuerlich absichtlich die Treiber bei jedem
Boot in einer anderen bzw. undefinierten Reihenfolge laden lassen. Aber
das ist als wenn sich jemand beschwert weil er humpelt, obwohl er sich
gerade selber in den Fuss geschossen hat.
Das eigentlich Argument hattest du ja schon genannt:
Da man heute oft Platten anschliesst und entfernt macht es Sinn im OS
nicht die dynamisch vergebenen sdx-Namen zu verwenden sondern welche die
an das Device gebunden sind.
Micha
--
Das Lesen von *Sektoren* gehoert nicht zum "ueblichen" Gebrauch einer
Festplatte. Die *Dateien*, um die es sich hier handelt, [...]
Hans-Peter Diettrich in dchlf
Diedrich Ehlerding
> Also soweit geht die Sache nun aber auch wieder nicht! Ich betreibe noch
> einige Rechner mit statischer Konfiguration (auch alte Linux-Maschinen
> die noch kein udev unterstuetzen), die duerften demnach ja gar nicht
> funktionieren. Die SCSI-Platten da drin antworten (genau wie heute) dann
> wenn sie gefragt werden. D.h. als erstes antwortet immer die Platte die
> als erstes abgefragt wird. Dabei ist es auch voellig egal ob die am
> gleichen Bus haengen oder auf x Busse verteilt sind, fuer den PCI wo die
> HAs drinstecken gilt naemlich das gleiche wie fuer SCSI
Steck mal einen Fibrechannelcontroller eines Servers an ein
Fibrechannel-Netz und mach mehrere Raidsysteme dahinter sichtbar. Nein, da
weißt du nicht, in welcher Reihenfolge da was abgefragt wird.
Thomas Bächler
> Helmut Hullen meinte:
>
>> Noch mal: Ausgangs-Problem war (in diesem Fall) die Reihenfolge, in der
>> die Kontroller befragt werden.
>
> Ausgangsproblem war, dass Clemens nicht bewusst war, dass er die sd-Knoten
> sinnvollerweise niemals in keinem Fall nicht benutzt, wenn ihm ein
> einigermaßen wartungsarmes System am Herzen liegt. Dein privates Problem
> ist dein blinder Hass auf udev, der dich dazu bringt, Leuten wie Clemens
> völlig danebenliegende Ratschläge zu geben.
Full ACK.
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
> Du meintest am 06.02.11:
>>> Wenn ich nun die Server Edition von ubuntu 10.04 installieren will,
>>> erkennt der Installer den onboard SATA Controller als sdb und den
>>> Intel Hardware RAID Controller als sda.
>>> Was muss ich machen, dass es genau umgekehrt ist, sprich onboard -->
>>> sda und Intel --> sdb?
>> Dein Wunsch gehört der Vergangenheit an. Es ist nicht vorgesehen
>> diese Namen zu beeinflussen, noch ist es notwendig.
> Sagt "udev". Aber "udev" lässt sich (wenn auch nicht kinderleicht)
> abschalten, und dann bestimme ich wieder, welcher Kontroller wann dran
> ist.
Spaetestens bei Multicore-CPUs und fest im Kernel eincompilierten
Treibern bleibt diese Zuordnung (so gern man es sich vielleicht auch
wuenschen wuerde) *nicht* bei jedm booten gleich (voellig unabhaengig
von udev) ...
> Ok - eventuell muss ich ein wenig mit den Kernelkonfigurations-Optionen
> spielen. Nachzuvollziehen beim Werkeln mit verschiedenen Live-CDs - die
> zeigen (unfreiwillig) die Varianten.
Auch das hilft nicht unbedingt immer. Warum schreibst du hier ueber Dinge,
bei denen du anscheinend eklatante Wissensdefizite hast? Warum bestehst
du auch dann noch auf deinen falschen Aussagen, wenn dir knallhart nach-
gewiesen wurde, dass du Unrecht hast?
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Juergen Ilse
Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Helmut Hullen meinte:
>> Sagt "udev". Aber "udev" lässt sich (wenn auch nicht kinderleicht)
>> abschalten, und dann bestimme ich wieder, welcher Kontroller wann dran
>> ist.
> Spätestens wenn du mehrere Platten am selben SCSI-Bus hast (oder mehrere
> SATA-Ports mit Platten belegt hast) hast du verloren, weil du nicht weißt,
> welche als erste antwortet.
Mehrere Platten am selben SCSI-Bus sind relativ unproblematisch, weil die
SCSI-ID in die Minor-Device-Number einfliesst und die Zuordnung vn Device-
Namen zu Device-Numbers IIRC konstant bleibt. Problematisch sind mehrere
SCSI-Busse an einem Controller oder mehrere SCSI-Controller die parallel
oder nicht jedesmal in identischer Reihenfolge initialisiert werden (und
heuzutage zaehlen da auch IDE und USB dazu, da auch die ueber den SCSI-
Layer angesprochen werden) ...
Florian Diesch
> Helmut Hullen wrote:
>
>> Du meintest am 06.02.11:
>>> Was muss ich machen, dass es genau umgekehrt ist, sprich onboard -->
>>> sda und Intel --> sdb?
>>
>> "udev" abschalten ...
>
> Lieber Helmut, eigentlich sollte es mittlerweile bei Dir angekommen sein,
> dass udev _nicht_ für die Zuordnung der sdX-Deviceknoten zu den Geräten
> verantwortlich ist, sondern das allein von der Lade- und
> Erkennungsreihenfolge der Kernelmodule abhängt.
udev *ist* dafür verantwortlich, die Gerätedateien anzulegen (und
verwendet standardmäßig für die sdX-Dateien den vom Kernel
vorgeschlagenen Namen), und daher auch der sinnvollste Platz (alternativ
könnte man natürlich auch den Kernel patchen), um die Benennung zu
ändern (was in den allermeisten Fällen aber unnötig ist, weil man auch
einen der von udev sowieso schon angelegten Symlinks verwenden kann).
Helmuts Antwort war natürlich dümmste mögliche.
Florian
--
Simple dict-like Python API for GConf:
<http://www.florian-diesch.de/software/easygconf/>
Diedrich Ehlerding
> weil die
> SCSI-ID in die Minor-Device-Number einfliesst
Sicher? Bei allen scsi-Treibern?
Ich bin nicht fit genug im Kernelquelltextlesen, das jetzt selber
nachzuprüfen. Was mich an deiner Aussage zweifeln lässt, sind Server mit
externen Raidsysteme mit typischerweise Fibrechannel-Frontend und einigen
bis vielen LUNs dahinter (d.h. das Raidsystem wird als einige bis viele
Platten sichtbar). Das FC-Frontend (der WWN des externen Speichers) wird
von den Treibern, zB QLogic oder Emulex-HBAs, letztlich wieder auf eine
scsi-ID abgebildet (aber man weiß nicht und kann auch nicht beeinflussen,
wie diese Abbildung genau wirkt; insbesondere kann es je nach Änderungen
im FC-Netzwerk bei nächsten Boot dazu kommen, dass zwei heute sichtbare
WWNs morgen in anderer Reihenfolge auf scsi-IDs abgebildet werden ...)
Wie auch immer nun die Abbildung auf scsi-IDs (also die dritte Ziffer des
Zahlentwuadrupels in /proc/scsi/scsi) nun genau ausfällt: die beim Booten
vorhandenen Platten werden immer /dev/sda, /dev/sdb usw., ohne Lücken, und
dazu passen die Major/Minor-Nummern. Die hängen also mindestens bei diesen
Treiben qla2xxx und lpfc nicht von der scsi-ID ab.
Hier ein Server auszugsweise: (eine SLES10; lsscsi-Output)
[0:0:0:0] cd/dvd TEAC DW-224E-A 1.4A /dev/sr0
[2:0:8:0] process SDR GEM318P 1 -
[2:1:8:0] process SDR GEM318P 1 -
[2:2:0:0] disk MegaRAID LD 0 RAID1 34G 515Q /dev/sda
[3:0:0:0] disk DGC LUNZ 0226 /dev/sdb
[3:0:0:11] disk DGC VRAID 0226 /dev/sdc
[3:0:0:12] disk DGC VRAID 0226 /dev/sdd
[3:0:1:0] disk DGC LUNZ 0226 /dev/sde
[3:0:1:11] disk DGC VRAID 0226 /dev/sdf
[3:0:1:12] disk DGC VRAID 0226 /dev/sdg
[3:0:2:0] disk DGC LUNZ 0226 /dev/sdh
[3:0:2:1] disk DGC VRAID 0226 /dev/sdi
und ein anderer (eine SLES11) auch auszugsweise
[0:0:0:0] disk DGC VRAID 0226 /dev/sda
[0:0:0:5] disk DGC VRAID 0226 /dev/sdb
[0:0:0:6] disk DGC VRAID 0226 /dev/sdc
[0:0:0:7] disk DGC VRAID 0226 /dev/sdd
[0:0:0:10] disk DGC VRAID 0226 /dev/sde
[0:0:0:20] disk DGC VRAID 0226 /dev/sdf
[0:0:0:21] disk DGC VRAID 0226 /dev/sdg
[0:0:0:22] disk DGC VRAID 0226 /dev/sdh
[0:0:0:23] disk DGC VRAID 0226 /dev/sdi
Wie man sieht, sind im ersten Fall gleich mehrere scsi-Controller beteiligt
an den Platten sda - sdi, und außerdem verschiedene scsi-IDs (am
Controller 3 die IDs 0, 1 und 2); der andere sieht hier nur an einem
scsi-Controller (0) ein Target und daran diverse LUNs.
Dennoch sieht an beiden Maschinen
# ls -l /dev/sd[abcdefghi]
brw-r----- 1 root disk 8, 0 2010-12-21 14:48 /dev/sda
brw-r----- 1 root disk 8, 16 2010-12-21 14:48 /dev/sdb
brw-r----- 1 root disk 8, 32 2010-12-21 14:48 /dev/sdc
brw-r----- 1 root disk 8, 48 2010-12-21 14:48 /dev/sdd
brw-r----- 1 root disk 8, 64 2010-12-21 14:48 /dev/sde
brw-r----- 1 root disk 8, 80 2010-12-21 14:48 /dev/sdf
brw-r----- 1 root disk 8, 96 2010-12-21 14:48 /dev/sdg
brw-r----- 1 root disk 8, 112 2010-12-21 14:48 /dev/sdh
brw-r----- 1 root disk 8, 128 2010-12-21 14:48 /dev/sdi
genau gleich aus, was die Zuordnung von sd-Name zu Major- und Minornumber
angeht - sdb ist immer (8,16), sdi ist immer (8,128) usw. usf.
Mit anderen Worten, die scsi-ID geht (mindestens bei diesen Treibern)
*nicht* in die Minornumber ein, ebensowenig (ID + LUN) oder sonst
irgendeine Adresse im scsi-Bus, sondern es werden einfach die Platten
durchgezählt, die irgendein scsi-Treiber entdeckt hat (16 minor numbers
pro Platte für die möglichen Partitionen, und das wars).
Diedrich (der gerne mal sehen würde, wie Helmut H. in so einem Umfeld ohne
udev und udev-Namen die Platten auch nur einigermaßen rebootfest
benamst ...)
Clemens Schueller
Oha, ich hätte nicht damit gerechnet, mit meinem Posting so einen
Flamewar bzgl. udev auslösen zu können - aber darum geht es ja nicht.
Diedrich Ehlerding <diedrich....@t-online.de> writes:
> Clemens Schueller meinte:
>> Wenn ich nun die Server Edition von ubuntu 10.04 installieren will,
>> erkennt der Installer
>>
>> den onboard SATA Controller als sdb und den Intel Hardware RAID
>> Controller als sda.
>>
>> Was muss ich machen, dass es genau umgekehrt ist, sprich onboard --> sda
>> und Intel --> sdb?
>
> Du müsstest die Reihenfolge ändern, in der in der initrd bzw. im initramfs
> die Treiber für die Controller geladen werden. Leider habe ich kein Ubuntu
> und auch kein Debian, kann dir also nicht genau sagen, wie das dort geht.
> Und auch darauf würde ich mich nicht verlassen; möglicherweise werden die
> beiden Treiber vom Bootmechanismus mehr oder weniger parallel geladen, und
> dann sieht es schlecht aus. Und auf den Installer-Kernel kannst du
> vermutlich gar nicht Einfluss nehmen. Außerdem ist nicht sicher, dass das
> installierte System die Treiber in der Reiihenfolge lädt wie der
> Installer-kernel.
Hmm, der Installer vertauscht die Kennungen schon beim Setup.
> Ganz eigentlich musst du dich also von der Idee verabschieden, dass die
> sdX-Namen rebootfest sind. Selbst wenn du den Installer oder die initrd
> bzw. das installierte initramfs verbiegst: Falls dein Server zB eine
> eSATA-Schnitsstelle hat, kann es dir passieren, dass du nach einem Reboot
> mit eingestöpselter externer Platte wieder die sd-Namen
> durcheinandergewürfelt bekommst. Dito, wenn du mit eingestöpselter
> USB-Platte oder Speicherkarte bootest.
Mir ist durchaus aufgefallen, dass die Kennungen gerne mal
durcheinandergewürfelt werden.
> Sorg also dafür, dass du nicht die sdX-Namen benutzt. Sowohl in der fstab
> als auch an ein paar anderen Stellen (grub zB). Möglichkeiten dafür gibt
> es viele:
> - udev-Namen (/dev/disk/by-id/<Seriennummer>); ja, ich weiß, über udev
> gibt es hier Glaubenskriege; hier ist aber udev eine sehr geeignete
> Methode. (Suse und Redhat verwenden die standardmäßig)
> - System auf LVM installieren (hat Ubuntus „Server Edition“ LVM?).
> - Filesysteme über Labels mounten (Achtung: nicht für grub).
> - u.a.m (etwa md, aber nur in Spezialfällen).
Wenn ich Dich jetzt also richtig verstehe, dann das System ganz normal
installieren und im Nachhinein die Verdrahtungen in der /etc/fstab und
in der grub Config ändern? Sprich, dass die udev Namen verwendet werden.
Danke Dir schon mal, werd die Sache die nächsten Tage mal angehen.
GreetinX, Clemens Schueller
Helmut Hullen
Du meintest am 06.02.11:
>>> Sagt "udev". Aber "udev" lässt sich (wenn auch nicht kinderleicht)
>>> abschalten, und dann bestimme ich wieder, welcher Kontroller wann
>>> dran ist.
>> Spätestens wenn du mehrere Platten am selben SCSI-Bus hast (oder
>> mehrere SATA-Ports mit Platten belegt hast) hast du verloren, weil
>> du nicht weißt, welche als erste antwortet.
> Also soweit geht die Sache nun aber auch wieder nicht! Ich betreibe
> noch einige Rechner mit statischer Konfiguration (auch alte
> Linux-Maschinen die noch kein udev unterstuetzen), die duerften
> demnach ja gar nicht funktionieren. Die SCSI-Platten da drin
> antworten (genau wie heute) dann wenn sie gefragt werden. D.h. als
> erstes antwortet immer die Platte die als erstes abgefragt wird.
> Dabei ist es auch voellig egal ob die am gleichen Bus haengen oder
> auf x Busse verteilt sind, fuer den PCI wo die HAs drinstecken gilt
> naemlich das gleiche wie fuer SCSI.
So ähnlich habe ich das auch bei einem meiner Rechner erleben dürfen:
IDE/PATA
SCSI-Kontroller
USB
SATA-Kontroller auf PCI-Karte
Je nachdem, welche Live-CD von welcher Distribution ich nehme, finde ich
die Platten unter verschiedenen Namen. Hängt u.a. mit der Kernel-
Konfiguration zusammen, hängt u.a. mit der Reihenfolge zusammen, in der
irgendwer/irgendwas (meistens irgendwo in der Init-Ramdisk) Module
nachlädt. Und irgendwann spuckt auch "udev" noch in die Suppe.
> Man kann jetzt mit Upstart natuerlich absichtlich die Treiber bei
> jedem Boot in einer anderen bzw. undefinierten Reihenfolge laden
> lassen. Aber das ist als wenn sich jemand beschwert weil er humpelt,
> obwohl er sich gerade selber in den Fuss geschossen hat.
> Das eigentlich Argument hattest du ja schon genannt:
> Da man heute oft Platten anschliesst und entfernt macht es Sinn im OS
> nicht die dynamisch vergebenen sdx-Namen zu verwenden sondern welche
> die an das Device gebunden sind.
Ist zwar richtig, und auch ich empfehle in diesem Umfeld, mit LABEL zu
arbeiten. Löst aber nicht das Problem des Erstfragers.
Helmut Hullen
Du meintest am 06.02.11:
> Dein privates Problem ist dein blinder Hass auf udev,
Ich hasse "udev" nicht, weder blind noch sehend. Ich versuche nur, es zu
vermeiden.
"udev" erschwert das Arbeiten mit einem Rechner, der mit mehreren
Festplatten und mehreren Netzwerkkarten bestückt ist, die ab und zu mal
ausgetauscht werden.
Sieghard Schicktanz
Du schriebst am Sun, 06 Feb 2011 12:04:32 +0100:
> udev ist nicht die Ursache von Clemens' Problem, sondern eine inzwischen
> mï¿œgliche Lï¿œsung dieses auch vor udev schon bestehenden Problems. Gelabelte
Und das Problem ist lediglich eine - neutral formuliert - "design decision"
der Kernel-Entwickler, die Zuordnung der Device-Namen _nicht_ fest mit der
Hardware zu verkoppeln.
Ist ja so auch in Ordnung, wenn man's denn dazusagt und nicht jede Menge
Ausreden erfindet, daￜ das so sein mￜￜte (andere System schaffen's ja
auch mit fester Zuordnung). Schlieï¿œlich hat man ja ein kostenfrei
verfï¿œgbares System, und kann dzf. entsprechende Ansprï¿œche stellen.
--
(Weitergabe von Adressdaten, Telefonnummern u.ￜ. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ï¿œhnlichem)
-----------------------------------------------------------
Mit freundlichen Grￜￜen, S. Schicktanz
-----------------------------------------------------------
Diedrich Ehlerding
> Oha, ich hätte nicht damit gerechnet, mit meinem Posting so einen
> Flamewar bzgl. udev auslösen zu können
Ach, das solltest du nicht so schwer nehmen. Helmut geht schon seit Jahren
ab wie das HB-Männchen, wenn auch nur von ferne irgendetwas udev-Ähnliches
als Lösung erwähnt werden könnte. Ist nicht neu, kennen die Alteingessenen
schon. Ich habe ihm nur deshalb so laut widersprochen, weil du ja
anscheinend eine Lösung für dein Problem suchst, und das, was er dazu
schreibt, ist einfach <censored>.
> Wenn ich Dich jetzt also richtig verstehe, dann das System ganz normal
> installieren und im Nachhinein die Verdrahtungen in der /etc/fstab und
> in der grub Config ändern? Sprich, dass die udev Namen verwendet werden.
Ja.
Neben der fstab musst du im Fall "grub" auch an /boot/grub/device.map
denken, da solltest du statt "(hd0) /dev/sda" sowas wie
"(hd0) /dev/disk/by-id/<deinebootplatte>" reinschreiben, damit der nächste
grub-update gut geht. (Es kann aber sein, dass Ubuntu grub2 verwendet, da
kenne ich mich nicht mit aus).
"ls -l /dev/disk/by-id" zeigt dir, welche Platte heute sda und welche sdb
ist; damit kannst du dann zurückrechnen, was du in fstab eintragen musst.
Wobei mich, ehrlich gesagt, wundert, dass eine "Server Edition" das nicht
von Anfang an so macht bzw. nicht mindestens anbietet. Andere
Distributionen tun das eine oder andere von dem, was ich da vorgeschlagen
hatte (Suse und SLES benutzen die udev-Namen, wenn man nicht explizit was
anderes will (die device.map ist bei Suse aber auch nicht immer so, wie
man es gern hätte ... :-( ); Redhat installiert sich auf einer
LVM-Volumegruppe und mountet /boot meine Erinnerung nach über ein Label).
Wenn die Ubuntu Server Edition sowas gar nicht anbietet, dann ist das
m.A.n. ein gewichtiger Minuspunkt für Ubuntus Eignung für Server, die
potentiell mehr als eine Platte haben.
Vielleicht schaust du nochmal genau hin; ich kann mir eigentlich kaum
vorstellen, dass die Ubuntu-Installationsroutine das überhaupt nicht
anbietet. Oder du fragst in dieser Richtung nochmal bei ubuntuusers.com.
Diedrich
Henning Paul
> So ähnlich habe ich das auch bei einem meiner Rechner erleben dürfen:
>
> IDE/PATA
> SCSI-Kontroller
> USB
> SATA-Kontroller auf PCI-Karte
>
> Je nachdem, welche Live-CD von welcher Distribution ich nehme, finde ich
> die Platten unter verschiedenen Namen. Hängt u.a. mit der Kernel-
> Konfiguration zusammen, hängt u.a. mit der Reihenfolge zusammen, in der
> irgendwer/irgendwas (meistens irgendwo in der Init-Ramdisk) Module
> nachlädt. Und irgendwann spuckt auch "udev" noch in die Suppe.
Glaubst Du das oder weißt Du das?
Diedrich Ehlerding
> Und das Problem ist lediglich eine - neutral formuliert - "design
> decision" der Kernel-Entwickler, die Zuordnung der Device-Namen nicht
> fest mit der Hardware zu verkoppeln.
Und wie stelltest du dir dieses vor - sagen wir mal bei einem Server, der
an ein größeres SAN angeschlossen ist? Der könnte einige Tausend Platten
sehen (einige Tausend habe ich zwar noch nicht gesehen, aber Server mit
einigen hundert /dev/sd-Knoten sehr wohl). Und ein anderer Server könnte
ebenfalls einige Tausend Platten in diesem SAN sehen, aber andere als der
erste. Welchen Namen außer einem von der Hardware gelieferten eindeutigen
Namen hältst du da für geeignet?
Du könntest natürlich die sehr hardware-nahen Namen /dev/disk/by-path/*
verwenden, die zB SuSEs udev-Regeln erzeugen; da steht etwa im Falle
externer Fibrechannel-Raidsysteme u.a. sowas wie PCI-Steckplatz des
Controllers, der WWN des Raidsystem-Frontendports, die LUN-Adresse an
diesem Raidsystem drin. Allein, was hilfts: auch diese Namen werden von
udev erzeugt, und du kannst sie auch heute schon verwenden - m.a.W. dein
Vorschlag ist etwas, was udev dir heute schon liefert; du musst es nur
benutzen.
Die Entwickler haben lediglich die sd-Namen von der Hardware entkoppelt
(bzw. die waren noch nie mit der Hardware wirklich verkoppelt; die hießen
immer schon sda, sdb usw - wie eben der Server seine Platten erkannte;
auch vor udev-Zeiten schon); aber mit udev kriegt man die so hardwarenah
wie man eben will.
Die Entscheidung der kernel-Entwickler, die sie da für udev getroffen
haben, ist für solche Konfigurationen einfach Gold wert. Und auch wenns
hier nicht gern gesehen wird: ein großes Softwarehaus in Redmond macht das
in seinen Systemen auch so, da heißen die \\physicaldisk_0 usw. Nur hat
dieses Softwarehaus keine udev-Schicht, mit der man vernünftig nachsehen
kann, welche Platte denn heute \\physicaldisk_12 ist ...
Diedrich Ehlerding
> So ähnlich habe ich das auch bei einem meiner Rechner erleben dürfen:
>
> IDE/PATA
> SCSI-Kontroller
> USB
> SATA-Kontroller auf PCI-Karte
>
> Je nachdem, welche Live-CD von welcher Distribution ich nehme, finde ich
> die Platten unter verschiedenen Namen.
Und? Wen störts, wenn man sich einmal angewöhnt, udev-Namen zu verwenden?
Warum ist es wichtig, ob eine Platte sdx oder sdab heißt?
> Ist zwar richtig, und auch ich empfehle in diesem Umfeld, mit LABEL zu
> arbeiten. Löst aber nicht das Problem des Erstfragers.
LABELs gehen nur, wenn auf der Platte ein Filesystem ist, helfen aber nicht
dabei, dir richtigen Platten von vielen auszuwählen (etwa um einen
Softwarespiegel über zwei externe Raidsysteme zu bauen; da ist es schon
von gewisser Wichtigkeit, dass man nicht versehentlich zwei Platten im
gleichen Gehäuse nimmt ...
Ansonsten lösen auch gelabelte Filesysteme das Ausgangsproblem - auch mit
denen muss man nicht mehr wissen, ob die Platte nun sdxy oder sduv heißt.
Hatte ich ja auch ganz am Anfang erwähnt. Immer vorausgesetzt natürlich,
dass man das in der Ubuntu-Installationsroutine auswählen kann.
Helmut Hullen
Du meintest am 06.02.11:
>> So ähnlich habe ich das auch bei einem meiner Rechner erleben
>> dürfen:
>>
>> IDE/PATA
>> SCSI-Kontroller
>> USB
>> SATA-Kontroller auf PCI-Karte
>>
>> Je nachdem, welche Live-CD von welcher Distribution ich nehme, finde
>> ich die Platten unter verschiedenen Namen. Hängt u.a. mit der
>> Kernel- Konfiguration zusammen, hängt u.a. mit der Reihenfolge
>> zusammen, in der irgendwer/irgendwas (meistens irgendwo in der
>> Init-Ramdisk) Module nachlädt. Und irgendwann spuckt auch "udev"
>> noch in die Suppe.
> Glaubst Du das oder weißt Du das?
siehe oben: das habe ich erleben dürfen.
Sieghard Schicktanz
Du schriebst am Sun, 06 Feb 2011 20:51:55 +0100:
> Und? Wen störts, wenn man sich einmal angewöhnt, udev-Namen zu verwenden?
Was sind "udev-Namen"? udev vergibt die Namen so, wie es seine Regeln
angeben, und die Regeln sind _änderbar_. Ohne weitere Angaben übernimmt
udev die Kernel-Namen (sd?).
> Warum ist es wichtig, ob eine Platte sdx oder sdab heißt?
Wenn die so uninteressant sind, warum gibt's die eigentlich? Die sind dann
doch vollkommen unnütz, also entbehrlich.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Sieghard Schicktanz
Du schriebst am Sun, 06 Feb 2011 20:45:51 +0100:
> > Und das Problem ist lediglich eine - neutral formuliert - "design
> > decision" der Kernel-Entwickler, die Zuordnung der Device-Namen nicht
> > fest mit der Hardware zu verkoppeln.
>
> Und wie stelltest du dir dieses vor - sagen wir mal bei einem Server, der
> an ein größeres SAN angeschlossen ist? Der könnte einige Tausend Platten
> sehen (einige Tausend habe ich zwar noch nicht gesehen, aber Server mit
> einigen hundert /dev/sd-Knoten sehr wohl). Und ein anderer Server könnte
> ebenfalls einige Tausend Platten in diesem SAN sehen, aber andere als der
> erste. Welchen Namen außer einem von der Hardware gelieferten eindeutigen
> Namen hältst du da für geeignet?
Wieso "außer einem von der Hardware gelieferten eindeutigen Namen"?
Da hab' ich doch garnischt dagegen gesagt. Ich hab' bloß festgestellt, daß
die Kernel-Entwickler eben die vom Kernel gelieferten Device-Namen _nicht_
mit der Hardware verkoppelt haben, wie Du ja zuvor in Deiner Warnung
herausgestellt hattest.
> Die Entscheidung der kernel-Entwickler, die sie da für udev getroffen
> haben, ist für solche Konfigurationen einfach Gold wert. Und auch wenns
Ach, Quatsch. Damit sind die direkt vom Kernel gelieferten Namen einfach
wertlos, die könnten genausogut komplett wegfallen und dafür z.B. die
"by-id"-Namen (o.ä.) benutzt werden. An denen könnte man dann mit einer
udev- Regel wieder kurze, leicht zu merkende oder wie auch immer geartete
Bezeichnungen anhängen, damit man nicht immer im /dev-Verzeichnis wühlen
muß.
Und mit Deinen riesigen SAN-Installationen (bei deren Umfang Du ja schon
mal großzügig eine Größenordnung "zugegeben" hast gegenüber dem, was
sogar Du als normal kennst): wie häufig sind die denn eigentlich so
anzutreffen? 0,001 oder 0,01% der Linux-Installationen? Das sind doch
sowieso Sonderspezialfälle, die wohl nicht mal mehr mit den Standard-
Linux-Treibern arbeiten, sondern spezielle Konfigurationen enthalten, die
dann mit der Menge an Kennungen auch zurechtkommen.
Und daß die möglichen Kennungen ausgehen könnten, ist ja dank des
Stellenwertsystems für numerische Kennzeichnungen nicht zu erwarten; da
könntest Du auch gut und gerne noch ein paar Größenordnungen zugeben.
> hier nicht gern gesehen wird: ein großes Softwarehaus in Redmond macht das
> in seinen Systemen auch so, da heißen die \\physicaldisk_0 usw. Nur hat
> dieses Softwarehaus keine udev-Schicht, mit der man vernünftig nachsehen
> kann, welche Platte denn heute \\physicaldisk_12 ist ...
Na, und da wechseln die Kennungen auch bei jedem Boot durch? Wie schaffen
die dann das, da wieder Ordnung 'reinzubringen?
Die ganzen Diskussionen hatt'mer doch schon mal - das ist halt so wie bei
dem CD-Zeugs, da gibt's eben zwei Lager, die auf ihren Standpunkten
beharren, und die anderen (die Mehrzahl) müssen eben sehen, wo sie bleiben.
--
Marc Haber
>"udev" erschwert das Arbeiten mit einem Rechner, der mit mehreren
>Festplatten und mehreren Netzwerkkarten bestückt ist, die ab und zu mal
>ausgetauscht werden.
Ganz im Gegenteil.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Henning Paul
> Du meintest am 06.02.11:
>
>>> Je nachdem, welche Live-CD von welcher Distribution ich nehme, finde
>>> ich die Platten unter verschiedenen Namen. Hängt u.a. mit der
>>> Kernel- Konfiguration zusammen, hängt u.a. mit der Reihenfolge
>>> zusammen, in der irgendwer/irgendwas (meistens irgendwo in der
>>> Init-Ramdisk) Module nachlädt. Und irgendwann spuckt auch "udev"
>>> noch in die Suppe.
>
>> Glaubst Du das oder weißt Du das?
>
> siehe oben: das habe ich erleben dürfen.
Dass udev in die Suppe spuckt?
Gruß
Henning
Diedrich Ehlerding
> Ach, Quatsch. Damit sind die direkt vom Kernel gelieferten Namen einfach
> wertlos, die kï¿œnnten genausogut komplett wegfallen und dafï¿œr z.B. die
> "by-id"-Namen (o.ￜ.) benutzt werden.
Ja. Sag ich ja. Benutzen sollte man die sd-Namen in der Tat nicht; die
sind eigentlich nur aus historischen Grï¿œnden noch da. Benutzen sollte
man dann, wenn mehr als eine Platte im Spiel sein kann, die udev-Namen.
> An denen kï¿œnnte man dann mit einer
> udev- Regel wieder kurze, leicht zu merkende oder wie auch immer geartete
> Bezeichnungen anhï¿œngen, damit man nicht immer im /dev-Verzeichnis wï¿œhlen
> muￜ.
Da man die selber schreiben mï¿œsste, gï¿œbe es keinen Unterschied dazu,
auch heute eigene udev-Regeln zu schreiben.
Im ï¿œbrigen geht das (selbstdefinierte, "schï¿œne" Namen statt
kilometerlanger udev-Zahlenfolgen) auch heute ï¿œber einen Umweg, nï¿œmlich
den dm_multipath-Treiber - da gibt es bereits jetzt eine
"ï¿œbersetzungstabelle", so dass die Platten zum guten Schluss
/dev/mapper/meine_bootplatte oder /dev/mapper/videodaten o.ￜ. heiￜen
kï¿œnnen. Das ist zwar von hinten durch die Brust geschossen, aber
funktionieren tut der dm_multipath auch auch dann, wenn er zu einer
Platte nur einen Weg hat.
Hakelig kann allerdings die Installation sein, wobei SLES und Redhat
auch das shcon in ihrer Installationsroutine anbieten. Wie es bei Ubuntu
aussieht, weiￜ ich nicht.
>
> Und mit Deinen riesigen SAN-Installationen (bei deren Umfang Du ja schon
> mal groￜzￜgig eine Grￜￜenordnung "zugegeben" hast gegenￜber dem, was
> sogar Du als normal kennst): wie hï¿œufig sind die denn eigentlich so
> anzutreffen? 0,001 oder 0,01% der Linux-Installationen? Das sind doch
> sowieso Sonderspezialfï¿œlle, die wohl nicht mal mehr mit den Standard-
> Linux-Treibern arbeiten, sondern spezielle Konfigurationen enthalten, die
> dann mit der Menge an Kennungen auch zurechtkommen.
Ganz im Gegenteil: seit udev ist Linux geeignet, auch solche
Installationen sinnvoll betreiben zu kï¿œnnen. Und quasi als Nebeneffekt
eigent sich eben derselbe Mechanismus, das (letztlich) selbe Problem von
Clemens im Kleinen zu lï¿œsen.
>> hier nicht gern gesehen wird: ein groï¿œes Softwarehaus in Redmond macht das
>> in seinen Systemen auch so, da heiï¿œen die \\physicaldisk_0 usw. Nur hat
>> dieses Softwarehaus keine udev-Schicht, mit der man vernï¿œnftig nachsehen
>> kann, welche Platte denn heute \\physicaldisk_12 ist ...
>
> Na, und da wechseln die Kennungen auch bei jedem Boot durch?
Ja - in SAN-Umgebung tun sie das.
> Wie schaffen
> die dann das, da wieder Ordnung 'reinzubringen?
Die verlassen sich auf die "Signatur", also eine auf die Platte
geschrieben "magic number", und in der Registry merken sie sich, welchen
Laufwerksbuchstaben (bzw. inwzischen auch, welchen Mountpoint) sie fï¿œr
welche Signatur verwenden. Man muss das von Hand konsistent halten, wenn
man zB einen Cluster baut, in dem mehrere Server auf dieselben Platten
zugreifen. Letztlich ein ï¿œhnliche Mechanismus wie ein Filesystem ï¿œber
seine UUID zu mounten.
Helmut Hullen
Du meintest am 07.02.11:
>> Ach, Quatsch. Damit sind die direkt vom Kernel gelieferten Namen
>> einfach wertlos, die k�nnten genausogut komplett wegfallen und daf�r
>> z.B. die "by-id"-Namen (o.�.) benutzt werden.
> Ja. Sag ich ja. Benutzen sollte man die sd-Namen in der Tat nicht;
> die sind eigentlich nur aus historischen Gr�nden noch da. Benutzen
> sollte man dann, wenn mehr als eine Platte im Spiel sein kann, die
> udev-Namen.
Besser: LABEL. Da kannst Du nach Funktion sortieren.
LABEL=Backup
ist weitgehend selbsterkl�rend und eindeutig zuzuordnen.
>> An denen k�nnte man dann mit einer
>> udev- Regel wieder kurze, leicht zu merkende oder wie auch immer
>> geartete Bezeichnungen anh�ngen, damit man nicht immer im
>> /dev-Verzeichnis w�hlen mu�.
> Da man die selber schreiben m�sste, g�be es keinen Unterschied dazu,
> auch heute eigene udev-Regeln zu schreiben.
Eben - warum einfach, wenn's auch umst�ndlich geht.
Warum soll ich Regel nach irgendeiner seltsamen Syntax schreiben, wenn
ich mein Ziel auch mit LABEL erreichen kann?
Helmut Hullen
Du meintest am 07.02.11:
Ab und zu auch das. Ist schon einige Monate her - ich habe den Ablauf
nicht protokolliert, sondern nur (mal wieder) "udev" weggeschaltet
(sofern das möglich war) oder aber die spezielle Live-CD
umweltfreundlich entsorgt.
Thomas Bächler
> Hallo Diedrich,
>
> Du schriebst am Sun, 06 Feb 2011 20:51:55 +0100:
>
>> Und? Wen störts, wenn man sich einmal angewöhnt, udev-Namen zu verwenden?
>
> Was sind "udev-Namen"? udev vergibt die Namen so, wie es seine Regeln
> angeben, und die Regeln sind _änderbar_. Ohne weitere Angaben übernimmt
> udev die Kernel-Namen (sd?).
Die "Haupt"namen sind nicht mehr änderbar, die bleiben nun grundsätzlich
so wie vom Kernel festgelegt.
Was man ändern kann, sind die Symlinks, die darauf zeigen. Und hier gibt
es die ominösen "udev-Namen", die mittlerweile Standard auf nahezu allen
Linux-basierten Desktop/Server-Systemen sind:
/dev/disk/by-{uuid,label}: UUID oder Label des enthaltenen Dateisystems.
/dev/disk/by-id: Irgendeine Kombination aus Modell- und Seriennummer
soweit ich sehen kann.
/dev/disk/by-path: Position im System (welcher Controller an welchem
PCI-Bus, etc)
Ist also für jeden was dabei.
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
> "udev" erschwert das Arbeiten mit einem Rechner, der mit mehreren
> Festplatten und mehreren Netzwerkkarten bestückt ist, die ab und zu mal
> ausgetauscht werden.
Nein, das tut es nicht. Der Umgang mit mehreren Platten geschieht am
besten, indem man die Devices "by-label" oder notfals "by-UUID" mountet,
da hat man (voellig unabhaengig von udev) die geringsten Probleme mit.
Und was die Netzwerkkarten angeht: udev *kann* hier dafuer sorgen, dass
die Namen der Netzwrkinterfaces von der Reihenfolge der Treiberinitiali-
sierung unabhaengig werden (wurde teils auch frueher schon gemacht, da
dann allerdings deutlich ahesslicher ...).
Michael Baeuerle
> Michael Baeuerle meinte:
> >
> > Also soweit geht die Sache nun aber auch wieder nicht! Ich betreibe noch
> > einige Rechner mit statischer Konfiguration (auch alte Linux-Maschinen
> > die noch kein udev unterstuetzen), die duerften demnach ja gar nicht
> > funktionieren. Die SCSI-Platten da drin antworten (genau wie heute) dann
> > wenn sie gefragt werden. D.h. als erstes antwortet immer die Platte die
> > als erstes abgefragt wird. Dabei ist es auch voellig egal ob die am
> > gleichen Bus haengen oder auf x Busse verteilt sind, fuer den PCI wo die
> > HAs drinstecken gilt naemlich das gleiche wie fuer SCSI
>
> Steck mal einen Fibrechannelcontroller eines Servers an ein
> Fibrechannel-Netz und mach mehrere Raidsysteme dahinter sichtbar. Nein, da
> weißt du nicht, in welcher Reihenfolge da was abgefragt wird.
Abgefragt wird da sicher auch immer in der gleichen Reihenfolge (auch
wenn ich das mangels FC-Netz noch nie probiert habe). Es koennen sich
aber natuerlich die Zuweisungen von IDs und LUNs zu den Geraeten aendern
wenn man an dem FC-Netz rumspielt. Das entspricht aber dann ziemlich
genau dem Umstecken der ID-Jumper an einem parallelen SCSI System - und
das aendert dann natuerlich auch dort die Reihenfolge der Erkennung -
eben gerade weil die Abfragereihenfolge gleich bleibt. Das gleiche gilt
fuer USB falls man Hubs hinzufuegt oder den Bus anders zusammensteckt,
so dass die Geraete anders auf die SCSI IDs gemapped werden.
Auf was ich hinaus wollte: Aendert man an der HW-Konfiguration nichts,
passiert bei jedem booten das gleiche (wenn man das so haben will und
nicht mit Sachen wie Upstart absichtlich zerschiesst!). Schliesslich
waren jahrelang alle GNU/Linux System darauf angewiesen um ueberhaupt zu
funktionieren.
Micha
Helmut Hullen
Du meintest am 07.02.11:
>> "udev" erschwert das Arbeiten mit einem Rechner, der mit mehreren
>> Festplatten und mehreren Netzwerkkarten bestückt ist, die ab und zu
>> mal ausgetauscht werden.
> Nein, das tut es nicht. Der Umgang mit mehreren Platten geschieht am
> besten, indem man die Devices "by-label" oder notfals "by-UUID"
> mountet, da hat man (voellig unabhaengig von udev) die geringsten
> Probleme mit.
Eben. Wenn ich "by label" mounte, dann brauche ich "udev" nicht.
Das funktioniert aber nur bei Platten. Nicht bei Netzwerkkarten.
Diedrich Ehlerding
>
> Warum soll ich Regel nach irgendeiner seltsamen Syntax schreiben, wenn
> ich mein Ziel auch mit LABEL erreichen kann?
Erstens kommen mit den heute verf�gbaren Distributionen verwendbare
Regeln mit, die Platten mit eindeutigen Hardware-spezifischen
Bezeichnungen benennen. Daf�r musst du also genau gar keine Regeln
selber schreiben, sondern einfach nur die benutzen, die deine
Distribution m Bauch hat. Wenn die keine verwendbaren Regeln im Bauch
hat, sieh dich nach einer anderen Distribution um.
Zweitens: Wenn du dein Ziel mit gelabelten Filesystemen erreichst, ist
alles gut, und das hatte ich Clemens ja auch als eine von mehreren
M�glichkeiten genannt. Es gibt aber Szenarien, in denen das nicht geht.
Zum Beispiel:
- dann, wenn du externe Raidsysteme mit mehreren Zugriffswegen
verwendest. Dann darfst du nicht die sd-Deviceknoten verwenden, sondern
musst die multipath-Namen nehmen. Die suche nach LABEL= sucht aber auch
auf den sd-Knoten ...
- dann, wenn du in diesen externen Speichersystemen oder auch per
soiftware Platten duplizierst (Clones anlegst), dann willst du gern
issen, ob du auf das Original oder den Clone zugreifst. In solchen
szenarien ist mounten �ber Label ebensoweni angesagt wie �ber UUID -
das, ws auf der Platte steht, w�rde mehrfach gefunden.
Ja, das ist nicht die �bliche Heimanwender-Umgebung. Ja, sowas braucht
man nur selten. Aber das, was in dieser Umgebung geht - n�mlich die
udev-Namen - geht auch in Heimanwender-Umgebung. Warum also zwei
verschiedene Mechanismen f�r denselben Zweck?
Diedrich
Diedrich Ehlerding
>> Fibrechannel-Netz und mach mehrere Raidsysteme dahinter sichtbar. Nein, da
>> weißt du nicht, in welcher Reihenfolge da was abgefragt wird.
>
> Abgefragt wird da sicher auch immer in der gleichen Reihenfolge (auch
> wenn ich das mangels FC-Netz noch nie probiert habe).
Nein, denn ...
> Es koennen sich
> aber natuerlich die Zuweisungen von IDs und LUNs zu den Geraeten aendern
> wenn man an dem FC-Netz rumspielt. Das entspricht aber dann ziemlich
> genau dem Umstecken der ID-Jumper an einem parallelen SCSI System - und
> das aendert dann natuerlich auch dort die Reihenfolge der Erkennung -
> eben gerade weil die Abfragereihenfolge gleich bleibt.
... es reicht aus, wenn sich die Netztopologie ändert, aber die
Zugriffswege und -rechte alle erhalten bleiben. Du kannst in deinem
Server dann keinerlei Unterscheid sehen; du siehst dieselben WWNs im
FC-Netz wie vorher und dieselben LUNs - sie werden nur eben heute auf
diese ID abgebildet und morgen auf jene. Das kann von Zeitbedingungen
abhängen, das kann von der Firmwareversion der Fibrechannel-switches
abhängen, das kann davon abhängen, ob ein Kabel hier oder dort
eingestöpselt wird.
Damit ändert sich weder die LUN-Adresse, noch entspricht das einer
Änderung des ID-Jumpers. Die ID bleibt völlig gleich, der Server sieht
(wenn er nicht neu gebootet wird) die Platte weiterhin unter der alten
Adresse und dem alten sd-Namen, sobald das Kabel wieder eingesteckt ist,
und kann problemlos weiter zugreifen. Erst beim Reboot werden die
sd-Namen an diesem Rechner durcheinandergewürfelt (aber nicht
notwendigerweise bei allen Servern in einem solchen Fibrechannel-Netz,
je nach Topologie ...)
Diedrich
Henning Paul
> Du meintest am 07.02.11:
>
>>> "udev" erschwert das Arbeiten mit einem Rechner, der mit mehreren
>>> Festplatten und mehreren Netzwerkkarten bestückt ist, die ab und zu
>>> mal ausgetauscht werden.
>
>> Nein, das tut es nicht. Der Umgang mit mehreren Platten geschieht am
>> besten, indem man die Devices "by-label" oder notfals "by-UUID"
>> mountet, da hat man (voellig unabhaengig von udev) die geringsten
>> Probleme mit.
>
> Eben. Wenn ich "by label" mounte, dann brauche ich "udev" nicht.
Kann smartd mit "LABEL=" umgehen? Kann hddtemp es? Auch wäre mir neu,
dass GRUB Legacy in der device.map etwas anderes als Blockdevices
verarbeiten könnte.
Ach so, ich vergaß, Du verwendest vermutlich weder smartd, hddtemp noch
GRUB. :-)
Gruß
Henning
Heiko Nocon
>Und das Problem ist lediglich eine - neutral formuliert - "design decision"
>der Kernel-Entwickler, die Zuordnung der Device-Namen _nicht_ fest mit der
>Hardware zu verkoppeln.
Das ist keine freie Entscheidung der Kernel-Entwickler gewesen, sondern
sie haben im Gegenteil nur auf Sachzw�nge _reagiert_, die aus der
allgemeinen Entwicklung der realen Hardware resultierten.
Sie haben schlicht bemerkt, da� in immer weniger Teilbereichen des
Hardwarezoos so eine Vorgehensweise �berhaupt m�glich war und daraus die
Konsequenz gezogen, es gleich ganz zugunsten einer einheitlichen
Vorgehensweise aufzugeben, n�mlich die Art der Enumeration komplett aus
dem Kernel herauszuhalten und statt dessen m�glichst viele Merkmale der
Hardware zur Enumeration im Userland bereitzustellen.
Bei dieser Entscheidung hat sicher auch die Tatsache eine Rolle
gespielt, da� eine hardwareabh�ngige oder buspositionsabh�ngige
Enumeration nicht f�r alle Anwendungsf�lle die optimale L�sung
darstellt.
Thomas Bächler
> Helmut Hullen wrote:
>
>> Du meintest am 07.02.11:
>>
>>>> "udev" erschwert das Arbeiten mit einem Rechner, der mit mehreren
>>>> Festplatten und mehreren Netzwerkkarten bestückt ist, die ab und zu
>>>> mal ausgetauscht werden.
>>
>>> Nein, das tut es nicht. Der Umgang mit mehreren Platten geschieht am
>>> besten, indem man die Devices "by-label" oder notfals "by-UUID"
>>> mountet, da hat man (voellig unabhaengig von udev) die geringsten
>>> Probleme mit.
>>
>> Eben. Wenn ich "by label" mounte, dann brauche ich "udev" nicht.
>
> Kann smartd mit "LABEL=" umgehen? Kann hddtemp es? Auch wäre mir neu,
> dass GRUB Legacy in der device.map etwas anderes als Blockdevices
> verarbeiten könnte.
Jedes Programm kann das, denn es sind nur Symlinks auf das echte Device
(/dev/disk/by-uuid/...)
Ralph Angenendt
> Ab und zu auch das. Ist schon einige Monate her - ich habe den Ablauf
> nicht protokolliert, sondern nur (mal wieder) "udev" weggeschaltet
> (sofern das möglich war) oder aber die spezielle Live-CD
> umweltfreundlich entsorgt.
Manchmal kannst du einem echt leid tun. Böse neue Welt!
Ralph
--
If the future isn't bright, at least it's colourful.
Nicht schreiben können: http://lestighaniker.de/
Ralph Angenendt
Wenn man udev hat, ja. Ansonsten steht das Label nur in den
Parititionsinformationen.
Ralph Angenendt
> Wenn man udev hat, ja. Ansonsten steht das Label nur in den
> Parititionsinformationen.
Den Dateisystemsinformationen natürlich (abgesehen von dem Tippfehler da
oben).
Helmut Hullen
Du meintest am 07.02.11:
>>> Nein, das tut es nicht. Der Umgang mit mehreren Platten geschieht
>>> am besten, indem man die Devices "by-label" oder notfals "by-UUID"
>>> mountet, da hat man (voellig unabhaengig von udev) die geringsten
>>> Probleme mit.
>>
>> Eben. Wenn ich "by label" mounte, dann brauche ich "udev" nicht.
> Kann smartd mit "LABEL=" umgehen? Kann hddtemp es?
Nein - nat�rlich nicht. LABEL funktioniert f�r Partitionen, also mit so
komischen Sachen, die gemountet werden.
Wenn ich bei "smartd.conf" einzig "DEVICESCAN" eintrage, dann werden mir
die Daten f�r "sda", "sdb" usw. angezeigt.
Auch in der "hddtemp.conf" sehe ich keine M�glichkeit, was anderes als
z.b. "/sda" zu benutzen. Hast Du da andere Informationen?
Ok - ich kann nat�rlich "irgendwie" einen Symlink "/dev/schnurrdibur"
auf "/dev/sda" zeigen lassen ...
> Auch w�re mir neu, dass GRUB Legacy in der device.map etwas anderes
> als Blockdevices verarbeiten k�nnte.
Ja und?
> Ach so, ich verga�, Du verwendest vermutlich weder smartd, hddtemp
> noch GRUB. :-)
Die Vermutung solltest Du wirklich rasch vergessen.
Henning Paul
>> Kann smartd mit "LABEL=" umgehen? Kann hddtemp es?
>
> Nein - natürlich nicht. LABEL funktioniert für Partitionen, also mit
> so komischen Sachen, die gemountet werden.
>
> Wenn ich bei "smartd.conf" einzig "DEVICESCAN" eintrage, dann werden
> mir die Daten für "sda", "sdb" usw. angezeigt.
>
> Auch in der "hddtemp.conf" sehe ich keine Möglichkeit, was anderes als
> z.b. "/sda" zu benutzen. Hast Du da andere Informationen?
>
> Ok - ich kann natürlich "irgendwie" einen Symlink "/dev/schnurrdibur"
> auf "/dev/sda" zeigen lassen ...
Eben. Bei mir steht da /dev/disk/by-id/ata-HERSTELLER-MODELL-
SERIENNUMMER. Geht nur mit udev.
>> Auch wäre mir neu, dass GRUB Legacy in der device.map etwas anderes
>> als Blockdevices verarbeiten könnte.
>
> Ja und?
>
>> Ach so, ich vergaß, Du verwendest vermutlich weder smartd, hddtemp
>> noch GRUB. :-)
>
> Die Vermutung solltest Du wirklich rasch vergessen.
Und dann kommst Du ohne udev klar? Ich möchte beispielsweise in meinem
grellm die Temperaturen meiner internen Platten angezeigt bekommen und
nicht die der externen, die beim Boot zufälligerweise gerade
eingeschaltet waren und jetzt sdc und sdd heißen.
Gruß
Henning
Henning Paul
Eben. Wenn udev läuft. Helmut sagt ja, er braucht kein udev, weil er per
"LABEL=" mountet. Für's mounten mag das ja gut gehen, aber alle anderen
Daemons können damit nichts anfangen.
Gruß
Henning
Helmut Hullen
Du meintest am 07.02.11:
>> Ok - ich kann natürlich "irgendwie" einen Symlink
>> "/dev/schnurrdibur" auf "/dev/sda" zeigen lassen ...
> Eben. Bei mir steht da /dev/disk/by-id/ata-HERSTELLER-MODELL-
> SERIENNUMMER. Geht nur mit udev.
Ach was - solche Symlinks konnte ich schon 1995 definieren, lange vor
der Erfindung von "udev".
> Und dann kommst Du ohne udev klar?
Natürlich!
> Ich möchte beispielsweise in
> meinem grellm die Temperaturen meiner internen Platten angezeigt
> bekommen und nicht die der externen, die beim Boot zufälligerweise
> gerade eingeschaltet waren und jetzt sdc und sdd heißen.
Erzähl doch mal, wie Du das derzeit löst!
Könnte es sein, dass Du irgendwelche Informationen der Art "diese 2
Platten" in die "hddtemp.conf" einträgst?
Helmut Hullen
Du meintest am 07.02.11:
>> Jedes Programm kann das, denn es sind nur Symlinks auf das echte
>> Device (/dev/disk/by-uuid/...)
> Eben. Wenn udev l�uft. Helmut sagt ja, er braucht kein udev, weil er
> per "LABEL=" mountet. F�r's mounten mag das ja gut gehen, aber alle
> anderen Daemons k�nnen damit nichts anfangen.
"alle anderen"? Welche bittesch�n?
"quotad" beispielsweise kann damit etwas anfangen.
Henning Paul
> Du meintest am 07.02.11:
>
>>> Ok - ich kann natürlich "irgendwie" einen Symlink
>>> "/dev/schnurrdibur" auf "/dev/sda" zeigen lassen ...
>
>> Eben. Bei mir steht da /dev/disk/by-id/ata-HERSTELLER-MODELL-
>> SERIENNUMMER. Geht nur mit udev.
>
> Ach was - solche Symlinks konnte ich schon 1995 definieren, lange vor
> der Erfindung von "udev".
Und die haben dann auch immer automatisch auf die richtige Platte
gezeigt?
>> Ich möchte beispielsweise in
>> meinem grellm die Temperaturen meiner internen Platten angezeigt
>> bekommen und nicht die der externen, die beim Boot zufälligerweise
>> gerade eingeschaltet waren und jetzt sdc und sdd heißen.
>
> Erzähl doch mal, wie Du das derzeit löst!
> Könnte es sein, dass Du irgendwelche Informationen der Art "diese 2
> Platten" in die "hddtemp.conf" einträgst?
Ich habe da vier /dev/disk/by-id/-Symlinks drin stehen. Und in gkrellm
habe ich dann als Beschriftung dieser 4 Temperaturen "SYS" und "RAID1"
bis "RAID3".
Gruß
Henning
Henning Paul
> Du meintest am 07.02.11:
>
>>> Jedes Programm kann das, denn es sind nur Symlinks auf das echte
>>> Device (/dev/disk/by-uuid/...)
>
>> Eben. Wenn udev läuft. Helmut sagt ja, er braucht kein udev, weil er
>> per "LABEL=" mountet. Für's mounten mag das ja gut gehen, aber alle
>> anderen Daemons können damit nichts anfangen.
>
> "alle anderen"? Welche bitteschön?
Ich erwähnte smartd und hddtemp. Das ginge auch gar nicht, da diese ja
beispielsweise ein Platten- und kein Partitionsdevice erwarten.
> "quotad" beispielsweise kann damit etwas anfangen.
Das ist dann ja erfreulich.
Gruß
Henning
Helmut Hullen
Du meintest am 07.02.11:
>>>> Ok - ich kann nat�rlich "irgendwie" einen Symlink
>>>> "/dev/schnurrdibur" auf "/dev/sda" zeigen lassen ...
>>> Eben. Bei mir steht da /dev/disk/by-id/ata-HERSTELLER-MODELL-
>>> SERIENNUMMER. Geht nur mit udev.
>> Ach was - solche Symlinks konnte ich schon 1995 definieren, lange
>> vor der Erfindung von "udev".
> Und die haben dann auch immer automatisch auf die richtige Platte
> gezeigt?
Klar. Weil ich definierte, was (nach meiner Meinung) "richtig" sei.
>>> Ich m�chte beispielsweise in
>>> meinem grellm die Temperaturen meiner internen Platten angezeigt
>>> bekommen und nicht die der externen, die beim Boot zuf�lligerweise
>>> gerade eingeschaltet waren und jetzt sdc und sdd hei�en.
>> Erz�hl doch mal, wie Du das derzeit l�st!
>> K�nnte es sein, dass Du irgendwelche Informationen der Art "diese 2
>> Platten" in die "hddtemp.conf" eintr�gst?
> Ich habe da vier /dev/disk/by-id/-Symlinks drin stehen. Und in
> gkrellm habe ich dann als Beschriftung dieser 4 Temperaturen "SYS"
> und "RAID1" bis "RAID3".
Aha. Also hast Du einzig den Umweg eingebaut, die Plattenbezeichnungen
"irgendwie" mit den Informationen zu verkn�pfen, die "udev"
bereitstellt. Die sind leider selten selbsterkl�rend oder sprechend.
Da arbeite ich lieber mit "blkid" und/oder "file -s".
Sieghard Schicktanz
Du schriebst am Mon, 07 Feb 2011 09:22:11 +0100:
> > Was sind "udev-Namen"? udev vergibt die Namen so, wie es seine Regeln
> > angeben, und die Regeln sind _ï¿œnderbar_. Ohne weitere Angaben ï¿œbernimmt
> > udev die Kernel-Namen (sd?).
>
> Die "Haupt"namen sind nicht mehr ï¿œnderbar, die bleiben nun grundsï¿œtzlich
> so wie vom Kernel festgelegt.
Das sind dann die (hier vorher so bezeichneten) "Kernel-Namen".
> Was man ï¿œndern kann, sind die Symlinks, die darauf zeigen. Und hier gibt
> es die ominï¿œsen "udev-Namen", die mittlerweile Standard auf nahezu allen
> Linux-basierten Desktop/Server-Systemen sind:
Ahso, die bezeichnest Du so - ist das irgendwo so (mehr oder weniger)
offiziell so eingefï¿œhrt worden?
(Ich hab' die letzte Zeit da leider nicht gar so viel davon mitbekommen,
weil ich doch recht beschï¿œftigt war; ich hab' nichtmal meine Maschinen
aktualisieren kï¿œnnen, weil die stï¿œndig mit "auf Achse" muï¿œten, soweit
beweglich. Deswegen sorry fï¿œr die dummen Fragen...)
--
(Weitergabe von Adressdaten, Telefonnummern u.ￜ. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ï¿œhnlichem)
-----------------------------------------------------------
Mit freundlichen Grￜￜen, S. Schicktanz
-----------------------------------------------------------
Sieghard Schicktanz
Du schriebst am Mon, 7 Feb 2011 12:27:27 +0000 (UTC):
> > Wenn man udev hat, ja. Ansonsten steht das Label nur in den
> > Parititionsinformationen.
>
> Den Dateisystemsinformationen natürlich (abgesehen von dem Tippfehler da
^#
Welchen? Den markierten? Der stand "von Dir aus gesehen" aber nicht "oben".
Platten-Label können je nach Dateisystem an unterschiedlichen Stellen
stehen, bei ext<n> wohl im Superblock. Bei FAT gab's Label im Partitions-
Ladesektor (1. Sektor der Partition, meintest Du den mit
"Parititionsinformationen"?) und im Dateisystem, die sogar unterschiedlich
sein konnten (wobei aber nur eines angezeigt wurde).
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Juergen Ilse
Helmut Hullen <Hel...@hullen.de> wrote:
> Du meintest am 07.02.11:
>>> Ok - ich kann natürlich "irgendwie" einen Symlink
>>> "/dev/schnurrdibur" auf "/dev/sda" zeigen lassen ...
>> Eben. Bei mir steht da /dev/disk/by-id/ata-HERSTELLER-MODELL-
>> SERIENNUMMER. Geht nur mit udev.
> Ach was - solche Symlinks konnte ich schon 1995 definieren, lange vor
> der Erfindung von "udev".
udev setzt sie bei jedem systemstart gemaess der aktuell geltenden
Zuordnung neu. Wer oder was macht macht das bei deinem Vorschlag?
Und dass die Zuordnung zwischen Plattenhardware und Devicenamen
und/oder Major und Minor-Device-Number nicht unbedingt zwingend
bei jedem Boot gleich sein muss, hatten wir doch schon (womit die
Aktualisierung bei jedem Boot zumindest dringend zu empfehlen ist,
wenn der Link zuverlaessig eine bestimmte Platte addressieren soll) ...
Thomas Rachel
> Hallo Ralph,
>
> Du schriebst am Mon, 7 Feb 2011 12:27:27 +0000 (UTC):
>
>>> Wenn man udev hat, ja. Ansonsten steht das Label nur in den
>>> Parititionsinformationen.
>>
>> Den Dateisystemsinformationen natürlich (abgesehen von dem Tippfehler da
> ^#
> Welchen? Den markierten?
"Paritions...".
> Platten-Label können je nach Dateisystem an unterschiedlichen Stellen
> stehen, bei ext<n> wohl im Superblock. Bei FAT gab's Label im Partitions-
> Ladesektor (1. Sektor der Partition, meintest Du den mit
> "Parititionsinformationen"?) und im Dateisystem, die sogar unterschiedlich
> sein konnten (wobei aber nur eines angezeigt wurde).
Richtig. Aus diesem Grund werden alle der libblkid(3) bekannten
Dateisysteme (inkl. LVM und RAID) durchprobiert (keine Ahnung, in
welcher Reihenfolge) und nach diversen Attributen, u.a. dem Label,
gefragt. Bei FAT (egal, ob 12, 16 oder 32) wird bevorzugt das Label im
Verzeichnisbaum, hilfsweise das im Header verwendet.
Thomas
Helmut Hullen
Du meintest am 07.02.11:
>>>> Ok - ich kann nat�rlich "irgendwie" einen Symlink
>>>> "/dev/schnurrdibur" auf "/dev/sda" zeigen lassen ...
>>> Eben. Bei mir steht da /dev/disk/by-id/ata-HERSTELLER-MODELL-
>>> SERIENNUMMER. Geht nur mit udev.
>> Ach was - solche Symlinks konnte ich schon 1995 definieren, lange
>> vor der Erfindung von "udev".
> udev setzt sie bei jedem systemstart gemaess der aktuell geltenden
> Zuordnung neu. Wer oder was macht macht das bei deinem Vorschlag?
Ich nat�rlich. Einmalig dann, wenn ich der Meinung bin, dass ein solcher
Link sinnvoll sei.
War oft sinnvoll, um das IDE-CD-ROM-Laufwerk zu definieren, oder das
Modem. Die ganz alten Leute werden das noch kennen.
> Und dass die Zuordnung zwischen Plattenhardware und Devicenamen
> und/oder Major und Minor-Device-Number nicht unbedingt zwingend
> bei jedem Boot gleich sein muss, hatten wir doch schon (womit die
> Aktualisierung bei jedem Boot zumindest dringend zu empfehlen ist,
> wenn der Link zuverlaessig eine bestimmte Platte addressieren soll)
> ...
Ja - darauf habe ich (auch vor diesem Thread) auch schon des �fteren
hingewiesen. Und auch, dass ich zur Vermeidung solcher Probleme LABEL
empfehle.
Betrifft aber Partitionen, nicht komplette Ger�te.
Noch mal zur Verdeutlichung: Symlinks sind schon seit ganz vielen Jahren
m�glich. Zur L�sung der Zuordnung von Partitionen zu Funktionen ist
LABEL jedoch eher sinnvoll.
Ach ja:
fdisk -l
df
mount
cat /proc/partitions
sind einige Befehle, die weder LABEL noch udev-Symlinks anzeigen.
Thomas Bächler
>> Was man ï¿œndern kann, sind die Symlinks, die darauf zeigen. Und hier gibt
>> es die ominï¿œsen "udev-Namen", die mittlerweile Standard auf nahezu allen
>> Linux-basierten Desktop/Server-Systemen sind:
>
> Ahso, die bezeichnest Du so - ist das irgendwo so (mehr oder weniger)
> offiziell so eingefï¿œhrt worden?
> (Ich hab' die letzte Zeit da leider nicht gar so viel davon mitbekommen,
> weil ich doch recht beschï¿œftigt war; ich hab' nichtmal meine Maschinen
> aktualisieren kï¿œnnen, weil die stï¿œndig mit "auf Achse" muï¿œten, soweit
> beweglich. Deswegen sorry fï¿œr die dummen Fragen...)
Spontan hab ich nur das hier gefunden, dort ist das Layout der by-id und
by-path Namen festgelegt:
http://people.redhat.com/harald/suse-device-nameing-layout-draft.pdf
Der de-facto Standard fï¿œr die Namensgebung ist bei Udev festgelegt und
wird meines Wissens nach von allen Distributionen so ï¿œbernommen:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/rules.d/60-persistent-storage.rules
Henning Paul
> Spontan hab ich nur das hier gefunden, dort ist das Layout der by-id
> und by-path Namen festgelegt:
> http://people.redhat.com/harald/suse-device-nameing-layout-draft.pdf
>
> Der de-facto Standard für die Namensgebung ist bei Udev festgelegt und
> wird meines Wissens nach von allen Distributionen so übernommen:
>
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/rules.d/60-
persistent-storage.rules
Demnächst sollen übrigens auch Hardware-bezogene Namen für
Netzwerkinterfaces von udev erzeugt werden:
http://www.heise.de/open/artikel/Kernel-Log-Eindeutige-Namen-fuer-
Netzwerkschnittstellen-1179882.html
Gruß
Henning
Michael Baeuerle
> Am 07.02.2011 10:49, schrieb Michael Baeuerle:
> >
> > Abgefragt wird da sicher auch immer in der gleichen Reihenfolge (auch
> > wenn ich das mangels FC-Netz noch nie probiert habe).
>
> Nein, denn ...
>
> > Es koennen sich
> > aber natuerlich die Zuweisungen von IDs und LUNs zu den Geraeten aendern
> > wenn man an dem FC-Netz rumspielt. Das entspricht aber dann ziemlich
> > genau dem Umstecken der ID-Jumper an einem parallelen SCSI System - und
> > das aendert dann natuerlich auch dort die Reihenfolge der Erkennung -
> > eben gerade weil die Abfragereihenfolge gleich bleibt.
>
> ... es reicht aus, wenn sich die Netztopologie ändert, aber die
> Zugriffswege und -rechte alle erhalten bleiben.
Das ist doch dann der gleiche Fall wie bei USB den ich erwaehnt hatte.
> Du kannst in deinem
> Server dann keinerlei Unterscheid sehen; du siehst dieselben WWNs im
> FC-Netz wie vorher und dieselben LUNs - sie werden nur eben heute auf
> diese ID abgebildet und morgen auf jene.
Eben vergleichbar wie bei USB. Da aendert sich die VID/PID ja auch nicht
wenn man die Bustopologie veraendert oder gar einen anderen Bus benutzt,
die SCSI ID oder der SCSI HA bzw. Channel ggf. aber schon.
> Das kann von Zeitbedingungen
> abhängen, das kann von der Firmwareversion der Fibrechannel-switches
> abhängen, das kann davon abhängen, ob ein Kabel hier oder dort
> eingestöpselt wird.
>
> Damit ändert sich weder die LUN-Adresse, noch entspricht das einer
> Änderung des ID-Jumpers.
OK, "entsprechen" war vielleicht das falsche Wort.
Das Mapping bestimmt aber auf jeden Fall, welches Device antwortet wenn
der Host IDx anspricht. Der Mid- & Upper-Layer im Kernel der den
Bus-Scan durchfuehrt und die Devicenamen zuweist interessiert sich nicht
mehr fuer Details jenseits dieser Abstraktion, die IDs und LUNs werden
dann in einer definierten Reihenfolge abgefragt. Und ja, auch auf
SMP-Maschinen mit mehreren HAs hat man das frueher problemlos
hinbekommen, seit 2.6.? mit parallelen Scans sollte das IMHO immer noch
funktionieren, ansonsten muss man eben "scsi_mod.scan=sync" setzen.
> Die ID bleibt völlig gleich, der Server sieht
> (wenn er nicht neu gebootet wird) die Platte weiterhin unter der alten
> Adresse und dem alten sd-Namen, sobald das Kabel wieder eingesteckt ist,
> und kann problemlos weiter zugreifen. Erst beim Reboot werden die
> sd-Namen an diesem Rechner durcheinandergewürfelt (aber nicht
> notwendigerweise bei allen Servern in einem solchen Fibrechannel-Netz,
> je nach Topologie ...)
Das darf aber nur passieren wenn sich an dem FC-Netz was veraendert hat.
Dann geht es logischerweise nicht, genau wie in meinem Beispiel mit USB.
Meine Aussage war ja lediglich: Wenn die Konfiguration statisch ist,
zerwuerfelt es einem die Zuordnung nicht (bzw. man kann es so
konfigurieren, dass das nicht passiert).
Das bezog sich auf diesen Satz:
|
| Spätestens wenn du mehrere Platten am selben SCSI-Bus hast (oder
mehrere
| SATA-Ports mit Platten belegt hast) hast du verloren, weil du nicht
weißt,
| welche als erste antwortet.
Und dieser Satz ist einfach falsch. Ich habe noch so konfigurierte
Rechner laufen (mit mehreren Bussen und mehreren Platten an einem Bus)
und das funktioniert.
Micha
Helmut Hullen
Du meintest am 08.02.11:
> Demn�chst sollen �brigens auch Hardware-bezogene Namen f�r
> Netzwerkinterfaces von udev erzeugt werden:
> http://www.heise.de/open/artikel/Kernel-Log-Eindeutige-Namen-fuer-
> Netzwerkschnittstellen-1179882.html
------------------ Zitat ein -------------
Dem ersten Netzwerk-Port auf dem Mainboard soll Udev dadurch den Namen
"em1" zuteilen, wobei das "em" f�r "embedded" steht; Netzwerkkarten
folgen dem Muster "pci<slot>#<port>" (etwa pci2#1), wodurch die Ports
einer Netzwerkkarte immer unter dem selben Namen ansprechbar sein
sollten, solange diese oder eine als Ersatz eingebaute Karte im selben
Steckplatz steckt.
------------------ Zitat aus -------------
Ok - dann bleibt das Verhalten des Systems vorhersagbar. Sch�n!
Das Programm meldet f�r meine beiden Karten in meinem Hauptrechner
"pci2#1" und "pci5#1". Da muss ich zwar irgendwann immer noch ein wenig
experimentieren, welcher Slot sich dahinter verbirgt, aber das Problem
ist l�sbar (notfalls, indem ich nicht alle Karten gleichzeitig
einstecke).
---------------------------------------------
Eben bei einem anderen Rechner ausprobiert, der mit 4 Netzwerkkarten
best�ckt ist (die auch brav funktionieren):
biosdevname -i eth0
bis
biosdevname -i eth3
liefert jedes Mal eine leere R�ckgabe sowie einen "errorlevel" <> Null.
Mitsamt "debug"-Meldungen:
PCI name : 0000:07.0 (oder �hnlich)
PCI Slot : Unknown
Mal sehen, was die Entwickler dazu sagen ...
---------------------------------------------
Noch wieder ein anderer Rechner: 2 PCI-Steckkarten, beide werden
(f�lschlicherweise) als "embedded" erkannt. Ok - Namen sind Schall und
Rauch.
Ralph Angenendt
> Rauch.
Hast du gerade eben mal Rawhide installiert und das damit versucht oder
hast du "demnächst" nicht verstanden? Oder wolltest du nur zeigen, wie
böse udev ist?
frank paulsen
> Noch wieder ein anderer Rechner: 2 PCI-Steckkarten, beide werden
> (fälschlicherweise) als "embedded" erkannt. Ok - Namen sind Schall und
> Rauch.
die sind doch embedded? zumindest haengen sie nicht ueber ein kabel
aussen am gehaeuse...
--
frobnicate foo
Helmut Hullen
Du meintest am 08.02.11:
>> Noch wieder ein anderer Rechner: 2 PCI-Steckkarten, beide werden
>> (fälschlicherweise) als "embedded" erkannt. Ok - Namen sind Schall
>> und Rauch.
> Hast du gerade eben mal Rawhide installiert und das damit versucht
> oder hast du "demnächst" nicht verstanden? Oder wolltest du nur
> zeigen, wie böse udev ist?
"biosdevname" funktioniert "in sich" auch dann, wenn "udev" nicht läuft.
Die Erkennung taugt noch nicht so recht.
Ich beschäftige mich mit mehr Programmen als nur mit "udev", vielleicht
solltest Du das bei Deinen Antworten berücksichtigen.
Helmut Hullen
Du meintest am 08.02.11:
>> Noch wieder ein anderer Rechner: 2 PCI-Steckkarten, beide werden
>> (f�lschlicherweise) als "embedded" erkannt. Ok - Namen sind Schall
>> und Rauch.
> die sind doch embedded? zumindest haengen sie nicht ueber ein kabel
> aussen am gehaeuse...
Doch ... ja ... "nicht ohne Werkzeug zu entfernen" ...
Eben auch ich auch noch mein Thinkpad-Notebook untersuchen lassen:
die PCcard-NIC wird als "embedded" erkannt, die on-board-NIC als
"pci1#1".
E-Mail an den Entwickler ist unterwegs; bald beginnt sein Arbeitstag.
Sieghard Schicktanz
Du schriebst am Tue, 08 Feb 2011 10:35:58 +0100:
> Spontan hab ich nur das hier gefunden, dort ist das Layout der by-id und
> by-path Namen festgelegt:
> http://people.redhat.com/harald/suse-device-nameing-layout-draft.pdf
Naja, ist aber nicht direkt "offiziell". Wird wohl nix besseres geben.
> Der de-facto Standard für die Namensgebung ist bei Udev festgelegt und
> wird meines Wissens nach von allen Distributionen so übernommen:
Auch das ist halt eher nur ein Vorschlag der Entwickler.
Immerhin ein Anfang...
Danke für die Information!
--
Clemens Schueller
Diedrich Ehlerding <diedrich....@t-online.de> writes:
> Clemens Schueller meinte:
Gleich mal vorweg: Das Subject ist nicht mehr aktuell - denn ich lass
den Intel RAID Verbund (4x 36 GiB 10k Platten) als Master laufen und die
Onboard SATA Drives als 2x 500 GiB per LVM zusammengefasst:
>> Wenn ich Dich jetzt also richtig verstehe, dann das System ganz normal
>> installieren und im Nachhinein die Verdrahtungen in der /etc/fstab und
>> in der grub Config ändern? Sprich, dass die udev Namen verwendet werden.
Bzgl. UUIDs usw. hab ich gar nichts ändern müssen - siehe unten.
> Ja.
>
> Neben der fstab musst du im Fall "grub" auch an /boot/grub/device.map
> denken, da solltest du statt "(hd0) /dev/sda" sowas wie
> "(hd0) /dev/disk/by-id/<deinebootplatte>" reinschreiben, damit der nächste
> grub-update gut geht. (Es kann aber sein, dass Ubuntu grub2 verwendet, da
> kenne ich mich nicht mit aus).
Soweit ich sehe, verwendet die 10er LTS grub2:
+----
| [mente@powerstation: ~]% apt-cache policy grub-pc
| grub-pc:
| Installiert: 1.98-1ubuntu10
| Kandidat: 1.98-1ubuntu10
| Versions-Tabelle:
| *** 1.98-1ubuntu10 0
| 500 http://at.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
| 100 /var/lib/dpkg/status
| 1.98-1ubuntu5 0
| 500 http://at.archive.ubuntu.com/ubuntu/ lucid/main Packages
+----
> Vielleicht schaust du nochmal genau hin; ich kann mir eigentlich kaum
> vorstellen, dass die Ubuntu-Installationsroutine das überhaupt nicht
> anbietet. Oder du fragst in dieser Richtung nochmal bei ubuntuusers.com.
+----
| [mente@powerstation: ~]% cat /etc/fstab | grep -v "^#"
| proc /proc proc nodev,noexec,nosuid 0 0
| /dev/mapper/vg--sys-lv--sys / ext4 errors=remount-ro 0 1
| UUID=f762dbc6-dfd7-4990-a004-f021ab0a479c /boot ext2 defaults 0 2
| /dev/mapper/vg--data-lv--data /data ext4 nodev,nosuid,noexec 0 2
| /dev/mapper/vg--sys-lv--home /home ext4 nodev,nosuid,noexec 0 2
| /dev/mapper/vg--sys-lv--var /var ext4 defaults 0 2
| UUID=e7f8ae0a-7eb6-43af-8711-55303e6ff5fe none swap sw 0 0
| /dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
|
| UUID="599F-1419" /media/music vfat defaults,auto,user,uid=1000,gid=1000,utf8 0 0
+----
Wie man sieht, verwendet das System UUIDs (die letzte Zeile hab ich per
Hand eingetragen).
BTW: Ist es ein großer Aufwand, zum LVM Verbund der 2 Onboard SATAs noch
eine 3te Platte hinzuzufügen (falls die 1 TiB mal voll sind)?
GreetinX, Clemens Schueller
Diedrich Ehlerding
> Wie man sieht, verwendet das System UUIDs (die letzte Zeile hab ich per
> Hand eingetragen).
Man sieht zweierlei: erstens läuft das System auf LVM, was schonmal eine
gute Idee ist, und zweitens wird /boot über die UUID gemountet. Damit
können dir in der Tat die sd-Namen egal sein.
> BTW: Ist es ein großer Aufwand, zum LVM Verbund der 2 Onboard SATAs noch
> eine 3te Platte hinzuzufügen (falls die 1 TiB mal voll sind)?
Nein, das ist völlig problemlos; genau dafür verwendet man ja LVM. .
Vorgehensweise (wenn du in deinem Fall das Volume "data" in
Volumegruppe "data-lv" vergrößern willst):
- neue Platte einbauen *und* *sicher* *identifizieren* (denn beim
Einbau werden die sd-Namen wieder verwürfelt; siehe weiter oben im
Faden ...)
- pvcreate /dev/<neue_platte> (nein, eine Partition brauchst du nicht
unbedingt; es schadet aber auch nicht wirklich, vorher eine anzulegen
und dann die Partition zu verwenden; insbesondere wenn du ein
Multiboot-System hast und gelegentlich auch ein Wintendo bootest,
verringert das die Verwirrung auf der Windows-Seite; dann eben
pvcreate /dev/<Partition_der_neuen_platte>
- vgextend data-lv /dev/<neue_platte> (oder -Partition wie oben)
- Dann entweder neue Volumes anlegen (lvcreate) oder vorhandene
Volumes vergrößern (wenn du den kompletten Platz nutzen willst:
lvextend -L +100%FREE /dev/data-lv/data ), dann je nach
Filesystemtyp Filesystem vergrößern (bei ext2/3 geht das im
laufenden Betrieb mit ext2online oder nach umount mit resize2fs; wie
man das bei ext4 macht, weiß ich nicht genau; manpages lesen).
Diedrich
umlenkend nach doulm, weil das kein Hardwarethema mehr ist.