Der stat Befehlszeilentool verwendet den stat / fstat usw. Funktionen, die Daten in stat zurückgeben Struktur. Die st_blocks Mitglied der stat Struktur gibt zurück:
Die Gesamtzahl der physischen Blöcke mit einer Größe von 512 Byte, die tatsächlich auf der Festplatte zugewiesen wurden. Dieses Feld ist nicht für blockspezifische oder zeichenspezifische Dateien definiert.
Für Ihr Beispiel "E-Mail" mit einer Größe von 965 und einer Blockanzahl von 8 bedeutet dies, dass 8 * 512 =4096 Bytes physisch auf der Festplatte zugewiesen sind. Der Grund, warum es nicht 2 ist, ist, dass das Dateisystem auf der Festplatte keinen Speicherplatz in Einheiten von 512 zuweist, sondern offensichtlich in Einheiten von 4096. (Und die Einheit der Zuweisung kann je nach Dateigröße und Komplexität des Dateisystems variieren. ZFS unterstützt z. B. unterschiedliche Zuordnungseinheiten.)
In ähnlicher Weise zeigt es für das wxPython-Beispiel an, dass 7056 * 512 Bytes oder 3612672 Bytes physisch auf der Festplatte zugewiesen sind. Du verstehst schon.
Die IO-Blockgröße ist "ein Hinweis auf die 'beste' Einheitsgröße für I/O-Vorgänge" - es ist normalerweise die Einheit der Zuordnung auf der physischen Festplatte. Lassen Sie sich nicht zwischen dem IO-Block und dem Block stat verwechseln wird verwendet, um die physische Größe anzugeben; die Blöcke für die physikalische Größe sind immer 512 Bytes.
Aktualisierung basierend auf Kommentar:
Wie gesagt, st_blocks So zeigt das Betriebssystem an, wie viel Speicherplatz von der Datei auf der Festplatte verwendet wird. Die tatsächlichen Zuordnungseinheiten auf der Platte sind die Wahl des Dateisystems. Beispielsweise kann ZFS Zuordnungsblöcke variabler Größe haben, sogar in derselben Datei , aufgrund der Art und Weise, wie Blöcke zugewiesen werden:Dateien haben zunächst eine kleine Blockgröße, und die Blockgröße nimmt weiter zu, bis sie einen bestimmten Punkt erreicht. Wenn die Datei später abgeschnitten wird, behält sie wahrscheinlich die alte Blockgröße. Basierend auf dem Verlauf der Datei kann sie also mehrere mögliche Blockgrößen haben. Bei einer gegebenen Dateigröße ist es also nicht immer offensichtlich, warum sie eine bestimmte physische Größe hat.
Konkretes Beispiel:Auf meiner Solaris-Box mit einem ZFS-Dateisystem kann ich eine sehr kurze Datei erstellen:
$ echo foo > test
$ stat test
Size: 4 Blocks: 2 IO Block: 512 regular file
(irrelevant details omitted)
OK, kleine Datei, 2 Blöcke, physische Festplattenauslastung beträgt 1024 für diese Datei.
$ dd if=/dev/zero of=test2 bs=8192 count=4
$ stat test2
Size: 32768 Blocks: 65 IO Block: 32768 regular file
OK, jetzt sehen wir eine physische Festplattennutzung von 32,5 KB und eine IO-Blockgröße von 32 KB. Ich habe es dann nach test3 kopiert und diese test3 abgeschnitten Datei in einem Editor:
$ cp test2 test3
$ joe -hex test3
$ stat test3
Size: 4 Blocks: 65 IO Block: 32768 regular file
Nun, hier ist eine Datei mit 4 Bytes darin - genau wie test - aber es verwendet physisch 32,5 KB auf der Festplatte, aufgrund der Art und Weise, wie das ZFS-Dateisystem Speicherplatz zuweist. Die Blockgröße nimmt zu, wenn die Datei größer wird, sie nimmt jedoch nicht ab, wenn die Datei kleiner wird. (Und ja, dies kann je nach Art der Dateien und Dateioperationen, die Sie auf ZFS ausführen, zu erheblicher Speicherplatzverschwendung führen, weshalb Sie die maximale Blockgröße pro Dateisystem festlegen und dynamisch ändern können.)
Hoffentlich können Sie jetzt verstehen, dass es nicht unbedingt eine einfache Beziehung zwischen Dateigröße und Nutzung der physischen Festplatte gibt. Selbst im obigen ist nicht klar, warum 32,5 KB benötigt werden, um eine Datei mit einer Größe von genau 32 KB zu speichern - es scheint, dass ZFS im Allgemeinen zusätzliche 512 Byte für zusätzlichen eigenen Speicher benötigt. Vielleicht verwendet es diesen Speicher für Prüfsummen, Referenzzählungen, Transaktionsstatus - Dateisystembuchhaltung. Durch die Einbeziehung dieser Extras in die angegebene physische Dateigröße scheint ZFS zu versuchen, den Benutzer nicht über die physischen Kosten der Datei zu täuschen. Das bedeutet nicht, dass es trivial ist, die Berechnung rückzuentwickeln, ohne intime Details über die zugrunde liegende Dateisystemimplementierung zu kennen.