22 de diciembre de 2008

Ext4 (lo que traerá Linux 2.6.28 parte I)

Parte de la documentación de Linux 2.6.28 en el fascista y opresor idioma ejpañol (versión en inglés de este documento).

Ext4 es la evolución del sistema de archivos más utilizado en el mundo Linux, Ext3. En muchos sentidos Ext4 es una mejora más profunda de Ext3 que la que Ext3 fue de Ext2. Ext3 consistió básicamente en añadir journaling, pero Ext4 modifica ciertas estructuras críticas del sistema de archivos, como las destinadas a almacenar los datos de los archivos. El resultado es un sistema de archivos con un diseño mejorado, mayor rendimiento y fiabilidad. Las principales mejoras que ofrece son:

  • Compatibilidad: Cualquier sistema de archivos Ext3 existente puede migrarse a Ext4 con un sencillo procedimiento de dos comandos a ejecutar en modo de solo-lectura (procedimiento descrito más adelante). Es decir, que puedes mejorar el rendimiento, límites de almacenamiento y características de un sistema de archivos sin necesidad de reformatear y/o reinstalar tu SO y entorno de software. Si necesitas las ventajas de Ext4 en un entorno de producción, puedes actualizar el sistema de archivos. El procedimiento es sencillo y no pone en riesgo los datos (eso si, se recomienda hacer copia de seguridad de los datos críticos, incluso si no estás actualizandote el sistema de archivos :). Ext4 solamente utilizará sus nuevas estructuras en los nuevos datos que se escriban, los datos antiguos podrán continuar siendo leidos y modificados cuando sea preciso. Esto significa, por supuesto, que una vez que se convierte el sistema de archivos a Ext4, no se puede regresar a Ext3 (aunque hay una posibilidad de montar un sistema de archivos Ext3 con Ext4 de modo que no se utilize el nuevo formato de disco, y así poder volver a montarlo con Ext3, pero así se pierden muchas de las ventajas de Ext4)

  • Mayores tamaños del sistema de archivos y de los archivos: Ext3 soporta 16 TB como máximo tamaño del sistema de archivos, y 2 TB de tamaño máximo de cada archivo. Ext4 añade direccionamiento de bloques de 48 bits, y tendrá 1 EB de tamaño máximo de sistema de archivos y 16TB de tamaño máximo de archivo. 1EB = 1.048.576 TB (1EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB). ¿Por qué 48 bits, y no 64? Hay algunas limitaciones que necesitan ser solucionadas antes de que Ext4 sea capaz de soportar 64 bits, y esas limitaciones no han sido tratadas en Ext4. Las estructuras de datos de Ext4 han sido diseñadas teniendo esto en mente, de modo que una futura actualización a Ext4 implementará soporte completo de 64 bits. 1EB será suficiente (en serio :) hasta que llegue ese momento. (Nota: el código para crear sistemas de archivo mayores de 16 TB no está presente en ninguna versión estable de e2fsprogs)

  • Escalabilidad de subdirectorios: El número máximo de subdirectorios que puede contener un solo directorio en Ext3 es 32.000. Ext4 rompe ese límite y permite un número ilimitado de subdirectorios.

  • Extents: Los sistemas de archivo tradicionales derivados de Unix, como Ext3, utilizan un sistema de mapeo de bloques indirecto para llevar cuenta de cada uno de los bloques correspondientes a los datos de un archivo. Este sistema es ineficiente para los archivos grandes, especialmente a la hora de borrarlos o truncarlos, porque el mapeado mantiene una entrada para cada bloque, y los archivos grandes tienen muchos bloques -> mapeados gigantescos cuya manipulación es lenta. Los sistemas de archivo modernos utilizan un sistema distinto llamado "extents". Un extent es básicamente un montón de bloques físicamente contiguis. Básicamente dice: "Los datos están en los próximos n bloques". Por ejemplo, a un archivo de 100 MB puede asignarsele un solo extent de ese tamaño, en vez de tener que crear un mapeado indirecto para 25.600 bloques (4KB por bloque). Los archivos gigantescos son divididos en varios extents. Los extents mejoran el rendimiento y tambien ayudan a reducir la fragmentación, ya que animan a a utilizar rangos continuos en el disco.

  • Asignación multibloque: Cuando Ext3 tiene que escribir nuevos datos al disco, hay un asignador de bloques que decide qué bloques libres serán utilizados para escribir esos datos. Pero el asignador de bloques de Ext3 solo puede asignar un bloque (4KB) de una vez. Esto significa que si el sistema necesita escribir los 100 MB de datos mencionados anteriormente, tendrá que llamar al asignador de bloques 25600 (¡y solamente son 100 MB!). No solo esto es muy ineficiente, no permite al asignador optimizar la política de asignación porque no puede saber cuantos datos van a asignarse en total, solo sabe lo de un bloque. Ext4 utiliza un "asignador multibloque" (mballoc), que puede asignas muchos bloques en una sola llamada, en lugar de un bloque por llamada, evitando de ese modo sobrecarga. Esto mejora el rendimiento, y es especialmente útil con asignación diferida y extents. Esta característica no afecta el formato del disco. Tambien hay que tomar nota de que el asignador de bloques/inodos de Ext4 tiene muchas otras mejoras, descritas en detalle en este documento.

  • Asignación diferida: La asignación diferida, en inglés delayed allocation, es una mejora de rendimiento (no cambia el formato del disco) que se encuentra en sistemas de archivos modernos como XFS, ZFS, btrfs or Reiser 4; no es una técnica muy expandida por haber sido considerado hasta hace poco como "peligrosa", y que consiste en retrasar la asignación de bloques lo más posible, contrariamente a lo que los sistemas de archivo tradicionales (como Ext3, reiser3, etc) hacen: asignar los bloques tan pronto como es posible. Por ejemplo, si un proceso escribe con write() algo, el sistema de archivos asignará inmediatamente los bloques en los que se colocarán los datos - incluso si los datos no se están escribiendo al disco en ese mismo momento y se van a mantener en el cache algún tiempo. Esta aproximación tiene desventajas. Por ejemplo, cuando un proceso está escribiendo continuamente datos a un archivo que va creciendo, write()s sucesivos asignarán bloques para los datos, pero el sistema de archivos no puede saber si el archivo va a continuar creciendo. Sin embargo, la asignación diferida no asigna los bloques inmediatamente cuando el proceso usa write()s; en vez de eso, difiere la asignación mientras los datos del archivo se mantengan en el cache, hasta que se escriban definitivamente en el disco. Esta aproximación da la oportunidad al asignador de bloques de optimizar la asignación en situaciones en las que el antiguo sistema no podía. La asignación diferida encaja muy bien con las dos anteriormente mencionadas características, extents y asignación multibloque, porque en muchos tipos de carga, cuando el archivo se escribe finalmente al disco, puede asignarse en extents cuya asignación de bloques se ha llevado a cabo con el sistema de asignación multibloque. El rendimiento mejora, y la fragmentación se disminuye en ciertos tipos de carga.

  • Fsck rápido: Hacer un fsck es una operación muy lenta, especialmente el primer paso: comprobar todos los inodos del sistema de archivos. En Ext4, al final de cada tabla de grupo de inodos se almacena una lista de inodos no utilizados (junto a un checksum, por seguridad), de modo que el fsck no los comprobará. El resultado es que el tiempo de fsck mejora de 2 a 20 veces, dependiendo del número de inodos utilizados. Hay que notar es fsck, y no Ext4, quien construye la lista de inodos no utilizados. Esto significa que tendrás que pasar un fsck para que se construya la lista de inodos no utilizados, y entonces el próximo fsck será el que sea más rápido (necesitas pasar un fsck para convertir un sistema de archivos Ext3 a Ext4 de todos modos). Hay tambien una característica que toma parte en este aceleramiento del fsck - "flexible block groups" - que tambien acelera las operaciones normales del sistema de archivos.

  • Checksumming del Journal: El journal es la parte más utilizada del disco, lo cual hace que los bloques que forman parte de él sean más susceptibles a sufrir un fallo de hardware. Y tratar de recuperar un log de un journal corrupto puede inducir a una corrupción masiva. Ext4 hace un checksum del journal para saber si los bloques del journal están fallando o están corruptos. Pero el checksumming del journal tiene un bonus: permite convertir el sistema de dos fases de Ext3 a una sola fase, acelerando las operaciones del sistema de archivos hasta en un 20% en algunos casos - asi que en este caso se gana fiabilidad y rendimiento al mismo tiempo. (Nota: La parte de esta característica que mejora el rendimiento, el logging asíncrono, está desactivado por defecto y será activado en el futuro)

  • Defragmentación en vivo: (Esta característica no está disponible en 2.6.28, pero probablemente lo estará en la próxima versión). Aunque la asignación diferida, los extents y la asignación multibloque ayudan a reducir la fragmentación, con el uso los sistemas de archivos pueden fragmentarse. Por ejemplo: Escribes tres archivos en un mismo directorio y contiguamente en el disco. Algún día necesitas actualizar el archivo del medio, pero el archivo actualizado es un poco más grande, asi que no hay suficiente espacio para él. No queda otra opción que fragmentar el exceso de datos a otro lugar del disco, que causara movimiento de brazo extra en el disco y por tanto pérdida de rendimiento, o tambien puedes asignar para el archivo actualizado espacio contíguo en otro lugar lejano a los otros dos archivos, lo cual causará movimiento de brazo si una aplicación necesita leer todos los archivos de un directorio (por ejemplo, un gestor de archivos creando miniaturas de un directorio lleno de imágenes). Además, el sistema de archivos solo puede ocuparse de ciertos tipos de fragmentación, no puede saber, por ejemplo, que debe mantener todos los archivos relacionados con la carga del SO juntos, porque no sabe qué archivos están relacionados con la carga del SO. Para solventar este problema, Ext4 soporta defragmentación en vivo, y hay una herramienta llamada e4defrag que puede defragmentar archivos individuales o todo el sistema de archivos.

  • Características relacionadas con los inodos: inodos más grandes, marcas de tiempo con granularidad de nanosegundos, atributos extendidos rápidos, reserva de inodos...

    • Mayores inodos: Ext3 soporta la configurabilidad de los tamaños de inodo (mediante el parámetro -I de mkfs), pero el tamaño de inodo por defecto es de 128 bytes. Ext4 por defecto tendrá 256. Este aumento es necesario para hacer espacio a varios campos extra (como la granularidad de nanosegundos o el versionamiento de inodos), y el tamaño restante del inodo será utilizado para almacenar atributos extendidos que sean lo suficientemente pequeños como para caber en ese espacio. Esto hará que el acceso a esos atributos sea mucho más veloz, lo cual aumenta entre 2 y 7 veces el rendimiento de las aplicaciones que hacen uso de estos atributos extendidos apodados "rápidos".

    • Reserva de inodos: La reserva de inodos consiste en reservar varios inodos para futuros archivos cuando se crea un directorio, confiando que serán utilizados en el futuro. Esto mejora el rendimiento, porque cuando los nuevos archivos sean creados en ese directorio podrán usar esos inodos que habían sido reservados. Por tanto, se mejora el rendimiento de la creación y eliminación de archivos.

    • Marcas de tiempo con granularidad de nanosegundos: Esto significa que los campos como mtime (modified time) o atime (access time) podrán usar una resolución de nanosegundos, en vez de la que hace uso Ext3, que tan solo alcanza una granularidad a nivel de segundo.

  • Preasignación persistente: Esta característica (disponible en Ext3 en las últimas versiones del kernel, y emulada la por glibc de no estar disponible) permite a las aplicaciones preasignar espacio de disco: El sistema de archivos asigna el espacio libre y los bloques necesarios, pero no hay ningún dato en ellos hasta que la aplicación verdaderamente se decida a escribirlos en el futuro. Esto es lo que las aplicaciones P2P hacen cuando preasignan espacio para descargas que tardarán horas o días en completarse, pero implementado con más eficiencia por el sistema de archivos y con una API genérica. Tiene muchos usos: en primer lugar, para evitar que las aplicaciones (como los P2P) lo hagan ellas mismas ineficientemente llenando un archivo de ceros. Segundo, para mejorar la fragmentación, ya que los bloques se asignarán de una sola vez para todo el archivo lo más contiguamente posible. Tercero, para asegurarse de que las aplicaciones tienen el espacio que ellas creen que van a necesitar, lo cual es importante para las aplicaciones tipo RT, ya que sin preasignación el sistema de archivos podría llenarse en la mitad de una operación importante. Esta característica está disponible mediante la interfaz de glibc posix_fallocate().

  • Barreras activadas por defecto: Esta opción mejora la integridad del sistema de archivos a costa de algo de rendimiento (se puede desactivar con "mount -o barrier=0", recomendado si estás haciendo benchmarks). De este artículo de LWN: "Antes de escribir el registro de commit [en el journaling], el código del sistema de archivos debe estar totalmente seguro de que todos los datos de las transaciones ha llegado al disco. Escribir los datos al disco en orden no es suficiente; los discos hoy en día tienen grandes caches y reordenarán las operaciones para mejorar el rendimiento. Asi que el sistema de archivos debe ordenar explicitamente al disco que escriba todos los datos del journaling antes de escribir los datos del registro de commit; si el registro de commit se escribe antes, el journal podría corromperse. El subsistema de E/S del kernel facilita esta tarea a travñes del uso de barreras; en esencia, una barrera prohibe la escritura de cualquier bloque tras la barrera, hasta que todos los bloques que se hayan escrito antes de la barrera estén realmente escritos en el disco. Utilizando barreras, los sistemas de archivos pueden estar verdaderamente seguros de que su estructura se mantiene siempre consistente en el disco"


Cómo usar Ext4:

Esta es la primera versión estable de Ext4, asi que aunque todo el desarrollo y lanzamiento final de este sistema de archivos se ha enlentecido y retrasado mucho para garantizar el mismo nivel de estabilidad que podría esperarse de las actuales implementaciones de Ext3, no dejan de aplicarse las mismas reglas que se aplican a todo software ".0".

Algo muy importante que hay que tener en cuenta es que NO hay soporte de Grub para Ext4. Bueno, eso no es del todo cierto: Hay soporte, pero no en las versiones utilizadas por las distros estables. Hay soporte en la rama de desarrollo de GRUB2, pero solo desde este commit. Hay paquetes de grub2 disponibles en Ubuntu y distros derivadas de Debian bajo el nombre "grub-pc". En la rama estable 0.9x, no hay soporte oficial, pero hay un proyecto de Google SoC que lo desarrolló, y Google encuentra parches. Asi que escoje. Las próximas distros basadas en Linux 2.6.28 probablemente tengan el soporte de un modo u otro. La opción segura es dejar tu directorio /boot en una partición Ext3.

Tambien necesitas una version de e2fsprogs actualizada, se recomienda la última versión estable, 1.41.3.

Migrar a Ext4 es muy sencillo. Hay tres métodos diferentes:

  • Creando un sistema de archivos desde cero: La opción más fácil, recomendada para las nuevas instalaciones. Simplemente actualiza el paquete e2fsprogs a Ext4, y crea el sistema de archivos normalmente.

  • Migrar un sistema de archivos Ext3 existente a Ext4: Tienes que utilizar la herramienta tune2fs en el sistema de archivos deseado, y ese sistema de archivos DEBE estar desmontado. Ejecuta:

    # tune2fs -O extents,uninit_bg,dir_index /dev/tusistemadearchivos

    Despues de ejecutar esto, DEBES pasarle un fsck. Si no lo haces, Ext4 NO MONTARÁ el sistema de archivos. Este fsck es necesario para devolver el sistema de archivos a un estado consistente. Te dirá que se han encontrado "checksum errors in the group descriptors". Es normal, eso es exactamente lo que tiene que reconstruirse para poder ser montado con Ext4, asi que no te sorprendas al verlos. Dado que para a preguntarte cada vez que encuentra uno de esos fallos, siempre responde que SI. Si no quieres que te pregunte, pásale el parámetro "-p" a fsck, significa "reparación automática":

    # fsck -pf /dev/tusistemadearchivos

    Hay otra cosa que debe mencionarse. Todos los archivos existentes continuarán utilizando el formato antiguo de mapeo indirecto para mapear todos los bloques de los datos. La herramienta de defragmentación en vivo permitirá migrar cada uno de esos archivos al formato de extents (utilizando una ioctl que ordena al sistema de archivos que reescriba el archivo en el formato de extents; puede utilizarse con seguridad mientras se usa el sistema de archivos con normalidad)

  • Montar un sistema de archivos Ext3 con Ext4, sin utilizar, de entre las nuevas características de Ext4, las que cambian el formato del disco. Podrás volver a montar el sistema de archivos con Ext3 de nuevo: Puedes montar un sistema de archivos existente con "mount -t ext4 /dev/tusistemadearchivos /mnt". Hacer esto sin haber hecho el proceso de conversión descrito en el punto de arriba forzará a Ext4 a no utilizar las características nuevas que utilizan el nuevo formato, solamente se utilizarán las características que no lo cambian, como mballoc o la asignación diferida. Se podrá, de este modo, volver a montar el sistema de archivos de nuevo como Ext3. Pero obviamente así te pierdes muchas de las ventajas de Ext4...

25 comentarios:

  1. Lo cierto es que ya me impresionó en su día ver como un fork pequeñito iba evolucionando en algo realmente potente e innovador respecto de ext3, pero tu resumen de nuevas features de ext4 deja mucho más claro que el salto va a ser muy grande respecto a la anterior generación del sistea de archivos y según tengo entendido usando bastante menos CPU de la que usaba Reiser4 (además de utilizar las API´s del kernel y no inventarse cosas de uso propio, claro :-D)

    ResponderEliminar
  2. Como siempre gracias por el trabajo que te has pegado.

    Pinta muy bien Ext4, y lo utilizaré, pero más adelante, que todavía no me fío.

    Mi ordenador cada día nota más la vejez así que todo lo que sea mejoras de rendimiento le vienen bien, parece que Ext4 irá muy bien con archivos grandes, pero ¿con los pequeños? Estoy deseando que salgan comparaciones con los sistemas existentes. Ahora mismo sólo uso Ext3, pero siempre estuve tentado a utilizar varios sistemas a la vez para aprovechar las ventajas de cada uno. ¿Esto seguirá siendo así o Ext4 barrerá a todos?

    Por cierto, me ha hecho gracia lo de la utilidad de desfragmentación. Más de uno se tirará de los pelos al recordar la de Windows.

    ResponderEliminar
  3. Hola Diego y demás:

    Me parece estupenda esta información del EXT4. Lo impolementaría hasta que le pongan todo eso, si no es en el 2.6.28, me pasaré tranquilamente cuando lo pongan en el 2.6.29 ;-)

    Parece que trae nuevas cosas, pero por lo que comentas, me lo esperaré un poco, para que lo afinan un poco más, y es cuando lo instalo en este portátil (que lo puedo hacer con un CD actualizado, pero con el e2fsprogs actualizado a 1.40 para arriba, que es lo que se necesita actualmente).

    Yo estoy usando Debian Sid, y me parece estupendo lo que están haciendo ahora con el EXT4, que no cabe duda, que lo implemente definitivamente, y espero que ello me contribuya a mantenerlo definitivamente :-)

    Slds. y felices fiestas.

    ResponderEliminar
  4. Eso de poder defragmentar un fichero me va a venir de pm para las máquinas virtuales y sus virtuales discos duros :-)

    Que ganas de que salga ya estable. (más ganas hay para Btrfs, pero bueno...)

    ResponderEliminar
  5. "Asignación retrasada" es una traducción no propia de descorazonados sino de cobardes.

    Lo correcto sería traducir "delayed allocation" por "asignación diferida" o "asignación aplazada" ya que no se trata de un "a saber cuando se asigna" -como en los aeropuertos- sino de interponer un plazo para la realización del write() -su permanencia en cache si no he entendido mal-.

    Que el que le puso el nombre en inglés se "olvidase" de llamarlo "deferred allocation" -por ejemplo- no nos impide ser valientes y llamar a las cosas por su nombre en vez de escondernos detrás de lo exótico que suena el anglicismo de turno. Porque para eso a mi me gusta más el "Allocate-on-flush" original.

    ResponderEliminar
  6. Fantástico Diego.
    ¿Podrías subir esto a la wikipedia? La descripición actual es muy pobre:
    http://es.wikipedia.org/wiki/Ext4

    ResponderEliminar
  7. Anónimo4:25 p. m.

    Pues no sé si el español será fascista y opresor, pero de momento tú ya has evitado escribirlo correctamente.

    ResponderEliminar
  8. Sr. Talibán Ortográfico: Aplaudo sus sugerencias. Sin embargo, en este tipo de posts siempre tengo que elegir entre la traducción total de los anglicismos, que desgraciadamente degenera -en mi opinión- la calidad técnica del texto y lo hace casi incomprensible, o no traducir ninguno, que es como que no se tradujera nada y además lo hace sentir a uno traidor de la patria. Asi que suelo optar por traducir los anglicismos más obvios y dejar los más esperpénticos. Sin embargo, agradezco su hallazgo, "asignación diferida", y ahora mismito lo estampo en el original.

    ResponderEliminar
  9. Anónimo4:48 p. m.

    quería haber dicho llamarlo correctamente: español; y no ejpanol.

    ResponderEliminar
  10. Tu post me parece excelente pero (gracias a ello) me a surgido una gigantesca duda. Despues de oirte hablar de eficiencia y del movimiento de brazo, imagino que estas hablando de un disco duro fisico. Que pasa con las tarjetas flash? No son acaso el futuro de los discos duros? Estan los nuevos sistemas de archivos desarrollandose por ese camino o habra que utilizar otros sistemas de archivos especificos?

    Gracias por tu tiempo y enhorabuena por el blog

    ResponderEliminar
  11. oscar: Si, parece que los discos SSD son el futuro, pero aun está por ver como se materializa ese futuro en el mundo de los sistemas de archivos, que aun está por ver. En la versión anterior de Linux se incluyó un sistema de archivos diseñado específicamente para almacenamiento flash (ubifs), pero solo para almacenamiento flash sin FTL...

    ResponderEliminar
  12. sin haber probado aún el EXT4, mucho tendria que mejorar el rendimiento del EXT3 para siquiera acercarse al de ReiserFS, lo mismo pasa con el fsck... eterno es el de un EXT3, y aunque la version nueva lo mejore en hasta 20 veces (y no sera siempre, dependera de lo usado que estuviera el disco cuando el SF cayó) tampoco estará ni cerca de el fsck que hace un ReiserFS, con la ventaja que en caso de encontrar "cosas perdidas" lo suele recuperar, mientras que en un EXT aparece una carpeta LOST+FOUND con ficheros nombrados secuencialmente que no sirve para una mierda... y sino que me diga quien sea si ha sido capaz de encontrar aquel fichero que se perdió cuando se cayó un servidor con un disco EXT3 entre toda la basura "recuperada" por fsck!! como mucho a los 100 ficheros revisados (los muuuuuy pacientes) optará probablemente por borrar toda la basura y dar el fichero por perdido

    lástima que a quien sea no le gustara que existiera un SF muchiiiiisimo mejor que EXTn y sobre el que no tuvieran el control ni entendieran su logica

    ResponderEliminar
  13. Anónimo9:33 p. m.

    a ver si aprendes a escribir paleto

    ResponderEliminar
  14. Anónimo9:36 p. m.

    igual de fascistas son ellos que tú

    ResponderEliminar
  15. makj: reiserfs es peor que ext4, los de suse cambiaron reiserfs por ext3 como sistema de archivos por defecto, hay un buen post que explica el por qué....

    Anónimo: LLO HEJKRIVO PERSEPTAMENTE PALETO

    ResponderEliminar
  16. Anónimo10:15 a. m.

    ¿Hay alguna explicación para el primer enlace, y la mención a lo de "fascista y opresor"? Porque el texto al que enlazas es larguísimo y no quisiera perder el tiempo leyéndolo entero (estoy ya harto de leer cosas así), pero en los primeros párrafos habla de la opresión de personas a personas (una opresión que supongo nadie niega a día de hoy). Cierto que el título es desafortunado, pero... ¿qué coño tiene que ver con Ext4? ¿Vale la pena que tengas que empezar tu texto así?

    Que ya sé que es tu blog, y escribes en él lo que te dé la gana, pero a mí personalmente me ha dolido mucho ver eso, en serio. Estoy muy cansado de leer discusiones como a la que invitas al poner ese enlace y hacer esa mención, y no me apetece nada tener que leerlo. Ayer vi el titular de esta entrada en mi lector de RSS, y me lo dejé para leer con más calma hoy, y cuando me dispongo a hacerlo, me encuentro con algo que me resulta bastante doloroso. Quizás yo tenga la piel demasiado fina, pero en serio, creo que no resulta nada bueno contestar a un error con otro error.

    ResponderEliminar
  17. De acuerdo con el último anónimo. No sé qué pinta esa referencia en un texto sobre EXT4. El escrito enlazado puede tener su parte de razón, o no, su parte de historia verificada, o no, pero en cualquier caso no aporta absolutamente nada a lo que aquí se hable.

    Tu blog es uno de los leo con mayor frecuencia, ya que tienes la virtud de resumir y explicar de manera sucinta textos que en origen resultan a veces un poco pesados de leer.

    Sin embargo, como catalán me disgusta profundamente que metas aquí debates que no tienen absolutamente nada que ver con Linux, y más propios de otras páginas donde se suele hablar a lo cafre de estos temas.

    Saludos,
    Eduard

    (PS: me ha extrañado inicialmente ver que una entrada sobre Ext4 tenía 16 comentarios (se me había pasado inicialmente el enlace). Ma ha bastado empezar a leerlos para ver la razón rápidamente...)

    ResponderEliminar
  18. El enlace a ese texto catalán es simplemente humor. Me gusta burlarme de estupideces así, no sé porque a otros les causan dolor de ningún tipo, a mi solo me causan risa y supongo que a la mayoría de la gente tambien.

    ResponderEliminar
  19. Anónimo10:25 p. m.

    A mi también me ha sorprendido la entrada del texto. Diego, reconocerás que cuando el humor es demasiado sutil y falta contexto para poder interpretarlo en sus intenciones, puede llegar a resultar ofensivo. No soy de la opinión del enlace pero creo que cabe entenderlo de muchas maneras (descabellado, humorístico, irónico, pero también agresivo).

    Es sorprendente la mezcla de una descripción precisa con una referencia de tan difícil interpretación en sus intenciones.

    Gracias de todos modos por tu trabajo.

    ResponderEliminar
  20. Hola Diego, el concepto de "barreras" es muy similar al de los "Checkpoints" en las Bases de Datos. ¿Es así?

    Estaría muy bueno analizar qué es lo que le falta a EXT4 para igualar en características a ZFS (además de madurez, claro) :-)

    Saludos
    Marcelo

    ResponderEliminar
  21. Marcelo: No es exactamente lo mismo pero si está relacionado, las barreras es el sistema que se utilizaría para implementar la parte final de un mecanismo de transacciones.

    En cuanto a ZFS; Ext4 jamás lo alcanzará en características, es imposible, para eso se inició btrfs

    ResponderEliminar
  22. Tambien, en caso de emergencia, se puede marcar el "test_fs" en un ext4 para volver a montar como ext3 o ext4dev, pero solo en caso de emergencia (ejemplo: user un liveCD con un kernel <2.6.28

    ResponderEliminar
  23. Por cierto, otra cosa, hay un bug conocido en la versión ext4 que trae el 2.6.28 que informa a las aplicaciones que escriben de que no hay espacio en disco cuando realmente sí lo hay.
    Es un poco molesto, y será arreglado en la versión 2.6.29 (o si la distribución que se usa trae un parche), y como 'workarround' temporal, se puede desmontar y remontar la partición cuando ésto suceda (y si es la partición /, reiniciar).
    Si os encontráis con éste fallo, no os tiréis de los pelos como yo, sino simplemente haced eso, o esperad hasta el 2.6.29 ;)

    ResponderEliminar
  24. Migrado ext3 a ext4 siguiendo los pasos dados.

    Todo perfecto, lo único que el fsck ha tardado un poco (partición de 917gigas). Bastante contento, y como parece que e4defrag aún no está listo, el viejo método de copiar y mover ha hecho el resto.

    ResponderEliminar
  25. Anónimo1:30 a. m.

    Que horrible que llames al idioma español fascista y opresor cuando ese idioma al que te refieres es al Castellano.

    El "español" no existe y yo por ejemplo hablo es colombiano y para más señas antioqueño y más detallado aún Medellinense!

    Horrible tu actitud y más en un documento de tecnología.

    Ahora que .... para fascistas y opresores todos los españoles y te lo digo desde américa a donde nos mandaron a los "mejores" de su raza. Todos ustedes, lo fueron, lo son y lo seguirán siendo.

    ResponderEliminar