Hallo,
da das Ganze schon ein bisschen her ist, zunächst einmal die Frage: Ist
es noch akut? Immerhin stand da was von "In einigen Monaten", könnte
also durchaus noch Thema sein.
Ein paar Ideen hätte ich dazu, erfordert aber zum Teil einen neuen
Kernel. Denn die Ladereihenfolge der Module ist so ein Kapitel für sich.
Ist aber ein Zweig fest einkompiliert, wird der sicherlich zuerst benutzt
und dann auch die Reihenfolge der Devices entsprechend angesetzt.
Die andere Variante wäre das devfs. Gibt es bei SuSE schon eine Weile
und ich glaube, die Unterstützung dafür ist sogar schon im Kernel drin,
allerdings erfordert das ein paar Änderungen im Bootsystem.
Sollte das noch nicht bekannt sein: Das devfs ist ein virtuelles
Dateisystem (wie proc), das im RAM realisiert wird. Jedes Device
bekommt dabei einen Node, jedes System ein Verzeichnis. Eine SCSI-
Platte hätte dann Namen wie:
scsi/host0/channel0/ID4/lun0 oder so ähnlich (das genaue System ist in
einem Howto oder so erläutert, die Namenssystematik ist mir jetzt im
Moment nicht so gegenwärtig). Da man aber in den Tabellen und
Dateien in aller Regel die alten Namen stehen hat, gibt es außerdem
den devfsd, einen Deamon, der beim Booten mitgestartet wird. Er kann
dann (über eine Steuerdatei, die man natürlich erstellen muss) die
devfs-Namen und die alten /dev-Namen zuordnen. In Tabellen wie der
fstab stehen dann die ganz normalen, bekannten Namen drin.
Der Grund für das Ganze war ursprünglich ein Problem, das Linux hat:
Die Devce-Number (also Major und Minor, die Nummern, die bei den
Nodes im dev-Verzeichnis an Stelle der Größe zu finden sind) ist eine
16-Bit-Integerzahl und steht in den Systemaufrufen zusammen mit einer
weiteren 16-Bit-Zahl in einer 32-Bit-Größe. Das ganze System wäre nur
schwer umzustellen, dadurch aber sind die Major (die den zuständigen
Treiber angibt) und die Minor-Number (die das Gerät oder die Partition
kennzeichnet) nur 8-Bit-Zahlen und da wird's langsam eng. Alte Treiber
(wie für die vor Jahren üblichen CD-ROM mit eigener
Schnittstellenkarte) blockieren Nummern und es werden immer mehr
davon gebraucht.
Durch die vielen Devices an den SCSI-Hostadaptern (bis zu 15 bisher),
die alle über den gleichen Treiber (gleiche Major) laufen, sind zum
Beispiel auf SCSI-Platten nur maximal 15 Partitionen pro Platte möglich
-bei bis zu 250 oder mehr GB kann das schon ein Problem werden (und
war es auch früher verschiedentlich, denn manche Dateisysteme sind
nur bis zu einigen hundert MB oder weniger zu gebrauchen -da sind
dann auch kleinere Platten recht schnell an der Grenze).
Bei devfs werden die Nummern dynamisch vergeben, dass bedeutet,
alte Treiber, die sowieso kaum noch jemand benutzt, belegen auch
keine Nummern mehr -auch, wenn man die Treiber für den Notfall oder
so noch vorhält. Würde man statt dessen diese Nummern für neuere
Treiber "recyclen", wären die alten Treiber endgültig außen vor und
wehe, ein altes Programm irgendwo in der Ecke benutzt dann noch die
Nummern in der alten Bedeutung.
Die heilige Kuh Abwärtskompatibilität in Reinkultur, hier hat sie auch
Linux erwischt.
Das System eignet sich aber auch prima für solche Zwecke. Denn,
selbst, wenn sich der "echte" SCSI-Adapter vor den "nachgemachten"
des S-ATA-Zweiges drängeln sollte, wäre dafür nur eine Änderung an
einer Stelle nötig: Die Host-Nummer Null des Emulators (S-ATA) würde
dann durch den SCSI-Adapter auf die Eins verdrängt, dass müsste dann
in der Steuerdatei des devfsd einmal geändert werden -und das war's
dann aber auch. Welche Namen man den Platten dann in der devfsd-
Steuerdatei gibt, bleibt jedem selbst überlassen, diese Namen sind ja
dann nicht mehr Systembezeichnungen. Da könnte man sogar Platz
lassen, falls man später noch was dazwischen-"friemeln" will (weitere S-
ATA-Zweige etwa oder umgekehrt weitere SCSI-Platten).
Die Systemnamen enthalten ja im Pfad auch den Hostadapter (als
Nummer) und die könnte sich ändern (wird sie wohl auch, die "Echten"
kommen eigentlich immer vor den "Falschen", außer, ein Zweig ist fest
einkompiliert), aber das ist eben dann nur an dieser einen Stelle ein
Problem (eventuell muss dann LILO/GRUB neu eingestellt werden, da in
den Map-Dateien sicher auch irgendwelche adapterbezogenen Daten
drin sind, aber das ist wieder BIOS-spezifisch, läuft also noch wieder
anders. Deshalb wohl nur eine neue Installation, damit der Installer die
Pfade entsprechend den neuen Gegebenheiten in die anderen
Informationen umwandelt).
Tschüß
Manfred
Datum: Tue, 23 Aug 2005 09:05:19 +0200
Von: Steffen Moser
Hallo,
ich habe vor einigen Tagen SuSE Linux 9.3 auf einem AMD-Opteron- .... schnipp .... Jetzt soll in einigen Monaten noch ein "richtiger" SCSI-Hostadapter in die Maschine eingebaut werden (Adaptec 29160 Ultra160 SCSI adapter), der sich zur Zeit noch in einem anderen Rechner befindet. An diesen Adaptec-Adapter sollen zwei weitere SCSI-Festplatten (und ein Streamer) angeschlossen werden.
Meine Frage nun: Wie verhindere ich nun, dass die zwei SCSI-Festplatten die Devicenamen der S-ATA-Platten "nach hinten" verschieben?
Ich hätte gerne, dass die S-ATA-Platten weiterhin "sda", "sdb", "sdc" und "sdd" heißen und die SCSI-Platten dann als "sde" und "sdf" an- schließen. Ich habe aber die Befürchtung, dass sich der SCSI-Controller quasi "vordrängelt".
Seht Ihr eine Möglichkeit, das zu verhindern (z.B. durch eine Modul- Option)? Wo wird die Reihenfolge festgelegt?
Soweit ich weiß, ist, wenn ich zwei "echte" SCSI-Einsteckadapter hätte, in der Regel die Nummer des PCI-Slots ausschlaggebend. In meinem Fall habe ich aber einen Onboard-S-ATA-Controller und einen PCI-SCSI-Adapter, da kann ich nur begrenzt "umstecken".
Oder muss ich ein Verschieben der Devicenamen einfach hinnehmen und eventuell die Devices der RAID-Sätze ändern?
Ich bedanke mich im Voraus für alle Antworten!
Viele Grüße, Steffen
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com