NTFS Blocksize ermitteln

64k Blocksize für bessere Leistung

Für Partitionen, auf denen beispielsweise Veeam-Backups, SQL-Datenbanken oder SQL-Logs liegen, sollten für bessere Leistung mit einer 64k Blockgröße formatiert sein. Dies lässt sich schnell mit einem Befehl überprüfen.

CMD-Shell als Administrator starten.

fsutil fsinfo ntfsinfo <Drive>

Beispiel für die Systempartition:

fsutil fsinfo ntfsinfo C:
NTFS-Volumeseriennummer : 0xa892e42c92e400a4
Version : 3.1
Anzahl der Sektoren : 0x000000001dc807ff
Gesamtzahl Cluster : 0x0000000003b900ff
Freie Cluster : 0x0000000000b42c71
Insgesamt reserviert : 0x0000000000000ff0
Bytes pro Sektor : 512
Bytes pro physischen Sektor : 512
Bytes pro Cluster : 4096
Bytes pro Dateidatensatzsegment : 1024
Cluster pro Dateidatensatzsegment : 0
MFT-gültige Datenlänge : 0x0000000017180000
MFT-Start-LCN : 0x00000000000c0000
MFT2-Start-LCN : 0x0000000000000002
MFT-Zonenstart : 0x0000000000eb7240
MFT-Zonenende : 0x0000000000eb9340
RM-Bezeichner: FFFF0956-A102-11E7-87BD-005056C00008

Wir sehen “Bytes pro Cluster: 4096”. Das sind 4KB.

Skript

Um die Blockgrößen aller lokalen Laufwerke zu ermitteln, kann man folgendes Skript verwenden, das Stuart Moore gepostet hatte:

$wql = "SELECT Label, Blocksize, Name FROM Win32_Volume WHERE FileSystem='NTFS'"
Get-WmiObject -Query $wql -ComputerName '.' | Select-Object Label, Blocksize, Name

Links

Stuart Moore – Get Cluster size for all disks and volumes on a Windows machine using powershell and wmi

Veeam Backup & Replication Best Practices

Different Blocksizes are evil!

Geahnt habe ich das schon immer, aber heute durfte ich das selbst miterleben. Storage vMotion von einem Volume (8MB Blocksize) auf ein frisch mit vmfs5 formatiertes Volume (1MB Blocksize). Zwanzig Gigabyte verschieben kann quälend langsam sein. Eine gleichgroße VM zwischen zwei LUNs mit gleicher Blockgröße dauerte nur einen Bruchteil der Zeit!

svMotion mit unterschiedlicher Blocksize
VM Protokoll LUN Source LUN Target Zeit [min]
 20 GB  FC 4Gbit  SAS 15k 8MB  SAS 15k 1MB  23
 20 GB  FC 4GBit  SAS 15k 8MB  SAS 15k 8MB  3

Wie kommt es zu derart frappierenden Unterschieden bei svMotion?

Die Ursache liegt in der Verwendung der unterschiedlichen Datamover, die vSphere5 für svMotion verwendet. Wenn die Storage kein Hardware Offload unterstützt, dann stehen zwei Datamover zur Auswahl:

  • fsdm der Standard Datamover. Liest den Block in den Applikationspuffer (svMotion) und schreibt diesen dann zum Ziel.
  • fs3dm : optimierter Datamover, der mit vSphere4 eingeführt wurde. Er Verschiebt die Daten auf Hypervisor Ebene unter Umgehung des Applikationspuffers.

Sobald Quelle und Ziel unterschiedliche Blockgrößen haben, fällt vSphere zurück auf den Standard Datamover fsdm. Die Blöcke werden gelesen und wegen unterschiedlicher Blockgröße an Quelle und Ziel neu organisiert, bevor sie geschrieben werden.

Ein sehr schöner Artikel hierzu erschien unter dem Titel “Blocksize impact” bei Yellow-Bricks und ein weiterer bei Frank Denneman unter dem Titel “Upgrading VMFS Datastores and SDRS