Linux y la fragmentación: si, ocurre

(Nota: Este post es el primero de una serie de varios artículos sobre la fragmentación. Se recomienda leer las serie completa: 2, 3 y 4).

El tópico de que Linux no necesita desfragmentación ha vuelto renacer. Suele hacerlo periódicamente, aunque por desgracia eso no lo haga más cierto. Ese argumento de que los sistemas de archivos en Linux no se fragmentan o que lo hace tan poco que apenas se nota, y que en NTFS en cambio lo hacen una barbaridad, nunca va acompañado, si se fijan, de una explicación. Eso es porque no la hay.

Creo que el origen del mito es visual. Windows tiene un desfragmentador de serie que muestra (mostraba) un bonito gráfico donde se ve el estado y progreso de la fragmentación, la cual deja de ser un concepto abstracto para volverse algo real, que se puede percibir mediante los sentidos. Oh, mira cuanta fragmentación. En una instalación Linux típica no hay ningún desfragmentador y mucho menos con gráficos, y al no verse nada es como que no existe (o se obtiene la cifra media de fragmentos/archivo, que es una bonita manera de ocultar la realidad con estadísticas): Oh, no tenemos fragmentación. Pero aunque no la veamos, existe. Hubo un tiempo en el que un servidor de ustedes muy de vez en cuando movía todo su sistema de una partición a otra del disco duro (cp -a), y la disminución del tiempo de inicio del sistema y del tiempo que transcurre entre KDM/GDM y la aparición del escritorio se podían medir en el reloj y en el menor carraspeo del disco duro. Apostaría a que la acertada decisión de eliminar la parte visual del desfragmentador en Windows Vista/7 se debe a la falsa sensación de conocimiento que mucha gente creía tener con las imágenes visuales.

Hay un par de cosas respecto a este asunto de la fragmentación que la mayoría de la gente (y en este blog, gente = frikis/geeks) desconoce de los sistemas de archivos. La primera es que los sistemas de archivos tienen muchas partes en común. El asignador de bloques para los datos, en particular -responsable de la fragmentación-, es un asignatura bastante común a todos, por no mencionar esos oscuros rincones en los que el sistema de archivos se funde de manera ambigua con la gestión de memoria.

En segundo lugar, una cosa es el formato físico del sistema de archivos, y otra su implementación. Una buena implementación puede incluso tapar los defectos de un sistema de archivos antiguo, y hacerlo mejor que uno nuevecito con una mala implementación. En Linux hay ejemplos muy próximos en los dos sentidos. Ext3/4 son sistemas de archivos viejos, desfasados, a diferencia de, por ejemplo, NTFS, que es claramente más moderno. Sin embargo la implementación de Ext4 es sobresaliente, capaz de competir con NTFS sin problemas e incluso con XFS en algunos puntos. En cambio Reiserfs v3 tiene un diseño muy nuevo, pero su implementación deja bastante que desear, por eso las empresas se pasaron a Ext4. Y algo con tanto prestigio como ZFS en todo su esplendor tuvo, nada más ser publicado y antes de mejorarlo, un algoritmo de asignación de bloques que se podía resumir con la frase "aquí te pillo, aquí te mato".

Uniendo los dos párrafos anteriores, se puede obtener la conclusión de que tomar decisiones de asignación de bloques que creen o no fragmentación en la disposición de los datos en el disco duro depende en gran medida de la implementación.

En principio, en teoría cualquier sistema de archivos puede hacer magníficas decisiones de asignación de bloques en lo que se refiere a fragmentación (otra cosa es el rendimiento y otros factores). Un buen ejemplo para comprenderlo es el caso de dos procesos escribiendo datos simultáneamente a dos archivos diferentes. Un asignador de bloques simple entrecruzará a lo largo del disco duro los datos de ambos archivos: primero un trozo del primer proceso, luego otro del segundo, posteriormente otro trozo del primero, etc, causando una fragmentación masiva. En cambio, un buen sistema debería detectar esta situación y tratar, por lo menos, de que los trozos que se entremezclen sean de un gran tamaño. Este tipo de heurísticas no dependen del formato del disco, y aunque cierto es que la facilidad para implementarlas esté influida por otros aspectos del sistema de archivos, a base de empeño un buen programador con muy poco respeto por la humanidad podría hacer maravillas hasta con FAT.

Resumiendo: Toda discusión sobre la fragmentación debería estar razonada en base a los algoritmos de asignación de bloques, que son quienes causan o evitan esa fragmentación. Los de Windows/NTFS no se conocen ni se conocerán nunca en detalle, pero los de Linux si que se conocen (aunque en todo google solo existan un par de referencias). Sin embargo, nunca los he visto expuestos en una discusión (no, esto no es suficiente), en cambio de Windows siempre se supone que no tienen absolutamente ni una sola línea de código dedicada a evitar la fragmentación, lo cual es una presunción (veo la imagen del desfragmentador, luego creo saber) demasiado atrevida. Sirva de ejemplo de desconocimiento de este tema que a pesar de que Ext4 incorpora varios cambios para evitar diferentes tipos de fragmentación, en tiempos del reinado del Ext3, que carece de esos cambios (y por tanto se fragmenta más), se afirmaba de todos modos que Linux no sufría fragmentación. O, peor aun, se afirma que los sistemas de archivos Unix previenen la fragmentación basándose en...¿exactamente qué hechos? (es más, ZFS y Btrfs se fragmentan una auténtica barbaridad por virtud de las técnicas COW).

Echen en Linux un ojo a la herramienta filefrag, como curiosidad yo tengo una ISO de un DVD en un Ext4 bajada con wget que está dividida en mil y pico extents. Y un SVG de 1.2 MB con 8 (un caso muy raro), y varias películas divididas en cientos cada una. Fragmentación pura y dura bajo un kernel 2.6.35-rc3 (eso si, si obtenemos la cifra media de fragmentos/archivo, los miles de archivos menores de 4KB rebajarán la media y harán que parezca que no pasa nada). Y no todo es culpa del sistema de archivos, no es casualidad que POSIX tenga la función fallocate(), es una prueba de que existen casos en los que un asignador de bloques no pueden predecir el futuro. Además, hay que tener en cuenta la fragmentación entre diferentes archivos, un tipo de fragmentación muy importante para el rápido inicio del sistema y de las aplicaciones y que prácticamente requiere un desfragmentador. No es casualidad que XFS, Ext4, y Btrfs tengan desfragmentadores, simplemente se necesitan (para Btrfs puede llegar a convertirse en un requisito).

Por supuesto, si usted quiere puede vivir sin desfragmentador, e incluso las distros Linux podrían no usarlo bajo la regla de que casi nunca hace falta, pero por esa regla de tres también Windows podría eliminarlo basándose en esa lógica. Lo acertado de Microsoft en este campo es que en vez de negar el problema y pretender que no existe, han proporcionado una herramienta para arreglarlo (también es bonito lo que hace OS X, defragmentar automáticamente un archivo al abrirlo si detecta que está fragmentado). Es como el caso de "no-tenemos-fsck-porque-nuestro-sistema-de-archivos-no-lo-necesita", puedes negar que necesitas un fsck todo lo que quieras, pero el mundo real es muy puñetero y aparecen usuarios necesitándolo. Lo mismo para los desfragmentadores.

Este tema es muy amplio (y se podría hablar de las mejoras de algoritmos que usa Ext4 y tal, y casos que no cubren), pero definitivamente no será en esta entrada, que ya es lo suficientemente larga...