Torvalds, preocupado por ext3 y ext4
Los sistemas de ficheros están siendo uno de los componentes que más están evolucionando en los últimos meses. Muchas distribuciones ya dan soporte a ext4 de forma nativa, y de hecho Fedora 11 lo tendrá como sistema de ficheros por defecto, mientras que Ubuntu permite elegirlo -aunque no sea la elección de serie- en su nueva edición, la 9.04 Jaunty Jackalope.
Sin embargo, no todo parece ser de color de rosa en este segmento: varios de los máximos desarrolladores de Linux y del mundo Open Source están teniendo un debate muy intenso sobre la eficacia real de sistemas de ficheros como ext4, que entre otras cosas se caracteriza por escrituras aplazadas en el tiempo, pero ese periodo de retraso es para algunos excesivo.
De hecho, Linus Torvalds ha arremetido contra esta característica de ext4 e incluso también ha atacado a ext3 -aunque en este caso dicho tipo de función no está activada por defecto- mientras que otros desarrolladores como Ted Ts’o -probablemente el mayor experto actual en este área- tratan de defender sus argumentos y explican que la diferencia entre retrasar las escrituras cinco segundos o 3 minutos no es representativa, y las ventajas son muchas para el resto de componentes del sistema.
Otros gigantes del desarrollo Open Source como Jesper Krogh, Ingo Molnar o Andrew Morton también se han metido en un debate tras el anuncio del kernel 2.6.29 en las listas de correo de este desarrollo, de modo que habrá que ver cómo acaba esa acalorada discusión. Desde luego desde un punto de vista práctico parece que ext4 solo trae ventajas a los usuarios, de modo que no puede ser tan malo… ¿o sí?
Claro que esta mal imagina un retraso de 6 minutos para almacenar todos los cambios en el disco duro, si por alguna razón se apaga la computadora, se congela etc. Todo lo ultimo que hubieras hecho los últimos minutos se pierde porque nunca se guardo.
Para un servidor puede no ser relevante, pero para una portátil es critico
Sin embargo las opiniones son diferentes y Puede ser malo dependiendo del punto de vista en que lo veas…
Bien lo dice un refran….no dejes para orita, lo que puedas hacer ahora….. jeeje
ahora en serio, un retraso, como indican, puede provocar perdida de los datos que no se han guardado en caso de un fallo electrico. Esto genera desconfianza en el sistema, ya que cuando hay un fallo electrico, nunca es planeado y nunca sabes lo que estaras haciendo cuando ocurra, o que tan importante es.
Pense que habian optimizado el sistema de alguna forma que no implicara un riesgo como este, porque en vista de este funcionamiento, es de plantearselo una segunda vez.
No sere un experto en el tema, pero en el caso de que el ordenador se cuelge o de que se vaya la luz NO pasaria nada, puesto que desde ext3 (ext3 incluido) ext viene con journaling, es decir, cuando se vuelva a encender tendra escritos que archivos se estaban moviendo, copiando, y terminara, o empezara, la operacion.
Tardara un poco mas en arrancar, pero no se acaba el mundo
S
Se a cortado el mensaje, iba a decir que me parece muy bien la funcion de aplazar los procesos, puesto que deberia dar agilidad al sistema cuando mas lo necesita, y quitar velocidad cuando no este haciendo practicamente nada.
Teóricamente estamos en un punto donde la informática nos garantiza pocos fallos de equipos, tanto de hardware como de software. Eso reduce el tema a un asunto de alimentación eléctrica. Aquí hay muchos fallos eléctricos, específicamente interrupciones de segundos o minutos, pero no es nada que no se pueda resolver con un UPS, y en un laptop, es transparente. Vamos a probar el EXT4 y veremos que ocurre ¿no les parece?
Para debatir del tema hay que hacerlo con criterio, y no me siento capacitado pues no conozco las especificaciones técnicas de cada sistema de archivos.
Una cosa debe quedar clara, pues en un primera lectura la “escritura postergada” pareció asustar a varios lectores. Pero como dijo @Dv, ext viene con journaling, por lo tanto cualquier juicio sobre la característica en discución por la mayoría es inutil.
Como todo cambio, como toda evolución tenemos los partidarios y detractores… como dejó a entender @Jesus, el tiempo juzgará la tecnología.
“Todo lo ultimo que hubieras hecho los últimos minutos se pierde porque nunca se guardo.”
Y encima los nodos índice y los directorios sí que se habrán escrito porque tienen un umbral menor que los datos reales, así que tendrás un sistema de ficheros con ficheros corruptos que el fsck no es capaz de arreglar.
Si Linus ve deficiencias, algo hay. Esperaremos como termina todo esto.
¿Velocidad o seguridad? Sin dudarlo me decanto por lo segundo. Mis datos son demasiado importantes como para, en pos de ganar unos mugrosos segundos, correr el riesgo de perderlos. No confío para nada en el Ext4, y jamás confiaré ciegamente en las computadoras. Son máquinas, y como tales, sujetas a fallos. Prefiero un sistema un poco más lento pero sólido y confiable.
Por lo pronto seguiré con Ext3 por un buen tiempo.
… ¿y porqué no un poco de ambas características? Velocidad y seguridad.
Quizá un tema de porcentajes ¿Qué tal un 60% de Seguridad y un 40% de Velocidad?
¿Podría ser ajustable? No creo que sea tan dificil para los programadores?
@Luciano
“Para debatir del tema hay que hacerlo con criterio, y no me siento capacitado pues no conozco las especificaciones técnicas de cada sistema de archivos.”
Tu mismo lo has dicho!!!
Ext3 escribe bloques de datos en el disco cada 5 segundos y en Ext4 se escribe en intervalos de entre 45 y 150 segundos. Lo que significa que Ext4 escribir menos a menudo en el disco, y lo realiza en bloques mayores y más distantes que Ext3, esto mejora rendimiento y alarga la vida del disco. Pero el problema es que si el sistema se cae, en Ext3 se pierden los últimos 5 segundos de escritura de datos, mientras que en Ext4 se pueden perder hasta 150 segundos.
Ted Ts’o desarrollador de Ext4 explica que es “realmente más un problema de diseño de la aplicación”, También se dice que los parches no serían incluídos en el próximo Kernel 2.6.29, sino hasta el siguiente Kernel 2.6.30.
Como han explicado arriba, para eso está el journaling http://es.wikipedia.org/wiki/Journaling
A mi modo de ver no pasaría nada porque tras el reinicio se terminarían de procesar las operaciones de escritura que faltarían por hacer cuando se produjo el corte. Eso es lo que estudié en su día y que hoy en día (por ahora) me funciona perfectamente.
Vamos a darle una oportunidad que verdaderamente se nota la diferencia, uso ubuntu jaunty y el sistema arranca muy rápido.
Un saludo.
Pregunta de ignorante… se supone que el journal que lleva el sistema no esta implementado de igual manera que el resto de los archivos en ext4 no? Lo digo por el hecho de que si se maneja de igual manera, en cuanto a tiempo de escritura en disco, y tarda tanto en escribir el journal al disco, es lo mismo que nada…
Ademas, nose bien como sera el funcionamiento del journal, pero segun la definicion del wikipedia el journal no apunta a la recuperacion de datos o archivos concretos sino mas bien “En el caso concreto de los sistemas de archivos, el journaling se suele limitar a las operaciones que afectan a las estructuras que mantienen información sobre:
* Estructuras de directorio.
* Bloques libres de disco.
* Descriptores de archivo (tamaño, fecha de modificación…)” (cita de wikipedia)
Lo cual haria que nuestro SO no quede corrupto, pero los datos nose…
Igualmente, como dije, no tengo mas que nociones acerca del tema, y en verdd nose como esta implementado el journaling tanto en ext3 como en ext4.
Saludos
Gente, no se asusten, primero, cuantas veces se cortó la luz mientras operan con un archivo? Piensen que también existe la posibilidad de que eso suceda sin formatos de guardado con retraso.
Segundo, los programas mas importantes guardan copias del archivo cada un intervalo, o cada grandes cambios, aunque esto no suceda en todos, en general sucede.
Tercero y principal, el problema no es del formato, sino de los programadores, se supone que cuando hay escrituras de disco importantes, o sea, a nivel usuario, el programa debe usar funciones de sincronización de disco, y no solo al utilizar ext4, sino en que siempre que se desee forzar la sincronización de datos, esto no es novedad, en c por ejemplo (que no es el lenguaje mas simple), es algo tan complejo como la rutina
sync(); //si, solo eso!
después de alguna escritura de disco importante (como podría ser el guardado del archivo)
En definitiva, no es un problema nuevo, ni un problema del formato, sino una falta de información a los programadores, muchos programas ya lo utilizan, y si no fuera así, no habría que reescribir el código, simplemente agregar cada tanto 1 (una) instrucción.
Siguen pensando que es un problema?
Excelente que tenga ese atraso, eso hace que la partición se defragmente menos y no digamos la velocidad y la vida del disco o del medio de almacenamiento.
Yo la he estado usando y si tuve problemas de alimentación al reiniciar el equipo no tuve ningún problema con la sesión en la cual estaba trabajando el journaling funciona bien. Creo que habría que suscribirse a la lista y ver los pormenores. Torvals tiene fama de exigente y es lo mínimo que se esperaría. Ted Ts’o es el experto en el tema y es cierto ya que gran parte de los recursos que utiliza tu computador se van en la escritura.
Creo que lo mejor que podemos hacer es instalar EXT4 y ayudar reportando bugs, por el momento estoy muy contento.
Me parece muy interesante ext4 en mi caso uso o abuso del p2p y siempre es de agradecer que no esté el disco duro siempre escribiendo. Me parece muy útil. Ahora tengo ubuntu instalado en un disco duro externo usb y no noto prácticamente la diferencia con un disco duro interno con otro sistema de ficheros. Pero pronto probaré a desconectarlo en caliente o a pegar un botonazo a ver que tal.
Todo depende desde el punto de vista en que se mire, como toda mejora tiene sus pros y sus contra y como bien se ha dicho puede ser preocupante debido a que se puede perder la informacion bajo ciertas circunstancias las cuales como comenta D1e6o! ocasionalmente ocurren mejor vean las otras mejoras:
usa el cheksum o suma de verificacio esto lo implementa para asegurar que los archivos recibidos no hayan sido corruptos, tambien es capaz de trabajar con volumenes de hasta 1 exbibyte (2^60 bytes, es decir 1.152.921.504.606.846.976 bytes. ), tambien es bueno mencionar que cuenta con Timestamps mejorados ya que estos seran medidos en nanosegundos en lugar de segundos y ademas se han añadido 2 bits del timestamp extendido a los bits más significativos del campo de segundos de los timestamps para retrasar casi 500 años el famoso problema del año 2038.
y como dice talishte hay que usarlo y repoortar los bugs que puedan existir es la mejor forma de contribuir, Yo estoy trabajando con Ubuntu 9.04 y no he tenido problema alguno en caso de tenerlo lo posteare. Saludos
hola amigos mi experiencia es la siguiente:
en mi computadora de escritorio tiene mal la fuente de poder y solamente afecta a los satas y al usb (se la tengo que cambiar solo que el tiempo no me ha dejado) sin embargo en ext4 me aparecen “sectores defectuosos” p’or problemas de los retrasos de escritura y tengo que formatearlo a bajo nivel (cualquier disco duro en ext4) no asi en ext3 ni en fat32, ntfs ni otros sistemas de ficheros.
si ya se que la culpable es la fuente pero con los otros sistemas no me ocurre nada grave