VMware-Forum

Ahoi zusammen,

bin grad eben in einer Lab-Umgebung ueber ein Infortrend iSCSI Storage gestolpert, dessen LUNs Storage-seitig mit 4k Block Size angelegt waren. Im vSphere Client nen VMFS drueberzulegen war nicht moeglich ("failed to get disk partition information"). Die LUNs hatten keinen bereits existierenden Partition Table, an dem sich ESX haette verschlucken koennen. Anbindung der ESXe laeuft ueber den Software Initiator. Die Block Size Storage-seitig auf 512 Byte runtergedreht, schon gings Anlegen ohne Probleme.

Hat jemand von euch schonmal dergleichen gesehen bzw. weiss woher die anscheinende Limitierung ruehrt?

Das läßt sich auf alle neueren HDDs mit einer Blocksize ungleich 512Byte beobachten. Davon können nur die neuesten Linux-Kernel 2.6.34+ oder/und nur W2k8-R2 booten. Die Plattenhersteller haben diesen in meinen Augen falschen Weg eingeschlagen, um Platten mit mehr als 2TB adressieren zu können und trotzdem bei 32bittigen LBA bleiben zu können. Im Endeffekt gehen die Hersteller damit dem Ärger mit Benutzer von GPT und 64bit-Systemen aus dem Weg. Die Treiberqualität der 64bit-OS hat sich in den letzten Jahren wesentlich erhöht und eigentlich wären diese Klimmzüge daher eigentlich nicht mehr nötig.

Diese Änderung der Blockgröße läßt sich daher am treffensten mit IPv6 vergleichen. Es gibt einen eingeführten Nachfolger und trotzdem wird am alten (IPv4) festgehalten und dazu sogar einige Bits umdeklariert, nur um den Zeitpunkt der unausweichlichen Umstellung hinauszuzögern.

Macht Sinn, dann kann der vmkernel die 4k Block Size wohl einfach noch nicht ab. Besten Dank fuer die Antwort!

Ergaenzend zum Thema: Hab eben mal nach ein paar Artikeln zum Thema 4k Bloecke im Allgemeinen und der Motivation dazu gesucht. Im Vordergrund stand bei den Artikeln eigentlich immer ECC, was bei steigenden Datendichten und somit mehr benoetigten ECC-Bits durch die Verwendung von 4k Bloecken deutlich platzeffizienter wird. Ermoeglichts den Plattenherstellern, mehr Platz aus ihren Platten zu kitzeln. In Zahlen: 81% Nutzbloecke @ 512 Byte, 96% Nutzbloecke @ 4 KByte. Lesenswerter Artikel z.B. hier http://www.anandtech.com/show/2888

Fuer die OS-Hersteller, Treiber-Bauer und Tool-Programmier ists natuerlich klar bloed, weil die schauen duerfen, wie sie mit den 4k auf diversen Layern umgehen. Das dabei die Problematik MBR, 32-Bit LBA und max. 2TB (Boot-)Volumen gleich mit erschlagen wuerde, ist wohl nur nen kleiner Trost am Rande ...

Mit GPT hätten sie diese Probleme aber auch nicht, leider sprechen nicht alle noch aktuellen 32bit-OS schon GPT. Die inzwischen schon älteren Versuche der c't mit einem 6TB-NAS endeten fast immer in kompletten Datenverlust, da die meisten OS davon nur die Größe modulo 2 sahen.

"Für die OS-Hersteller, Treiber-Bauer und Tool-Programmierer" gilt es jetzt dasselbe Problem wie schon bei GPT zu umschiffen. Ohne Anpassung an eine geänderte Blockgrösse verursachen sämtlich Lowlevel-Programme nur noch Datensalat.

ACK, also zwei Baustellen gleichzeitig zu beackern. OS/Treiber/Tools wg. Platten >2TB mit GPT verheiraten und jetzt auch noch 4K kompatibel machen, weil die Plattenhersteller weniger Verschnitt und bessere Fehlerkorrektur wollen. Mei ist das schön, dass ich keiner betroffenen Gruppe angehöre Wenn ich das richtig gelesen habe, gibts bei den 4K-Platten immerhin vorübergehende Zugeständnisse in Form von 512B -> 4K Mappings. Somit ham die Entwicklern ne Schonfrist und wir was zu tun (das eh schon populäre Thema Block Alignment ... http://lwn.net/Articles/377895/ oder im Artikel von oben). Lustig, was man nicht so alles lernt, wenn man mal kurz mitm iSCSI Storage im Lab rumspielen will

Die Zugeständnisse beim Mapping und Block-Alignment sind aber von zweifelhafter Natur. Sobald der betreffende Schalter/Jumper mal vergessen wird, was beim HW-Ausfall im Eifer des Gefechts durchaus passieren kann, gibt es wieder Datensalat.
Ich könnte mir auch vorstellen, daß an variable Blocksize und Block-Alignment angepaßte SW Probleme mit solchen Jumperaktivierten Laufwerken bekommt.