¿Por qué están fragmentados estos archivos en un volumen ext4?


19

Tengo una ext4partición de 900 GB en un disco duro (magnético) que no tiene defectos ni sectores defectuosos. La partición está completamente vacía, excepto por un lost+founddirectorio vacío . La partición se formateó utilizando los parámetros predeterminados, excepto que configuré el número de bloques de sistema de archivos reservados en 1%.

Descargué el archivo ~ 900MB xubuntu-15.04-desktop-amd64.isoen el directorio del punto de montaje de la partición usando wget. Cuando finalizó la descarga, descubrí que el archivo estaba dividido en cuatro fragmentos:

filefrag -v /media/emma/red/xubuntu-15.04-desktop-amd64.iso
Filesystem type is: ef53
File size of /media/emma/red/xubuntu-15.04-desktop-amd64.iso is 1009778688 (246528 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:            
   6:   190464..  223231:     231424..    264191:  32768:     229376:
   7:   223232..  246527:     264192..    287487:  23296:             eof
/media/emma/red/xubuntu-15.04-desktop-amd64.iso: 4 extents found

Pensando que esto podría ser liberado de wgetalguna manera, eliminé el archivo ISO de la partición, dejándolo vacío nuevamente, luego copié el archivo ~ 700MB v1.mp4en la partición usando cp. Este archivo también estaba fragmentado. Se dividió en tres fragmentos:

filefrag -v /media/emma/red/v1.mp4
Filesystem type is: ef53
File size of /media/emma/red/v1.mp4 is 737904458 (180153 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  180152:     198656..    219064:  20409:             eof
/media/emma/red/v1.mp4: 3 extents found

¿Por qué está pasando esto? ¿Y hay alguna manera de evitar que suceda? Pensé que ext4estaba destinado a ser resistente a la fragmentación. En cambio, encuentro que fragmenta inmediatamente un archivo solitario cuando no se usa todo el resto del volumen. Esto parece ser peor que ambos FAT32y NTFS.


44
Estoy tratando de imaginar bajo qué circunstancias esto podría importar, y estoy vacío.
Greg Hewgill

44
@GregHewgill: Importó porque pensé que era anormal. Ahora sé que es normal, no importa.
EmmaV

Respuestas:


17

3 o 4 fragmentos en un archivo de 900mb son muy buenos. La fragmentación se convierte en un problema cuando un archivo de ese tamaño tiene más de 100 fragmentos. No es raro que fat o ntfs fragmenten ese archivo en varios cientos de piezas.

Por lo general, no verá mejor que eso al menos en los sistemas de archivos ext4 más antiguos porque el tamaño máximo de un grupo de bloques es de 128 MB, por lo que cada 128 MB el espacio contiguo se divide por algunos bloques para los mapas de bits de asignación y las tablas de inodo para Grupo siguiente bloque. Una característica ext4 más reciente llamada flex_bg permite agrupar una cantidad de (generalmente 16) grupos de bloques de estas tablas juntas, dejando ejecuciones más largas de bloques asignables pero dependiendo de su distribución y qué versión de e2fsprogs se usó para formatearla, esta opción puede No haber sido utilizado.

Puede usar tune2fs -lpara verificar las funciones habilitadas cuando se formateó su sistema de archivos.


Muy interesante. Asumí que todas las tablas de inodo, etc., estaban al comienzo del volumen.
EmmaV

1
@EmmaV distribuyéndolos por el disco, relativamente cerca de los datos a los que se refieren, da como resultado búsquedas más cortas y un acceso más rápido al disco :)
hobbs

10

Realmente no puedo responder, pero creo que esto podría ayudar:

Observe cómo cada fragmento tiene, como máximo, 32768 bloques de tamaño (una potencia de 2, que debería levantar una bandera de que algo está sucediendo, y también darle una pista sobre algo que debe buscar).

También vale la pena señalar, esas compensaciones físicas entre extensiones son bastante cercanas entre sí.

De: Diseño de disco Ext4

Un sistema de archivos ext4 se divide en una serie de grupos de bloques. Para reducir las dificultades de rendimiento debido a la fragmentación, el asignador de bloques se esfuerza mucho por mantener los bloques de cada archivo dentro del mismo grupo, reduciendo así los tiempos de búsqueda. Se especifica el tamaño de un grupo de bloques sb.s_blocks_per_group blocks, aunque también se puede calcular como 8 * block_size_in_bytes. Con el tamaño de bloque predeterminado de 4KiB, cada grupo contendrá 32,768 bloques, para una longitud de 128MiB

Y más abajo:

La primera herramienta que ext4 usa para combatir la fragmentación es el asignador de bloques múltiples. Cuando se crea un archivo por primera vez, el asignador de bloques asigna especulativamente 8 KB de espacio en disco al archivo [...] Un segundo truco relacionado que usa ext4 es la asignación retrasada. Bajo este esquema, cuando un archivo necesita más bloques para absorber las escrituras del archivo, el sistema de archivos difiere al decidir la ubicación exacta en el disco hasta que todos los buffers sucios se escriben en el disco. Al no comprometerse con una ubicación en particular hasta que sea absolutamente necesario (se alcanza el tiempo de espera de confirmación, o se llama a sync (), o el núcleo se queda sin memoria), la esperanza es que el sistema de archivos pueda tomar mejores decisiones de ubicación.

Entonces, diría que el asignador solo se preocupa por la localidad de datos dentro del grupo de bloques (esos bloques de 32K), pero no por los grupos de bloques que son contiguos entre sí.


La primera cita que diste responde a mi pregunta.
EmmaV

1
Cada extensión tiene un máximo de 32k bloques porque esa es la longitud máxima que puede cubrir un descriptor de extensión. Las extensiones no son fragmentos. Si observa que varios de los bloqueos físicos de las extensiones siguen inmediatamente a los de la extensión anterior, por lo que no constituyen un fragmento (6 extensiones frente a 3 fragmentos).
psusi
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.