Pensamientos computables - www.pensamientoscomputables.com
105

El viejo mito de la fragmentación en Linux

Publicado el: 11/03/2012
desfragmentador
La informática es una ciencia en la que, a menudo, se crean falsas creencias debido al desconocimiento de lo que ocurre en realidad en la máquina. Esta vez voy a desmontar una de estas viejas creencias, la de que el disco duro no se fragmenta en distribuciones de Linux y por lo tanto no hace falta desfragmentar.

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.

Pensamientos (8): Ver comentarios Comentar
Categorías: ,

Comparte:

Copia y pega en tu página:

Comparte
Escribe tus pensamientos computables

Respondiendo a los siguientes comentarios:

Para comprobar que eres un humano responde correctamente:

Esta pregunta no me gusta, ¡cambialá!

Ninguno de estos datos será almacenado.

(Escribe el correo electrónico)

Campo obligatorio.

(Escribe el correo eléctronico o los correos electrónicos separados por comas)

Campo obligatorio.

Para comprobar que eres un humano responde correctamente:

Esta pregunta no me gusta, ¡cambialá!

Pensamientos
Akai_sensei
Fecha: 29/05/2012 Hora: 2:50:25

=o

se agradece el tremendo espacio de aprendizaje que tienes, pero... mi duda es:

me quiero comprar un notebook y quiero ponerle linux, ahora que veo tu articulo, se que va a tener un % de fragmentacion y ademas que no voy a tener la herramienta desfragmentacion que viene en windows; entonces ¿Como o a traves de que programa puedo desfragmentar el disco si tengo linux?

.:Salu2:.

.:By_Akai_sensei:.

Le responde 1 comentario Ver comentario
Respondiendo a 1 comentario Ver comentario
Daiatron
Fecha: 03/06/2012 Hora: 16:04:26

Gracias

Depende de la distro que uses, si como yo usas Ubuntu, o alguna otra distro basada en Debian, puedes usar shake que lo puedes encontrar aquí http://www.vleu.net/shake/

Anónimo
Fecha: 17/08/2012 Hora: 1:21:12
Buena informacion.....
Anónimo
Fecha: 02/11/2012 Hora: 9:52:18
Grandiosa información, tenia tiempo buscando un defragmentador para linux a pesar que en contra de toda logica solo encontraba que en linux no existia la fragmentación. Probaré el shake haber que tal.
Anónimo
Fecha: 31/12/2012 Hora: 4:02:09
Tu árticulo es puro FUD, los sistemas de archivos tienen sus algoritmos de almacenamiento de archivo, por dios mi tesis del doctorado se baso en ello. Los sistemas de archivo en Linux como el Ext4 (en el cual enfoque parte de mi tesis) utilizan "extents" Un extent es un conjunto de bloques físicos contiguos, mejorando el rendimiento al trabajar con ficheros de gran tamaño y reduciendo la fragmentación. Un extent simple en ext4 es capaz de mapear hasta 128MB de espacio contiguo con un tamaño de bloque igual a 4KB. Además de que utilizan el algoritmo de "Asignación retrasada de espacio en el disco" que no solo evita la fragmentación, mejora el rendimiento... Me pondría extender infinitamente, pero no tiene sentido. No te voy a negar que también en Linux puede haber fragmentación, mas nunca sería la misma que en el sistema NTFS o FAT. Cuando hagas un artículo ten la propiedad de hacer puntos comparativos y no solo FUD.
Le responde 1 comentario Ver comentario
Respondiendo a 1 comentario Ver comentario
Daiatron
Fecha: 01/01/2013 Hora: 18:52:11

Con este artículo no pretendo ni mucho menos desacreditar a Linux, ni decir qué sistema archivos es el mejor, ni pretendo entrar en profundidad en el problema. Simplemente queria explicar por qué la fragmentación es inevitable.

Quizás el ext4 de Linux sea mejor que la última versión de NTFS de Windows (la última creo que es la 5.1), pero aunque se explique con todo detalle como funcionan, no creo posible decir cuál es mejor sin un estudio científico en el que se hayan realizando pruebas reales o al menos simulaciones. Si tu has hecho este estudio o conoces algún artículo científico en referencia a esto, sería muy interesante que lo compartieras.

Anónimo
Fecha: 15/01/2013 Hora: 19:17:25

Como todo si y no.. normalmente en las distribuciones linux se utiliza LVM, para no ser muy tecnico, es como poner una capa delante de la lectura de los discos y crearte tu propio disco ¿como?, ¿para que?

..bueno voy a poner un caso "extremo", digamos que tengo un puñado de pendrive de estos que te dan de propaganda de 4GB cada uno, pues cojo un hub y pincho uno, ..ya tengo un disco de 4GB, pero ..como me parece pequeño, creo un LVM que llamare DISCOS_PEN y a este LVM le incorporo ese Pen de 4gb, en él monto mi distro Linux.

..pero se me queda pequeño y al poco no tengo espacio, pincho otro pen de 4g y EXTIENDO mi LVM en caliente, sin parar ni mi sistema ni mis aplicaciones, en pocos minutos ( o segundos dependiendo de la experiencia) ya tengo un disco DISCO_PEN de 8gb, esto lo puedo seguir haciendo hasta que ya no tenga espacio para pinchar un PEN, pero puedo pinchar a otro hub (conectado a un USB) otro grupos de PEN... esto se puede hacer, lo que pasa es que como es logico con HD normales, aunque lo norma es que en el caso de servidores linux estan conectados a una cabina de discos de varios TERAS y se le va dando lo que se denomina una LUN que no es mas ni menos que un disco creado de forma "virtual" en la cabina que puede corresponder con un disco fisico, un trozo de disco o varios discos o cachos de discos, al final tienes una LUN de por ejemplo 300GB con los que amplias un LVM quedando el tamaño anterior los 300GB SIN PARAR S.O ni tan siquiera aplicaciones.

..ahora que tiene que ver esto con la fragmentación.... pues que seguro que hay fragmentación.... aqui tenemos servidores con File system ( lo que seria unadad C: o E: ... de windows) de varios GB incluso alguna de mas de 1T. sobre cabinas EVA ( son de HP) cuyos discos mas grandes son de 256GB... super rapidos pero de 256GB, ademas están en RAID 5 (sistema que hace que la informacion este duplicada en dos sitios simultanemaente) ..pues imaginaros la de cientos de cachitos que hay... repartidos por varios discos....

Pero porque "importa poco" la fragmentación... porque realmente hay una capa delante que seria como un indice donde un fichero seria un capitulo y se le indica los numero de paginas que lo componen, que serian los cachitos del fichero repartidos NO solo por un disco sino POR LOS cachitos de DISCOS.

El S.O mediante la gestion del LVM lanza la petición de tal forma que la controladora de/del disco/discos envie/en los datos simultaneamente "recomponiendose" la estructura del fichero, al fin y alcavo la lectura es secuencial, pero si te llegan todos los trozos casi a la vez , depende que tipo de comunicacion puedes enviarlos "así"...

Esta claro que con discos antiguos la cosa no va bien, pero ni en Windows7 ,8 ,10 o Fedora, Centos RedhAT SUSE ......

chao

Anónimo
Fecha: 02/09/2014 Hora: 23:11:17

muy buen articulo, me a sido muy util para ampliar mi entendimiento sobre como se mueven los archivos dentro de un disco duro... y el comentario de la persona que hizo la tesis sobre este tema, muy bueno Gracia!!!!...

Pero con tantos problemas sobre la fragmentacion, ¿ahy alguna solucion para mantener el disco siempre en orden?... ¿o tendremos que estar diario o semanal (como hago yo) desfragmentando el disco duro, para tener un optimo manejo de archivos? y ¿puede causar un problema el hecho de defragmentar tanto?

Daiatron en Google+