Vom Betriebssystem adressierbare Festplattengröße

Ich habe einen 3ware 9550SXU-12-Speichercontroller und 750G-Festplatten daran angeschlossen. Die Festplatten sind als einzelne Einheiten konfiguriert (nicht JBOD).

Ich habe einige Leistungstests durchgeführt, hauptsächlich um die Auswirkungen von Partitionsausrichtung, Verschlüsselung, RAID-Level usw. auf die Lese- / Schreib- / Iops-Leistung zu ermitteln.

Ich war überrascht, dass in meinem Fall die Lese- / Schreibleistung für dieselbe Speicherkonfiguration bei ausgerichteten Partitionen etwas geringer war als bei nicht ausgerichteten.

Dies veranlasste mich zu prüfen, ob es einen Unterschied gibt, wie die Festplatte für das Betriebssystem sichtbar ist, wenn eine Verbindung über den 3ware-Controller hergestellt wird und wenn der Port auf dem Motherboard verwendet wird, der überhaupt keine RAID-Unterstützung bietet.

Ich kenne die DCB-Metadaten (Disk Control Block), die 3ware-Controller auf den Datenträgern ablegen, um den Controller auszutauschen, ohne ihn neu konfigurieren zu müssen, wenn die Konfigurationsdaten aus dem DCB-Block auf den Datenträgern gelesen werden. Mein Controller verwendet das 'Neue Format', was anscheinend bedeutet, dass der Controller den DCB in die letzten 1024 LBAs der Festplatte schreibt.

Ich war interessiert zu sehen, ob meine Ausrichtungsbemühungen nicht durch den 3ware-Controller vereitelt wurden, der dem Betriebssystem nur einen Teil der Festplatte präsentiert.

Was ich gefunden habe:

• Der Anfang der Festplatte sieht genauso aus, wenn sie mit oder ohne 3ware-Controller verbunden ist. Die Ausrichtung sollte hier nicht beeinflusst werden. Verifiziert mit dd / md5sum.
• Die letzten 1024 * 512B der Festplatte enthalten tatsächlich etwas, das von 3ware dort abgelegt zu werden scheint (gemessen an den dort lesbaren Zeichenfolgen).
• Jetzt der interessante Teil: Unter 3ware-Kontrolle meldet die Festplatte eine Mediengröße von 749988741120 B und bei direkter Verbindung 750156374016 B, was bedeutet, dass das Betriebssystem bei einer Verbindung über den 3ware-Controller auf etwa 160 MB weniger Festplattenmedien zugreifen kann.

Es wäre verständlich, wenn es sich nur um einen Unterschied von 1024 x 512B (DCB) handeln würde, aber 160 MB scheinen etwas zu viel Speicherplatz für diese Art von Controller-Metadaten zu sein.

FRAGEN:

Weiß jemand, ob es andere Überlegungen beim Ausrichten von Paritionen auf Festplatten gibt, die an Controller angeschlossen sind, die die Einheitenkonfiguration auf diesen Festplatten speichern, die ich möglicherweise übersehen habe?

Aus Neugier - weiß jemand, wofür die letzten 160 MB Festplattenmedien verwendet werden?

Vielen Dank

Ich kann nicht direkt kommentieren, da ich mit 3ware nicht vertraut bin.

Im Allgemeinen bin ich jedoch auf einige Speicher-Arrays gestoßen, die Speicherplatz "stehlen". Es gibt verschiedene Gründe, darunter:

• Der Controller führt ein heruntergefahrenes Betriebssystem aus und benötigt Speicherplatz. (Konfiguration / Verwaltung usw.)
• Der Controller führt einen Schreibcache aus und muss im Falle eines Stromausfalls den Cache im Notfall leeren.
• Größennormalisierung, um geringfügige Abweichungen bei den Festplattengrößen zu ermöglichen.
• eine in der Steuerung eingebaute 'Zuordnungseinheit', die z. B. nur die Zuweisung fester Vielfacher zulässt. (Normalerweise auf Cache- / Paging-Grenzen ausgerichtet).

In Bezug auf die Ausrichtung - der einzige Grund, warum ich mir vorstellen kann, dass Ihre korrekte Ausrichtung langsamer ist, ist, wenn Ihr Controller auch die Ausrichtung übernimmt. Zunehmend sind Arrays / Controller dem Host-Betriebssystem bewusst - teilweise aufgrund der Notwendigkeit, SCSI-Flags korrekt zu setzen, aber auch aufgrund dieses Ausrichtungsproblems.

Wenn Ihr Array die Plattform Ihres Hosts kennt, wird die Ausrichtung möglicherweise bereits intern angepasst. (und indem Sie sich selbst ausrichten, haben Sie es erneut falsch ausgerichtet).