El 2009-03-17 a las 13:13 +0100, Rafa Grimán escribió:
El Tuesday 17 March 2009, Camaleón escribió:
Por eso mismo. Que el sistema se cuelgue, es normal.
Pero _NO_ debería serlo.
No, claro, pero sucede.
Que haya apagones, también. Que no haya un SAI, también.
No debería ser normal no tener un SAI.
Hombre, no todos tienen los recursos necesarios para tenerlo y no por ello tienen que arriesgar sus datos cada vez que encienden el equipo O:-)
Componentes en mal estado, pues también.
No debería ser normal tener componentes en mal estado.
¿Por qué estos ejemplos que pones se consideran "normal" o aceptables? En un coche _NO_ son aceptables. Por lo menos nadie en su sano juicio conduce un coche cuyas ruedas están lisas sin dibujo o cuyos frenos no funcionen o se "cuelguen". Nadie compra pantalones rotos (bueno, a menos que sea la última moda y quieras ser la super-estrella ... nunca he entendido las modas). Nadie compra comida caducada. Nadie va a un dentista cuyas manos huelen a pie.
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...). 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. 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.
¿Y cómo debe actuar el sistema en esos casos? Fácil: problemas de hardware, debe registrar errores de acceso (lectura y escritura). Problemas más serios, pues también debería regsitrarlos.
1º Ver rollo que he escrito más arriba ;)
2º Se podrán registrar los errores que no bloqueen el sistema, que sean "normales", que sean previsibles ... pero los que no entran en esas categorías ... va a ser difícil.
Bueno, me refería a los errores de hardware más que de software. Obviamente, si el sistema deja de responder, también deja de responder la gestión de ¿casi todo? :-) No sé qué nivel o rango de acción tienen los desarrolladores del kernel en ésto, es decir, qué es registrable y qué no :-?
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, 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
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. 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. ¿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.
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.
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
¿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? :-?
Si se puede apagar, se apagará. Hay que programar con esa premisa, pensando siempre en sucesos probables. Hardware en mal estado, apagones, bloqueos o cuelgues son variables "posibles".
Sí, son predecibles, lo malo es ¿cuándo se van a dar? Si se sabe el cuándo, se puede programar al sistema de ficheros o al kernel o al driver o a quien sea para que guarde los datos al disco o a dónde sea.
Por cierto, estoy de acuerdo contigo en que hay que mejorar el software.
:-)
Y de una buena programación. Ya te digo que de nada sirve prever y tener toda la seguridad si el sistema está mal diseñado porque no se ha previsto que el equipo se puede quedar colgado en cualquier momento. Y eso es algo que sucede a diario. No sabe "cuándo", pero se sabe "qué" y "cómo". Algo se podrá hacer para evitar esa pérdida de datos.
Para empezar, se puede intentar dirigir las medidas (inversión en desarrollo) a intentar evitar cuelgues porque el sw esté mal desarrollado. Pero esto no interesa: mola más añadir una nueva feature que depurar un driver (o una aplicación cualquiera). En cuanto a las empresas: tres cuartos de lo mismo, da más prestigio añadir una nueva funcionalidad que corregir cuelgues.
Como pasa con los controladores de las tarjetas gráficas, no importa que se cuelguen o rendericen el 2D a paso de tortuga con tal de que el juego de última hornada les dé un benchmark bueno para las revistas :-(
Puedo esperar perder datos si lanzo el equipo por la ventana, o si se quema en un incendio. Pero no espero perder datos si se va la luz :-)
Si se va la luz, hay que tener en cuenta una serie de cosas:
- es un evento impredecible en cuanto a cuándo se va a producir. Que se va aproducir: sí, alguna vez se tiene que dar, pero cuándo ... es difícil predecir
- la razón por la que se produce es impredecible también: ¿fenómeno atmosférico? ¿La señora de la limpieza ha desenchufado el servidor y ha enchufado la aspiradora? ¿El usuario ha pulsado el botón "sin querer"?
- el material informático es 100% DEPENDIENTE de la electricidad por lo que a nivel sw no hay nada que se pueda hacer, la solución TIENE que ser por hardware: baterías, por ejemplo. Por sw NO se puede solucionar ya que si falla la luz -> falla el hw -> falla el sw ya que el sw DEPENDE del hw que a su vez depende de la luz.*
* Por poner un ejemplo sencillo: una bombilla. Ya puedes tener el mejor de los filamentos o gas o lo que sea la bombilla que tienes que si se va la corriente ... adiós luz aka veo menos que un plátano liado en un trapo aka oscuridad. Es inmediato. Ahora diréis: "Ya, pero hay gases que permiten mantener una combustión durante X tiempo por lo que la luz (incandescencia) no desaparece de golpe y bla, bla, bla, ..." Esto es una solución hardware y sería similar a usar un SAI o una batería o un condensador o lo que sea, NO es una solución sw.
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 >:-)
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...") >:-)
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
Este problema afecta a la mayoría de sistemas de archivo, así que nadie se libra, con empresa gorda detrás o sin ella.
Incluso afecta a sw que no es sistema de ficheros ;)
También :-)
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
En cuanto al ordenador, también: me interesa saber cuándo va a fallar el componente (sea hw o sw) porque ya sé que va a fallar, lo que no sé es cuándo. De ahí que haya cosas como SMART, redundancia, alta disponibilidad, disaster recovery, business continuance, ... De lo contrario (si supiéramos cuándo va a fallar), no nos haría falta todo eso, lo haríamos por sw ;)
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 ;-) 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