El stat la herramienta de línea de comandos usa el stat / fstat etc. funciones, que devuelven datos en el stat estructura. El st_blocks miembro de los stat la estructura devuelve:
El número total de bloques físicos de tamaño 512 bytes realmente asignados en el disco. Este campo no está definido para archivos especiales de bloques o caracteres especiales.
Entonces, para su ejemplo de "Correo electrónico", con un tamaño de 965 y un recuento de bloques de 8, indica que 8 * 512 =4096 bytes están asignados físicamente en el disco. La razón por la que no es 2 es que el sistema de archivos en el disco no asigna espacio en unidades de 512, evidentemente las asigna en unidades de 4096. (Y la unidad de asignación puede variar según el tamaño del archivo y la sofisticación del sistema de archivos. Por ejemplo, ZFS admite diferentes unidades de asignación).
De manera similar, para el ejemplo de wxPython, indica que 7056*512 bytes o 3612672 bytes están asignados físicamente en el disco. Entiendes la idea.
El tamaño del bloque de E/S es "una pista sobre el 'mejor' tamaño de unidad para las operaciones de E/S"; generalmente es la unidad de asignación en el disco físico. No te confundas entre el bloque IO y el bloque que stat utiliza para indicar el tamaño físico; los bloques de tamaño físico son siempre de 512 bytes.
Actualización basada en el comentario:
Como dije, st_blocks es cómo el sistema operativo indica cuánto espacio utiliza el archivo en el disco. Las unidades reales de asignación en el disco son la elección del sistema de archivos. Por ejemplo, ZFS puede tener bloques de asignación de tamaño variable, incluso en el mismo archivo , debido a la forma en que asigna los bloques:los archivos comienzan con un tamaño de bloque pequeño y el tamaño del bloque sigue aumentando hasta que llega a un punto determinado. Si el archivo se trunca más tarde, probablemente mantendrá el tamaño de bloque anterior. Entonces, según el historial del archivo, puede tener múltiples tamaños de bloque posibles. Entonces, dado el tamaño de un archivo, no siempre es obvio por qué tiene un tamaño físico particular.
Ejemplo concreto:en mi caja de Solaris, con un sistema de archivos ZFS, puedo crear un archivo muy corto:
$ echo foo > test
$ stat test
Size: 4 Blocks: 2 IO Block: 512 regular file
(irrelevant details omitted)
Bien, archivo pequeño, 2 bloques, el uso del disco físico es 1024 para este archivo.
$ dd if=/dev/zero of=test2 bs=8192 count=4
$ stat test2
Size: 32768 Blocks: 65 IO Block: 32768 regular file
Bien, ahora vemos un uso del disco físico de 32,5 K y un tamaño de bloque de E/S de 32 K. Luego lo copié a test3 y truncó este test3 archivo en un editor:
$ cp test2 test3
$ joe -hex test3
$ stat test3
Size: 4 Blocks: 65 IO Block: 32768 regular file
Bueno, ahora, aquí hay un archivo con 4 bytes, como test - pero está usando 32.5K físicamente en el disco, debido a la forma en que el sistema de archivos ZFS asigna espacio. Los tamaños de los bloques aumentan a medida que el archivo se hace más grande, pero no disminuyen cuando el archivo se hace más pequeño. (Y sí, esto puede conducir a una pérdida sustancial de espacio según los tipos de archivos y las operaciones de archivo que realice en ZFS, razón por la cual le permite establecer el tamaño máximo de bloque por sistema de archivos y cambiarlo dinámicamente).
Con suerte, ahora puede apreciar que no existe necesariamente una relación simple entre el tamaño del archivo y el uso del disco físico. Incluso en lo anterior, no está claro por qué se necesitan 32,5 K bytes para almacenar un archivo que tiene exactamente un tamaño de 32 K; parece que ZFS generalmente necesita 512 bytes adicionales para su propio almacenamiento adicional. Tal vez esté usando ese almacenamiento para sumas de verificación, recuentos de referencia, estado de transacciones, contabilidad del sistema de archivos. Al incluir estos extras en el tamaño de archivo físico indicado, parece que ZFS intenta no engañar al usuario en cuanto a los costos físicos del archivo. Eso no significa que sea trivial aplicar ingeniería inversa al cálculo sin conocer detalles íntimos sobre la implementación del sistema de archivos subyacente.