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 <lists@steffen-moser.de> An: suse-linux@suse.com Betreff: Reihenfolge S-ATA-/SCSI-Festplatten

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