Crecimiento monótono del tamaño del directorio Linux / recuento de bloques


8

En Linux, (tal vez como una función del tamaño de bloque del sistema de archivos), cuando creo un directorio y statéste devuelve un tamaño de 4096. Puedo crear archivos en este directorio, hasta cierto punto, sin aumentar el tamaño percibido del directorio (según lo informado por stat).

En algún momento, a medida que el directorio se llena con muchos archivos, el tamaño del directorio aumenta (no estoy hablando del contenido del directorio, estoy hablando de los bloques consumidos para representar el directorio en sí). Si se eliminan los archivos, el tamaño del directorio sigue siendo el mismo.

Aquí hay un ejemplo rápido:

[root@uxlabtest:/]$ mkdir test
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:04.000000000 -0400
Change: 2011-07-26 14:06:04.000000000 -0400

Luego toca un montón de archivos:

[root@uxlabtest:/]$ for i in `seq 1 10000`; do touch /test/$i; done
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:56.000000000 -0400
Change: 2011-07-26 14:06:56.000000000 -0400

Luego borre los archivos:

[root@uxlabtest:/]$ rm -rf /test/*
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:07:11.000000000 -0400
Modify: 2011-07-26 14:07:12.000000000 -0400
Change: 2011-07-26 14:07:12.000000000 -0400

Mis preguntas son:

  • ¿Por qué el tamaño / bloque de conteo de un directorio aumenta monotónicamente?
  • ¿Es esta una función del sistema de archivos subyacente o de Linux VFS?
  • ¿Se puede reducir el tamaño del directorio sin eliminar y volver a crear el directorio?
  • Puntos de bonificación: apunte al código fuente del núcleo donde se implementa este comportamiento.

No estoy realmente seguro de por qué esto es rechazado. Estas son preguntas legítimas, claramente expresadas con comandos dados para replicar el escenario. Las respuestas a estas preguntas satisfarían el conocimiento de la comunidad y serían útiles para documentarlas en alguna parte.
loopforever

Respuestas:


9

Aquí están las respuestas que son verdaderas para ext2 / ext3 / ext4. Si son ciertos para otros sistemas de archivos depende de su implementación.

  1. user48838 respondió este correctamente. Más archivos consumen más metadatos. Se asignan en fragmentos de 4k o en cualquier otro tamaño definido en el momento de la creación del sistema de archivos
  2. Sí, es una característica / problema del sistema de archivos real
  3. En un sistema de archivos ext3 esto no es posible. Solo recreando el directorio (vacío)
  4. El código fuente está por aquí y en archivos relacionados.

Pero tienes suerte. Cuando recrea la misma cantidad de archivos que ya eliminó, el tamaño del directorio seguirá siendo el mismo. Solo cuando agregue más archivos, aumentará.


1
Una cosa: "e2fsck -fD" debe compactar cada directorio en un sistema de archivos ext2 / 3. Esto puede hacer lo que desea el OP, aunque sospecho que es lento, y el sistema de archivos debe estar fuera de línea. Esto probablemente lleva más tiempo que vincular cada archivo en un nuevo directorio y eliminar los antiguos.
akramer

4

Los incrementos de bloque que está viendo se deben a cómo el sistema de archivos administra su almacenamiento de archivos y la información de administración de archivos relacionada. En su situación descrita, eso parecería incrementos de 4K, por lo que cada entrada "nueva" / "única" en el sistema de archivos reservará 4K, ya sea que el tamaño real de los datos llene todo el 4K. Si los datos relacionados ocupan todo el 4K, entonces otro bloque de 4K se reserva y se llena según sea necesario para almacenar todo el flujo / secuencia de datos relacionados.

Dependiendo de las eliminaciones "duras" frente a las "suaves" administradas por el sistema de archivos, es posible que la eliminación (por lo general no para la funcionalidad "recuperar") libere inmediatamente los bloques que se reservaron. Algunos sistemas de archivos pueden diferenciar diferentes tipos de "eliminaciones" y proporcionar las capacidades de administración de bloques de almacenamiento correspondientes.

La forma en que se aborda e implementa la gestión de almacenamiento difiere según los sistemas de archivos, por lo que en los sistemas operativos que admiten sistemas de archivos múltiples / modulares, el sistema operativo generalmente solo proporcionará "ganchos" para que el sistema de archivos se integre.


1

Agregando algunos comentarios divagantes a la buena respuesta del usuario 48838:

Todo es un archivo, incluidos los directorios. Para almacenar toda esa información de archivo, necesita espacio.

También sería válido mostrar, digamos, '64B usado' para un directorio pequeño y realmente mostrar la cantidad de espacio utilizado, pero de todos modos estaríamos usando múltiples de 4K en el disco, por lo que fue una decisión de diseño simplemente mostrar el Cantidad de espacio utilizado.

Desde una perspectiva de diseño FS, ¿por qué molestarse en tener que calcular lo que se utilizó? No es necesario. Y luego tendrías que mover las entradas para evitar dejar agujeros ... ick.

Cuando se producen eliminaciones y se reduce el tamaño del directorio para que pueda liberar un bloque, toda esa administración tendría que suceder antes de poder hacerlo. ¿Por qué molestarse en ahorrar unos KB? Lo más probable es que tenga que expandirlo más tarde de todos modos.

Dejado como ejercicio para el lector: piense por qué su directorio / lost + found se crea vacío pero ocupa 16K (al menos en ext3).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.