Tengo un entorno virtualizado de muy alta densidad con contenedores, así que estoy tratando de hacer que cada contenedor sea realmente pequeño. "Realmente pequeño" significa 87 MB en Ubuntu 14.04 base (Trusty Tahr) sin romper la compatibilidad del administrador de paquetes.
Así que uso LVM como almacenamiento de respaldo para mis contenedores y recientemente encontré números muy extraños. Aquí están.
Creemos un volumen lógico de 100 MiB (sí, potencia de 2).
sudo lvcreate -L100M -n test1 /dev/purgatory
Me gustaría comprobar el tamaño, así que emito sudo lvs --units k
test1 purgatory -wi-a---- 102400.00k
Dulce, esto es realmente 100 MiB.
Ahora hagamos un sistema de archivos ext4 . Y, por supuesto, recordamos el -m 0parámetro, que evita el desperdicio de espacio.
sudo mkfs.ext4 -m 0 /dev/purgatory/test1
mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
25688 inodes, 102400 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
Dulce y limpio. Tenga en cuenta el tamaño del bloque: nuestro volumen lógico es pequeño, por lo que mkfs.ext4 decidió hacer un bloque de 1 KiB, no los 4 KiB habituales.
Ahora lo montaremos.
sudo mount /dev/purgatory/test1 /mnt/test1
Y llamemos dfsin parámetros (nos gustaría ver 1 bloques KiB)
/dev/mapper/purgatory-test1 95054 1550 91456 2% /mnt/test1
Espera, oh shi ~
Tenemos 95054 bloques en total. Pero el dispositivo en sí tiene 102400 bloques de 1 KiB. Tenemos solo el 92.8% de nuestro almacenamiento. ¿Dónde están mis bloques, hombre?
Veámoslo en un dispositivo de bloque real. A tiene un disco virtual de 16 GiB, 16777216 bloques de 1K, pero solo 15396784 bloques están en salida df. 91.7%, ¿qué es?
Ahora sigue la investigación (spoiler: sin resultados)
El sistema de archivos podría comenzar no al comienzo del dispositivo. Esto es extraño, pero posible. Afortunadamente, ext4 tiene bytes mágicos, verifiquemos su presencia.
sudo hexdump -C / dev / purgatory / test1 | grep "53 ef"
Esto muestra superbloque:
00000430 a9 10 e7 54 01 00 ff ff 53 ef 01 00 01 00 00 00 |...T....S.......|
Hex 430 = Dec 1072, entonces en algún lugar después del primer kilobyte. Parece razonable, ext4 omite los primeros 1024 bytes para rarezas como VBR, etc.
- Esto es diario!
No, no es. El diario toma espacio de Disponible si la salida de df.
- ¡Oh, tenemos dump2fs y podríamos comprobar los tamaños allí!
... muchos greps ...
sudo dumpe2fs /dev/purgatory/test1 | grep "Free blocks"
Ay.
Free blocks: 93504
Free blocks: 3510-8192
Free blocks: 8451-16384
Free blocks: 16385-24576
Free blocks: 24835-32768
Free blocks: 32769-40960
Free blocks: 41219-49152
Free blocks: 53249-57344
Free blocks: 57603-65536
Free blocks: 65537-73728
Free blocks: 73987-81920
Free blocks: 81921-90112
Free blocks: 90113-98304
Free blocks: 98305-102399
Y tenemos otro número. 93504 bloques libres.
La pregunta es: ¿qué está pasando?
- Dispositivo de bloque: 102400k (dice lvs)
- Tamaño del sistema de archivos: 95054k (df dice)
- Bloques gratuitos: 93504k (dumpe2fs dice)
- Tamaño disponible: 91456k (df dice)
ext2para particiones pequeñas.ext2parece razonable aquí, claroRespuestas:
Prueba esto:
mkfs.ext4 -N 104 -m0 -O ^has_journal,^resize_inode /dev/purgatory/test1Creo que esto te permite entender "lo que está pasando".
-N 104(establezca el número de iNodes que debe tener su sistema de archivos)-m 0(sin bloques reservados)-O ^has_journal,^resize_inode(desactiva las funcioneshas_journalyresize_inoderesize_inode"costo" de espacio libre (la mayoría de los 1550 bloques 1K / 2% que ve en sudf- 12K se usan para la carpeta "perdido + encontrado")has_journal"costos" de espacio utilizable (4096 1K-Blocks en su caso)Obtenemos
102348de102400, otros 52 bloques inutilizables (si hemos suprimido el "lost + found" carpeta). Por eso nos sumergimos endumpe2fs:y cuente los bloques utilizados (para el superbloque de copia de seguridad, los descriptores de grupo, el mapa de bits de bloque, el mapa de bits de Inode y la tabla de Inode) o we
grepand count:que nos da el recuento de líneas que tienen un solo bloque (en nuestro ejemplo) y
lo que nos da el recuento de líneas que tienen dos bloques (en nuestro ejemplo).
Entonces tenemos (en nuestro ejemplo)
13líneas con un bloque cada una y19líneas con dos bloques cada una.lo que nos da
51bloques que están en uso por ext4. Finalmente solo queda un bloque. El bloque 0, que son los1024bytes omitidos al principio para cosas como el sector de arranque.fuente
dfen fs con journal: 95054k -dfen fs sin jorunal 99150k - y no mezcle espacio "utilizable" y "libre".mkfs.xfs -l size=512 -d agcount=1creará un sistema de archivos con el tamaño de registro mínimo absoluto (también conocido como diario), pero el rendimiento de escritura podría verse afectado. No creo que el código XFS sea compatible sin un registro. Posiblemente de solo lectura, para admitir casos en los que un dispositivo de registro externo está roto. (también,agcount=1es probablemente otra idea terrible para el rendimiento de escritura, especialmente en paralelo. Y los encabezados de los grupos de asignación también son probablemente pequeños)mkfs.xfs -d agcount=1en una partición de 100MiB se obtuvo un FS de 95980kiB, con 5196k usados, 90784k disponibles. La cuenta predeterminada es 4 y el tamaño de registro predeterminado es 1605 bloques (también el mínimo). Por lo tanto, XFS utiliza un registro tan pequeño como esté dispuesto a permitirle especificar, para FSes pequeños.La respuesta corta:
No todo el espacio en el dispositivo de bloque se convierte en espacio disponible para sus datos: parte del espacio en bruto es necesario para las partes internas del sistema de archivos, la contabilidad detrás de escena.
Esa contabilidad incluye el superbloque, los descriptores de grupo de bloque, los mapas de bits de bloque e inodo y la tabla de inodo. Además, se crean copias del súper bloque con fines de respaldo / recuperación en varias ubicaciones. Una lectura larga sobre los componentes internos del sistema de archivos EXT4 se puede encontrar en ext4.wiki.kernel.org .
Dado que EXT4 es un sistema de archivos registrado que también ocupa algo de espacio.
Además, se reserva algo de espacio para futuras expansiones del sistema de archivos.
La respuesta larga:
He recreado su escenario en uno de mis sistemas de prueba:
Luego, incluso antes de montar el sistema de archivos, se
dumpe2fsmuestra:y después del montaje:
Entonces, ¿qué
dfnos muestra? De los 102400 bloques del dispositivo de almacenamiento sin procesar, 99150 bloques de 1K son visibles para el sistema de archivos, lo que significa que 3250 bloques de 1 kilobyte de espacio de almacenamiento sin procesar se han vuelto inutilizables para el almacenamiento de datos real.¿A dónde fueron esos bloques? Desplazarse hacia abajo en la
dumpe2fssalida muestra exactamente dónde:1 block(bloque # 0) Los primeros 1024 bytes se omiten para permitir la instalación de sectores de arranque x86 y otras rarezas.1 blockestá ocupado por el superbloque primario.1 blockcontiene los descriptores de grupo.256 blocksestán reservados para la Tabla de descriptores de grupo para permitir el cambio de tamaño futuro del sistema de archivos.16 blocksse asignan para el mapa de bits del bloque.16 blocksse asignan para el mapa de bits de inodo.246 blocksson asignados para la tabla de inodo.Eso ya representa 537 de los 3250 bloques faltantes. Un sistema de archivos ext4 se divide en una serie de grupos de bloques y el desplazamiento hacia abajo muestra una asignación similar de la capacidad de almacenamiento sin procesar a los componentes internos del sistema de archivos en los otros grupos de bloques:
Ahora de vuelta a la
dfsalida:La razón por la que en ese nuevo sistema de archivos ya está marcado el 7% de la capacidad como en uso es:
99150 (el tamaño del sistema de archivos) MENOS 5120 (el recuento de bloques reservado) MENOS 5646 (bloques usados, 4096 de los cuales son del Diario (nuevamente parte de la salida de dumpe2fs))
= 88384
El recuento de bloques libres en dumpe2fs es el tamaño disponible del sistema de archivos menos el uso real (y no tiene en cuenta los bloques reservados), por lo que 99150 - 5646 = 93504.
fuente
No es una respuesta a la pregunta, pero tengo curiosidad, así que imagino que otras personas lo harán. Como ya tenía un liveCD arrancado y tenía un disco duro con el que podía meterme sin preocuparme de que los errores tipográficos dañaran nada, seguí adelante y probé.
Hice particiones con todos los FSes para los que Ubuntu 14.10 incluye un mkfs, en particiones de 100MiB. (excepto minix, que solo admite 64MiB, y bfs, que es algo de SCO del que nunca he oído hablar).
Primero miré
df -kespacio disponible (con la configuración por defecto mkfs), entoncesdded/dev/zeroa un archivo en cada FS para asegurarse de que se podrían llenar todo el camino hacia arriba. (es decir, compruebe que el reclamoavailable spaceestaba realmente disponible).for i in /media/ubuntu/small-*;do sudo dd if=/dev/zero of="$i/fill" bs=16k;done¿Por qué btrfs tiene tanto espacio inutilizable? Tal vez para los metadatos? bueno no:
Ambos sistemas de archivos basados en árboles no pueden empaquetar un archivo vacío en ninguna parte, pero todos los demás sí.
O simplemente mire qué tamaño puede crear un archivo:
(Llamé a mi partición ext4 "small-ext" porque no estaba planeando volverme loco y hacer todos los sistemas de archivos. Así que ext = ext4 aquí. NO el original pre-ext2 ext.)
Y
df -ksalida después de eliminarlos nuevamente:(jfs volvió al 1% usado después de que eliminé "tocado" también. O hubo un retraso de tiempo, o tomó otra escritura para obtener el tamaño disponible para actualizar).
De todos modos, creo que es por mi curiosidad.
fuente