☰

Wie viele physische Festplatten kann SLES 9 verarbeiten? Gibt es irgendwelche Einschränkungen?

tag-icon • tag-icon sles
Wie viele physische Festplatten kann SLES 9 verarbeiten? Gibt es irgendwelche Einschränkungen?

Ich glaube, es gibt eine Beschränkung, wie viele Festplatten eine SLES 9-Maschine verarbeiten kann (32 Bit). Ich kann die Zahl nicht über Google finden.

Meine Frage: Kann jemand anhand dieser Nummer sagen, um welche Nummer es sich handelt?

Antwort1

Begründete Vermutung

4PiB.

Rechtfertigung

SLES 9 istjetzt etwa ein Jahrzehnt alt, daher werden keine so großen Dateisysteme unterstützt wie moderne Linux-Distributionen oder so viele Volumes wie moderne Kernel. Der neueste unterstützte Kernel in SLES 9 ist 2.6.5.

Sie beschränken sich auch künstlich selbst, wenn Sie ein 32-Bit-Betriebssystem verwenden: Größere Dateisysteme erfordern mehr RAM zur Verwaltung. Eine konservative Faustregel lautet 1GiBproTiB. Da 32-Bit-Linux normalerweise auf 4 GiB beschränkt ist[1], drängen Sie es dazu, ein 32-Bit-Linux zu verwenden, um mehr als 4 TiB zu verwalten. Ich bin bis zu 16 TiB gegangen und damit durchgekommen[2], aber das empfehle ich eigentlich nicht. Eine häufige Horrorgeschichte ist, dass ein System fscknach einem Stromausfall aufgrund von RAM-Mangel nicht abgeschlossen werden kann und das Dateisystem somit nicht erneut gemountet werden kann.

Das leistungsfähigste Dateisystem, das in SLES 9 integriert ist, istJFS. Die Beschränkung der Datenträgergröße liegt imPetabyte, also praktisch unbegrenzt.

SLES 9 unterstützt außerdemReiserFS, das eine Datenträgergrößenbeschränkung von 16 TiB hat. Aus den oben genannten Gründen der RAM-Beschränkung ist dies eine gute Lösung für Ihr 32-Bit-System.

Es gibt auch eine Begrenzung der Anzahl von /dev/sdGerätepfaden im Linux-Kernel. Diese wurde im Laufe der Lebenszeit von Linux ein paar Mal geändert, in üblichen Zweierpotenzwerten. Die Begrenzung für SLES 9 liegt wahrscheinlich bei 256 Volumes, basierend auf derdokumentierte Grenzefür RHEL 3 und 4, die ungefähr zeitgleich mit SLES 9 erschienen.[3]

Das Speicherlimit ist das Volumengrößenlimit multipliziert mit der maximalen Anzahl von Volumen. Meine obige Zahl von 4 PiB basiert auf einer maximalen Volumengröße von 16 TiB x 256 Volumen.

Du wirst nicht ans Limit gehen

Das ist eine Menge Speicher, egal wie man ihn anordnet. Die tatsächliche Zahl ist aus praktischen Gründen nicht so wichtig. Allein genug Festplatten an einen einzigen Computer anzuschließen, um diese geschätzte Grenze zu erreichen, wird eine ziemliche Herausforderung sein, insbesondere angesichts der Tatsache, dass die gängigen Festplattencontroller, die mit Kernel 2.6.5 kompatibel sind, moderneErweitertes FormatFestplatten, daher können Sie wahrscheinlich keine Festplatten verwenden, die größer als 2 TB sind.

Das bedeutet, dass Sie Tausende von physischen Festplatten benötigen, um dieses 4-PiB-Limit zu erreichen.

Wenn Sie nicht zuerst auf eine Konnektivitäts- oder Rackgrößenbeschränkung stoßen, stoßen Sie auf eine andere praktische Beschränkung, bevor Sie die absolute technische Grenze erreichen.

Fußnoten:

  1. PAEermöglicht bis zu 64 GiB auf einem 32-Bit-System, aber ich weiß nicht, ob der Kernel den Speicherplatz über 4 GiB hinaus für den Puffercache verwenden kann.

    Keine fsckmir bekannte Implementierung kann PAE nutzen, da dies in User-Space-Anwendungen eine Menge spezieller Tricks erfordert. In den vergangenen Jahren, als es eine praktikable Lösung für das RAM-Limit-Problem war, hat nur eine äußerst kleine Anzahl von Programmen PAE wirklich genutzt. (Heute würden Sie einfach ein 64-Bit-Betriebssystem verwenden.)

  2. Der RAM-Bedarf hängt von der Anzahl der Dateien und Verzeichnisse auf der Festplatte und der Anzahl gleichzeitiger Zugriffe ab. Die „1 GiB pro TiB-Regel“ ist daher eine Art Proxy-Regel.

    Ich glaube, der einzige Grund, warum ich mit 16 TiB auf einem 32-Bit-Kernel davonkam, ist, dass es sich um digitale Videoserver mit wenigen gleichzeitigen Benutzern handelte. Da die Dateien relativ wenige und groß waren, fsckmusste ich nicht mit einer großen Anzahl von Verzeichnissen oder Dateien jonglieren.Inodes, und es mussten nicht viele Dateisysteminformationen im RAM gespeichert werden, um die Anzahl gleichzeitiger Benutzer zu verfolgen.

    Ein gutes Gegenbeispiel wäre ein E-Mail-Server, der Tausende von Benutzern gleichzeitig bedienen kann, von denen jeder auf eine große Zahl kleiner Dateien zugreifen möchte, die über Tausende von Verzeichnissen verstreut sind.

  3. Neuere Kernel erhöhen das Limit auf 1.024, 4.096 oder 8.192 Volumes.

    Theoretisch/dev/sdzzz....können Sie mit 29 s bis zu erreichen z, was ungefähr 10 41 Bänden entspricht, aber zuerst werden andere praktische Grenzen ins Spiel kommen.

Antwort2

Meines Wissens gibt es keine Begrenzung, und wenn es eine Begrenzung gibt, werden Sie diese wahrscheinlich nicht erreichen. Nach dem Durchlaufen aller sd[az] werden die Laufwerke mit sdaa bis sdazz usw. gekennzeichnet. Wenn es also eine Begrenzung gibt, dann ist es die Anzahl der Laufwerke, die das Schema innerhalb der maximalen Dateipfadlänge kennzeichnen kann (UUIDs könnten sich ändern, da bin ich mir nicht sicher).

Das gilt nur für IDE, SCSI, SATA und ähnliche. Ich glaube, für USB und andere gelten andere Beschränkungen.

verwandte Informationen