WMI: BytesPerSectors einer Festplatte ermitteln

[Glados]

Ich komme gerade nicht weiter. Ich versuche die Sektorgröße einer Festplatte zu ermitteln.
Das Problem für mich jetzt ist, dass Win32_Volume zwar DriveLetter kennt, aber nicht BytesPerSector.
Dafür kennt Win32_DiskDrive BytesPerSector, aber nicht DriveLetter.
DriveLetter brauche ich aber um einen Vergleich anstellen zu können.

Das hier ist mein Code bisher (99% von WMI Code Ceator).
Ich habe Festplatte C (SanDisk SSD) und D (Seagate HDD).

Wenn ich im Aufruf unten "D" übergebe, zeigt mir die Showmessage als DriveLetter tatsächlich D, aber der Rest zeigt Daten meiner SSD (Caption).

Delphi-Quellcode:

procedure GetVolumeSectorSize(Volume: string);
 function GetWMIObject(const objectName: string): IDispatch;
 var
  chEaten: Integer;
  BindCtx: IBindCtx; // for access to a bind context
  Moniker: IMoniker; // Enables you to use a moniker object
 begin
  OleCheck(CreateBindCtx(0, BindCtx));
  OleCheck(MkParseDisplayName(BindCtx, StringToOleStr(objectName), chEaten, Moniker)); // Converts a string into a moniker that identifies the object named by the string
  OleCheck(Moniker.BindToObject(BindCtx, nil, IDispatch, Result)); // Binds to the specified object
 end;

var
 FWMIService, FWMIServiceEx: OLEVariant;
 FWbemObjectSet, FWbemObjectSetEx: OLEVariant;
 oEnum, oEnumEx: IEnumvariant;
 iValue, iValueEx: LongWord;
begin;
 Volume := Trim(Volume);

 if Volume = '' then
  Exit;

 FWMIService := GetWMIObject(Format('winmgmts:\\%s\%s', ['.', 'root\CIMV2']));
 FWbemObjectSet := FWMIService.ExecQuery(Format('SELECT * FROM %s WHERE DriveLetter=%s', ['Win32_Volume ', QuotedStr(Volume + ':')]), 'WQL', 0);
 oEnum := IUnknown(FWbemObjectSet._NewEnum) as IEnumvariant;

 if oEnum.Next(1, FWbemObjectSet, iValue) = 0 then
  begin
   FWMIServiceEx := GetWMIObject(Format('winmgmts:\\%s\%s', ['.', 'root\CIMV2']));
   FWbemObjectSetEx := FWMIServiceEx.ExecQuery(Format('SELECT * FROM %s', ['Win32_DiskDrive']), 'WQL', 0);
   oEnumEx := IUnknown(FWbemObjectSetEx._NewEnum) as IEnumvariant;

   while oEnumEx.Next(1, FWbemObjectSetEx, iValueEx) = 0 do
    begin
     ShowMessage(string(FWbemObjectSet.Properties_.Item('DriveLetter', 0)) + sLineBreak + string(FWbemObjectSetEx.Properties_.Item('Caption', 0)) + ': ' + Format('BytesPerSector    %d',
      [Integer(FWbemObjectSetEx.Properties_.Item('BytesPerSector', 0))]));
    end;
  end;
end;

CoInitialize(nil);
try
 GetVolumeSectorSize('D');
finally
 CoUninitialize;
end;

Resultat

Zitat:

D:
SanDis SDSSDHII120G SCSI Disk Device: BytesPerSector 512

[p80286]

Darf ich mal fragen, warum Dich der Wert interessiert?
wenn Du nicht gerade einen Treiber programmierst, dann ist die Sektorgröße für Dich relativ uninteressant. viel interessanter ist die Clustergröße.
Bei der Sektorgröße muß man in der Zwischenzeit fragen welche gemeint ist, die logische oder die physische.
Es gibt in der Zwischenzeit Datenträger, deren physische Sektorgröße z.b. 4k ist, deren Kontroller jedoch nach außen mit der klassischen Größe 512 Byte operiert.

Gruß
K-H

[Towmuz]

Moin,

schau doch mal in diese Klasse,

Code:

Win32_PerfRawData_PerfDisk_PhysicalDisk

, über "DiskBytesPersec" bekommst du wohl den gesuchten Wert,
über "Name" wird dir der Einhängepunkt und die zugehörigen Partitionen in einem string ausgegeben.

Für die Partitionen selbst gibt´s auch

Code:

Win32_PerfRawData_PerfDisk_LogicalDisk

.

[Glados]

Zitat:

wenn Du nicht gerade einen Treiber programmierst, dann ist die Sektorgröße für Dich relativ uninteressant. viel interessanter ist die Clustergröße.

Ich möchte herausfinden, ob man meine Datrei-kopier-funktion mit der richtigen Buffergröße verbessern kann.

Wäre das dann die Clustergröße?

[p80286]

Ja

aber es gibt noch Auswirkungen von Cache und oder Datentransferraten etc.
Darum ist eine Aussage wie "wenn der Buffer so groß wie das Cluster ist, hab ich ein Optimum an Performance" nicht unbedingt richtig. Es ist ein brauchbarer Kompromiss. Je nach Medium/Rechner/Konfiguration ist das Optimum etwas ganz anderes.
Nach meiner Erfahrung bringen mehr als 12k Buffer bei Dateien, die über's Netz kommen überhaupt nichts, während Festplatten durchaus 32,64,..K Buffer mögen.
Aber das sind ganz grobe Werte, die mit Deiner Situation überhaupt nicht korrelieren müssen.

Gruß
K-H

[himitsu]

Und wofür wird das eigentlich benötigt?

Manchmal kann man einfach auch feste Werte verwenden, die fast überall gut funktionieren. (z.B. 32kb oder 64kb)

Abgesehn von den verschiedenen Caches der Speichercontroller, des Bus-Systems, der CPU, des OS (WindowsFileCache) usw,
ist ein Datenträger mehrfach geteilt.

Sector (kleinste Aufteilung des Datenträgers ... gerade bei SSD oder USB-Stick ist der oft nur virtuell)
Cluster (Einteilung im Dateisystem)
Blocks (reale Einteilung einer SSD, denn die Löschfunktion kann nur größere Bereiche auf einmal löschen, bzw. sie ist nur in "kleinerer" Anzahl verbaut)
Die sind jeweils ein Vielfaches der Sektoren, bzw. von 512 (aber theoretisch ist jeder Wert möglich)

Zitat:

Bei der Sektorgröße muß man in der Zwischenzeit fragen welche gemeint ist, die logische oder die physische.

Jupp, theoretisch ist es vorgesehn, dass Hardware anderer Größen verwenden kann, aber aus kompatibilitätsgründen mit schrottiger Hardware (Speichercontrollern) und Sorftware tuen viele Speicher so, als wenn sie mit den "manchmal" hardcodierten 512 Byten arbeiten, aber eigentlich arbeiten sie "physisch" mit einer anderen Größe und sagen dem System nur, dass sie "logisch" anders unterteilt wären.
Gerade bei großen TB-Festplatten und Speichersicks wird intern mit weniger "größeren" Sektoren gearbeitet, aber dem System wird über einen zwischengeschateten Cache vorgegaukelt, es wären 512 Byte per Sektor.

Festplatten mit z.B. 4-64KB pro Sektor sind schon länger im Umlauf und CD/DVD (2048 B) hat schon immer eine andere Sectorgröße.
Wobei CDs eigentlich real sogar 2352 Bytes pro Sektor haben (inkl. Zusatzdaten) :stupid:


Gerade bei gibt es für Speicherchips einen großen Unterschied zwischen Lesen und Schreiben, wo die Sectorgröße fast garnichts hilft.

Wo man unbedingt auf Sectoren achten muß, ist beim Lesen/Schreiben ohne Buffer/Cache, da dort kein Cache existiert und man somit ausschließlich nur ganze "Blöcke" verarbeiten kann.


Zusätzlich dann noch die Speicherausrichtung (Beispiel auf dem Datenträger, aber auch im RAM/Cache gibt es sowas)
https://www.thomas-krenn.com/de/wiki...tion_Alignment

Und am Ende kommen dann nicht nur die Minimalgrößen, sondern auch system-/zustandsabhängige Maximalgrößen zum Einfuss ... sonst könnte man auch einfach immer 32MB oder gar 1GB nehmen was im normalfall immer ein Vielfaches der Sector/Cluster/Blocks wäre.