Reihenfolge der HDDs
Andreas Pesch
ich habe in meinen Rechner eine neue, zusätzliche Festplatte eingebaut,
jetzt sind 3 Stück darin.
Angeschlossen sind sie an SATA1, SATA2 und die neue an SATA3.
So werden sie auch beim Systemstart erkannt und ausgegeben.
Auf der Platte an SATA1 befindet sich u.a. ein Ubuntu 8.04, welches eine
Partition von der Platte an SATA2 (sdb1) gemountet hat.
Mit nur 2 Platten:
SATA1 -> sda
SATA2 -> sdb
Nachdem ich nun die 3. Platte eingebaut habe, wird diese von Linux-Systemen
(Dem Ubuntu 8.04 auf SATA1 und dem neu installierten 9.10 auf SATA3) als
sdb erkannt, die Platte an SATA2 wird als sdc erkannt.
SATA1 -> sda
SATA2 -> sdc
SATA3 -> sdb
Grundsätzlich macht es mir kein Problem, da habe ich halt den Eintrag in der
fstab geändert und sdb1 wird jetzt als sdc1 gemountet.
Aber: Wieso werden die Platten nicht in der von mir erwarteten Reihenfolge
erkannt?
SATA1 -> sda
SATA2 -> sdb
SATA3 -> sdc
Schöne Grüße und einen guten Rutsch!
Andreas
Tim Ritberg
Diedrich Ehlerding
> Aber: Wieso werden die Platten nicht in der von mir erwarteten
> Reihenfolge erkannt?
>
> SATA1 -> sda
> SATA2 -> sdb
> SATA3 -> sdc
Du solltest ganz grundsätzlich nicht den Namensraum /dev/sd* verwenden -
wie du gemerkt hast, weden die beim Booten immer neu durchgezählt, und je
nachdem, welche Platten beim Booten in welcher Reihenfolge erkannt werden,
hast du diese oder jene Namen. Mounte Filesysteme entweder über eine auf
der Platte stehende Identifikation, sei es ein Filesystem-Label, sei es
eine LVM-Struktur, sei es eine md-UUID im Falle von Software-RAID, oder
verwende die udev-Namen, die aus einer zur Platte gehörenden
Hardwareidentifikation erzeugt werden (/dev/disk/by-id/*); diese Namen
sind rebootfest (allerdings nicht plattentauschfest)
>
--
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 ungelesen entsorgt.
Helmut Hullen
Du meintest am 29.12.09:
> ich habe in meinen Rechner eine neue, zus�tzliche Festplatte
> eingebaut, jetzt sind 3 St�ck darin.
[...]
> Nachdem ich nun die 3. Platte eingebaut habe, wird diese von
> Linux-Systemen (Dem Ubuntu 8.04 auf SATA1 und dem neu installierten
> 9.10 auf SATA3) als sdb erkannt, die Platte an SATA2 wird als sdc
> erkannt.
[...]
> Aber: Wieso werden die Platten nicht in der von mir erwarteten
> Reihenfolge erkannt?
Das d�rfte (mal wieder) an "udev" liegen; dieses Programm setzt die
Zuordnungen ungefragt nach eigenem Gusto.
Such mal in "/etc/udev/rules.d" nach SATA, sda usw.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Henning Paul
> Hallo, Andreas,
>> Aber: Wieso werden die Platten nicht in der von mir erwarteten
>> Reihenfolge erkannt?
>
> Das d�rfte (mal wieder) an "udev" liegen; dieses Programm setzt die
> Zuordnungen ungefragt nach eigenem Gusto.
N�. Das tut der Controllertreiber. Im Gegenteil, dank udev kann man dem
entgegenwirken, indem man sprechende Symlinks verwendet.
Bei Netzwerkinterfaces h�ttest Du recht, aber (Platten-)Devices kann man
nicht umbenennen.
Gru�
Henning
Helmut Hullen
Du meintest am 29.12.09:
>> Aber: Wieso werden die Platten nicht in der von mir erwarteten
>> Reihenfolge erkannt?
>>
>> SATA1 -> sda
>> SATA2 -> sdb
>> SATA3 -> sdc
> Du solltest ganz grunds�tzlich nicht den Namensraum /dev/sd*
> verwenden
Doch - das ging mehr als 10 Jahre auch unter Linux recht gut.
> - wie du gemerkt hast, weden die beim Booten immer neu
> durchgez�hlt, und je nachdem, welche Platten beim Booten in welcher
> Reihenfolge erkannt werden, hast du diese oder jene Namen.
Aber bei den meisten Rechnern �ndert sich weder die Zahl noch die
Bedeutung der Festplatten ohne Wissen des Besitzers.
Einzig bei per USB oder Firewire (oder neuerdings eSATA) angebundenen
Platten ist der Devicename (z.B. /dev/sdc) nicht so hilfreich; da hilft
"LABEL" viel eher als die Eigenm�chtigkeit von "udev".
Henning Paul
> Hallo, Diedrich,
>
> Du meintest am 29.12.09:
>
>>> Aber: Wieso werden die Platten nicht in der von mir erwarteten
>>> Reihenfolge erkannt?
>>>
>>> SATA1 -> sda
>>> SATA2 -> sdb
>>> SATA3 -> sdc
>
>> Du solltest ganz grunds�tzlich nicht den Namensraum /dev/sd*
>> verwenden
>
> Doch - das ging mehr als 10 Jahre auch unter Linux recht gut.
N�, mein lieber Helmut, wenn Du die externe SCSI-Platte vor dem Booten
vergessen hast einzuschalten, ging das genau so schief.
>> - wie du gemerkt hast, weden die beim Booten immer neu
>> durchgez�hlt, und je nachdem, welche Platten beim Booten in welcher
>> Reihenfolge erkannt werden, hast du diese oder jene Namen.
>
> Aber bei den meisten Rechnern �ndert sich weder die Zahl noch die
> Bedeutung der Festplatten ohne Wissen des Besitzers.
Du kannst sicherstellen, dass die USB-Platte niemals beim Reboot
versehentlich noch an ist? Oder dass nicht noch ein USB-Stick steckt?
Jetzt komm mir nicht mit "dann sorge ich eben mit selbstgeschriebenen
Skripten und modprobe-Regeln daf�r, dass usb_storage garantiert immer
erst zum Schluss geladen wird".
> Einzig bei per USB oder Firewire (oder neuerdings eSATA) angebundenen
> Platten ist der Devicename (z.B. /dev/sdc) nicht so hilfreich;
Eben. Und da sich interne und externe SATA-Platten nicht unterscheiden
lassen, braucht man eben einen solchen Mechanismus f�r alle Platten.
> da hilft "LABEL" viel eher als die Eigenm�chtigkeit von "udev".
Kann man verwenden, manchmal ist aber die Hardwarebezeichnung ein
besseres Kriterium als der Datentr�gername.
Gru�
Henning
Diedrich Ehlerding
>> Du solltest ganz grundsätzlich nicht den Namensraum /dev/sd*
>> verwenden
>
> Doch - das ging mehr als 10 Jahre auch unter Linux recht gut.
Ja - solange die Hardwarekonfiguration konstant blieb und solange die
Treiber in definierter Reihenfolge geladen wurden. Es gibt aber
Situationen, in denen mehrere Treiber ihre Platten scannen, da ist
überhaupt nicht vorhersehbar, welche Platte welchen Deviceknoten bekommt.
> Aber bei den meisten Rechnern ändert sich weder die Zahl noch die
> Bedeutung der Festplatten ohne Wissen des Besitzers.
In diesem Fall war aber genau das der Fall, und der Besitzer stolperte in
den vorhersehbaren Abgrund, in den er bei Nichtverwendung dieses
Namensraums eben nicht gestolpert wäre. Im Übrigen passiert genau das (die
Änderung der Zahl der Festplatten beim Booten) bereits dann, wenn man
versehentlich einen USB-Stick beim letzten Shutdown vergessen hatte
abzuziehen.
>
> Einzig bei per USB oder Firewire (oder neuerdings eSATA) angebundenen
> Platten ist der Devicename (z.B. /dev/sdc) nicht so hilfreich; da hilft
> "LABEL" viel eher als die Eigenmächtigkeit von "udev"
Die sd*-Namen sind überall da nicht hilfreich, wo sich die
Plattenkonfiguration beim Reboot ändern kann. Zum Beispiel bei jedem
Aldi-PC mit eSata-Anschluss, ganz allgemein immer dann, wenn externe
Platten ein Thema sein können, egal ob USB oder Firewire oder Fibrechannel
oder eSata oder SAS.
Dass du kein Fan von udev bist, ist hier nicht wirklich unbekannt.
udev-Namen sind zugegebenermaßen hässlich, aber eben rebootfest, und das
ist es, worauf es hier ankommt, und udev-Namen werden von diversen
Distributionen in deren Installationstool angeboten. Wenn du mal genau
hinschaust, hatte ich im Übrigen gelabelte Filesysteme und LVM als andere
Möglichkeiten bereits erwähnt, und zwar vor udev. Und es gibt neben
Szenarien, in denen Label, LVM usw. die bessere Wahl sind, durchaus auch
Szenarien, in denen LVM und Label zu großer Konfusion führen können
(sowohl diese wie jene liegen aber jenseits des Heimanwenderbereichs).
Wenn du also deinem Beißreflex gegen jeden, der es wagt, die Vokabel "udev"
auch nur zu denken, ohne gleich den Exorzisten zu bestellen, wieder Zügel
anlegen könntest, wäre ich dir zu gewissem Dank verpflichtet.
Diedrich
Markus Wichmann
> Hallo, Diedrich,
>
> Du meintest am 29.12.09:
>
>>> Aber: Wieso werden die Platten nicht in der von mir erwarteten
>>> Reihenfolge erkannt?
>>>
>>> SATA1 -> sda
>>> SATA2 -> sdb
>>> SATA3 -> sdc
>
>> verwenden
>
> Doch - das ging mehr als 10 Jahre auch unter Linux recht gut.
>
Mittlerweile ist /dev/sd* ein irgendwas mit vielem Hotplug-Gelumpe, dass
selten irgendwelchen Regeln unterliegt.
BTW: Die PATA-Treiber wurden doch vor einiger Zeit in die libata
geworfen, weswegen eine zeitlang die PATA-Geräte auch /dev/sd* hießen.
Wieso heißen die jetzt seit geraumer Zeit wieder /dev/hd*?
>> - wie du gemerkt hast, weden die beim Booten immer neu
>> durchgezählt, und je nachdem, welche Platten beim Booten in welcher
>> Reihenfolge erkannt werden, hast du diese oder jene Namen.
>
> Aber bei den meisten Rechnern ändert sich weder die Zahl noch die
> Bedeutung der Festplatten ohne Wissen des Besitzers.
>
Was der Besitzer weiß, ist egal: Das OS muss es wissen. Wenn ich eine
USB-Platte dranhänge, und sich dadurch die Bezeichnung der
root-Festplatte verschiebt, kann Linux nicht booten.
> Einzig bei per USB oder Firewire (oder neuerdings eSATA) angebundenen
> Platten ist der Devicename (z.B. /dev/sdc) nicht so hilfreich; da hilft
> "LABEL" viel eher als die Eigenmächtigkeit von "udev".
>
Du Witzbold hast vermutlich noch nie in den Quelltext von mount
reingeguckt. Was denkst du, wo mount die Info herbekommt, welche Platte
LABEL=root jetzt genau ist? Rate mal. Hint: Der Kernel ist es nur
indirekt.
Also wettere nicht immer gegen udev, als hättest du Ahnung.
> Viele Gruesse
> Helmut
>
>
Tschö,
Markus
--
Progress (n.): Process through which USENET evolved from smart people in
front of dumb terminals to dumb people in front of smart
terminals.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Christian Baer
>> Du solltest ganz grunds�tzlich nicht den Namensraum /dev/sd*
>> verwenden
> Doch - das ging mehr als 10 Jahre auch unter Linux recht gut.
Nicht nur unter Linux hat das gut funktioniert. Unter FreeBSD z.B.
konnte man die Devicenamen auch statisch vergeben. Dann war die 3.
ata-Platte (das hei�t secondary master) immer ad2, egal ob ad1 nun
eingebaut war oder nicht. Dummer war nur, da� diese Option in den Kernel
eincompiliert werden mu�te und im Standardkernel nicht dabei war.
>> - wie du gemerkt hast, weden die beim Booten immer neu
>> durchgez�hlt, und je nachdem, welche Platten beim Booten in welcher
>> Reihenfolge erkannt werden, hast du diese oder jene Namen.
> Aber bei den meisten Rechnern �ndert sich weder die Zahl noch die
> Bedeutung der Festplatten ohne Wissen des Besitzers.
Ohne Wissen vielleicht nicht. Aber eine kaputte Platte in der Mitte kann
im gegebenen Fall schon eine gewisse Sauerei anrichten.
> Einzig bei per USB oder Firewire (oder neuerdings eSATA) angebundenen
> Platten ist der Devicename (z.B. /dev/sdc) nicht so hilfreich; da hilft
> "LABEL" viel eher als die Eigenm�chtigkeit von "udev".
Sehe ich auch so. eSATA ist ja noch vergleichsweise brav. Bei
USB-Massenspeicher sind die Namen praktisch nicht vorhersehbar.
> "Ubuntu" - an African word, meaning "Slackware is too hard for me".
Man kann auch schreiben: "Ubuntu - damit es nicht ein Jahr dauert, bis
man mit dem System arbeiten kann"
Gru�
Christian
--
Ich kam.
Ich ging.
Und ich war da gewesen.
Marc Haber
>Du meintest am 29.12.09:
>> Du solltest ganz grundsätzlich nicht den Namensraum /dev/sd*
>> verwenden
>
>Doch - das ging mehr als 10 Jahre auch unter Linux recht gut.
Wie Du vielleicht weißt, hat sich in dieser Zeit die Hardware
weiterentwickelt, Hotplug ist auch bei Massenspeichern der Regelfall,
und der alte Mechanismus deswegen deutlich fehlerträchtiger als
früher. Deswegen hat man gut funktionierende ALternativen entwickelt.
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
Marc Haber
>BTW: Die PATA-Treiber wurden doch vor einiger Zeit in die libata
>geworfen, weswegen eine zeitlang die PATA-Geräte auch /dev/sd* hießen.
>Wieso heißen die jetzt seit geraumer Zeit wieder /dev/hd*?
Tun sie das? In Kernel 2.6.32.2 jedenfalls nicht. Und hoffentlich
bleibt das so, ich bin's leid, von Hardwaregegebenheiten auf den
Nodenamen schließen zu müssen.
Markus Wichmann
> Markus Wichmann <null...@gmx.net> wrote:
>>BTW: Die PATA-Treiber wurden doch vor einiger Zeit in die libata
>>geworfen, weswegen eine zeitlang die PATA-Geräte auch /dev/sd* hießen.
>>Wieso heißen die jetzt seit geraumer Zeit wieder /dev/hd*?
>
> Tun sie das? In Kernel 2.6.32.2 jedenfalls nicht. Und hoffentlich
> bleibt das so, ich bin's leid, von Hardwaregegebenheiten auf den
> Nodenamen schließen zu müssen.
>
> Grüße
> Marc
>
Ich meine mich zu erinnern, dass ich alle meine Festplatten auf Labels
umgestellt habe, weil irgendwo in der 2.6.20-er Serie des Kernels die
PATA-Treiber in die libata gepresst wurden, weswegen es kein hda mehr
gab, sondern nur noch sda (was aber nicht sein muss, weil eine bestimmte
Treibergruppe vorher noch geladen wird... war es FireWire?). Deswegen
flog im /dev/sd*-Namensraum plötzlich alles, was sich Massenspeicher
nennen konnte, durcheinander und /dev/disk war ein sehr schön geordneter
Ort.
Nebenbei widersprichst du dir ein wenig selbst: Wenn die PATA-Treiber
wirklich in die libata kommen, ist der /dev/sd*-Namensraum ziemlich
nutzlos, was andere Mechanismen (/dev/disk/by-uuid, /dev/disk/by-label)
nötig macht. Und da suchst du dir ja den Namen für den Devnode aus :-)
Sieghard Schicktanz
Du schriebst am Tue, 29 Dec 2009 13:20:52 +0100:
> Du kannst sicherstellen, dass die USB-Platte niemals beim Reboot
> versehentlich noch an ist? Oder dass nicht noch ein USB-Stick steckt?
Wozu mï¿œsste das denn sichergestellt werden?
> Jetzt komm mir nicht mit "dann sorge ich eben mit selbstgeschriebenen
> Skripten und modprobe-Regeln dafï¿œr, dass usb_storage garantiert immer
> erst zum Schluss geladen wird".
usb_storage _wird_ normal erst nach den Plattentreibern geladen.
Mal davon abgesehen, daￜ es sowieso Unsinn ist, fￜr ein Gerￜt, das nur
optional verwendet wird, schon beim Systemstart die Treiber zu laden -
das heiï¿œt hier, schon in der initrd. Die initrd sollte nur die fï¿œr den
Start nￜtigsten Treiber enthalten, damit sie nicht unsinnig groￜ wird.
(Jedenfalls ist es totaler Blï¿œdsinn - nichtsdestotrotz von den meisten
Distributionen so praktiziert - sogar schon die Sound-Treiber in der initrd
zu laden.)
> Eben. Und da sich interne und externe SATA-Platten nicht unterscheiden
> lassen, braucht man eben einen solchen Mechanismus fï¿œr alle Platten.
Nachdem SATA ja mit den Mehrfachanschlￜssen Schluￜ gemacht hat und die
Controller jeweils eine eigene "Bus-Nummer" haben, sollte das eigentlich
kein Problem sein. Alle Controller sollten immer dieselben Kennungen
zugewiesen bekommen, wodurch eine konsistente Initialisierung
sichergestellt ist (wￜre?) - bei expliziten ￜnderungen weiￜ der Benutzer ja
(hoffentlich), daￜ (und wie) er das passend einzustellen hat.
> > da hilft "LABEL" viel eher als die Eigenmï¿œchtigkeit von "udev".
>
> Kann man verwenden, manchmal ist aber die Hardwarebezeichnung ein
> besseres Kriterium als der Datentrï¿œgername.
Manchmal aber auch eher nicht - da kommt es immer auf die Verwendung an.
Besonders be ider Systemplatte kann ein Mount per Hardwarebezeichnung (oder
gar der "tollen" UUID) bei Austausch oder Neuinstallation recht
"interessante Effekte" produzieren... ;->
--
(Weitergabe von Adressdaten, Telefonnummern u.ￜ. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ï¿œhnlichem)
-----------------------------------------------------------
Mit freundlichen Grￜￜen, S. Schicktanz
-----------------------------------------------------------
Henning Paul
> Markus Wichmann <null...@gmx.net> wrote:
>>BTW: Die PATA-Treiber wurden doch vor einiger Zeit in die libata
>>geworfen, weswegen eine zeitlang die PATA-Geräte auch /dev/sd* hießen.
>>Wieso heißen die jetzt seit geraumer Zeit wieder /dev/hd*?
>
> Tun sie das? In Kernel 2.6.32.2 jedenfalls nicht.
Tun sie auch generell nicht. Es kann allerdings aber auch Situationen geben,
in denen noch der alte IDE-Treiber verwendet werden muss, weil der libata-
Treiber bspw. einen Bug hat.
Gruß
Henning
--
henning paul home: http://home.arcor.de/henning.paul
PM: henni...@gmx.de , ICQ: 111044613
Henning Paul
> Du schriebst am Tue, 29 Dec 2009 13:20:52 +0100:
>
>> Du kannst sicherstellen, dass die USB-Platte niemals beim Reboot
>> versehentlich noch an ist? Oder dass nicht noch ein USB-Stick steckt?
>
> Wozu müsste das denn sichergestellt werden?
Damit sich die Bezeichnung der Root-Platte nicht ändert.
>> Jetzt komm mir nicht mit "dann sorge ich eben mit selbstgeschriebenen
>> Skripten und modprobe-Regeln dafür, dass usb_storage garantiert immer
>> erst zum Schluss geladen wird".
>
> usb_storage _wird_ normal erst nach den Plattentreibern geladen.
Nö. Gerade erst gestern bei Ubuntu gesehen.
> Mal davon abgesehen, daß es sowieso Unsinn ist, für ein Gerät, das nur
> optional verwendet wird, schon beim Systemstart die Treiber zu laden -
> das heißt hier, schon in der initrd. Die initrd sollte nur die für den
> Start nötigsten Treiber enthalten, damit sie nicht unsinnig groß wird.
Um mit derselben initrd bspw. auch den Boot von auf USB-Platten oder -Sticks
installierten Systemen ermöglichen zu können, muss die initrd auch die USB-
Treiber enthalten.
> (Jedenfalls ist es totaler Blödsinn - nichtsdestotrotz von den meisten
> Distributionen so praktiziert - sogar schon die Sound-Treiber in der
> initrd zu laden.)
Sound ist mir noch nicht untergekommen, Netzwerk schon, damit man auch mal
spontan von einem NFS-Root booten kann.
>> Eben. Und da sich interne und externe SATA-Platten nicht unterscheiden
>> lassen, braucht man eben einen solchen Mechanismus für alle Platten.
>
> Nachdem SATA ja mit den Mehrfachanschlüssen Schluß gemacht hat und die
> Controller jeweils eine eigene "Bus-Nummer" haben, sollte das eigentlich
> kein Problem sein.
Ähem, Port Multiplier existieren...
> Alle Controller sollten immer dieselben Kennungen
> zugewiesen bekommen, wodurch eine konsistente Initialisierung
> sichergestellt ist (wäre?) - bei expliziten Änderungen weiß der Benutzer
> ja (hoffentlich), daß (und wie) er das passend einzustellen hat
Jetzt wird ja schon in der PCI-Device-/Busreihenfolge numeriert. Wenn dann
aber mal ein Device mittendrin fehlt, gehts schief.
Natürlich könnte man sich mit Hilfe von udev einen Symlink nach Solaris-
Vorbild bauen, /dev/c0d0t0 o.ä., wo sich dann direkt Controller-, Bus- und
Targetnummern (für den USB-Kartenleser dann auch noch LUNs) direkt ablesen
lassen. Aber dafür ist dann udev die Abhilfe und nicht etwa der Verursacher
des Problems, wie hier manche gerne zetern...
Sieghard Schicktanz
Du schriebst am Wed, 30 Dec 2009 08:23:21 +0100:
Hoppla, das hï¿œtt' ich jetzt fast ï¿œbersehen...
> Damit sich die Bezeichnung der Root-Platte nicht ï¿œndert.
Das sicherzustellen ist eigentlich Aufgabe des Systems.
> > usb_storage _wird_ normal erst nach den Plattentreibern geladen.
>
> Nￜ. Gerade erst gestern bei Ubuntu gesehen.
Ich schrieb "normal" - sowas sehe ich _nicht_ als normal an. In der - mM -
immer noch ï¿œberwiegenden Mehrzahl der Fï¿œlle werden Computer immer noch von
Festplatten gestartet, jedenfalls von was eingebautem, das so angesprochen
wird. _Nicht_ ï¿œber USB.
Und wenn ￜber USB, dann weiￜ das in der Regel der Betreiber und kann das
entsprechend einrichten.
> > Mal davon abgesehen, daￜ es sowieso Unsinn ist, fￜr ein Gerￜt, das nur
> > optional verwendet wird, schon beim Systemstart die Treiber zu laden -
...
> Um mit derselben initrd bspw. auch den Boot von auf USB-Platten oder
> -Sticks installierten Systemen ermï¿œglichen zu kï¿œnnen, muss die initrd
> auch die USB- Treiber enthalten.
Schï¿œn, und was spricht dann dagegegen, den fï¿œr den _Ausnahmefall_ nï¿œtigen
Treiber nachrangig zu laden? Hat Linux etwa Probleme, von sdf7 oder sowas
zu booten? Mir zumindest ist sowas nicht bekannt.
> > (Jedenfalls ist es totaler Blï¿œdsinn - nichtsdestotrotz von den meisten
> > Distributionen so praktiziert - sogar schon die Sound-Treiber in der
> > initrd zu laden.)
>
> Sound ist mir noch nicht untergekommen, Netzwerk schon, damit man auch
> mal spontan von einem NFS-Root booten kann.
Auch Netzwerkboot ist nachrangig; nￜtzlich kann er schon sein - nur muￜ der
dann vorher schon eingerichtet sein; "mal eben spontan" dï¿œrfte in den
seltensten Fï¿œllen gehen.
Doch, Sound hab' ich AFAIR auch schon gesehen; bei SuSi evtl., oder sowas,
oder evtl. auch Fedora oder Mandriva - es ist schon einige Zeit her, daￜ
ich einige Distributionen zum "Umstieg" ausprobiert hatte.
> > Nachdem SATA ja mit den Mehrfachanschlￜssen Schluￜ gemacht hat und die
> > Controller jeweils eine eigene "Bus-Nummer" haben, sollte das eigentlich
> > kein Problem sein.
>
> ï¿œhem, Port Multiplier existieren...
Ja, und? ï¿œndern sich damit etwa die Zuordnungen der _internen_ Controller?
Wenn das der Fall ist (weiￜ ich nicht, hab' ich nicht), dann ist das System
mM fehlkonstruiert. Meinetwegen mag sich so'n Ding irgendwohin plazieren,
aber die _fest_ eingebauten Kennungen haben auch fest zu bleiben.
Daￜ sich die von den System-Verwaltungsfunktionen (u.a. udev) daraus
abgeleiteten Kennungen dann immer noch ï¿œndern kï¿œnnen, ist mM ebenfalls ein
prinzipieller Design-Fehler.
BTW, warum gibt es eigentlich _keine_ Device-Knoten, die die
Hardware-Zuordnung im Gerï¿œt wiederspiegeln? Es gibt welche, die die Platten
identifizieren, die nach ggfs. vorhandenen Labels gehen, und die die
(flï¿œchtigen) UUIDs benutzen - aber keine, die die Bus-Kennungen verwenden.
Das wï¿œre doch eigentlich viel sinnvoller; dann wï¿œrde auch bei einem
Plattentausch die Zuordnung erhalten bleiben und das System bliebe
boot-fï¿œhig. ?
(Bei mir hat der IDE-Controller die Bus-Id "00:02.5" - ein Device-Knoten ￜ
la "/dev/disk/by-busid/00_02.5.1.1" fï¿œr die erste Partition der ersten
Platte da dran wï¿œre eindeutig und unabhï¿œngig von allen Einrichtungs-
Imponderabilien. Und weil der auf der Hauptplatine sitzt, ï¿œndert nichmal
das Einstecken oder 'rausnehmen einer PCI-Karte da was dran...)
> Jetzt wird ja schon in der PCI-Device-/Busreihenfolge numeriert. Wenn
> dann aber mal ein Device mittendrin fehlt, gehts schief.
Wenn _zusï¿œtzlich_ und _unabhï¿œngig_ von den "eingebauten" Kennungen
"enumeriert" ( >-I ) wird, dann sicher. Wenn die Gerï¿œte-Kennungen oder Bus-
Ids benutzt wï¿œrden, wï¿œre das nicht der Fall.
> Natï¿œrlich kï¿œnnte man sich mit Hilfe von udev einen Symlink nach Solaris-
> Vorbild bauen, /dev/c0d0t0 o.ￜ., wo sich dann direkt Controller-, Bus-
Tja, das wurde ja durch udev "obsolet" gemacht - das alte devfs hatte das.
> und Targetnummern (fï¿œr den USB-Kartenleser dann auch noch LUNs) direkt
> ablesen lassen. Aber dafï¿œr ist dann udev die Abhilfe und nicht etwa der
> Verursacher des Problems, wie hier manche gerne zetern...
Naja, udev ist (u.a.) eine Abhilfe fï¿œr ein Problem, das erst dadurch
geschaffen wurde. Es folgt ganz zwanglos dem Leitspruch fï¿œr den
Computereinsatz:
"Der Computer erleichert einem viele Arbeiten, die man ohne ihn ï¿œberhaupt
nicht hï¿œtte"...
Diedrich Ehlerding
> Ich schrieb "normal" - sowas sehe ich nicht als normal an. In der - mM -
> immer noch überwiegenden Mehrzahl der Fälle werden Computer immer noch
> von Festplatten gestartet, jedenfalls von was eingebautem, das so
> angesprochen wird. Nicht über USB.
[...]
> Schön, und was spricht dann dagegegen, den für den Ausnahmefall nötigen
> Treiber nachrangig zu laden? Hat Linux etwa Probleme, von sdf7 oder sowas
> zu booten? Mir zumindest ist sowas nicht bekannt.
[...]
> Auch Netzwerkboot ist nachrangig; nützlich kann er schon sein - nur muß
> der dann vorher schon eingerichtet sein; "mal eben spontan" dürfte in den
> seltensten Fällen gehen.
Rechnen musst du aber sehr wohl damit, dass der Distributionskernel scsi-,
sata-, auch USB- und Netzwerktreiber in die initrd packt, und rechnen
musst du damit, dir nicht bewusst zu sein, in welcher Reihenfolge er was
lädt. Vor kurzem beobachtet: ein etzwas älteres Debian mit externen
Fibrechannelcontrollern nachgerüstet, alles läuft, Fibrechannelkabel
angestöpselt , rebootet, nix geht mehr ... eben aus genau diesem Grunde;
eine der externen Platten hieß nun sda. Kabel raus, reboot, geht
wieder ...
Kurz: jeder BUchse deines Rechners, an der eine externe Platte hängen
könnte, bringt potentiell deine sd-Knoten durcheinander.
>> > Nachdem SATA ja mit den Mehrfachanschlüssen Schluß gemacht hat und die
>> > Controller jeweils eine eigene "Bus-Nummer" haben, sollte das
>> > eigentlich kein Problem sein.
>>
>> Ähem, Port Multiplier existieren...
>
> Ja, und? Ändern sich damit etwa die Zuordnungen der internen Controller?
Die sd-Namen bleiben dennoch nicht gleich. Wenn deine interne Platte an
Port 2 steckt und die externe dann an Port 1 ...
> BTW, warum gibt es eigentlich keine Device-Knoten, die die
> Hardware-Zuordnung im Gerät wiederspiegeln? Es gibt welche, die die
> Platten identifizieren, die nach ggfs. vorhandenen Labels gehen, und die
> die (flüchtigen) UUIDs benutzen
Wenn du mit irgendwelchen Controller- oder Portnummern arbeiten willst,
bist du bei /dev/disk/by-path - das ist aber auch udev.
Bei mir gibt es
/dev/disk/by-id - die Identifikation der Platte bzw. der LUN des
Raidcontrollers;
/dev/disk/by-label - das Filesystemlabel
/dev/disk/by-uuid - die Filesystem-UUID
/dev/disk/by-path - BUs- und Hardwareeinbauplatz
Was meinst du also mit "flüchtig"? Die Platten-ID wechselt beim
Plattentausch, die Filesystem-UUID und Label beim mkfs, und wenn du
Probleme mit den PCI-steckplätzen deines Rechners vermutest und externe
Controller auf einen anderen Einbauplatz steckst, ist "by-path" auch
anders.
Diedrich
Sieghard Schicktanz
Du schriebst am Thu, 31 Dec 2009 07:28:56 +0100:
> > Ich schrieb "normal" - sowas sehe ich nicht als normal an. In der - mM -
> > immer noch ï¿œberwiegenden Mehrzahl der Fï¿œlle werden Computer immer noch
> > von Festplatten gestartet, jedenfalls von was eingebautem, das so
...
> Rechnen musst du aber sehr wohl damit, dass der Distributionskernel scsi-,
> sata-, auch USB- und Netzwerktreiber in die initrd packt, und rechnen
Leider ja, wenigstens bei vielen Distributionen. Bei "meiner" wird jeweils
eine angepasste inird gebaut; daneben gibt's dann auch noch eine
"vollstï¿œndige" mit allen (un-) mï¿œglichen Treibern.
> musst du damit, dir nicht bewusst zu sein, in welcher Reihenfolge er was
Das ist schlecht - kann man da nicht nachschauen?
> lï¿œdt. Vor kurzem beobachtet: ein etzwas ï¿œlteres Debian mit externen
> Fibrechannelcontrollern nachgerï¿œstet, alles lï¿œuft, Fibrechannelkabel
> angestï¿œpselt , rebootet, nix geht mehr ... eben aus genau diesem Grunde;
> eine der externen Platten hieￜ nun sda. Kabel raus, reboot, geht
Jaaaa... _das_ ist aber eine andere Baustelle - die Zuordnung der Gerï¿œte-
Namen zu den Gerï¿œten. Wenn die willkï¿œrlich ist, dann ist ein Durcheinander
eben inbegriffen (da gab'S doch mal so 'nen schï¿œnen Spruch drï¿œber,
allerdings fï¿œr Windows - aber Linux eifert dem ja recht heftig nach...
Bug-Compatibility?)
> Kurz: jeder BUchse deines Rechners, an der eine externe Platte hï¿œngen
> kï¿œnnte, bringt potentiell deine sd-Knoten durcheinander.
Und das ist ein prinzipieller Fehler im System.
> > Ja, und? ï¿œndern sich damit etwa die Zuordnungen der internen Controller?
>
> Die sd-Namen bleiben dennoch nicht gleich. Wenn deine interne Platte an
> Port 2 steckt und die externe dann an Port 1 ...
Dann sollte trotzdem die interne (z.B.) sdb (Nr. 2) heiï¿œen und die externe
sda (Nr. 1), und dasselbe fï¿œr die interne, wenn extern fehlt. Bei SCSI
geht's ja auch - aber auch da brauchte's erstmal lange Zeit des Wehklagens
der Betroffenen, bevor das endlich fest mit den Ids verkoppelt wurde. Mit
der Hinzunahme der IDE-Laufwerke gibt's denselben Schmarrn jetzt wieder...
> > BTW, warum gibt es eigentlich keine Device-Knoten, die die
> > Hardware-Zuordnung im Gerï¿œt wiederspiegeln? Es gibt welche, die die
...
> Wenn du mit irgendwelchen Controller- oder Portnummern arbeiten willst,
> bist du bei /dev/disk/by-path - das ist aber auch udev.
Ich hatte mir auch eingebildet, daￜ es sowas geben sollte - ich finde es
aber bei meiner Kiste (udev 146-2) nicht (mehr?)! Ist das weggefallen?
> Bei mir gibt es
...
> /dev/disk/by-path - BUs- und Hardwareeinbauplatz
Interessant... Welche udev-Version?
> Was meinst du also mit "flï¿œchtig"? Die Platten-ID wechselt beim
> Plattentausch, die Filesystem-UUID und Label beim mkfs, und wenn du
Genau das.
> Probleme mit den PCI-steckplï¿œtzen deines Rechners vermutest und externe
> Controller auf einen anderen Einbauplatz steckst, ist "by-path" auch
> anders.
Dann bin ich ja auch darauf vorbereitet (sollte es zumindest sein). Das gilt
ja auch dann, wenn ich mein System z.B. auf eine andere, zusï¿œtzlich
angeschlossene Platte umverlagere.
Aber wenn ich eine neue Platte _als Ersatz_ fï¿œr die alte einbaue, weil die
kaputtgegangen oder zu klein geworden ist, sollte das nicht den Systemstart
verhindern, wie es derzeit immer wieder vorkommt (es gab darï¿œber hier schon
lï¿œngere Diskussionen).
"by-path" wï¿œre hier evtl. eine Abhilfe (mangels Verfï¿œgbarkeit kann ich
grade nicht feststellen, ob das tatsￜchlich hￜlfe), aber es mￜￜte dann auch
_benutzt_ werden, anstelle der %&/(=% UUIDs, die grade so beliebt sind.
Henning Paul
>> Bei mir gibt es
> ...
>> /dev/disk/by-path - BUs- und Hardwareeinbauplatz
>
> Interessant... Welche udev-Version?
Das ist keine Frage der udev-Version, sondern der udev-Konfiguration, die
distributionabhängig ist. Das meinte ich damit, dass man sich udev-Regeln
bauen kann, die die Solaris-Notation nachbilden.
Sieghard Schicktanz
Du schriebst am Fri, 01 Jan 2010 14:48:04 +0100:
> >> Bei mir gibt es
> > ...
> >> /dev/disk/by-path - BUs- und Hardwareeinbauplatz
> >
> > Interessant... Welche udev-Version?
>
> Das ist keine Frage der udev-Version, sondern der udev-Konfiguration, die
Schien mir aber so, weil AFAIR das auch bei mir mal existiert hat...
> distributionabhï¿œngig ist. Das meinte ich damit, dass man sich udev-Regeln
> bauen kann, die die Solaris-Notation nachbilden.
Daￜ man da Regeln bauen kann, habe ich ja nicht bestritten. Daￜ das
distributionsabhï¿œngig ist, macht die Sache etwas unï¿œbersichtlich, sozusagen.
Ich habe ï¿œbrigens mal bei meinem System nachgeschaut, da _gibt_ es
interessanterweise solche Regeln - ebenso interessanterweise werden die
aber nicht ausgefï¿œhrt, d.h. die links nicht angelegt. Entweder sind die
Voraussetzungen dafï¿œr nicht gegeben (so genau habe ich das noch nicht
analysiert) oder die werden aus einem anderen Grund ï¿œbergangen (die udev-
Syntax kennt ja den angeblich gefï¿œhrlichsten Befehl der Programmierung, das
"goto"...).
Gut, ich brauch' das vorerst nicht, da werd' ich jetzt nicht enorm viel
Sucherei 'reinstecken, aber wundern tu' ich mich da schon bisserl...
Trotzdem wï¿œre es mM sinnvoll, gleich die Grundstruktur der Gerï¿œte-Knoten-
Bezeichnungen eindeutig zu machen, anstatt dann nachtrï¿œglich mit vielen
Heftpflastern meistens brauchbare Korrekturen anzubringen. So ist's eher 'n
Flickerlteppich.
Marc Haber
>(Jedenfalls ist es totaler Blödsinn - nichtsdestotrotz von den meisten
>Distributionen so praktiziert - sogar schon die Sound-Treiber in der initrd
>zu laden.)
Das ist vermutlich zuverlässiger als auch noch eine (ggf. falsche)
Liste von Treibern mitzuführen, die man zum Bootzeitpunkt _wirklich_
braucht.
Marc Haber
>Nebenbei widersprichst du dir ein wenig selbst: Wenn die PATA-Treiber
>wirklich in die libata kommen, ist der /dev/sd*-Namensraum ziemlich
>nutzlos,
Ich brauch sowas eigentlich nur im Rescuesystem, und da sitzt mir das
alte "sda" immer noch lockerer als das neue Devicenodezeugs.
Andreas Pesch
> Hallo, Diedrich,
>
> Du meintest am 29.12.09:
>
>> - wie du gemerkt hast, weden die beim Booten immer neu
>> durchgezählt, und je nachdem, welche Platten beim Booten in welcher
>> Reihenfolge erkannt werden, hast du diese oder jene Namen.
Nenene, da hast Du mich falsch verstanden!
Beim booten wird immer die gleiche Reihenfolge gefunden und auch im Linux
ist es immer die gleiche Reihenfolge!
Meine FRage war, warum nicht die SATA-Reihenfolge auch, wie von mir
erwartet, die Reihenfolge der Devices in Linux ergibt:
SATA1 -> sda
SATA2 -> sdb
SATA3 -> sdc
Alles andere ist kein Problem, kommt immer gleich an und funktioniert,
nachdem ich die Mountdevices angepasst habe.
Frohes neues Jahr und schöne Grüße!
Andreas
Diedrich Ehlerding
>> musst du damit, dir nicht bewusst zu sein, in welcher Reihenfolge er was
>
> Das ist schlecht - kann man da nicht nachschauen?
Nachschauen allein nützt nix, denn ...
>
>> lädt. Vor kurzem beobachtet: ein etzwas älteres Debian mit externen
>> Fibrechannelcontrollern nachgerüstet, alles läuft, Fibrechannelkabel
>> angestöpselt , rebootet, nix geht mehr ... eben aus genau diesem Grunde;
>> eine der externen Platten hieß nun sda. Kabel raus, reboot, geht
... hier hatte sich die Softwarekonfiguration nicht geändert, und auch die
Serverhardware nicht. Der Server hatte schon immer einen internen
Raidcontroller, irgendein LSI, und einen externen Controller (QLogic).
Solange an den externen Ports des QLogic nix angeschlossen war, hieß die
interne Platte /dev/sda. Wie sich nach Anstöpseln der exterenen Platten
aber herausstellte, hatte das System _schon_ _immer_ den Treiber für den
Controller mit externen Ports als ersten geladen - nur waren da nie
Platten zu sehen gewesen. Nun bootete das System, aus initrd oder
initramfs oder woher auch immer wurde der Modul für den externen
Controller, qla2xxx, geladen, fand dort eine Platte, die er sda nannte -
nur war dort eben kein Root-Filesystem. Also bootete das System nicht.
Folgerung: es reicht nicht aus, zu wissen, in welcher Reihenfolge die
Treiber geladen werden, wenn externe Kabel im Spiel sind.
> Jaaaa... das ist aber eine andere Baustelle - die Zuordnung der Geräte-
> Namen zu den Geräten.
Nein, genau das _ist_ die Baustelle, um die es geht. Wenn du vorher dein
root-Filesystem /dev/sda1 genannt hast, die Platte jetzt aber /dev/sdb1
heißt, weil eine andere Platte /dev/sda genannt wird, hast du verloren,
wenn du in der fstab auf /dev/sda5 verweist und nicht auf irgendeinen
rebootfesten Namen.
>> Kurz: jeder BUchse deines Rechners, an der eine externe Platte hängen
>> könnte, bringt potentiell deine sd-Knoten durcheinander.
>
> Und das ist ein prinzipieller Fehler im System.
Nein. Es bedeutet nur, dass man sich nicht darauf verlassen darf, dass
diese Namen rebootfest sind. Und dagegen hilft, auch wenn es Helmut H.
nicht gefällt, udev - damit bekommt man rebootfeste Namen.
>> Die sd-Namen bleiben dennoch nicht gleich. Wenn deine interne Platte an
>> Port 2 steckt und die externe dann an Port 1 ...
>
> Dann sollte trotzdem die interne (z.B.) sdb (Nr. 2) heißen und die
> externe sda (Nr. 1), und dasselbe für die interne, wenn extern fehlt.
Natürlich hat die interne Platte auch hinterher einen sd-irgendwas-namen -
nur hilft das nicht, weildu nicht weißt, welchen. /dev/sda in der fstab
ist immer dann bodenloser Leichtsinn, wenn es sich um Maschinen mit
externen Ports für Platten handelt.
>> > BTW, warum gibt es eigentlich keine Device-Knoten, die die
>> > Hardware-Zuordnung im Gerät wiederspiegeln? Es gibt welche, die die
> ...
>> Wenn du mit irgendwelchen Controller- oder Portnummern arbeiten willst,
>> bist du bei /dev/disk/by-path - das ist aber auch udev.
>
> Ich hatte mir auch eingebildet, daß es sowas geben sollte - ich finde es
> aber bei meiner Kiste (udev 146-2) nicht (mehr?)! Ist das weggefallen?
Diverse SuSEn (10.irgendwas, 11.irgendwas, SLES10 und SLES11) haben das.
Andreas Pesch
> Andreas Pesch schrieb:
>> Aber: Wieso werden die Platten nicht in der von mir erwarteten
>> Reihenfolge erkannt?
>>
> Falsche Boardbeschriftung?
Daran hatte ich auch schon gedacht bzw. an falsche Interpretation der
Beschriftung meinerseits. Tauschen der Anschlüsse hat aber nur bei der
Anzeige beim booten etwas gebracht, die Platten waren schön getauscht,
wurden aber immer noch in der gleichen Reihenfolge von Linux erkannt, wie
vorher.
Diese war dann aber in diesem Fall so, wie von mir erwartet! ;-O
Henning Paul
> Daran hatte ich auch schon gedacht bzw. an falsche Interpretation der
> Beschriftung meinerseits. Tauschen der Anschlüsse hat aber nur bei der
> Anzeige beim booten etwas gebracht, die Platten waren schön getauscht,
> wurden aber immer noch in der gleichen Reihenfolge von Linux erkannt, wie
> vorher.
Dann brauchen die Platten wohl einfach unterschiedlich lange, sich nach
einem Busreset zu melden. WIMRE versucht der Treiber durch gleichzeitige
Initialisierung Zeit zu sparen. Wenn dann eine Platte etwas länger braucht,
wird sie erst später als die anderen enumeriert.
Helmut Hullen
Du meintest am 29.12.09:
> Mittlerweile ist /dev/sd* ein irgendwas mit vielem Hotplug-Gelumpe,
> dass selten irgendwelchen Regeln unterliegt.
> BTW: Die PATA-Treiber wurden doch vor einiger Zeit in die libata
> geworfen, weswegen eine zeitlang die PATA-Ger�te auch /dev/sd*
> hie�en. Wieso hei�en die jetzt seit geraumer Zeit wieder /dev/hd*?
"Das kommt drauf an!" - eben habe ich mal wieder Slackware 13
installiert (Kernel 2.6.29.6): P-ATA f�hrt zu /dev/hd*. Ist bei "runt"
immer noch genauso. D�rfte am ehesten von der Kernel-Konfiguration
abh�ngen - und die ist allemal von Distribution zu Distribution
verschieden.
Diedrich Ehlerding
>>> - wie du gemerkt hast, weden die beim Booten immer neu
>>> durchgezählt, und je nachdem, welche Platten beim Booten in welcher
>>> Reihenfolge erkannt werden, hast du diese oder jene Namen.
>
>
> Nenene, da hast Du mich falsch verstanden!
>
> Beim booten wird immer die gleiche Reihenfolge gefunden und auch im Linux
> ist es immer die gleiche Reihenfolge!
>
> Meine FRage war, warum nicht die SATA-Reihenfolge auch, wie von mir
> erwartet, die Reihenfolge der Devices in Linux ergibt:
>
> SATA1 -> sda
> SATA2 -> sdb
> SATA3 -> sdc
Ich habe schon verstanden, dass du in erster Linie erwartet hättest, dass
die Platte an Port2 als zweite und nicht als dritte erkannt wird.
Möglicherweise sind einfach die Ports flasch beschriftet ... gibt es bei
dir /dev/disk/by-path, und was steht da drin? (ls -l)? Was sagen die
Boot-Messages zu den Platten?
Selbst wenn du jedoch die Reihenfolge kennst, in der die Platten dann
erkannt werden, wenn drei Platten abgestöpselt sind (also selbst wenn es
so wäre wie du erwartest), dann würde das System dann, wenn du die als sdb
erkannte Platte rausnimmst und dann rebootest, das System die beiden
verbliebenen nicht als sda und sdc erkennen, sondern als sda und sdb; d.h.
wenn die Platte, die vorher als zweite erkannt worden war, kaputtgeht,
wird die vormals dritte dann als zweite erkannt! Die erste scsi-Platte,
die erkannt wird, heißt in dieser Session sda, die zweite heißt sdb - ganz
egal, wo sie steckt. sd-Namen sind *nicht* rebootfest!
Deshalb nochmal: vergiss die sd-Namen, insbesondere wenn dein Rechner
irgendeine Möglichkeit hat, externe Platten anzuschließen (dazu gehören
auch usb-Sticks, Speicherkarten aus Kameras usw., firewire,
eSATA-Ports, ...)
Sieghard Schicktanz
Du schriebst am Sat, 02 Jan 2010 16:26:26 +0100:
> > Das ist schlecht - kann man da nicht nachschauen?
>
> Nachschauen allein nï¿œtzt nix, denn ...
...
> ... hier hatte sich die Softwarekonfiguration nicht geï¿œndert, und auch die
> Serverhardware nicht. Der Server hatte schon immer einen internen
> > Jaaaa... das ist aber eine andere Baustelle - die Zuordnung der Gerï¿œte-
> > Namen zu den Gerï¿œten.
>
> Nein, genau das _ist_ die Baustelle, um die es geht. Wenn du vorher dein
Neinenein, das ist schon die Baustelle, die ich meine - die Zuordnung der
Kennungen nach den _gerade gefundenen_ Gerï¿œten, nicht nach den physisch
vorgesehenen. Warum muￜ denn die erste _gefundene_ Platte "sda" heiￜen,
wenn davor noch zwei andere hï¿œngen kï¿œnnten? Die kï¿œnnte dann doch auch "sdc"
sein, dann wï¿œrde das System genauso laufen, aber _wenn_ dann eine andere
eingebaut wï¿œrde, bliebe die so erhalten und es gï¿œbe keinen ï¿œrger. Bei SCSI
ging das doch auch, daￜ die Kennungen nach Bus-Id vergeben wurden. Erst
seit der Hinzunahme von (S-) ATA geht das Chaos wieder wie vormals los.
> >> Kurz: jeder BUchse deines Rechners, an der eine externe Platte hï¿œngen
> >> kï¿œnnte, bringt potentiell deine sd-Knoten durcheinander.
> >
> > Und das ist ein prinzipieller Fehler im System.
>
> Nein. Es bedeutet nur, dass man sich nicht darauf verlassen darf, dass
> diese Namen rebootfest sind. Und dagegen hilft, auch wenn es Helmut H.
> nicht gefï¿œllt, udev - damit bekommt man rebootfeste Namen.
Ja, eben, das ist ja der Fehler. Es _mￜￜte_ nicht so sein, und zwar _mit_
und _mittels_ udev. Und es war schonmal nicht so. Zuletzt mit dem devfs.
> >> Wenn du mit irgendwelchen Controller- oder Portnummern arbeiten willst,
> >> bist du bei /dev/disk/by-path - das ist aber auch udev.
Ich hab' ja garnichts gegen udev gesagt - und das "by-path" ist ja auch gut
gemeint (wenn es auch bei mir derzeit irgendwie nicht geht); nur, _warum_
muￜ das jetzt unbedingt eine _zusￜtzliche_ "Schicht" sein? Warum nicht
direkt? ("nativ", fï¿œr DAmisch- [Deutsch-Amerikanisch-] Sprachige;)
Sieghard Schicktanz
Du schriebst am Sat, 02 Jan 2010 11:27:48 +0100:
> >(Jedenfalls ist es totaler Blï¿œdsinn - nichtsdestotrotz von den meisten
> >Distributionen so praktiziert - sogar schon die Sound-Treiber in der
> >initrd zu laden.)
>
> Das ist vermutlich zuverlï¿œssiger als auch noch eine (ggf. falsche)
> Liste von Treibern mitzufï¿œhren, die man zum Bootzeitpunkt _wirklich_
> braucht.
Abgesehen davon, daￜ "vermutlich" kein stichhaltiges Argument ist, ist es
definitiv nicht so - fï¿œr eine Installation ist die Notwendigkeit
einzusehen, aber fï¿œr das installierte System sollte eine initrd mit der
wirklich nￜtigen Treiberaustattung gebaut werden, und daￜ das geht, zeigen
diverse Distributionen, die das auch machen ("mein" Arch-linux z.B., auch
wenn man da recht beliebig "aufblasen" kann...).
"Netterweise" liegen bei solchen Systemen, die eine "Allround"-initrd
haben, _dieselben_ Treiber dann ja nochmal im Filesystem 'rum
(/lib/modules), damit man die Treiber auch mal 'rauswerfen und bei spï¿œterem
Bedarf wieder laden kann. Und _wenn_ man das kann, dann werden _diese_
Treiber fï¿œr den Systembetrieb doch sicher nicht zwingend gebraucht?
(Sicher kann es Ausnahmen geben - z.B. ein System, das von USB hochgefahren
und spï¿œter nur noch von Platte betrieben wird - aber das sind wirklich nur
_Ausnahmen_, die eine _Sonder_behandlung rechtfertigen.)
(Im ï¿œbrigen soll es auch Treiber geben, die sich nicht so gut gegenseitig
vertragen, oder die ihre Hardware auch mal falsch zu finden meinen - in dem
Fall hast Du mit der "Universal-initrd" mit Zitronen gehandelt...)
Marc Haber
>Du schriebst am Sat, 02 Jan 2010 11:27:48 +0100:
>> >Distributionen so praktiziert - sogar schon die Sound-Treiber in der
>> >initrd zu laden.)
>>
>> Liste von Treibern mitzuführen, die man zum Bootzeitpunkt _wirklich_
>> braucht.
>
>Abgesehen davon, daß "vermutlich" kein stichhaltiges Argument ist, ist es
>definitiv nicht so - für eine Installation ist die Notwendigkeit
>einzusehen, aber für das installierte System sollte eine initrd mit der
>wirklich nötigen Treiberaustattung gebaut werden, und daß das geht, zeigen
>diverse Distributionen, die das auch machen ("mein" Arch-linux z.B., auch
>wenn man da recht beliebig "aufblasen" kann...).
Und wie macht Arch-Linux das? Wie unterscheidet man zwischen "dieses
Kernelmodul liegt nur rum" und "ich brauche dieses Kernelmodul
unbedingt um mein root-fs einzuhängen"?
Diedrich Ehlerding
>> Nein, genau das ist die Baustelle, um die es geht. Wenn du vorher dein
>
> Neinenein, das ist schon die Baustelle, die ich meine - die Zuordnung der
> Kennungen nach den _gerade gefundenen_ Geräten, nicht nach den physisch
> vorgesehenen. Warum muß denn die erste gefundene Platte "sda" heißen,
> wenn davor noch zwei andere hängen könnten? Die könnte dann doch auch
> "sdc" sein, dann würde das System genauso laufen, aber wenn dann eine
> andere eingebaut würde, bliebe die so erhalten und es gäbe keinen Ärger.
Woher soll das System denn wissen, wieviele Platten da evtl. noch hängen?
Welche Namensräume willst du dafür reservieren? Wieviele Knoten (sda, sdb,
sdc, ...) soll es für diesen Zweck benutzen - 4, weil deine Hardware
gerade 4 steckplätze dafür hat? Und was, wenn morgen ein Mainboard mit 6
oder 8 Steckplätezn kommt? Und was, wenn morgen ein Mainboard mit 2 SATA
und 2 SAS-Steckplätzen kommt, und ich will nur die SAS-Platten benutzen
und sie sda und sdb nennen, du aber nur die SATA-Platten, und auch die
sollen sda und sdb heißen?
Schon hinter einem klassischen SCSI-Controller können 7 targets hängen, und
je nachdem hinter jedem target etliche LUNs, aber wieviele wirklich da
sind, weiß man nicht im Voraus. Raidcontroller teilen die verfügbare
Plattenkapazität zimlich beliebig in logische Platten ein, die dem System
gegenüber dann als scsi-LUNs gegenübertreten. Noch schlimmer ist es mit
externen Raidsystemen und den dort üblichen Fibrechannelnetzwerken, da
können hinter einem Controller bzw. HBA ggf. Hunderte von Platten hängen
(gesehen habe ich schon Server mit 320 sd-Knoten, wobei die 80 PLatten
über 3 Raidsysteme verteilt waren und jede Platte über 4 Wege sichtbar
war; und das Ganze noch dynmaisch veränderbar, d.h., es kamen immer mal
Platten dazu und wieder weg; nein, da kommst du mit den sd-Namen wirklich
nicht mehr weiter ...). Und es ist auch durchaus nicht sicher, dass
interne PLatten (SATA oder auch PATA) unbedingt an erster Stelle stehen
sollen (vielleicht will ja jemand so einen Server von der externen Platte
booten?), und es ist auch nicht klar, dass ein SATA-Controller immer an
erster stelle im System steckt (vielleicht hast du ja mehrere
SATA-Controller, oder SATA, SAS, SCSI, Fibrechannel und wasweißichnoch in
bunter Mischung?).
Martin Schmitz
> Und wie macht Arch-Linux das? Wie unterscheidet man zwischen "dieses
> Kernelmodul liegt nur rum" und "ich brauche dieses Kernelmodul
> unbedingt um mein root-fs einzuhängen"?
Keine Ahnung, wie Arch das macht. Bei Slackware entscheidet das die
intelligenteste Komponente des Systems: der, der die Finger auf der
Tastatur liegen hat. Der erstellt die initrd mit mkinitrd und div.
Parametern, darunter eine Liste der einzubauenden Module. Sehr oft
reicht hier der Treiber für das FS, ggf. noch einer für den
Plattenkontroller.
Für Neulinge gibt es aber auch ein Shell-Skript, das div. Dinge aus
/proc liest und danach einen Vorschlag für 'mkinitrd'-Parameter macht.
Martin
Sieghard Schicktanz
Du schriebst am Sun, 03 Jan 2010 10:16:09 +0100:
> Und wie macht Arch-Linux das? Wie unterscheidet man zwischen "dieses
> Kernelmodul liegt nur rum" und "ich brauche dieses Kernelmodul
> unbedingt um mein root-fs einzuhï¿œngen"?
Eine Mￜglichkeit kￜnnte doch sein, daￜ man die Moduln nimmt, die sowohl fￜr
einen Datentrï¿œgerzugriff taugen als auch gerade im System aktiv sind.
Das kï¿œnnen immer noch zuviele sein, und in Ausnahmefï¿œllen sogar die
falschen - aber in Ausnahmefï¿œllen bin ich durchaus auch zu einem manuellen
Eingriff bereit.
Das _"root-fs"_ wird doch sicher in _jedem_ Fall zum einen eindeutig
bekannt und identifizierbar sein und zum anderen ein geladenes, aktives
Treiber-Modul belegen, oder? (Oder auch nicht, wenn es, wie bei mir, fest
im Kernel steckt. Dann ist auch ein Boot _ganz ohne_ initrd mï¿œglich.)
ï¿œbrigens braucht ja auch der Bootmanager die Information, wo er den Kernel
und die initrd herholen soll, und der Kernel muￜ "wissen", welche Partition
er als root mounten soll, und beide haben ganz unterschiedliche Zï¿œhlweisen.
Da funktionieren Automatismen nur noch fï¿œr ganz einfache Standardfï¿œlle, alles
komplexere braucht sowieso Nachbearbeitung. Also geht's doch wieder zu Fuￜ.
_Eigentlich_ sollte der intelligentere Teil der Kombination aus Computer
und Benutzer ja der letztere sein - aber ich sehe schon auch, daￜ das
inzwischen nicht mehr immer der Fall zu sein scheint... :-<
Sieghard Schicktanz
Du schriebst am Sat, 2 Jan 2010 22:05:07 +0000 (UTC):
> Und welche Platten sind "vorgesehen"? An einem Anschuￜ muￜ ja nicht nur
> eine einzelne Platte mï¿œglich sein, da kï¿œnnte ja eine ganze Reihe von LUs
Ja sicher.
> mï¿œglich sein. Und wenn du das haben willst, dann kannst du ja udev und
> /dev/disk/by-path nehmen.
Kann ich (wie geschrieben) mangels Funktion der entsprechenden Regeln
derzeit nicht (und die anzupassen tue ich mir mangels Notwendigkeit nicht
an), aber prinzipiell hast Du da natï¿œrlich recht, was ich ja auch schon
geschrieben habe. Ich frage mich nur, warum das eine _zusï¿œtzliche_ Schicht
sein mï¿œssen soll.
> Warum sollte es? Warum sollte man diese Logik unbedingt in den Kernel
> einbauen, wenn man ihn dort nicht zwingend braucht und er deswegen
> genausogut im Userspace liegen kann? "by-path" ist nicht unbedingt
> sinnvoller als "by-id" fï¿œr die Adressierung auf Treiberebene.
Woher erfï¿œhrt "der Userspace" die "by-path"-Information?
Naklar, ï¿œber Aufrufe von Treiber-Funktionen, die _wo_ laufen?
Doch nicht etwa im Kernel-Kontext? Oder doch?
Das kommt schon sehr nahe an die Schlagersï¿œngervision von der deutschen
Bï¿œrokratie, die mal den "Antrag auf Erteilung eines Antragsformulars"
besungen hat... (weiï¿œt Du, wer das damals war? ;)
Sieghard Schicktanz
Du schriebst am Sun, 03 Jan 2010 10:11:47 +0100:
> Woher soll das System denn wissen, wieviele Platten da evtl. noch hï¿œngen?
Woher weiￜ es denn die udev-Regel?
> Welche Namensrï¿œume willst du dafï¿œr reservieren? Wieviele Knoten (sda, sdb,
> sdc, ...) soll es fï¿œr diesen Zweck benutzen - 4, weil deine Hardware
> gerade 4 steckplï¿œtze dafï¿œr hat? Und was, wenn morgen ein Mainboard mit 6
Wie war das doch noch mit den PCI-Komponenten - die sollten doch eine
Mï¿œglichkeit enthalten, ihre Fï¿œhigkeiten dem System ohne Benutzerinteraktion
vermelden zu kï¿œnnen; dazu gehï¿œrt(e?) doch _auch_, was da so an Datenquellen
und -Senken damit verbunden ist. Bei USB das gleiche.
Willst Du das ernsthaft nicht _gleich_ nutzen, sondern ersatmal irgendwas
zusammenstopseln, um dann in einem zweiten Gang die _richtige_ Information
zu sammeln und zur Verfï¿œgung zu stellen? Hï¿œrt sich irgendwie nach einem
undurchdachten Grundkonzept an, dem nachtrï¿œglich eine provisorische Schicht
ï¿œbergebï¿œgelt wurde, um die Benutzbarkeit zu verbessern...
> Schon hinter einem klassischen SCSI-Controller kï¿œnnen 7 targets hï¿œngen,
Genau, und die wurden in der letzten Zeit _vor_ udev auch schï¿œn zur
Nummrierung der Gerï¿œte-Knoten benutzt, nachdem es jahrelange Berschwerden
der Benutzer gegeben hatte, daￜ die sequentielle Numerierung immer wieder
zu Problemen fï¿œhrte.
> und je nachdem hinter jedem target etliche LUNs, aber wieviele wirklich da
> sind, weiￜ man nicht im Voraus. Raidcontroller teilen die verfￜgbare
Abersicherdoch weiￜ man, wieviele das sein kￜnnen. Und auch _das_ lￜￜt sich
berï¿œcksichtigen - notfalls eben durch eine Zusatzstelle in der Numerierung.
> (gesehen habe ich schon Server mit 320 sd-Knoten, wobei die 80 PLatten
> ï¿œber 3 Raidsysteme verteilt waren und jede Platte ï¿œber 4 Wege sichtbar
> war; und das Ganze noch dynmaisch verï¿œnderbar, d.h., es kamen immer mal
Und wie stellte sich das RAID dem _Betriebssystem_ dar? Als /dev/sda?
Oder jede einzelne Platte jeder Gruppe einzeln mit jeder einzelnen
Partition? Natï¿œrlich nicht _intern_ im RAID-Controller, sondern fï¿œr das
System, das die Daten nutzen sollte.
> interne PLatten (SATA oder auch PATA) unbedingt an erster Stelle stehen
> sollen (vielleicht will ja jemand so einen Server von der externen Platte
> booten?), und es ist auch nicht klar, dass ein SATA-Controller immer an
_Und_? Dann bootet er halt ausnahmsweise _nicht_ von /dev/sda1, sondern
auch mal von /dev/sdp3 - wo ist das Problem?
(Bei 80 Platten mￜￜte das natￜrlich, laￜ' mal zￜhlen, /dev/sdcc sein, wenn
man die "Spreadsheet"-Zï¿œhlweise ansetzt. Die Partition ist dann natï¿œrlich
wieder eine Nummer dahinter.)
> erster stelle im System steckt (vielleicht hast du ja mehrere
> SATA-Controller, oder SATA, SAS, SCSI, Fibrechannel und wasweiï¿œichnoch in
> bunter Mischung?).
Ich seh' immer noch nicht, wo da das Problem sein soll...
(zumindest das _technische_ Problem.)
Diedrich Ehlerding
>> Woher soll das System denn wissen, wieviele Platten da evtl. noch hängen?
>
> Woher weiß es denn die udev-Regel?
Sie weiß nicht und muss auch nicht wissen, wie viele Platten da
potentiell hängen könnten. Das müsste nur derjenige wissen, der statisch
Namensräume reservieren will.
Die udev-Namen sind symlinks auf die sd-Instanz, die gerade vergeben
wurde. Der rebootfeste udev-Name /dev/disk/by-id/blablubb zeigt heute
auf sdc und morgen auf sdb - d.h. wenn die Platte einen anderen sd-Namen
bekommt, macht das nix, weil der udev-Name so bleibt wie vorher.
>
>> Welche Namensräume willst du dafür reservieren? Wieviele Knoten (sda, sdb,
>> sdc, ...) soll es für diesen Zweck benutzen - 4, weil deine Hardware
>> gerade 4 steckplätze dafür hat? Und was, wenn morgen ein Mainboard mit 6
>
> Wie war das doch noch mit den PCI-Komponenten - die sollten doch eine
> Möglichkeit enthalten, ihre Fähigkeiten dem System ohne Benutzerinteraktion
> vermelden zu können; dazu gehört(e?) doch _auch_, was da so an Datenquellen
> und -Senken damit verbunden ist.
Wenn du Namensräume reservieren willst, musst du nicht für das was
reservieren, was gerade verbunden ist, sondern für das, was potentiell
dranhängen könnte. Im Fibrechannelumfeld können hinter einem HBA im
Extremfall -zig Endgeräte mit je einigen Hundert LUNs, im Extremfall
potentiell je mehreren Tausend LUNs hängen. Mag sein, dass der
HBA-Treiber eine Obergrenze von z.B. 2^15 Devices hat - aber die willst
du nicht alle reservieren; und wenn morgen ein neuer Treiber kommt mit
ner anderen Obergrenze, was tust du dann?
Mit anderen Worten: statisch Namensräume in entsprechender Breite zu
reservieren ist keine übermäßig gute Idee.
(Am Rande: Ich weiß, dass FIbrechannel-Umfeld nix mit Heimanwendung zu
tun hat, aber möchte dennoch zart darauf hinweisen, dass hier nicht nur
die reine Anzahl zum Problem beim Reservieren führt, sondern auch noch
das Thema der "Überstzung" von FC-Protokoll und FC-WWNs in
scsi-Protokoll und scsi-targets; schon der HBA weiß nicht sicher,
welchen WWN (welches Raidsystem) er als ewrstes erkennt und welches als
zweites; d.h. auch hierdurch kann beim Booten bzw. Laden des Moduls die
Reihenfolge der Platten vertauscht sein).
Kurz, die /dev/sd-Namen sind einfach ungeeignet für alle außer sehr
kleinen und sehr statischen Konfigurationen. Oder, wie es auch ein
Redhat-Mensch mal sagte:
| ● 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)
> Bei USB das gleiche.
> Willst Du das ernsthaft nicht _gleich_ nutzen, sondern ersatmal irgendwas
> zusammenstopseln, um dann in einem zweiten Gang die _richtige_ Information
> zu sammeln und zur Verfügung zu stellen? Hört sich irgendwie nach einem
> undurchdachten Grundkonzept an, dem nachträglich eine provisorische Schicht
> übergebügelt wurde, um die Benutzbarkeit zu verbessern...
Reden wir hier darüber, wie man einen Server sinnvoll und sicher
betreiben kann, oder darüber, wie man ihn betrieben können sollte? Wenn
dir das Konzept nicht gefällt, dann entwickle ein anderes, oder mit dem,
das funktioniert.
Natürlich ist hier Linux historisch gewachsen - früher gab es nur die
sd-Namen, und die sind nun einmal nicht rebootfest. Da man rebootfeste
Namen braucht, kann man sich entweder an eindeutien Hardware-IDs
orientieren (das macht udev mit /dev/disk/by-id) oder an Platteninhalten
(LVM, Plattenlabeln, was auchimmer; so macht es auch Windows bei der
Zuordnung von Platten zu Laufwerksbuchstaben anhand der Signatur). Beide
Varianten haben Vorteile und Nachteile - such dir halt eine passende
Variante aus für deinen Einsatzfall.
>> und je nachdem hinter jedem target etliche LUNs, aber wieviele wirklich da
>> sind, weiß man nicht im Voraus. Raidcontroller teilen die verfügbare
>
> Abersicherdoch weiß man, wieviele das sein können.
So? wieviele denn? Zum Beispiel im Falle Fibrechannel können das
potentiell durchaus mehrere Tausend sein (d.h. das Protokoll hate ine
entsprechende Adressbreite), und zwar je PCI-steckplatz (in jedem könnte
ja so ein Fibrechannel-Controller stecken). Natürlich sind die
typischerweise nicht alle vergeben, aber sie können (auch im laufenden
Betrieb) theoretisch alle sichtbar werden. Ach ja, potentiell könnte
jeder möglcihe Fibrechannel-WWN (sowas Ähnliches wie ne MAC-Adresse,
d.h. besteht aus 8 Bytes beliebigen Inhalts) hinter jedem Controller
sichtbar werden ... dann reservier mal schön.
> Und auch _das_ läßt sich
> berücksichtigen - notfalls eben durch eine Zusatzstelle in der Numerierung.
Es steht dir ohne weiteres frei, Deviceknoten à la solaris zu erzeugen.
Bau halt eigene udev-Regeln, oer lies aus /proc und /sys selber aus, wie
/proc/scsi/scsi und /dev/sd* gerade zusammenhängen. Dann bekomnmst du so
eine Notation wie /dev/disk/c#b#t#d#. Dann hättest du eben udev manuell
nacherfunden - was solls also, das gibts ja schon. Siehe
/dev/disk/by-path ...
>> (gesehen habe ich schon Server mit 320 sd-Knoten, wobei die 80 PLatten
>> über 3 Raidsysteme verteilt waren und jede Platte über 4 Wege sichtbar
>> war; und das Ganze noch dynmaisch veränderbar, d.h., es kamen immer mal
>
> Und wie stellte sich das RAID dem _Betriebssystem_ dar? Als /dev/sda?
> Oder jede einzelne Platte jeder Gruppe einzeln mit jeder einzelnen
> Partition? Natürlich nicht _intern_ im RAID-Controller, sondern für das
> System, das die Daten nutzen sollte.
Das Betriebssystem sieht in diesem Falle 320 sd-Knoten (also /dev/sdb
bis /dev/sdcc oder so ähnlich). Zugreifen tut es über die
dm_multipath-Knoten (dm_multipath ersetzt die LInks in /dev/disk/by-id
durch Links auf /dev/dm-###, benutzt aber denselben Namensraum wie
udev). Der Server sieht also 80 Platten in /dev/disk/by-id. Und die
verwendet er - egal wie die sd-Knote heute oder morgen heißen. ER hat
damit einen rebootfesten Namensraum für sehr viele Platten. Und
erfreulicherweise sieht der zweite Server des Clusters diese Platten
automatisch unter exakt genau densselben Namen - egal, ob dieser Server
dieses Raidsystem zuerst scannt und jeder jenes, oder beide in derselben
Reihenfolge; egal ob eine LUN bei diesem Server im laufenden Betrieb
hinzugefügt wurde und deshalb /dev/sdcd heißt oder ob sie beim anderen
server nach Reboot irgendwo anders einsortiert wurde, egal ob dieser
Server eine und jeder zwei interne Platten hat, egal ob dieser oder
jener Server erst die internen und dann die externen Platten scannt oder
umgekehrt.
> Ich seh' immer noch nicht, wo da das Problem sein soll...
> (zumindest das _technische_ Problem.)
Schau einfach mal etwas genauer hin.
Diedrich
Sieghard Schicktanz
Du schriebst am Mon, 04 Jan 2010 11:24:49 +0100:
> > Woher weiￜ es denn die udev-Regel?
>
> Sie weiￜ nicht und muss auch nicht wissen, wie viele Platten da
> potentiell hï¿œngen kï¿œnnten. Das mï¿œsste nur derjenige wissen, der statisch
> Namensrï¿œume reservieren will.
Aha - genau _das_ _macht_ aber doch diese angesprochene udev-Regel.
> Wenn du Namensrï¿œume reservieren willst, musst du nicht fï¿œr das was
> reservieren, was gerade verbunden ist, sondern fï¿œr das, was potentiell
> dranhï¿œngen kï¿œnnte. Im Fibrechannelumfeld kï¿œnnen hinter einem HBA im
Wirklich? Wie kann dann diese udev-Regel _reboot-feste_ Namen fï¿œr die Links
erstellen, wenn das garnicht mï¿œglich ist?
> Extremfall -zig Endgerï¿œte mit je einigen Hundert LUNs, im Extremfall
> potentiell je mehreren Tausend LUNs hï¿œngen. Mag sein, dass der
> HBA-Treiber eine Obergrenze von z.B. 2^15 Devices hat - aber die willst
> du nicht alle reservieren; und wenn morgen ein neuer Treiber kommt mit
> ner anderen Obergrenze, was tust du dann?
Noch'ne Stelle anhï¿œngen, z.B. Wie erzeugst Du eine um eins hï¿œhere Zahl,
wenn Du eine beliebig groï¿œe schon hast? Und wie machst Du das, wenn Du die
grￜￜte gegeben hast, die in die Anzahl Stellen passt, die schon benutzt
sind?
> Mit anderen Worten: statisch Namensrï¿œume in entsprechender Breite zu
> reservieren ist keine ￜbermￜￜig gute Idee.
Aber auch keine ￜbermￜￜig groￜartige Aufgabe, solange die Anzahl der
Namensrï¿œume beschrï¿œnkt bleibt.
> (Am Rande: Ich weiￜ, dass FIbrechannel-Umfeld nix mit Heimanwendung zu
> tun hat, aber mï¿œchte dennoch zart darauf hinweisen, dass hier nicht nur
> die reine Anzahl zum Problem beim Reservieren fï¿œhrt, sondern auch noch
> das Thema der "ï¿œberstzung" von FC-Protokoll und FC-WWNs in
> scsi-Protokoll und scsi-targets; schon der HBA weiￜ nicht sicher,
> welchen WWN (welches Raidsystem) er als ewrstes erkennt und welches als
> zweites; d.h. auch hierdurch kann beim Booten bzw. Laden des Moduls die
> Reihenfolge der Platten vertauscht sein).
Und wie lï¿œst Du _dieses_ Problem reboot-fest?
Wenn das geht, dann geht das immer.
> Kurz, die /dev/sd-Namen sind einfach ungeeignet fï¿œr alle auï¿œer sehr
Warum stellst Du immer auf "die /dev/sd-Namen" ab? Ob die sd<irgendwas>
oder anders heiￜen, ist doch eigentlich egal. Ich finde es bloￜ - sorry -
bescheuert, daￜ die _als Grundlage_ erzeugten Namen wild
durcheinanderlaufen kï¿œnnen und erst mit einer zweiten "Schicht" eine
gewisse Ordnung in das Durcheinander gebracht werden muￜ.
Warum nicht gleich auf der Systemebene Ordnung halten?
> kleinen und sehr statischen Konfigurationen. Oder, wie es auch ein
> Redhat-Mensch mal sagte:
... ohne das Grunspproblem erkannt zu haben...
> Reden wir hier darï¿œber, wie man einen Server sinnvoll und sicher
> betreiben kann, oder darï¿œber, wie man ihn betrieben kï¿œnnen sollte? Wenn
Letzteres.
> Natï¿œrlich ist hier Linux historisch gewachsen - frï¿œher gab es nur die
> sd-Namen, und die sind nun einmal nicht rebootfest. Da man rebootfeste
Die _waren_ es aber einmal.
> So? wieviele denn? Zum Beispiel im Falle Fibrechannel kï¿œnnen das
> potentiell durchaus mehrere Tausend sein (d.h. das Protokoll hate ine
> entsprechende Adressbreite), und zwar je PCI-steckplatz (in jedem kï¿œnnte
Solange Du sie in endlicher Zeit aufzï¿œhlen kannst, lassen sich
Bezeichnungen dafï¿œr erzeugen. Zahlensysteme mit Stellenwertigkeit sind
schon lange erfunden, und sie mï¿œssen nichtmal auf die dezimale
Zifferndarstellung beschrï¿œnkt sein. Jede Tabellenkalkulation kann das (bei
der Spaltennumerierung). Die Anzahl der Stellen kann bedarfsweise angepasst
werden.
> > Ich seh' immer noch nicht, wo da das Problem sein soll...
> > (zumindest das _technische_ Problem.)
>
> Schau einfach mal etwas genauer hin.
Nein, da ist keins. Das "Problem" ist allenfalls ein verwaltungs-
"technisches". Sprich: "Das haben wir schon immer so gemacht."
Henning Paul
>> Nat�rlich ist hier Linux historisch gewachsen - fr�her gab es nur die
>> sd-Namen, und die sind nun einmal nicht rebootfest. Da man
>> rebootfeste
>
> Die _waren_ es aber einmal.
Nein, die waren es nie! Die wurden fr�her in Controller- und
Target-Reihenfolge vergeben. Einmal vergessen, die externe SCSI-Platte
vorm Boot einzuschalten, hatten sich alle
Plattenbezeichnungen "dahinter" verschoben.
Gru�
Henning
Diedrich Ehlerding
>>> Woher weiￜ es denn die udev-Regel?
>> Sie weiￜ nicht und muss auch nicht wissen, wie viele Platten da
>> potentiell hï¿œngen kï¿œnnten. Das mï¿œsste nur derjenige wissen, der statisch
>> Namensrï¿œume reservieren will.
>
> Aha - genau _das_ _macht_ aber doch diese angesprochene udev-Regel.
Nein, das tut sie nicht. Sie reserviert nicht Namensrï¿œume, wie du es dir
vorzustellen scheinst (es gibt also nicht auf Vorrat ein /dev/sdc, wenns
nicht tatsï¿œchlich mehrer als 2 Platten im System gibt), sondern sie
erzeugt dann, wenn es eine Platte gibt, einen eindeutigen Namen dafï¿œr.
Und welchen namen sie aus welchen Eigenschaften erzeugt, ist ggf. sogar
dir ï¿œberlassen - vielleicht willst du lieber uï¿œnber steckplatz des
COntrollers usw. arbeiten und ich ï¿œber die Hardware-ID der LUN. Die mit
den ï¿œblichen udev-Regeln ausgelieferten namensschemata sind ja kein
Zwang, du kannst (wenn es fï¿œr dich sinnvoll und nï¿œtig ist) durchaus
andere Schemata erfinden.
>> Wenn du Namensrï¿œume reservieren willst, musst du nicht fï¿œr das was
>> reservieren, was gerade verbunden ist, sondern fï¿œr das, was potentiell
>> dranhï¿œngen kï¿œnnte. Im Fibrechannelumfeld kï¿œnnen hinter einem HBA im
>
> Wirklich? Wie kann dann diese udev-Regel _reboot-feste_ Namen fï¿œr die Links
> erstellen, wenn das garnicht mï¿œglich ist?
Lies nochmal genau, was ich sage. Eben weil sie die Namen dynamisch
erzeugt und nicht (wie weiter oben irgendwo gefordert) statisch
vorreserviert, kann sie das.
>
>> Extremfall -zig Endgerï¿œte mit je einigen Hundert LUNs, im Extremfall
>> potentiell je mehreren Tausend LUNs hï¿œngen. Mag sein, dass der
>> HBA-Treiber eine Obergrenze von z.B. 2^15 Devices hat - aber die willst
>> du nicht alle reservieren; und wenn morgen ein neuer Treiber kommt mit
>> ner anderen Obergrenze, was tust du dann?
>
> Noch'ne Stelle anhï¿œngen, z.B. Wie erzeugst Du eine um eins hï¿œhere Zahl,
> wenn Du eine beliebig groï¿œe schon hast? Und wie machst Du das, wenn Du die
> grￜￜte gegeben hast, die in die Anzahl Stellen passt, die schon benutzt
> sind?
Dann bekï¿œmst du aber beim kernelupdate andere devicenamen aï¿œls bisher.
Das willst du auch nnicht wirklich.
>> (Am Rande: Ich weiￜ, dass FIbrechannel-Umfeld nix mit Heimanwendung zu
>> tun hat, aber mï¿œchte dennoch zart darauf hinweisen, dass hier nicht nur
>> die reine Anzahl zum Problem beim Reservieren fï¿œhrt, sondern auch noch
>> das Thema der "ï¿œberstzung" von FC-Protokoll und FC-WWNs in
>> scsi-Protokoll und scsi-targets; schon der HBA weiￜ nicht sicher,
>> welchen WWN (welches Raidsystem) er als ewrstes erkennt und welches als
>> zweites; d.h. auch hierdurch kann beim Booten bzw. Laden des Moduls die
>> Reihenfolge der Platten vertauscht sein).
>
> Und wie lï¿œst Du _dieses_ Problem reboot-fest?
mit udev - sagte ich doch schon. Ich benutze /dev/disk/by-id; das wird
aus Hardwareeigenschaften der LUN erzeugt und nicht aus Controller,
Target, LUN. Dazu kann die LUN sogar heute auf Adresse 17 sichtbar sein
und morgen, nach Umkonfiguration des externen Raidsystems, auf einer
anderen Adresse; sie hat immer noch dieselbe Hardware-UUID und wird
unter demselben symlink sichtbar.
> Wenn das geht, dann geht das immer.
Ja. Nï¿œmlich mit udev ;-)
>> Kurz, die /dev/sd-Namen sind einfach ungeeignet fï¿œr alle auï¿œer sehr
>
> Warum stellst Du immer auf "die /dev/sd-Namen" ab?
Weil der OP erwartete, dass eine Platte, die heute /dev/sdb heiï¿œt,
morgen auch so heiï¿œt, un d seine fstab darauf abgestellt hatte. Das war
das Problem, von dem wir ausgegangen waren.
> Ob die sd<irgendwas>
> oder anders heiￜen, ist doch eigentlich egal. Ich finde es bloￜ - sorry -
> bescheuert, daￜ die _als Grundlage_ erzeugten Namen wild
> durcheinanderlaufen kï¿œnnen und erst mit einer zweiten "Schicht" eine
> gewisse Ordnung in das Durcheinander gebracht werden muￜ.
> Warum nicht gleich auf der Systemebene Ordnung halten?
Geht es dir nur um die Frage symlink oder Deviceknoten?
Meinetwegen erzeuge nicht einen symlink, sondern einen Deviceknoten.
Vielleicht geht auch das mit udev (habe ich noch nicht probioert). Aber
warum; was hï¿œttest du davon, dass /dev/<eindeutigerName> anstelle eines
symlinks auf /dev/sd<soundso> nun ein Deviceknoten mit zufï¿œllig
derselben major- und minor-Number wie /dev/sd<soundso> ist? Das macht
die Sache nur unï¿œbersichtlich.
Komplett verzichten auf /dev/sd wird man auf lange Zeit nicht kï¿œnnen
(u.a. deshalb, weil es ja Leute gibt wie dich und Helmut Hullen, die
eine panische Furcht vor udev zu haben scheinen).
>> Reden wir hier darï¿œber, wie man einen Server sinnvoll und sicher
>> betreiben kann, oder darï¿œber, wie man ihn betrieben kï¿œnnen sollte? Wenn
>
> Letzteres.
Dann diskutier das in der Devicemapper-Mailingliste oder der
kernel-Mailingliste. Ich rede hier darï¿œber, was geht und wie es geht.
>> Natï¿œrlich ist hier Linux historisch gewachsen - frï¿œher gab es nur die
>> sd-Namen, und die sind nun einmal nicht rebootfest. Da man rebootfeste
>
> Die _waren_ es aber einmal.
Nein, die waren es nie (jedenfalls nicht seit ich das kenne, und das war
schon vor udev-Zeiten). Frï¿œher gab es genau darum sowas wie "scsidev",
letztlich eine Miniversion von udev, die auch nichts anderes machte als
aus Hardwareeigenschaften rebootfeste Namen zu erzeugen. Wenn du einen
Server mit zwei externen SCSI-Kabeln hattest und heute dieses, morgen
jenes Kabel beim Booten weggenommen hatest, hast du schon immer
gehï¿œkelten Datenrhabarber gekocht, wenn du dich auf die sd-Namen
verlassen wolltest.
Diedrich
Henning Paul
> Komplett verzichten auf /dev/sd wird man auf lange Zeit nicht k�nnen
> (u.a. deshalb, weil es ja Leute gibt wie dich und Helmut Hullen, die
> eine panische Furcht vor udev zu haben scheinen).
Ich habe auch den Eindruck, dass manche Leute hier die Problematik bei
der Benamsung der Blockdevices mit der hier schon mehrfach diskutierten
Netzwerkinterfacebezeichnung verwechseln: Netzwerkinterfaces kann man
mittels "ifrename" umbenennen, da kann udev treiben was es m�chte (ob
man das jetzt gut findet oder nicht). Bei Blockdevices muss udev mit
dem arbeiten, was ihm vorgesetzt wird, da z�hlt der Kerneltreiber f�r
SCSI-Platten einfach die Namen hoch und man kann nur noch versuchen,
angemessene Namen f�r Symlinks zu finden. Anscheinend ist manchen
dieser wichtige Unterschied nicht klar, die glauben dann, die sdX-Namen
w�rden von udev erzeugt werden (was ja per Definition p�se und aller
Voraussicht nach der Untergang des Abendlandes ist).
Gru�
Henning
Helmut Hullen
Du meintest am 05.01.10:
> Komplett verzichten auf /dev/sd wird man auf lange Zeit nicht k�nnen
> (u.a. deshalb, weil es ja Leute gibt wie dich und Helmut Hullen, die
> eine panische Furcht vor udev zu haben scheinen).
Ich habe weder eine panische noch eine unpoanische Furcht vor udev. Ich
weiss, wo und wie ich es abschalten kann.
Und ich pflege es deshalb abzuschalten, weil es ungefragt in meiner
Konfiguration herumferkeln will.
Volker Gringmuth
> > Das kommt schon sehr nahe an die Schlagersängervision von der deutschen
> > Bürokratie, die mal den "Antrag auf Erteilung eines Antragsformulars"
> > besungen hat... (weißt Du, wer das damals war? ;)
>
> IIRC Reinhard May (und kurzes gurgeln zeigt, daß mich die Erinnerung
> nicht trügt).
Nur daß er sich auch damals schon mit ey schrob. Der mit ay, das war Karl.
vG
--
"Haben Sie in der DDR Leute gesehen, die 40 Stunden die Woche arbeiten und
kein Geld haben, sich Lebensmittel zu kaufen? Nein, dafür müssen Sie in die
USA gehen. Das nennt man nämlich kapitalistische Mißwirtschaft. Die USA
sind viel pleitere-re-re-re-re-rer, als es die DDR jemals war!" (Volker
Pispers, "Bis neulich")
Sieghard Schicktanz
Du schriebst am Tue, 05 Jan 2010 10:01:43 +0100:
> >> sd-Namen, und die sind nun einmal nicht rebootfest. Da man
...
> > Die _waren_ es aber einmal.
>
> Nein, die waren es nie! Die wurden frï¿œher in Controller- und
> Target-Reihenfolge vergeben. Einmal vergessen, die externe SCSI-Platte
> vorm Boot einzuschalten, hatten sich alle
> Plattenbezeichnungen "dahinter" verschoben.
Das war davor, ja, und es gab jahr(zehnt)elange Klagen darï¿œber.
Entweder mit oder sogar schon vor Einfï¿œhrung des devfs (oder auch parallel
dazu im Kernel) wurde das umgestellt auf feste Zuordnung nach Ids, so wie
auch bei den IDE-Platten (leider habe ich keine archï¿œologischen Fundstï¿œcke
mehr dazu - AFAIR habe ich das selber so am Laufen gehabt.)
Interessanterweise ging das bei den IDE-Platten von Anfang an so - bis vor
kurzem die auch in das SCSI-Namensschema integriert wurden und damit ihre
Zuordnung verloren.
Henning Paul
> Interessanterweise ging das bei den IDE-Platten von Anfang an so
Das war lediglich ein Nebeneffekt davon, dass Primary/Secondary Master/Slave
alle unterschiedlicher Adressierung bedurften (0x170 vs. 0x1f0 und
Master/Slave innerhalb dessen durch subtiles Registergefummel), also
aufgrund einer Altlast aus 286er-Zeiten.
> - bis vor
> kurzem die auch in das SCSI-Namensschema integriert wurden
Sie wurden ja nicht nur ins SCSI-Namensschema integriert, sondern ins
gesamte SCSI-Treibermodell. (Was damals auch schon mit ide_scsi für das
Brennen auf ATAPI-Laufwerken notwendig war.)
> und damit ihre Zuordnung verloren.
Das war zwar praktisch, aber faktisch nur eine Altlast.
Sieghard Schicktanz
Du schriebst am Tue, 05 Jan 2010 10:15:26 +0100:
> > Aha - genau _das_ _macht_ aber doch diese angesprochene udev-Regel.
>
> Nein, das tut sie nicht. Sie reserviert nicht Namensrï¿œume, wie du es dir
> vorzustellen scheinst (es gibt also nicht auf Vorrat ein /dev/sdc, wenns
Die Bezeichnung "Namensrï¿œume" stammt von Dir, ich habe mich der nur
angeschlossen - es kann leicht sein, daￜ Du darunter was anderes verstehst.
> vorzustellen scheinst (es gibt also nicht auf Vorrat ein /dev/sdc, wenns
> nicht tatsï¿œchlich mehrer als 2 Platten im System gibt), sondern sie
> erzeugt dann, wenn es eine Platte gibt, einen eindeutigen Namen dafï¿œr.
Ja sicher - geht ja auch nicht anders, wenn die sd-Bezeichnungen einfach
der Reihenfolge des Auffindens nach vergeben werden. Die "reboot-festen"
Kennungen mￜssen allerdings durchaus so aufgebaut sein, daￜ sie "Platz auf
Vorrat" fï¿œr (gerade) nicht angeschlossene Gerï¿œte haben - wenn keine Platte
auf Id 4, aber eine auf 5 angeschlossen sind, dann darf die auf Id 5 eben
_nicht_ einen Namen bekommen, der mit dem fï¿œr die Id kollidieren kï¿œnnte.
Das geht, wenn die Id bei der Konstruktion der Bezeichnung mitbenutzt wird.
> Und welchen namen sie aus welchen Eigenschaften erzeugt, ist ggf. sogar
> dir ï¿œberlassen - vielleicht willst du lieber uï¿œnber steckplatz des
Mir ist das reichlich egal, wie die Namen genau strukturiert sind. Mir ist
es sogar einigemaￜen egal, daￜ sie sich verschieben kￜnnen, wenn ich
_weiￜ_, was das impliziert. Es gibt nur - hￜufig auch _hier_ - immer wieder
Klagen und Probleme mit dem derzeit praktizierten Verfahren...
> > Wirklich? Wie kann dann diese udev-Regel _reboot-feste_ Namen fï¿œr die
> > Links erstellen, wenn das garnicht mï¿œglich ist?
>
> Lies nochmal genau, was ich sage. Eben weil sie die Namen dynamisch
> erzeugt und nicht (wie weiter oben irgendwo gefordert) statisch
> vorreserviert, kann sie das.
Und wie kann sie damit sicherstellen, daￜ es da bei unterschiedlichen
konfigurationen nicht _doch_ mal zu Kollisionen kommt?
Eben weil die Namen entsprechend der hardwaremￜￜigen Gegebenheiten
konstruiert werden und nicht einfach stur nach Auftauchen durchnumeriert.
Das ist eben sowas wie der Unterschied zwischen den Nummern der Sitze in den
Stuhlreihen eines Theaters und den Nummern der Eintrittskarten der Besucher.
Henning Paul
>> vorzustellen scheinst (es gibt also nicht auf Vorrat ein /dev/sdc, wenns
>> nicht tatsächlich mehrer als 2 Platten im System gibt), sondern sie
>> erzeugt dann, wenn es eine Platte gibt, einen eindeutigen Namen dafür.
>
> Ja sicher - geht ja auch nicht anders, wenn die sd-Bezeichnungen einfach
> der Reihenfolge des Auffindens nach vergeben werden. Die "reboot-festen"
> Kennungen müssen allerdings durchaus so aufgebaut sein, daß sie "Platz auf
> Vorrat" für (gerade) nicht angeschlossene Geräte haben - wenn keine Platte
> auf Id 4, aber eine auf 5 angeschlossen sind, dann darf die auf Id 5 eben
> _nicht_ einen Namen bekommen, der mit dem für die Id kollidieren könnte.
> Das geht, wenn die Id bei der Konstruktion der Bezeichnung mitbenutzt
> wird.
Zum Beispiel. Oder die Plattenseriennummer. Oder die UUID des enthaltenen
Dateisystems.
>> Und welchen namen sie aus welchen Eigenschaften erzeugt, ist ggf. sogar
>> dir überlassen - vielleicht willst du lieber uünber steckplatz des
>
> Mir ist das reichlich egal, wie die Namen genau strukturiert sind. Mir ist
> es sogar einigemaßen egal, daß sie sich verschieben können, wenn ich
> _weiß_, was das impliziert. Es gibt nur - häufig auch _hier_ - immer
> wieder Klagen und Probleme mit dem derzeit praktizierten Verfahren...
Die Klagen höre ich hauptsächlich von Leuten, die nicht gewillt sind, ihr
altes Denkmuster über Bord zu werfen. Und es ist auch immer eine Frage des
Defaults. openSUSE benutzt die typenbezeichnungs-/seriennummerbasierte
Nomenklatur, Ubuntu UUIDs, Debian WIMRE die nackten sdX-Namen. Alles hat
seine Vor- und Nachteile. Wenn man aber versteht, was das für Konsequenzen
hat, ist das alles gar kein Problem.
> Und wie kann sie damit sicherstellen, daß es da bei unterschiedlichen
> konfigurationen nicht _doch_ mal zu Kollisionen kommt?
Indem jedes Schema in seinem eigenen Verzeichnis residiert.
> Eben weil die Namen entsprechend der hardwaremäßigen Gegebenheiten
> konstruiert werden und nicht einfach stur nach Auftauchen durchnumeriert.
Richtig. Was war jetzt nochmal Dein Kritikpunkt?
> Das ist eben sowas wie der Unterschied zwischen den Nummern der Sitze in
> den Stuhlreihen eines Theaters und den Nummern der Eintrittskarten der
> Besucher.
Sozusagen. Oder dem Namen des Theaterbesuchers. Den kann man auch benutzen,
wenn man ihn ausrufen möchte, weil er an seinem Auto das Licht hat brennen
lassen. Das klappt auch dann noch, wenn er sich kurzfristig auf einen
anderen Sitzplatz gesetzt hat...
Sieghard Schicktanz
Du schriebst am Tue, 05 Jan 2010 21:29:15 +0100:
> > kollidieren kï¿œnnte. Das geht, wenn die Id bei der Konstruktion der
> > Bezeichnung mitbenutzt wird.
>
> Zum Beispiel. Oder die Plattenseriennummer. Oder die UUID des enthaltenen
> Dateisystems.
Nenenene - sooo nicht. Hier war von Bezeichnungen die Rede, die die fest
eingebaute Hardware bzw. die Anschlumï¿œglichkeiten wiederspiegeln - weder die
Plattenseriennummer noch erst recht eine UUID tun das auch nur annï¿œhernd.
Eine Platte kann anderswo angeschlossen werden, eine UUID ï¿œbersteht
nichtmal das Neuanlegen des Dateisystems.
> > wieder Klagen und Probleme mit dem derzeit praktizierten Verfahren...
>
> Die Klagen hï¿œre ich hauptsï¿œchlich von Leuten, die nicht gewillt sind, ihr
> altes Denkmuster ï¿œber Bord zu werfen. Und es ist auch immer eine Frage
Bzw. von Leuten, die aus irgendeinem Grund vermeiden mￜchten, daￜ
irgendwelche Daten auf einmal auf einen anderen Datentrï¿œger purzeln (oder
gar nicht mehr), weil bei irgendwelchen Arbeiten mit nachfolgend nï¿œtigem
Neustart sich irgendwelche Kennungen verschoben haben. Klar ist das ein
altes, ï¿œberkommenes Denkmuster, aber die Faulheit wird auch in weiteren
hundert und tausend Jahren nicht auszurotten sein... ;->
> des Defaults. openSUSE benutzt die
> typenbezeichnungs-/seriennummerbasierte Nomenklatur, Ubuntu UUIDs, Debian
> WIMRE die nackten sdX-Namen. Alles hat seine Vor- und Nachteile. Wenn man
> aber versteht, was das fï¿œr Konsequenzen hat, ist das alles gar kein
> Problem.
Solange sich die ganzen Bewegungen in einem ï¿œberschaubaren Rahmen halten,
ist das kein Problem. Wenn es aber, wie jemand hier schrieb, um Hunderte
von Datentrï¿œgern geht, dann wird die Sache doch etwas unï¿œbersichtlich.
> > Und wie kann sie damit sicherstellen, daￜ es da bei unterschiedlichen
> > konfigurationen nicht _doch_ mal zu Kollisionen kommt?
>
> Indem jedes Schema in seinem eigenen Verzeichnis residiert.
Das geht an der Frage vorbei - die Kollisionsfreiheit muￜ fￜr _jedes_
"Schema" separat gegeben sein. Es gibt schlieï¿œlich nicht eigene
Verzeichnisse fï¿œr IDE, SCSI, USB, Firewire, FibreChannel u.v.a.
in /dev/by_path - da liegt alles schï¿œn eintrï¿œchtig beisammen.
> > Eben weil die Namen entsprechend der hardwaremￜￜigen Gegebenheiten
> > konstruiert werden und nicht einfach stur nach Auftauchen
> > durchnumeriert.
>
> Richtig. Was war jetzt nochmal Dein Kritikpunkt?
Ich dachte, das hￜtte ich allmￜhlich oft genug gesagt: daￜ dieses Schema
(wie Du es nennst) _eine_ _zusï¿œtzliche_ _Schicht_ ï¿œber den Standard-
Bezeichnern darstellt.
Henning Paul
>> Die Klagen h�re ich haupts�chlich von Leuten, die nicht gewillt sind,
>> ihr altes Denkmuster �ber Bord zu werfen. Und es ist auch immer eine
>> Frage
>
> Bzw. von Leuten, die aus irgendeinem Grund vermeiden m�chten, da�
> irgendwelche Daten auf einmal auf einen anderen Datentr�ger purzeln
> (oder gar nicht mehr), weil bei irgendwelchen Arbeiten mit nachfolgend
> n�tigem Neustart sich irgendwelche Kennungen verschoben haben. Klar
> ist das ein altes, �berkommenes Denkmuster, aber die Faulheit wird
> auch in weiteren hundert und tausend Jahren nicht auszurotten sein...
> ;->
Es ist immer eine Frage der Abw�gung der Vor- und Nachteile. Die
Distributionen nehmen an, dass der Vorteil, dass das System auch dann
noch bootet, wenn versehentlich ein USB-Stick beim Reboot stecken
gelassen worden ist, den Nachteil �berwiegt, dass wenn man seine alte
Platte mit rsync, dump/restore oder tar auf eine neue umkopiert hat und
jetzt von dieser booten m�chte die fstab und den Kernel-root-Parameter
anpassen muss. Denn wer gen�gend Sachverstand mitbringt, eine Platte
umzukopieren, f�r den ist das Anpassen der Plattenbezeichnung ein
Klacks.
Und jetzt kommt mir nicht mit "Verwindowsung", "Zugest�ndnis an den
Dummuser" o.�. Wer die verwendeten Kennungen nicht mag, kann die in der
menu.lst und fstab immer noch in nackte sdX-Eintr�ge �ndern.
>> des Defaults. openSUSE benutzt die
>> typenbezeichnungs-/seriennummerbasierte Nomenklatur, Ubuntu UUIDs,
>> Debian WIMRE die nackten sdX-Namen. Alles hat seine Vor- und
>> Nachteile. Wenn man aber versteht, was das f�r Konsequenzen hat, ist
>> das alles gar kein Problem.
>
> Solange sich die ganzen Bewegungen in einem �berschaubaren Rahmen
> halten, ist das kein Problem. Wenn es aber, wie jemand hier schrieb,
> um Hunderte von Datentr�gern geht, dann wird die Sache doch etwas
> un�bersichtlich.
Diedrich schrieb, jeder "Endpunkt" in solch einer Konstellation verf�ge
�ber einen weltweit eindeutigen Identifier. Dann nimmt man den und gut
ist.
>> > Und wie kann sie damit sicherstellen, da� es da bei
>> > unterschiedlichen konfigurationen nicht _doch_ mal zu Kollisionen
>> > kommt?
>>
>> Indem jedes Schema in seinem eigenen Verzeichnis residiert.
>
> Das geht an der Frage vorbei - die Kollisionsfreiheit mu� f�r _jedes_
> "Schema" separat gegeben sein. Es gibt schlie�lich nicht eigene
> Verzeichnisse f�r IDE, SCSI, USB, Firewire, FibreChannel u.v.a.
> in /dev/by_path - da liegt alles sch�n eintr�chtig beisammen.
Und zwar kollisionsfrei, da jede PCI-Bus-, PCI-, Bus-, Target-ID und LUN
eindeutig ist.
In /dev/by-uuid sowieso, da UUIDs per Definition "unique"
sind, /dev/by-id verwendet Seriennummer und Typenbezeichnung (auch
eindeutig), nur in /dev/by-label nicht, aber das ist dann Sache des
Users.
>> > Eben weil die Namen entsprechend der hardwarem��igen Gegebenheiten
>> > konstruiert werden und nicht einfach stur nach Auftauchen
>> > durchnumeriert.
>>
>> Richtig. Was war jetzt nochmal Dein Kritikpunkt?
>
> Ich dachte, das h�tte ich allm�hlich oft genug gesagt: da� dieses
> Schema (wie Du es nennst) _eine_ _zus�tzliche_ _Schicht_ �ber den
> Standard- Bezeichnern darstellt.
Aber da die Standard-Bezeichner unbrauchbar, weil fl�chtig sind, hat man
doch gar keine andere Wahl. Und mit dieser Tatsache muss man nunmal
leben. Du kannst Dir doch Dein eigenes Unix schreiben, in dem das nicht
so ist. :-)
Gru�
Henning
Diedrich Ehlerding
> so wie
> auch bei den IDE-Platten (
Bei /dev/hda usw. hat man auch nicht das Problem, dass es potentiell
sehr viele IDE-Platten sein kï¿œnnten, die hinter einem Controller hï¿œngen.
Nun magst du zwar sagen: SATA ist auch nicht dafï¿œr gedacht, Hunderte bis
Tausende externe Platten anzuhï¿œngen. UNd du magst auch sagen: man hï¿œtte
SATA auch anders implementieren kï¿œnnen als das (wie auch USB, Firewire,
Fibrechannel) auch als scsi zu behandeln. Gewiss doch, hï¿œtte man - hat
man aber nicht.
SCSI jedenfalls wurde schon in kernel 2.4 der Reihe nach durchnumeriert,
wies eben gerade kam. Und bei externen Platten kommt es eben dann zu
Problemen mit den Namen.
Diedrich
Diedrich Ehlerding
> Hier war von Bezeichnungen die Rede, die die fest
> eingebaute Hardware bzw. die Anschlumï¿œglichkeiten wiederspiegeln - weder die
> Plattenseriennummer noch erst recht eine UUID tun das auch nur annï¿œhernd.
> Eine Platte kann anderswo angeschlossen werden, eine UUID ï¿œbersteht
> nichtmal das Neuanlegen des Dateisystems.
Hier velwechserst du was.
Auch Platten bzw. die LUNs eines Raidsystems haben typischerweise eine
eindeutige UUID - und zwar jede LUN eine eigene. Selbst wenn das
Raidsystem nur eine (fï¿œr alle LUNs gleiche) Seriennummer ha, hat dennoch
jede LUN eine eigene, weltweit identische, einmalige UUID. Und genau die
wird typischerweise von den gï¿œngigen udev-Regeln fï¿œr /dev/disk/by-id
verwendet. Mit anderen Worten, eine LUN eines solchen Raidsystems hat
erstens einen eindeutigen, unverwechselbaren Namen (keine andere heiï¿œt
genauso), und dieser Name ist automatisch auf allen angeschlossenen
Systemen gleich - selbst dann, wenn ein server die LUN ï¿œber Fibrechannel
sieht und ein anderer ï¿œber iscsi, was bei manchen Raidsystemen mï¿œglich ist.
Nï¿œheres siehe "sg_vpd -p 0x83 <device>" oder "sg_inq -p 0x83 <device>".
Nein, diese Hardwar-UUID hat *nichts* mit der Fileystem-UUID zu tun, und
sie ï¿œndert sich auch nicht, wenn man ein Filesystem darauf anlegt oder
nicht.
> Solange sich die ganzen Bewegungen in einem ï¿œberschaubaren Rahmen halten,
> ist das kein Problem. Wenn es aber, wie jemand hier schrieb, um Hunderte
> von Datentrï¿œgern geht, dann wird die Sache doch etwas unï¿œbersichtlich.
Eben. Und genau da ist es von entscheidender Bedeutung, dass man
*sicher* ist, dass alle angeschlossenen Systeme wirklich dieselben Namen
fï¿œr dieselben Datentrï¿œger und unterschiedliche Namen fï¿œr
unterschiedliche Datentrï¿œger haben.
> Ich dachte, das hￜtte ich allmￜhlich oft genug gesagt: daￜ dieses Schema
> (wie Du es nennst) _eine_ _zusï¿œtzliche_ _Schicht_ ï¿œber den Standard-
> Bezeichnern darstellt.
Und - was stï¿œrt dich daran, dass das symlinks sind, statt Devicenodes?
Diedrich
Sieghard Schicktanz
Du schriebst am Wed, 06 Jan 2010 09:27:42 +0100:
> Nun magst du zwar sagen: SATA ist auch nicht dafï¿œr gedacht, Hunderte bis
> Tausende externe Platten anzuhï¿œngen. UNd du magst auch sagen: man hï¿œtte
Nee, ich mag sagen daￜ es ￜberhaupt kein Problem wￜre, da "Hunderte bis
Tausende externe Platten anzuhï¿œngen" - hda bis hdzz reichen schon fï¿œr gut
700 Stï¿œck, und mit 'ner dritten Stelle geht's bis weit ï¿œber 10000.
Kein Problem hier...
> SCSI jedenfalls wurde schon in kernel 2.4 der Reihe nach durchnumeriert,
> wies eben gerade kam. Und bei externen Platten kommt es eben dann zu
> Problemen mit den Namen.
Und deswegen wï¿œrde, um den Klagen ï¿œber die dadurch entstehenden Probleme zu
entgegnen, die Numerierung nach Ids eingefï¿œhrt; es mag evtl. _mit_, ich
meine aber unabhï¿œngig davon schon vor, der Einfï¿œhrung des devfs gewesen
sein. Und mit der Einfï¿œhrung des "gegen devfs wesentlich verbesserten"
udev wieder abgeschafft.
Sieghard Schicktanz
Du schriebst am Wed, 06 Jan 2010 09:47:19 +0100:
> > eingebaute Hardware bzw. die Anschlumï¿œglichkeiten wiederspiegeln -
> > weder die Plattenseriennummer noch erst recht eine UUID tun das auch
...
> Auch Platten bzw. die LUNs eines Raidsystems haben typischerweise eine
> eindeutige UUID - und zwar jede LUN eine eigene. Selbst wenn das
> Raidsystem nur eine (fï¿œr alle LUNs gleiche) Seriennummer ha, hat dennoch
> jede LUN eine eigene, weltweit identische, einmalige UUID. Und genau die
^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^
Hￜ? Daￜ ein Unikat "weltweit identisch" ist ist wohl eine Trivialitￜt...
...
> Nein, diese Hardwar-UUID hat *nichts* mit der Fileystem-UUID zu tun, und
> sie ï¿œndert sich auch nicht, wenn man ein Filesystem darauf anlegt oder
> nicht.
Und wie wird die angelegt und wie und und wo wird die gespeichert?
Wenn die mit den _Anlegen_ des RAID-Verbunds erstellt und auf den Platten
abgelegt wird, dann ist sie nicht unverï¿œnderlich.
> > Ich dachte, das hￜtte ich allmￜhlich oft genug gesagt: daￜ dieses Schema
> > (wie Du es nennst) _eine_ _zusï¿œtzliche_ _Schicht_ ï¿œber den Standard-
> > Bezeichnern darstellt.
>
> Und - was stï¿œrt dich daran, dass das symlinks sind, statt Devicenodes?
Die Flickschusterei.
(Mich stï¿œrt genauso die Verwendung von Kundennummern, Lieferantennummern,
Besuchernummern, Versicherungsnummern und ï¿œhnlichen ï¿œberflï¿œssigen multiplen
Bezeichnern, vor allem, wenn dann bei einer Frage als erstes zurï¿œckkommt
"geben Sie mir erst ihre <irgendwas>nummer!" [Nein, ï¿œblicherweise kein
"bitte" oder sowas dabei!]. Gnrfzg. (c))
Sieghard Schicktanz
Du schriebst am Wed, 06 Jan 2010 09:18:17 +0100:
> > Bzw. von Leuten, die aus irgendeinem Grund vermeiden mￜchten, daￜ
> > irgendwelche Daten auf einmal auf einen anderen Datentrï¿œger purzeln
...
> Es ist immer eine Frage der Abwï¿œgung der Vor- und Nachteile. Die
> Distributionen nehmen an, dass der Vorteil, dass das System auch dann
> noch bootet, wenn versehentlich ein USB-Stick beim Reboot stecken
> gelassen worden ist, den Nachteil ï¿œberwiegt, dass wenn man seine alte
> Platte mit rsync, dump/restore oder tar auf eine neue umkopiert hat und
Aber daￜ _beide_ dieser Nachteile durch die von Dir genannten "by-path"-
Kennungen _gleichzeitig_ vermieden werden kï¿œnnten, will keiner riskieren?
Das ist wohl zuviel der Vorteile, das kann man den Nutzern wohl nicht
zumuten...
Diedrich Ehlerding
>> Nein, diese Hardwar-UUID hat nichts mit der Fileystem-UUID zu tun, und
>> sie ändert sich auch nicht, wenn man ein Filesystem darauf anlegt oder
>> nicht.
>
> Und wie wird die angelegt und wie und und wo wird die gespeichert?
> Wenn die mit den Anlegen des RAID-Verbunds erstellt und auf den Platten
> abgelegt wird, dann ist sie nicht unveränderlich.
Das Raisdsystem erfindet die beim Erzeugen der LUN. Mindestens manche
Raidsysteme erzeugen dann, wenn eine LUN im Raidsystem gelöscht und neu
angelegt wird, auch nicht wieder dieselbe UUID. Die liegt nicht auf den
Platten, sondern im Controller des Raidsystems. Unveränderlich ist sie auf
jeden Fall, d.h. diese LUN wird nie eine andere UUID bekommen. Es mag
Raidsysteme geben, die dann, wenn man eine LUN zerstört und wieder anlegt,
möglicherweise dieselbe UUID erneut erzeugen - da kann man dann trefflich
drüber streiten, ob es nicht eben dieselbe Platte ist, die allerdings vom
Storageadministrator gelöscht wurde.
>> Und - was stört dich daran, dass das symlinks sind, statt Devicenodes?
>
> Die Flickschusterei.
Aha. Ich übersetze also mal: du hast keine ernsthaften Einwände
vorzubringen, sondern willst nur mal eben auf den Boden stampfen, damit
alle anderen alles anders machen.
Es bleibt dir unbenommen, einben anderen, eigenen Mechanismus nach deinem
Gusto zu erfinden. Die anderen werdens nicht für dich tun, bloß weil du
symlinks hässlich findest.
Sieghard Schicktanz
Du schriebst am Thu, 07 Jan 2010 16:30:44 +0100:
> Das Raisdsystem erfindet die beim Erzeugen der LUN. Mindestens manche
> Raidsysteme erzeugen dann, wenn eine LUN im Raidsystem gelï¿œscht und neu
> angelegt wird, auch nicht wieder dieselbe UUID. Die liegt nicht auf den
^^^^^^^^^^^^^^^^^^^^^^^^^^
> Platten, sondern im Controller des Raidsystems. Unverï¿œnderlich ist sie auf
^^^^^^^^^^^^^^
> jeden Fall, d.h. diese LUN wird nie eine andere UUID bekommen. Es mag
^^^^^^^^^^
Wie passt das zusammen?
> Aha. Ich ï¿œbersetze also mal: du hast keine ernsthaften Einwï¿œnde
> vorzubringen, sondern willst nur mal eben auf den Boden stampfen, damit
> alle anderen alles anders machen.
Wenn Du das so sehen willst - sicher kann man auch ï¿œberall Provisorien
anbringen und sich damit durchhangeln (es heiï¿œt ja, nichts wï¿œre so
dauerhaft wie ein Provisorium).
Joerg Hoh
> Wenn Du das so sehen willst - sicher kann man auch �berall Provisorien
> anbringen und sich damit durchhangeln (es hei�t ja, nichts w�re so
> dauerhaft wie ein Provisorium).
Die Geschichte von Unix ist voll von solchen Provisorien, Workarounds,
Inkonsistenzen und kruder Hacks. Insbesondere wenn man sich die �lteren,
propriet�ren Unices wie AIX und Solaris anschaut (gerne auch aktuelle
Versionen, wobei langsam offenbar ein bisschen Besserung einzutreten
scheint).
Gru�
J�rg
--
What did you do to the cat? It looks half-dead. -Schroedinger's wife
Diedrich Ehlerding
>> Das Raisdsystem erfindet die beim Erzeugen der LUN. Mindestens manche
>> Raidsysteme erzeugen dann, wenn eine LUN im Raidsystem gelöscht und neu
>> angelegt wird, auch nicht wieder dieselbe UUID. Die liegt nicht auf den
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Platten, sondern im Controller des Raidsystems. Unveränderlich ist sie
>> auf
> ^^^^^^^^^^^^^^
>> jeden Fall, d.h. diese LUN wird nie eine andere UUID bekommen. Es mag
> ^^^^^^^^^^
> Wie passt das zusammen?
Es passt gut zusammen. Oder was war deine Frage? Ach so, du hast es nicht
verstanden, weil du mit solchen Systemen noch nichts zu tun hattest, Gern
für dich also nochmal im Detail:
- solche Raidsysteme können logische Platten ("LUNs" nennen die Raidsysteme
die) einrichten.
- eine solche LUN wird für einen Server an einem Frontendport sichtbar, an
dem man zB ein SCSI- oder SAS- oder Fiberchannelkabel anschließt
- An diesem Kabel hat sie für diesen Server eine Adresse.
- An diesem Kabel können für einen Server mehrere bis viele solche LUNs
sichtbar sein
- Wenn der Server im scsi-inquire bestimmte Informationen abfragt, nennt
ihm das Raidsystem u.a. die UUID dieser LUN.
- Eine solche LUN kann für mehrere Server sichtbar sein (zB in shared
disk-Umgebungen, CLustern usw.)
- Alle Server, die eine solche LUN sehen, erhalten dieselbe UUID für
dieselbe LUN und unterschiedliche UUIDs für unterschiedliche LUNs genannt,
ganz egal, unter welcher scsi-Adresse sie am Frontendport sichtbvar wird,
und ganz egal, mit welcher Sorte Controller (iscsi, SAS,
Fibrechannel, ...) der Server zugreift.
- diese UUID, die mit scsi-Inquire-Kommandos ausgelesen wird, ist eine
Eigenschaft der LUN, die vom Raidsystem vergeben wird. Typischerweise kann
man sie nicht beeinflussen und schon gar nicht verändern.
- Man kann in solchen Raidsystemen LUNs zerstören und wieder neu einrichten
(d.h. in der Administrationssoftware des Raidsystem heißt sie evtl.
nachher genauso wie vorher), und man kann sie auch so neu einrichten, dass
der Server sie auf derselben Adresse sieht.
- Gleichwohl hat die neu erzeugte LUN typischerweise eine neue UUID, d.h.
der Server merkt, dass ih auf derselben scsi-Adresse eine andere Platte
untergeschoben werden soll.
- Letzteres ist allerdings möglichewrwesie nicht bei allen Raidsystemen so;
d.h. die Hersteller von Raidsystemen bzw. die Erfinder von
Raidsystem-Firmware sind sich uneins, ob eine LUN, die intern wieder so
heißt wie wie vorher zerstörte, nun eine andere Identität haben muss oder
nicht.
Die UUID einer LUN eines typischen Raidsystems ist also mindestens insoweit
eindeutig, als zu keinem Zeitpunkt zwei LUNs mit derselben UUID
existieren. Sie ist insofern unveränderlich, als man sie nicht
beeinflussen kann, solange die LUN existiert. Ob man den Fall
"Umkonfiguration des Raidsystems mit Löschung und Neuerzeugung einer LUN
gleichen internen Namens wie vorher" als Löschung des Inhalts der LUN mit
Mitteln des Raidsystems ansieht (womit diejenigen Firmwareerfinder
gerechtfertigt wären, die beim Neueinrichten unter demselben internen
Namen dieselbe UUID wieder vergeben), oder ob man die neu eingerichtetet
LUN als eine neue Entität betrachtet, die nur zufällig denselben Namen hat
(womit diejenigen gerechtfertigt wären, die in dieser situation eine neue
UUID generieren), ist letztlich Geschmackssache; allerdings muss
derjenige, der mit einem solchen umkonfigurierten Raidsystem arbeitet,
wissen, wie sein System sich verhält.
Und diese UUID steht dann in /dev/disk/by-id als eindeutiger und
clusterweit automatisch identischer Name der Platte. Also eigentlich genau
das, was du haben willst - denn ob da ein symlicnk stht oder nicht, kann
dir eigentlich wumpe sein.