Una interesante opinión del problema de Ext4

Supimos que Ext4 fue aceptado en el núcleo Linux , poco tiempo después, se encontraron problemas en cierto software, como KDE, que podía poner en riesgo su estabilidad al corromper o perder archivos al escribir en ellos. Se determino que el problema surgía de una falla de las aplicaciones, en el método en el cual ellas escribían información en los archivos.

Esta es mi traducción de un comentario anónimo de un articulo de Slashdot sobre el tema de la estabilidad del Sistema de Archivos Ext4. Espero que a ustedes lectores no les importe quién escribió el mensaje sino el mensaje en sí. El articulo lo pueden ver aquí y el enlace directo al comentario aquí.

“Sólo en Linux es culpa del usuario que las aplicaciones tengan pérdida de datos debido a que los desarrolladores de núcleo Linux cambiaron la semántica del sistema de archivos. Al menos Microsoft toma un poco responsabilidad por sus errores. : /[1]

He seguido el debate de ext4. Aquí está un rápido sinopsis:

• 
  
  Un hacker del núcleo Linux descubre en una comparativa de rendimiento que puede hacer que un Sistema de Archivos funcione 50% más rápido si él reordena la escritura de metadatos del Sistema de Archivos por delante de la escritura de datos del Sistema de Archivos. El hacker escribe en su código un mensaje: "¡Ahora es 50% más rápido!".
  
  
  

• 
  
  A los pocos meses, los usuarios empiezan a descubrir corrupciones de datos en los archivos de KDE. Específicamente, una copia de un archivo A a A¹, ftruncate(A¹), write(A)¹, rename(A¹ a A), bloquea el cliente, causando que el archivo contenga los datos de A y no de A¹.[2]
  
  
  

• 
  
  El hacker del núcleo de Linux ignora el problema como “no-es-un-bug”, debido a que las aplicaciones no hacen uso correctamente de fdadasync() / fsync(), que (de acuerdo a la semántica de POSIX[3]) debería prevenir la corrupción de datos. El detalle es que actualmente POSIX no dice que rename es una "barrera de escritura" entre los datos y los meta-datos, aunque todo el mundo supone que es así y TODOS los demás sistemas de archivos lo toman así ( y en mi opinión como programador de sistemas profesionales, esto es una deducción de comportamiento en el estándar de POSIX y no un comportamiento deseado). Entonces el hacker del núcleo de Linux técnicamente esta en lo correcto, pero ha introducido un comportamiento que va en contra de todas las implementaciones anteriores.
  
  
  

• 
  
  El hacker del núcleo de Linux (y algunos escritores de Slashdot) atacan a los desarrolladores de KDE por ser incompetentes por que ellos no leyeron una sub-sub-clausula de las especificaciones de POSIX que 1) no esta mencionada en man[4], 2) de todos modos solo es leída por los programadores del núcleo, y 3) es acerca de dos ordenes de magnitudes tan arcanas que cualquier desarrollador promedio de interfaces graficas jamás leería su documentación.
  
  
  

• 
  
  El 90% de los usuarios y el 80% de los programadores se preguntan que demonios son fdatasync() y fsync(), cual es la diferencia entre las barreras de escritura que tienen los datos y los meta-datos, y por que el comportamiento predeterminado [de Ext4] corrompe los datos.
  
  
  

• 
  
  El hacker del núcleo de Linux promete hacer unos cuantos parches para arreglar el problema, así no romper el software que ha estado funcionando bien en los últimos 10 años.
  
  
  

• 
  
  Aquellos que tienen experiencia se dan cuenta que desde que el hacker dijo que no era un problema en primer lugar, saben que estos parches tienden a ser más un intento de solución a medio-terminar que ser un parche que garantice la integridad de los datos. La programación tiene una historia larga y orgullosa de hacer una solución rápida para satisfacer (en este caso, la comunidad de Linux) haciendo que un síntoma se vaya en vez de arreglar el problema desde la raíz.
  
  
  

• 
  
  Nosotros preguntamos en Slashdot si el problema fue realmente solucionado, por que el 99% de nosotros no tiene la experiencia técnica de entender los parches del Sistema de Archivos de Linux como para averiguar si actualmente ha sido solucionado.
  
  
  

Tengo una moraleja en esta historia. Los Sistemas de Archivos tienen una cardinal, una regla inviolable: NO CORROMPER LOS DATOS DE LOS USUARIOS. La garantía que de si el usuario realiza una lectura de datos, el usuario va a obtener ó buenos datos ó un error (o la indicación explicita de que no existen datos). [Por ejemplo, los desarrolladores de] Google le gusta los Sistemas de Archivos que pierden datos, pero ellos no devuelven resultados de búsqueda corruptos. Con Ext3 puede reordenar las escrituras, pero utiliza un flujo de datos seguro de 5 segundos de forma predeterminada para mantener un indicé de corrupción de datos bajo. Ext4 ignora esta regla que permite una silenciosa corrupción de datos pero que logra ser el mejor en comparativas de rendimiento, y en vez de aceptar la responsabilidad, el hacker de núcleo culpa los cuestionamientos de los demás.

El peor peligro para el éxito de Linux no es Microsoft. Es el orgullo de muchos desarrolladores de Linux , los usuarios y defensores, que están demasiado ocupados viendo quien es responsable y culpar a todos los demás para solucionar los problemas de usuario real. (Y sí, soy un seguidor de la filosofía de Raymond)[5].”

En mi experiencia, nunca he tenido problemas de estabilidad con Ext4 (más que hacer que mi disco duro se caliente como el diablo), actualmente, existen muy pocas distribuciones que utilizan Ext4 en la instalación de forma predeterminada. Sin embargo, el simple hecho de ofrecer como alternativa viable a Ext4 sin ofrecer ninguna advertencia es para mí, una clara muestra de la falta de responsabilidad de parte de los desarrolladores hacia los usuarios y una clara muestra de las fallas en el diseño de las distribuciones[6].

[1] Por favor, no comenten acerca de esto por que esta fuera de tema, yo solo traduje, ¿ok?.

[2] En realidad no es así, es peor. El comando rename ha apuntado A a A¹, pero los datos de A¹ aun no se han escrito así que no tiene datos. Eso hace que un cambio en un archivo de configuración podría terminar con un archivo de configuración con 0 bytes, provocando que posteriormente la aplicación falle (pues la mayoría de las aplicaciones solo recrean un archivo de configuración a su estado predeterminado cuando dicho archivo no existe, no cuando este se encuentra vacio).

[3] "Interfaz para Sistemas Operativos migrables basados en UNIX". Especificaciones de diseño que el software debería seguir para que sea compatible con otros sistemas operativos basados en UNIX.

[4] Ya saben, es el sistema de documentación de sistemas operativos basados en Unix.

[5] Lo mismo que el punto [1].

[6] Ejemplo, Windows desactiva el cache del disco duro por defecto y puede ser activada esta opción por medio de una interfaz grafica. En la misma interfaz se le advierte al usuario de la posible perdida de datos y se le recomienda tener una fuente alterna de energía para evitar esto. Pero desconozco si el retraso de la escritura de datos es tan larga como la de Ext4 (60 segundos). Supongo que no lo es.