Hola :) El Tuesday 17 March 2009, Camaleón escribió:
El 2009-03-17 a las 08:43 +0100, Rafa Grimán escribió:
El Monday 16 March 2009, Camaleón escribió:
Entiendo que un disco duro se estropeé (por edad/tiempo de vida, por defecto de fabricación o por problemas externos -mecánicos o electrónicos-) pero entiendo *menos* que un sistema de archivos hoy en día no sepa (o pueda) gestionar un apagón forzoso y esporádico porque a veces no hay más remedio que apagar a lo bruto, se tenga SAI detrás o no.
Porque es algo incontrolable e impredecible. Si se pudiera predecir un apagón, caida de tensión, ... el sistema de ficheros (concretamente el kernel) sí podría reponder. Pero es algo completamente caótico, no puedes predecir un apagón. Bueno, a lo mejor una persona puede más o menos hacerse una idea si va a haber un apagón ya que sabe: el estado de la instalación eléctrica, si llueve o no, si hace viento, si hay guerra, ... Pero el pobre sistema operativo no sabe esas cosas ;)
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 * 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). ** 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. 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. En el caso del FLOSS hay que sumar las ganas de colaborar: betatesters, programadores, ... Si hay ganas de colaborar, nos irá mejor :)
¿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, ...
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) - ... 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. 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 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 ;) 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, ... ;) 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