Hola :) El Tuesday 17 March 2009, Camaleón escribió: [...]
Esto es lo mismo. ¿Por qué en la informática es normal? ¿Por qué se acepta como normal que no haya SAI, que no haya backup, que las cosas se cuelgan? _NO_ señor.
Sí, son inventos hechos por Humanos y, por tanto, imperfectos por lo que tienden a fallar (de ahí los MTBF). Se acepta que haya un % de error. Pero es que en la informática se acepta un % de error enorme: es "normal" Y ESO QUE _TODO_ DEPENDE DE LA INFORMÁTICA (banca, sanidad, ...).
A ver. Te pongo el ejemplo del sector que conozco. Ingeniería y construcción. ¿Las casas se caen? Hombre, pues no es lo normal. ¿Pero _no_se caen? pues sí, pero se contruye con teniendo en cuenta (ni te imagians) una cantidad de variables no "precedibles" (no sabes cuándo) pero si esperables (vientos, tipo de sulo, tipo de construcción, zona sísmica, etc...).
Sí me lo imagino porque tenemos muchos clientes en ese mundo y porque en la Facultad estuve en un proyecto para diseñar mediante algoritmos genéticos casas y teléfonos móviles :)
Nadie espera un terremoto en Valencia, pero hace poco hubo temblores de escala 4. No pasó nada porque la normativa actual es bastante clara, cocisa y segura.
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.
La parte por el todo no puede ser, no es de rigor. Los problemas hay que aislarlos y no pueden afectar a todo el conjunto, sólo, claro está, en casos extremos. Por ejemplo, si quito el pilar central de un edificio, con el tiempo y factores externos se acabará por derrumbar. Pero no compares quitar un pilar base con apagar el sistema de forma abrupta :-)
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. [...]
Si el usuario no tiene datos, no puede saber que hay un problema y no puede solucionarlo.
Pero si compras hardware (memoria RAM, por poner un ejemplo) malo y te falla (lo normal) ... ¿qué datos guardas si están todos corruptos o bien se han esfumado? Si la placa base es mala ... los datos que se transmiten pueden corromperse o bien un problema de tensión te puede dañar el disco de forma que NO puedes acceder al disco: ¿dónde guardo qué datos?
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. 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.
que puede hacerte que tengas que volver a instalar de nuevo porque el equipo se cuelga de manera inesperada (por ejemplo) cuando antes no lo hacía y no sabés el motivo (¿será por el problema que tuve al apagarlo a lo bruto aquél día o fallará la fuente, o quizá el disco duro tenga algún problema...?)
¡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. 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.
Si el sistema se cuelga, el sistema de archivos debería poder gestionarlo. Es un evento esperable, y tendrían que estar preparados para ese tipo de errores.
Si el cuelgue es por un módulo de RAM o controladora de disco defectuoso, ¿qué datos y dónde se guardan? Si el sistema de refirgeración del procesador es defectuoso y hace que el procesador realice cálculos erróneos, ¿me puedo fiar de ellos aunque los guarde?
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.
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".
¿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. 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. 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
No te digo hace 30 años, pero hoy en día, pues sí.
No digo que estés equivocada. Lo que digo es que no es tan fácil como te imaginas/piensas.
No, supongo que no lo es, pero merece la pena mejorar la seguridad de los datos.
Estoy de acuerdo, pero hay que ver cuál es realmente el problema y ponerle soluciones a ese problema concretamente.
Se avanza mucho en hardware pero poco en software :-(
IMHO, se avanza demasiado y se asienta (aka depura y profile) poco :( Es decir, se introducen demasiadas novedades (¿features?) sin asentar y depurar las que ya existen.
Sí, cierto. Hay mucha cantidad y poca calidad. Y lo que es peor, en algunos casos se pierden funcionalidades.
Las cosas que no se pueden precedir, también se gestionan. Y eliminar datos del disco no es precisamente lo más deseable.
Pero es que a lo mejor esos datos nunca llegaron a disco, luego no estás eliminando los datos ... simplemente nunca existieron ;)
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. Por ejemplo, para editar en tiempo real 4k (el nuevo formato de las pelis), tienes que garantizar 1200 MegaBytes/s. Teóricamente cada SATA te da 300 MegaBytes/s ... JA!! Un disco FibreChannel de 300 GB a 10 krpm te está dando sostenido y garantizado unos 30 MB/s ... echa cuentas: unos 40 discos. Bien, pues los 1.2 Gbytes/s lo necesita CADA estación de edición, es decir los 1200 MegaBytes/s los tienes que multiplicar por el número de estaciones de postproducción que vas a tener. Luego tienes que sumar los de audio, los de 3D, los que hacen el juego, los que hacen los trailers, ... Ahora tienes que sumar el overhead de escribir el bit de paridad, el overhead del sistema de ficheros y gestor de volúmenes. Ahora tienes el ancho de banda necesario TOTAL que tiene que ofrecer tu sistema de almacenamiento. Es decir, por cada estación necesitarías unos 50 discos (posiblemente más) = 15 TB en discos de 300 GB FC y 10 krpm. Ahora tienes que sumar los discos de paridad y que una Peli entera 4k está consumiendo unos 180 mil ficheros, cada uno pesando 50 MegaBytes. Es decir, necesitas unos 9000000 MegaBytes por peli ~ 8 TB. Si hechas cuentas, vas a tener ocupado más o menos la 1/10 parte o menos del volumen total disponible que tienes, simplemente para dar el ancho de banda. Ten en cuenta que los 8 TB son más o menos fijos (puede ser GB arriba o GB abajo), pero por cada etsación de postproducción necesitas al menos 15 TB. A eso hay que sumar el renderfarm y todos los demás que están accediendo al almacenamiento :( Un ejemplo real: Sr. de los Anillos. 300 personas moviendo más de 1 TB al día de datos, 300 millones de ficheros y unos 200 TB por peli (incluyendo bandas sonoras, juegos, trailers, ...). No es una peli editada en 4k, pero te vale para hacer números del ancho de banda necesario. En manufacturing y HPC ocurre lo mismo. Un ejemplo, para diseñar el traje de Phelps, se escanearon y filmaron 400 nadadores y más de 100 materiales para hacer el estudio de CFD de su cuerpo y poder diseñar el traje de natación. Si tus discos no son capaces de dar un buen ancho de banda ... tienes a los procesadores parados :( Esto mismo es váildo para diseñar un coche, una lavadora, estudios de deformación de materiales en la cosntrucción, ... El disco duro es el gran lastre de la informática :(
¿Qué datos se eliminan y en base a qué? ¿Archivos de configuración de programas, archivos necesarios para el inicio del sistema? ¿Se elimina al azar, no hay prioridades? Una cosa así no puede quedar al libre albedrío :-/
En el caso que nos atañe (KDE pierde ficheros de configuración). No es que se produzca al azar, es que KDE lo ha hecho mal. Es decir, no crea un fichero temporal en el que guarda los datos y luego renombra. Si hiciera esto (crear un fichero temporal, borrar el original y luego renombrar), la probabilidad de pérdida de datos sería mucho menor. En este enlace lo explican mejor:
Los archivos de configuración de kde es lo que ha visto, sencillamente porque lo ha ido a utilizar y le había desaparecido ¿pero... qué más se ha perdido? :-?
Eso ya habría que preguntárselo a él ;) [...]
Es que en una bombilla predomina hardware, o la cambias o la cambias. Además, las de bajo consumo o las led duran más >:-)
Cierto.
Otro ejemplo: un coche. El conductor sería el sw, el coche el hardware y la gasolina la electricidad. Por muy buen conductor que seas, por muy previsor que seas, ... si pillas un bache y se te arranca el depósito de pronto (equivalente a se va la luz de pronto) o el motor se para. Sí, ya si vas cuesta abajo o vas a 270 KM/h no paras en seco, pero eso sería una solución HW (física, inercia) y no de sw (tu, conductor).
Pero si el coche hubiera tenido algún sensor inteligente que detecte el firme, el bache lo hubiera evitado o le hubiera avisado al conductor ("oye, que tienes un desnivel a tantos metros, activa los amortiguadores o reduce la velocidad...") >:-)
Pero eso sería firmware, no software ;)
Las SSD basadas en DRAM tienen algunas ventajas.
Pero siguen DEPENDIENDO de la electricidad. Si falla la luz, es inmediato el fallo a menos que haya un HW por en medio que garantice cierta corriente (batería, por ejemplo). El sw no puede hacer nada porque es una capa superior que DEPENDE de las que hay abajo, por lo que si las de abajo fallan ... lo de arriba falla. Y si lo de abajo falla impredeciblemente ... lo de arriba no puede hacer nada.
Suspendes a ram o suspendes a "poner-aquí-X-componente-que-permita-almacenar-datos-para-luego-recueprar los" :-P
Pero si es RAM y falla la luz ... good bye datos ... :( [...]
No se puede precedir el factor tiempo (cuándo) pero sí qué es lo puede hacer (subir o bajar las acciones, si hará lluvia, sol o viento). Pero hay variables con las que sí se puede jugar. Sabes qué le puede afectar al sistema de archivos (apagón, bloqueo, hardarwe, componente lógico...) pues solucionemos las variables de las que sí tenemos información.
Pero es que lo que precisamente te interesa saber es cuándo para poder estar preparado en ese momento. Por ejemplo el tiempo, sé que va a llover (o al menos eso creo y espero ;), pero lo que me interesa saber es cuándo para saber si salir con paraguas o sembrar o ponerme chanclas o quedarme en casa y comprar un SAI por si cae un rayo y me estropea el ordenador ;)
Pues llevas siempre el paraguas encima :-P
Sí hombre y un abrigo por si hace frío y las gafas de sol por si hace sol y un gorro y ... No te digo! [...]
Por cierto, sé que va a tocar la lotería, pero quiero saber cuándo y dónde ... para ir y comprarla !!!!
Como decía Niels Bohr: "Es difícl hacer predicciones, especialmente si son en el futuro" ;)
Si no compras lotería seguro que nunca te toca ;-)
Eso es lo malo ... que sí que compro y aún no me ha tocado, por eso quiero saber dónde y cuándo va a tocar ;) 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