Il stat lo strumento a riga di comando usa stat / fstat ecc., che restituiscono dati nel stat struttura. Il st_blocks membro del stat struttura restituisce:
Il numero totale di blocchi fisici di dimensione 512 byte effettivamente allocati su disco. Questo campo non è definito per i file block special o character special.
Quindi per il tuo esempio "Email", con una dimensione di 965 e un conteggio di blocchi di 8, indica che 8*512=4096 byte sono allocati fisicamente su disco. Il motivo per cui non è 2 è che il file system su disco non alloca lo spazio in unità di 512, evidentemente li alloca in unità di 4096. (E l'unità di allocazione può variare a seconda della dimensione del file e della sofisticazione del file system. Ad esempio, ZFS supporta diversi unità di allocazione.)
Allo stesso modo, per l'esempio wxPython, indica che 7056*512 byte o 3612672 byte sono allocati fisicamente su disco. Hai capito.
La dimensione del blocco IO è "un suggerimento sulla 'migliore' dimensione dell'unità per le operazioni di I/O" - di solito è l'unità di allocazione sul disco fisico. Non confonderti tra il blocco IO e il blocco che stat utilizza per indicare la dimensione fisica; i blocchi per dimensione fisica sono sempre 512 byte.
Aggiornamento basato sul commento:
Come ho detto, st_blocks è il modo in cui il sistema operativo indica quanto spazio viene utilizzato dal file su disco. Le effettive unità di allocazione su disco sono scelte dal file system. Ad esempio, ZFS può avere blocchi di allocazione di dimensioni variabili, anche nello stesso file , a causa del modo in cui alloca i blocchi:i file iniziano con una piccola dimensione del blocco e la dimensione del blocco continua ad aumentare fino a raggiungere un punto particolare. Se il file viene successivamente troncato, probabilmente manterrà la vecchia dimensione del blocco. Quindi, in base alla cronologia del file, può avere più dimensioni di blocco possibili. Quindi data la dimensione di un file non è sempre ovvio il motivo per cui ha una particolare dimensione fisica.
Esempio concreto:sulla mia macchina Solaris, con un file system ZFS, posso creare un file molto breve:
$ echo foo > test
$ stat test
Size: 4 Blocks: 2 IO Block: 512 regular file
(irrelevant details omitted)
OK, file piccolo, 2 blocchi, l'utilizzo del disco fisico è 1024 per questo file.
$ dd if=/dev/zero of=test2 bs=8192 count=4
$ stat test2
Size: 32768 Blocks: 65 IO Block: 32768 regular file
OK, ora vediamo un utilizzo del disco fisico di 32,5K e una dimensione del blocco IO di 32K. L'ho quindi copiato in test3 e troncato questo test3 file in un editor:
$ cp test2 test3
$ joe -hex test3
$ stat test3
Size: 4 Blocks: 65 IO Block: 32768 regular file
Bene, ecco un file con 4 byte al suo interno, proprio come test - ma utilizza fisicamente 32,5 K sul disco, a causa del modo in cui il file system ZFS alloca lo spazio. Le dimensioni dei blocchi aumentano man mano che il file diventa più grande, ma non diminuiscono quando il file diventa più piccolo. (E sì, questo può portare a uno spreco di spazio sostanziale a seconda del tipo di file e delle operazioni sui file che esegui su ZFS, motivo per cui ti consente di impostare la dimensione massima del blocco in base al filesystem e di modificarla dinamicamente.)
Si spera che ora tu possa apprezzare che non esiste necessariamente una semplice relazione tra le dimensioni del file e l'utilizzo del disco fisico. Anche in quanto sopra non è chiaro il motivo per cui sono necessari 32,5 K byte per archiviare un file di dimensioni esattamente 32 K:sembra che ZFS abbia generalmente bisogno di 512 byte extra per l'archiviazione aggiuntiva. Forse sta usando quell'archiviazione per checksum, conteggi dei riferimenti, stato delle transazioni - contabilità del file system. Includendo questi extra nella dimensione fisica del file indicata, sembra che ZFS stia cercando di non fuorviare l'utente sui costi fisici del file. Ciò non significa che sia banale decodificare il calcolo senza conoscere dettagli intimi sull'implementazione del file system sottostante.