El 2009-03-17 a las 17:57 +0100, Rafa Grimán escribió: (A ver cuándo llega este correo...)
El Tuesday 17 March 2009, Camaleón escribió:
Yo espero lo mismo en informática, espero la misma fiabilidad y que que el hecho de apagar el sistema a lo bruto no termine en una pérdida de datos.
Pero volvemos a lo mismo. Un apagón es inmediato: la RAM y la CPU se quedan sin electricidad instantáneamente por lo que los datos que contienen se pierden inmediatamente por lo que el propio sistema operativo "desaparece". Lo único que se puede hacer frente a un apagón es mitigarlo con baterías.
Bueno, ahora mismo es lo único que se puede hacer. Vale. Pero eso no significa que sea lo idóneo. Por ejemplo, al reiniciar el equipo tras un corte de corriente, el sistema de archivos podría contener los datos anteriores y posteriores al corte, ambos, para que decida el usuario qué información es la quiere mantener. Es decir, debería tener una especie de registro de transacciones (a modo de cvs) propio. "Hola $user, he detectado un corte en el suministro de energía. Dispongo de los últimos datos que se iban a escribir a disco, que son A y B. A se almacenó el día xx-xx-xxxx a la hora yy:yy, ocupa z bytes y B se almacenó el día xx-xx-xxxx a la hora yy:yy, ocupa z bytes. ¿Cuál quieres mantener?" Por ejemplo O:-)
Uno sucede (o puede suceder) a diario y el otro no, es un caso aislado y extremo.
Efectivamente, un pilar no es como cortar la electricidad. La electricidad es la base de todo. Es como quitar de golpe la planta baja entera (puertas, ventanas, tabiques, muros, pilares, muros de carga, suelo, ... TODO). ¿Qué ocurre? Se caen los pisos de arriba ya que no se sustentan. Si a un equipo le quitas de golpe la luz, lo que hay en CPU y en RAM desaparece instantáneamente y ¿qué hay en RAM y en CPU? El kernel, que es el que gestiona el sistema de ficheros. No se puede ejecutar NINGÚN comando, no se pueden guardar datos, entre otras cosas porque ya no hay datos que guardar, se han esfumado.
Pero desparece porque es un error que está "mal gestionado". De acuerdo que todos tienen su parte de culpa: sistema operativo, aplicaciones, sistema de archivos y hadware, pero el hecho de recurrir a un sistema de baterías para mantener el flujo de corriente para evitar una corrupción de los archivos que conlleve a la pérdida de datos en un equipo (estamos hablando de un sistema de baterías que tiene... pues no sé ¿cuántos años tiene el sistema de baterías modernas, actuales? según la wikipedia ¡¡más de 200 años!! :-O), pues eso, que no me parece loable.
Ya, pero te das cuenta en el momento, lo cambias y listo. En cambio, un fallo del sistema de archivos que no escribe los datos porque se piensa que están escritos pero realmente no lo están (eso es lo que comentabas hace poco) pues te deja a dos velas: ademaś de perder datos, no sabes el alcance de esa pérdida,
Pero eso no es culpa del sistema de ficheros ni del kernel, es culpa de los discos duros:
a) han avanzado tan poco que tienen que "aumentar" la velocidad con cachés (aka RAM)
b) aún así, siguen siendo tan lentos que los sistemas de ficheros necesitan implementar cosas como delayed allocation
c) el firmware del disco duro es el que engaña al sistema de ficheros "mintiendo" y diciendo que los datos están guardados
El problema no es el sistema de ficheros. De hecho, el sistema de ficheros (sea cual sea) lo ha intentado mitigar/corregir/disimular mediante técnicas que, si se usa hw malo o no se dispone de SAIs ... se va al garete todo lo que no ha sido guardado.
¡Pues mal hecho! No se puede esperar una instalación eléctrica perfecta ni unos componentes perfectos, porque no existen. Al menos en el mundo real. Así que los sistemas de ficheros deben adecuarse al mundo real, no a su "mundo ideal" porque los resultados son desastrosos :-) ¿Crees que un ingeniero construye sobre "supuestas situaciones ideales"? Al menos, los ingenieros tienen la obligación de avisarlo y documentarlo. "Este aparato está preparado para funcionar en tales condiciones ambientales, con un rango máximo de tantos grados Cº y un porcentaje de humedad relativa del tanto %. Cumple la normativa de seguridad 'x' que determina 'y'..." ¿Quién se responsabiliza de la pérdida de datos? ¿"Nadie"? Por eso a la informática aún le falta cierta "rigurosidad" que tienen otras disciplinas científicas >:-)
Puedes pensar: "hombre tampoco se pierde tanto rendimiento ni son tan lentos los discos". Pues te propongo una demo: monta tu sistema de ficheros como sync y luego me cuentas. Verás lo que es la desesperación. Y eso que sigues usando la caché del disco duro, si encima la deshabilitas para poder garantizar la escritura a disco ... te veo en un charco de lágrimas.
Pues no lo he probado, la verdad :-?
¡No sabes nada! Si al menos registrara los datos que elimina :-P
Pero es que no es el sistema de ficheros, es el disco duro, es el hardware (bueno, el firmware de los discos duros) el "culpable". Si los discos fueran la décima parte de rápidos que la RAM, te aseguro que estos problemas no ocurrirían y que los sistemas de ficheros no implementarían estas técnicas. Pero como los fabricantes de discos duros no han avanzado NADA ... pues es lo que hay.
Por mucho que el sistema de ficheros implemente sync a disco y las aplicaciones un fflush() o fsync() o cualquier otra función, la caché del disco duro sigue allí y el firmware sigue funcionando de dicha manera. NO hay forma de garantizar la escritura a disco si se tiene la caché activada. Como dijo Carlos, falta algún tipo de comunicación entre firmware del disco y sistema operativo que te garantice que el dato se ha escrito a disco físicamente. Poder se puede hacer, pero te tira el rendimiento por debajo de los suelos. Probad lo que os he comentado de montar con sync.
Que garantice la escritura y que lleve un registro de las transacciones... ¿no hay ningún estándar definido para ésto?
Aún me acuerdo los gritos que dió la gente cuando SUSE 10.2 (o fue la 10.1) montaba los USB como sync. ¡¡¡ Y eso que eran USB !!! Que son más rápidos que un disco duro.
Sí, recuerdo mensajes de la lista con problemas en las llaves usb, que se ralentizaba la copia de archivos. Pero... ¿USB más rápido que un disco duro? :-? Si tienen que hacer la conversión de ide/ata o sata a usb ¿no?
Pero si los hoy en día los componentes funcionan sin electricidad :-P. Está la hibernación, la suspensión y seguro que habrá algún otro estado más de ahorro.
Siguen consumiendo energía y en los casos que no se consume, se guarda el estado en un fichero (swap) y no es un proceso inmediato.
Pues debería serlo >:-P
El disco duro debería tener incorprado algún sistema de seguridad adicional. A ver, no te digo que haga milagros, pero si todos los componentes del equipo están en buen estado ¿por qué un simple apagón hace que pierdas datos? No sólo le puedes echar la culpa al hardware sino también a la gestión que hace el sistema con los archivos.
Sí puedes porque (en el caso de los discos duros), el último responsable es el disco duro: su lentitud ha dado lugar a que se hagan estas "chapuzas".
Pero no se puede desarrollar ignorando ésto: si el hardware (en este caso, los discos duros) tienen esa limitación, no se puede pasar por alto. La fiabilidad e integridad de los datos es importante.
¿Qué tenemos, memoria ram? Pues que la usen, que el disco vuelque los datos a la ram (a modo de buffer) y que pueda recuperarlos y volver a escribirlos en disco antes de desecharlos y dejar el archivo a 0 bytes.
Sí, pero si se va la luz, TODO lo que hay en RAM se desvanece en tiempo real ;) Para luchar contra la pérdida de luz sólo hay soluciones hardware: pilas o baterías, como lo quieras llamar o similares.
Bueno... cuando la luz se va y el reproductor del dvd se para, al menos no "pierde" el disco :-P
Para luchar contra los problemas de los discos duros, lo único que se puede hacer hasta ahora es lo que se ha hecho al diseñar sistemas de ficheros.
Que es no tener la certeza de que los datos se han escrito y darlo por válido... con lo cual terminas por perder información.
Para luchar contra corrupción de datos por fallos en la CPU o en el disco, lo único que se puede hacer es CRC y similares
Eso sí :-)
Pues que los pases a algún sistema secundario de almacenamiento :-P
Caché/buffer ;)
La cosa, en el caso de los discos duros, es la velocidad penosa que tienen. Te pongo un ejemplo. En el mundo de media, de BBDD en tiempo real y de HPC (sí, incluyendo CAD/CAM/CAE ~ manufacturing). Cuando se requiere un ancho de banda determinado y garantizado ... hay veces que se llegan a poner 20 veces más discos de los necesarios porque si no lo haces ... simplemente no das el rendimiento.
(...)
El disco duro es el gran lastre de la informática :(
Computación distribuida... al menos para los ejemplos de las cantidades "mostruosas" que has puesto ;-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org