Hola :) El Tuesday 17 March 2009, Camaleón escribió:
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.
Buena idea, pero para que se dé lo que comentas, tienen que poderse guardar esos datos modificados de alguna manera en algún sitio y si no tenemos SAI la pérdida de datos en RAM y CPU es inmediata. Luego no hay nada que guardar :(
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.
Pero es que TIENES que garantizar una cantidad de energía (en este caso luz) determinada para que no se pierdan los datos. Puedes crearte un sistema de ficheros similar a un CVS, puedes desarrollar un sistema predictivo que intente predecir fallos, un sistema que se corrige a sí mismo, ... Pero si le quitas la luz de golpe ... adiós info porque no hay energía. NECESITAS las baterías, es una cuestión/problema de hardware, no es un problema de software. Es como si de pronto le quitas la CPU al ordenador, pues no funciona, por muy bueno y predictivo que sea el sistema operativo, si le quitas la CPU: al carajo. [...]
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 :-)
Pero es que eso es lo que intentan, pero hay cosas a las que no se puede hacer frente. A un fallo de luz sólo le puedes hacer frente con baterías porque la dependencia es absoluta. Lo que hay en RAM y en la CPU desaparece en tiempo real y el kernel (sistema de ficheros es parte del kernel) se encuentra en RAM: desaparece. No hay período de gracia ni de buen rollo ni de "Espera, que estoy guardando datos". Es como si te cortan la cabeza (problema de hardware), si te cortan la cabeza ... no hay nada que hacer. Los desarrolladores de sistemas de ficheros se enfrentan con la vida real y la vida real es eso: si no hay electricidad, no funciona. Y si la electricidad desaparece de golpe: se va todo al carajo. Es un problema de física aka hardware, NO es un problema de software.
¿Crees que un ingeniero construye sobre "supuestas situaciones ideales"?
Al menos, los ingenieros tienen la obligación de avisarlo y documentarlo.
Sí, de acuerdo, pero si a un ingeniero le dices: "Oye, ¿qué pasa si por arte de magia quito todo el primer piso?" Da igual el tipo de ladrillo, cemento, ... que use que el edificio se va abajo.
"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 >:-)
TOTALMENTE de acuerdo !!!! :D
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 :-?
Prueba, prueba, ... >:)
¡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?
Que yo sepa, no. Pero aunque lo haya, un sync a disco es eterno y determinados entornos NO se lo pueden permitir así a la ligera.
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?
Da igual, la velocidad es "similar". Si ese ejemplo no te vale, prueba lo que te he dicho de montar con sync tus particiones.
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
Para serlo, se debería hacer un sync a disco en cada escritura y eso es eterno. Es algo que no se pueden permitir determinados mercados y que el 99.999999999999999% de los usuarios si lo sufren ... dejan de usar un ordenador por la lentitud. Ten en cuenta que no es una única aplicación la que estaría haciendo sync a disco, piensa en todas las aplicaciones que lanzas y usas simultáneamente.
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.
Ya, pero dile a un banco, a un hospital, a una televisión, ...: "Ná, esperate un rato que esque cada vez que se guarda un fichero, se hace sync a disco". Por experiencia, te puedo decir a dónde te mandan ;) Haz la prueba de trabajar con los sistemas de ficheros montados con sync y, si tienes tiempo, monta un SAMBA/NFS y haz lo mismo ... a ver cuánto tiempo tarda en responder el servidor.
:)
¿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
Porque los datos están en un soporte que no se borra. Si sustituyes el DVD por un módulo de RAM, verás como los datos no siguen allí ;)
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.
Por desgracia es así. Pero te repito, no es culpa del sistema de ficheros, es culpa de los fabricantes de discos.
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 ;-)
Pero no siempre es útil. Un ejemplo: BBDD. A todo el mundo le ha dado por BBDD distribuidas y en cluster -> ahora resulta que el cuello de botella es la red porque la tabla A está en el servidor 1 y la tabla B está en el 2 y la comunicación es mediante una red gigabit ethernet. Esot es un ejemplo sencillo con 2 servidores, imagínate cuando se montan 8, todas las comunicaciones que se llevan a cabo. Otro ejemplo: sistemas de ficheros distribuidos o paralelos (como Lustre, pNFS, GPFS, ...). Son muy buenos, pero ocurre lo mismo, necesitas una infraestructura de red salvaje y resulta que el cuello de botella en este caso es ... el cliente. Puedes montar una red con InfiniBand cuyos servidores de datos distribuidos tienen 100 puertos InfiniBand, pero el cliente sólo tiene 1 puerto InfiniBand luego el ancho de banda máximo que será capaz de soportar el cliente es de: lo que dé su puerto InfiniBand y el bus PCIe en el que esté enchufado así como la CPU. Con esto no quiero parecer pesimista, sólo quiero hacer ver que las cosas son más complicadas de lo que parecen. Esto no es bueno ni malo, ni todo lo contrario: simplemente es. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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