Estamos viviendo un momento en el que está surgiendo (o mejor dicho terminando de surgir) un nueva generación de sistemas de ficheros. Estamos asistiendo a evoluciones en los sitemas de ficheros de red, inclusión de características RAID y mejoras en la utilización del ancho de banda sobrante de los discos, entre otras muchas cosas.

Todo esto supone, bajo mi punto de vista, un cambio lógico y positivo, aunque desgraciadamente no todo ha sido perfecto y han saltado algunas polémicas con algunos sistemas.

Creo que la más sonada ha ocurrido con ext4 y una característica llamada allocate-on-flush o delayed allocation. Esta técnica consiste marcar como ocupado el espacio necesario para escribir unos datos que se han ordenado guardar en el sistema de ficheros, posponiendo la escritura real de los mismos al momento que el sistema estime conveninente. Este sistema permite, por un lado, mejorar el rendimiento del sistema, ya que se pueden escribir los datos en un momento de menor carga, por ejemplo, a la vez que posibilita un almacenamiento más ordenador de la información en el disco duro (menor fragmentación), lo que se traduce en tasas de lectura más altas.

Cuando ext4 se marcó como release, ubuntu lo activó en la beta de Jaunty saltó la alarma dado que bajo ciertas condiciones este sistema daba como resultado archivos con logitud 0 (quiere decir, ningún contenido). En realidad, el problema era debido al uso incorrecto de la systemcall fsync() por parte de muchas aplicaciones, que además provoca demoras y sensación de bloqueos en el sistema.

Ante este comportamiento hay mucha gente que se ha sentido insegura con respecto a la integridad de los datos en este sistema de ficheros, aunque mi planteamiento va mucho más allá.

A la hora de montar un sistema para producción (aka. servidor), la teoría dice que es conveniente maquetarlo y de esta forma poder testear el rendimiento, la estabilidad, la seguridad y la fiabilidad del sistema. La práctica me dice que en muchas empresas esto “no es posible” y los sistemas se pasan directamente a producción.

Dependiendo pues del tiempo que se tenga para implantarlo, se mirará el elegir el sistema de ficheros más conveniente para la aplicación que tendrá el servidor. Existe una oferta más o menos amplia, y cada sistema ofrecerá mejor rendimiento, estabilidad u otro tipo de características al servicio que se quiere montar, eso está claro. Pero cuando no hay tiempo de eso… ¿Qué se hace?

Muchas veces se utiliza un sistema de ficheros que se sepa que funciona más o menos bien, en términos de rendimiento, dando por hecho que todos son estables. Sin embargo esto no tiene por qué ser necesariamente cierto. Si no se hacen cuadrar buffers, tamaños de bloques de escritura por parte de los servidores, los sistemas de ficheros, tamaños de clusters, distribución de los bloques de datos en los discos de un RAID, etc. siempre se puede meter la pata. Esto implicaría que bajo determinadas circunstancias muy concretas se podrían perder datos o quedar éstos en un estado inconsistente. Sería el caso, por ejemplo, de ejecutar un MySQL en ext3 con las opciones de montaje por defecto y utilizando innDB con cache.

Tal y como he comentado, hay que tener en cuenta muchas características: los discos utilizados, la controladora RAID (en caso de que exista), el sistema de ficheros y la configuración del servidor. Así pues, es necesario informarse de la correcta configuración de todos estos datos antes de poner un servidor en producción.

Con respecto al problema de ext4 en ubuntu, el autor de zona de sistemas me ha comentado que como usuario en entorno gnome de este sistema no ha tenido ningún tipo de problema. Gracias a él por aportarme estos datos.