¿Quien dice que Linux no se fragmenta?

para home:

#fsck.ext3 -vcp /dev/sda4
non-contiguous inodes (15,2%)


para boot:

#fsck.ext3 -vcp /dev/sda1
non-contiguous inodes (21,1&)


Llevo días que al compilar se ralentiza todo lo que esté haciendo, incluso a veces llega a bloquearse. Una solución pasaba por usar nice para cambiar la prioridad de acceso al disco, pero eso es como reemplazar un fusible quemado sin antes corregir el fallo que provocó la sobrecarga. Absurdo porque se volverá a quemar (qué metafórica me siento, vaya). The Gimp también funcionaba a trompicones editando imágenes no especialmente grandes. Firefox se colgaba de vez en cuando, aunque bueno, eso creo que es normal en él y no se solucionará con un mejor acceso a disco. Pero la gota que ha colmado el vaso ha sido al tratar de capturar un vídeo DV de la cámara.

Uso Kino como se recomienda hasta la saciedad en todos los rincones de Internet. Ya lo he usado en el pasado, en instalaciones anteriores, y me funcionaba de maravilla, pero desde la última vez que reinstalé el sistema (en la pasada Campus Party) no he conseguido que funcione correctamente. Por estos motivos pensé que el problema estaría en los módulos. Bueno, por esto y porque el error que salía decía claramente:

"AVISO: el módulo del kernel raw1394 no se ha cargado o no hay permisos para leer o escribir en /dev/raw1394"

Con los permisos de /dev/raw1394 revisados y los módulos cargados correctos esta situación se acercaba a un poltergeist. Según leí en algún foro un usuario comentaba que Kino le funcionaba estupendamente salvo cuando tenía el firewire “built in” en el kernel en lugar de como módulo. ¿Pues a ver si va a ser eso?


# cd /usr/src/linux make menuconfig

Device drivers -- IEEE1394...

“¡Bingo! Lo tengo puesto integrado, así que vamos a probar como módulo haciendo caso a este buen hombre, que si a él le funciona a mí no tiene por qué no“.

Tras recompilar kernel, drivers de nvidia y arrancar de nuevo seguía sin funcionar correctamente. Capturaba a ratos y a ratos salía el error. En este momento decidí probar dvgrab en consola que me sacaba los siguentes errores en los puntos que, se me antoja, serían los mismos en los que el Kino escupía su propio error de módulos.


"buh019.avi": buffer underrun near: This error means that the frames could not be written fast enough.
“buh019.avi”: 1.00 MB 7 frames timecode 01:11:00.17 date 2009.05.08 11:17:03 Warning: 1 dropped frames.

Oh, oh, oh, ¿qué tenemos aquí? Está claro que ext3 sí se fragmenta. Ahora el problema es solucionar esto si no viene con herramienta para desfragmentarlo “porque eso en linux no se usa”.

Siempre se ha dicho que linux no necesita herramientas de defragmentación, y lo cierto es que llevo 5 años sin usar una, pero todos los sistemas se fragmentan aunque los sistemas de ficheros estén pensados para que no ocurra. A diferencia de FAT, que comienza a grabar los datos de forma secuencial (y si éstos necesitan ser regrabados con un tamaño mayor ya no cabrán y habrá fragmentación), ext3 graba datos de forma heurística buscando por el disco espacio suficiente y separado para todo el tamaño a considerar. Aquí hay un gran artículo que lo explica. Ésto consigue reducir la fragmentación a niveles mínimos durante la mayor parte del tiempo, pero como es lógico ver, al llegar a un 80% de ocupación de disco, buscar espacios enteros libres empieza a ser difícil y es inevitable que aumente el nivel de fragmentación. Mi disco está a un 95% de capacidad, así que no me asombra que esté hecho una mierda.

Opciones descartadas:
- usar shake, pues tengo la partición al 93% así que no sirve.
- pasar a ext2 con tune2fs para usar e2defrag. Aquí dice que se pueden perder datos :S.
- migrar a ext4

Opciones a considerar:
- Copiar toda la partición a otro disco externo y de vuelta a mi disco. No sé cuán de efectivo será.
- Dar una vuelta a los bytes en el disco creando una partición con el espacio libre, poniéndola delante (esto obliga a sobreescribir los datos detrás) y finalmente borrándola de nuevo para volver dónde estábamos. Viene a ser lo mismo que la primera opción, pero leo que a un tipo que lo comenta no le llegó a funcionar.
- usar XFS

Al fin y al cabo me pregunto ¿por qué uso ext3? ¿se fragmentaría tanto Reiserfs como ext3 en mi disco (para el tipo de uso que le doy)? ¿Y si voy a editar vídeo y fotos, no será XFS una buena opción? ¿Para cuándo ext4? Hay muchas consideraciones que tener en cuenta a la hora de elegir qué sistema de ficheros usar.

La mayoría de los linux usan ext3 y reiserfs por la costumbre ancestral de aceptar lo que viene por defecto. Y es que en realidad éstos sistemas son excelentes en las distribuciones en las que vienen ya metidos porque se parchean para aumentar su rendimiento. Durante los ‘90 ext2 (Second Extended Filesystem, el segundo intento por desbancar Minix de los sistemas con linux) fue muy popular y se afianzó en casi todos los sistemas, pero tenía el gran fallo de no tener journalling (diario de cambios) y conforme crecía el tamaño de los discos, se hacía un problema el “chequeo” de la integridad del sistema de ficheros que podía llegar a durar horas. Para solventar esto surgieron dos ramas de trabajo desde el kernel: reiserfs que pretendía usar journaling de forma nativa, y ext3 que suponía una mejora sobre el ext2 existente. Cada distribución eligió uno de los dos (Suse 6.1 incorporó reiserfs y Red Hat 7.2 ext3) y la rama del kernel 2.4 ya vino desde el principio con soporte para ambos. Desde entonces éstos 2 sistemas de ficheros son los más utilizados.

Los sistemas de ficheros que fueron surgiendo más adelante siempre presentan más reparo, aún cuando los estudios de velocidad en Namesys demuestran que Reiser4 podría ser en la actualidad el sistema de ficheros más rápido en Linux, sobretodo cuando se sobrepasan los 50.000 ficheros en el disco.

Pero no todo es la velocidad y también se demostró que éste sistema es, con creces, el que más CPU consume, siendo sólo superado en algunos casos por reiserfs. Sinceramente yo me decanté por ext3 porque con el tamaño de mi disco, montar un sistema con reiserfs tardaba 4 veces más, pero ahora debería tal vez considerar XFS como opción para el próximo formateo. XFS pisa los talones a Reiser4 en velocidad y rinde particularmente bien con volúmenes grandes de datos.

Según leo, hay que evitar ext3 cuando hay demasiados ficheros pues éste especifica el número de inodos durante el formateo y esto restringe el número de ficheros a almacenar. Reiserfs y XFS funcionan con asignación automática de inodos. En espacio de disco, resiserfs es el que más consigue reducir el tamaño que ocupan ficheros pequeños y es más rápido que ext3.

Así que creo que finalmente usaré reiserfs para la partición raíz y una nueva partición para portage y XFS para el home.

Aquí hay un pdf a un artículo en linux magazine con mucha información al respecto.

¿Más ideas?

Tags: ext2, ext3, Linux, reiserfs, sistemas de ficheros, xfs

Sigue los comentarios con el siguiente feed: RSS 2.0.