¿Cómo calcula el comando stat los bloques de un archivo?

Question

Me pregunto cómo el comando stat calcula los bloques de un archivo. He leído el article, que dice:

Los st_blocks valor da el tamaño del archivo en bloques de 512 bytes. (Esto puede ser más pequeño que st_size/512, por ejemplo, cuando el archivo tiene agujeros). El valor st_blksize da el tamaño de bloques "preferido" para una E/S eficiente del sistema de archivos. (Escribir en un archivo en trozos más pequeños puede causar una ineficaz lectura-modificación-reescritura.)

pero no puedo verificarlo en mi prueba.

mi sistema de archivos es ext3.

los dumpe2fs -h/dev/sda3 muestra:

... 
First block: 0 
Block size: 4096 
Fragment size: 4096 
... 

Luego ejecutar

kent@KentT60:~/Desktop$ stat Email 
File: `Email' 
Size: 965 Blocks: 8 IO Block: 4096 regular file 
Device: 80ah/2058d Inode: 746095 Links: 1 
Access: (0644/-rw-r--r--) Uid: (1000/ kent) Gid: (1000/ kent) 
Access: 2009-08-11 21:36:36.000000000 +0200 
Modify: 2009-08-11 21:36:35.000000000 +0200 
Change: 2009-08-11 21:36:35.000000000 +0200 

Si Bloques aquí significa: ¿cuántos bloques 512bytes, el número debe ser de 2 No 8. Yo pensó que, el tamaño de bloques del sistema de archivos (bloque io) es 4k. Si fs obtendrá el archivo Correo electrónico, obtendrá un mínimo de 4k del disco (bloques de 8 x 512 bytes), lo que significa 965/512 + 6 = 8. No estoy seguro si la suposición es correcta.

otra prueba:

kent@KentT60:~/Desktop$ stat wxPython-demo-2.8.10.1.tar.bz2 
File: `wxPython-demo-2.8.10.1.tar.bz2' 
Size: 3605257 Blocks: 7056 IO Block: 4096 regular file 
Device: 80ah/2058d Inode: 746210 Links: 1 
Access: (0644/-rw-r--r--) Uid: (1000/ kent) Gid: (1000/ kent) 
Access: 2009-08-12 21:45:45.000000000 +0200 
Modify: 2009-08-12 21:43:46.000000000 +0200 
Change: 2009-08-12 21:43:46.000000000 +0200 


3605257/512=7041.xx = 7042 

siguiente mi suposición anterior, esto sería 7042 + 6 = 7048. pero el resultado muestra stat 7056.

Y otro ejemplo de internet en http://www.computerhope.com/unix/stat.htm. Copio el ejemplo en la parte inferior de la página aquí:

File: `index.htm' 
Size: 17137 Blocks: 40 IO Block: 8192 regular file 
Device: 8h/8d Inode: 23161443 Links: 1 
Access: (0644/-rw-r--r--) Uid: (17433/comphope) Gid: (32/ www) 
Access: 2007-04-03 09:20:18.000000000 -0600 
Modify: 2007-04-01 23:13:05.000000000 -0600 
Change: 2007-04-02 16:36:21.000000000 -0600 

En este ejemplo, FS tamaño de bloque es 8k. Supongo que el número de bloque debe ser 16xN, pero es 40. perderse ...

cualquiera puede explicar cómo calcula el stat los bloques?

Gracias!

Answer 1

La herramienta de línea de comandos stat utiliza los stat/fstat etc. funciones, que devuelven datos en la estructura de stat. El st_blocks miembro de las stat estructura de retornos:

el número total de bloques físicos de tamaño de 512 bytes realmente asignado en el disco. Este campo no está definido para archivos especiales de bloque o especiales de caracteres.

Por lo tanto, para su ejemplo de "Correo electrónico", con un tamaño de 965 y un conteo de bloques de 8, indica que 8 * 512 = 4096 bytes están físicamente asignados en el disco. La razón por la que no es 2 es que el sistema de archivos del 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 forma similar, para el ejemplo de wxPython, indica que 7056 * 512 bytes, o 3612672 bytes, están físicamente asignados en el disco. Entiendes la idea.

El tamaño del bloque IO es "una pista sobre el 'mejor' tamaño de unidad para las operaciones de E/S" - por lo general, es la unidad de asignación en el disco físico. No se confunda entre el bloque IO y el bloque que stat usa para indicar el tamaño físico; los bloques para el tamaño físico siempre son 512 bytes.

Actualización basada en comentario:

Como dije, st_blocks es cómo el sistema operativo indica la cantidad de espacio utilizado por 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 los tamaños de bloque siguen aumentando hasta que llega a un punto particular. Si el archivo se trunca posteriormente, probablemente mantendrá el antiguo tamaño del bloque. Por lo tanto, según el historial del archivo, puede tener múltiples tamaños de bloques 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, que puede crear un archivo muy corto:

$ echo foo > test 
$ stat test 
    Size: 4    Blocks: 2   IO Block: 512 regular file 
(irrelevant details omitted) 

bien, pequeño archivo, 2 manzanas, uso de 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 el uso del disco físico de 32.5K, y un tamaño de bloque IO de 32K. a continuación, lo copié a test3 y truncadas este archivo test3 en un editor:

$ cp test2 test3 
$ joe -hex test3 
$ stat test3 
    Size: 4    Blocks: 65   IO Block: 32768 regular file 

Ahora bien, aquí hay un archivo con 4 bytes en que - al igual que test - pero es el uso de 32.5K físicamente en el disco, a causa de la forma en que el sistema de archivos ZFS asigna espacio. Los tamaños de bloques aumentan a medida que el archivo aumenta, pero no disminuyen cuando el archivo se hace más pequeño. (Y sí, esto puede generar un desperdicio de espacio sustancial según los tipos de archivos y operaciones de archivos que realice en ZFS, por lo que le permite establecer el tamaño máximo de bloque por sistema de archivos y cambiarlo dinámicamente).

Esperamos que ahora tenga en cuenta 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.5K bytes para almacenar un archivo que tiene exactamente 32K de tamaño, parece que ZFS generalmente necesita 512 bytes adicionales para almacenamiento adicional propio. Tal vez esté usando ese almacenamiento para sumas de verificación, recuentos de referencia, estado de la transacción, 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 sobre los costos físicos del archivo. Eso no significa que sea trivial realizar una ingeniería inversa del cálculo sin conocer detalles íntimos sobre la implementación del sistema de archivos subyacente.