El viejo mito de la fragmentación en Linux

En primer lugar, para el que no lo sepa, la fragmentación consiste en el almacenamiento de archivos en bloques de forma no contigua, que hace que los discos duros vayan más lentos, al tener que desplazarse más veces el cabezal para leer un mismo archivo.

Voy a extenderme bastante en este artículo, pero para el que quiera leer poco, voy a explicar porqué la fragmentación es inevitable en los tres puntos siguientes:

1. Varios procesos pueden querer escribir en el disco al mismo tiempo, y el algoritmo de asignación de bloques tiene que ubicarlos. Esto se hace muchas veces sin saber el tamaño total de cada archivo.

2. Cuando el disco duro está casi lleno sólo se pueden guardar los archivos en los bloques disponibles.

3. El algoritmo de asignación de bloques no puede predecir cuánto crecerán los archivos o qué archivos serán borrados.

Sé que muchos usuarios de Linux insistirán en que su sistema no se fragmenta más de un determinado porcentaje y es que la herramienta fsck de Linux, te da el porcentaje de archivos fragmentados (non-contiguous files). Esto es un dato totalmente irrelevante para saber cuál es la fragmentación real del disco. Podemos tener un millón de archivos pequeños sin fragmentar y sólo mil archivos muy fragmentados, por lo que esta herramienta nos dará un porcentaje bajo, cuando, por otro lado, la herramienta de Windows da realmente el porcentaje de fragmentación del disco y no de los archivos fragmentados, por lo que, en Windows, siempre obtendremos un porcentaje más alto para el mismo nivel de fragmentación.

Otro argumento que esgrimen los defensores de la no fragmentación en Linux, como Roberto Di Cosmo que escribió el artículo "Armario con cajones y lavado de cerebros", es el hecho de que en Windows existe la herramienta para desfragmentar y en Linux no (al menos no de forma nativa). El que no venga instalada esta herramienta por defecto, no significa que no haga falta. De hecho, en Windows dan mejor soporte a este problema al proporcionar la herramienta.

Normalmente se culpa al sistema de ficheros de que en un sistema operativo concreto haya más o menos fragmentación. En realidad esto no es del todo correcto, ya que el verdadero culpable no es el sistema de ficheros, si no de una parte de éste llamada algoritmo de asignación de bloques, que se encarga de decidir donde se almacenan los archivos que vamos creando. Este algoritmo puede variar entre distintas implementaciones de un mismo sistema de archivos, por ejemplo, el sistema de archivos FAT de Windows, implementa de forma distinta este algoritmo, respecto a la implementación que hace Linux del mismo sistema de archivos.

A continuación, voy a detallar los tres puntos que he señalado al principio. Para ello voy a suponer que tenemos un disco duro ficticio muy pequeño con 11 bloques libres (voy a representar cada bloque con "[]" y sí está ocupado, dentro voy a escribir el número de archivo que contiene en este formato: [número de archivo.número de trozo del archivo]). Empecemos:

Caso 1: varios procesos pueden querer escribir en el disco al mismo tiempo, y el algoritmo de asignación de bloques tiene que ubicarlos. Esto se hace muchas veces sin saber el tamaño total de cada archivo.

Cuando dos procesos tienen que escribir al mismo tiempo en el disco duro, para que el usuario no perciba que uno de ellos se ha parado y crea que realmente funcionan al mismo tiempo, el sistema operativo deja que un proceso guarde un trozo de archivo, saca el proceso del procesador y carga el otro proceso para que guarde otro trozo de un archivo distinto. En este tipo de situación es fácil que ocurra algo así:

Supongamos que nos estamos bajando en nuestro navegador dos archivos al mismo tiempo. Se empieza a guardar cada archivo en una parte distinta del disco:

[1.1][   ][   ][   ][2.1][   ][   ][   ][   ][   ][   ]

Al cabo de un rato los procesos han dejado el disco duro así:

[1.1][1.2][1.3][1.4][2.1][2.2][1.5][   ][   ][   ][   ]

Resulta que el archivo 1, ocupaba 5 bloques, un bloque más de lo esperado y se ha producido fragmentación.

Caso 2: cuando el disco duro está casi lleno sólo se pueden guardar los archivos en los bloques disponibles.

En este caso, supongamos que tenemos 10 bloques que están llenos y los archivos están en una situación ideal, es decir, perfectamente alineados:

[1.1][1.2][2.1][2.2][3.1][3.2][3.3][4.1][4.2][5.1][   ]

Al día siguiente borramos dos archivos, el 2 y el 3, estos archivos ocupaban dos bloques cada uno, por lo que nos queda esto:

[1.1][1.2][   ][   ][3.1][3.2][3.3][   ][   ][5.1][   ]

A continuación nos llega un nuevo archivo, llamémoslo archivo 6, que ocupa tres bloques. Además, hay que tener en cuenta, que para llenar un bloque tardamos dos horas, en vaciarlo una. En este caso hay dos posibles estrategias:

1. Guardar el archivo 6 donde quepa provocando fragmentación. En este caso tardamos tres horas en guardar el nuevo archivo en los tres bloques:

[1.1][1.2][6.1][6.2][3.1][3.2][3.3][6.3][   ][5.1][   ]

2. Mover el archivo 3 para dejar hueco al archivo 6 y así no provocar fragmentación. En este otro caso, tardamos tres horas en sacar el archivo número 3, seis horas en volverlo a guardar y otras tres en guardar el archivo número 6. En total hemos empleado once horas en guardar el nuevo archivo, con lo que conseguimos que el disco duro esté perfectamente organizado, por lo que ahorraremos 5 minutos de tiempo cada vez que queramos ver el archivo 6:

[1.1][1.2][3.1][3.2][3.3][6.1][6.2][6.3][   ][5.1][   ]

Obviamente, por lo general, no vamos a tener tiempo de usar la segunda estrategia, por eso todos los sistemas de ficheros optan siempre por la primera. Por lo tanto, en todos los sistemas de ficheros vamos a tener fragmentación, un mal menor que obtenemos a cambio de no tener que dejar el ordenador encendido todo el día para copiar las fotos de las vacaciones. ¿Y no hay ninguna otra forma de solucionar este problema para evitar la fragmentación y además no tener que desfragmentar al guardar un archivo? Pues no, no hay ninguna a no ser que tengamos un disco duro infinito.

Caso 3: el algoritmo de asignación de bloques no puede predecir cuánto crecerán los archivos o qué archivos serán borrados.

Hemos guardado dos archivos. A la hora de asignar bloques, el algoritmo puede escoger entre guardarlos de forma contigua o uno separado del otro, por si acaso el primero de ellos tiene que crecer. La primera estrategia es mejor para el caso 2 (esta es la que se suele usar en sistemas de ficheros de Windows) y la segunda para este caso (la que se suele usar en sistemas de ficheros de Linux y que crea un problema llamado fragmentación del espacio libre). Así que supongamos que estamos usando la mejor estrategia para este caso, guardarlos de forma esparcida:

[1.1][1.2][   ][   ][2.1][2.2][   ][   ][   ][   ][   ]

Ahora resulta que hay que añadir tres trozos más al archivo 1. De nuevo tenemos dos posibles soluciones:

1. Guardar el archivo que sobra a continuación del archivo 2, provocando fragmentación:

[1.1][1.2][1.3][1.4][2.1][2.2][1.5][   ][   ][   ][   ]

2. Sacar el archivo 1 y ponerlo a continuación del 2. De esta manera no hay fragmentación pero se tarda mucho más tiempo en guardar el nuevo trozo de archivo:

[   ][   ][   ][   ][2.1][2.2][1.1][1.2][1.3][1.4][1.5]

Otra vez, la solución que escogen absolutamente todos los sistemas de archivos para su algoritmo de asignación de bloques, es la primera, ya que la segunda es temporalmente inviable.

No se sí es mejor la estrategia de asignación de bloques en los sistemas de ficheros de Linux o en los de Windows, puede que sea el ext4 de Linux o el último NTFS de Windows 7. Si alguien conoce algún artículo científico donde lo hayan comprobado puede comentarlo, pero lo que es seguro es que la fragmentación es inevitable y que aumenta con el uso.

Por último, para el que después de leer esto, crea que ya tiene una idea lo suficientemente clara para entender bien el problema de la fragmentación, que sepa que no conoce ni una décima parte del problema. En realidad, es algo muchísimo más complejo y hay muchas y variadas técnicas para resolverlo. Para que el disco duro lea lo más rápido posible un archivo que ocupa más de una pista, el archivo debe estar colocado en la siguiente pista en una determinada posición ideal, para que al mover el brazo lector a esa pista después de leer la anterior, quede perfectamente alineado con el siguiente dato que tiene que leer.