El 2009-03-17 a las 10:31 +0100, Rafa Grimán escribió:
El Tuesday 17 March 2009, Camaleón escribió:
Pero Rafa, un equipo no sólo se apaga a lo bruto por un apagón. Se puede quedar colgado ¿qué hacemos? Tenemos un SAI enorme, raid con batería y el equipo hay que apagarlo a lo bruto porque no responde.
Más caos ;) Puede colgarse el sistema por:
- un driver defectuoso: impredecible por el sistema operativo. Aquí entra en juego la fase alpha y beta y los release candidates. Además de depuración y profiling (que cada vez se hace menos) y hardware bien documentado.
- hardware defectuoso: predecible en algunos casos (SMART, por ejemplo), pero en otros no es tan fácil (RAM, aunque tiene sus posibles soluciones*)
- usuario: NO hay solución. El usuario es EL peligro de cualquier sistema informático. El sistema operativo NO puede hacer frente a esto, los programadores NO pueden predecir el comportamiento de un usuario. La ÚNICA solución es que el usuario NO se acerque al sistema informático.**
- hardware mal conectado: el sistema operativo no puede hacer frente a esto
Por eso mismo. Que el sistema se cuelgue, es normal. Que haya apagones, también. Que no haya un SAI, también. Componentes en mal estado, pues también. ¿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. Si el usuario no tiene datos, no puede saber que hay un problema y no puede solucionarlo. 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. No te digo hace 30 años, pero hoy en día, pues sí.
* FB-DIMM permite tener módulos de spare y mirroring de memoria (algo así como un RAID 1 de memoria y módulos de spare por si falla un módulo del RAID 1 de RAM). Ambas características son independientes por lo que puedes usar ambas a la vez o sólo una de ellas o no usar ninguna de ellas. También está la opción de comprobación de bits, Linux es capaz de recuperarse de errores de hasta 2 bits (creo, no recuerdo si son 2 ó 3 bits erróneos en un módulo de memoria).
Se avanza mucho en hardware pero poco en software :-(
** En un cliente vimos una vez un cartel puesto en un servidor que ponía: "No tocar con el dedo". Se conoce que eso de "No tocar" no especifica lo suficiente. Aunque "con el dedo" especifica demasiado, así que alguien lo podrá tocar con el codo, por ejemplo.
Vale, estoy de acuerdo que ante el usuario no hay protección que valga. Si lo puede romper, lo romperá y si lo puede "colgar", lo "colgará" X-)
Al programar algo (sea el kernel, un driver, un cliente de correo, ... lo que sea), para evitar ciertas cosas, hay que preveerlas. Algunas sí se pueden predecir, pero otras no. Todo lo que sea predecible (o que ya se haya sufrido) se puede intentar corregir a nivel hardware y software, lo demás no. Bueno ... también está el factor económico y el factor tiempo: si no se dispone de alguno de estos factores ... la calidad baja.
Las cosas que no se pueden precedir, también se gestionan. Y eliminar datos del disco no es precisamente lo más deseable. ¿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 del FLOSS hay que sumar las ganas de colaborar: betatesters, programadores, ... Si hay ganas de colaborar, nos irá mejor :)
Pero los sistemas de archivos se usan en muchos ámbitos y por muchas empresas (IBM, Oracle...) que tienen recursos. No sólo dependen de la comunidad libre.
¿De qué sirven todas esas precauciones (fuente de alimentación redundante, sai, batería en controladora)? ¿De nada...? :-(
Sirven para hacer frente a situaciones predecibles (apagón, por ejemplo) o situaciones por las que ya hemos pasado (tasa de fallo de módulos de memoria o de disco). Lo demás es caótico: impredecible, complejo, ...
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".
Esa situación la debe de gestionar el sistema operativo y la debe gestionar correctamente, al menos para evitar una pérdida de datos. Perder datos es la peor acción que podría hacer un sistema.
Siempre y cuando se pueda predecir o se haya sufrido antes. En el caso de lo de las cachés de los discos duros. Carlos propuso ideas buenas (baterías, CRCs, funciones, ...), la cosa ahora depende de: - roadmaps - inversión - interés - nuevas tecnologías (aka discos SSD) - ...
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. 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 :-)
Pero de nuevo, te trae "nuevos" problemas: pérdida de celdas (antes eran sectores defectuosos). Y traerá otros problemas que no conocemos por lo que hasta que no se den ... no podremos resolver.
Las SSD basadas en DRAM tienen algunas ventajas.
A esto hay que añadir que en el caso de los discos duros y sistemas de ficheros, hay más cosas: - comportamiento de las aplicaciones - comportamiento de los usuarios - comportamiento de las librerías en las que se basa la aplicación - hardware "no relacionado" con el disco (como fuente de alimentación, placa base, controladora, bus de datos, CPU, registros de la CPU, ...) - etc.
IMHO, debería haber más dedicación/inversión a/en: - debugging - profiling - betatesting
Y en investigación :-P
Y no dar tanta importancia a las fechas. Gentoo, Debian, Slackware y otras no se dejan llevar tanto por la fecha de release sino más bien por su estabilidad y fiabilidad. Sí, ya sé: - no hay una empresa por detrás y, por tanto, no hay intereses económicos por lo que se pueden tomar el tiempo que les dé la gana - no son distros para el usuario casero que exige novedades cada X tiempo. No estoy muy de acuerdo con esto, conozco muchos usuarios que lo que quieren es que funcione y les da igual si hay o no novedades - también han tenido sus problemas - nadie es perfecto ;)
Este problema afecta a la mayoría de sistemas de archivo, así que nadie se libra, con empresa gorda detrás o sin ella.
Obviamente, esto supone invertir mucho tiempo y las empresas no están de acuerdo en invertir tiempo porque: - la competencia se te echa encima - el cliente se te echa encima - el tiempo es dinero - "ya lo arreglaremos" - es más importante anunciar una nueva funcionalidad que el corregir un error ya que una nueva funcionalidad siginifca "avance" y corregir un error significa "tu aplicación funciona mal".
El caos también se gestiona o al menos se pueden hacer aproximaciones para evitar males mayores :-)
Pero no se puede predecir (por ejemplo el comportamiento de la bolsa, el tiempo, ...). El azar sí es predecible (aka tasa de fallos de discos, de módulos de memoria, ... ;)
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. 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