Hola :) El Friday 13 March 2009, Carlos E. R. escribió:
El 2009-03-13 a las 11:57 +0100, Rafa Grimán escribió:
...
Hablando de si se va la luz. Ocurre, por ejemplo, en las cabinas de discos que tienes una caché por controladora protegida por una batería (~ mini-SAI). Pero, ¿qué ocurre si hay un fallo eléctrico interno y uno de los discos pierde durante un breve período de tiempo alimentación? Pues que los datos que había en la caché del disco ese ... se han esfumado !!! La caché de la controladora de la cabina está bien protegida por la batería, pero la del disco no.
Nopes, el RAID no protege ante esto. Tened en cuenta los pasos:
1.- la controladora le dice al RAID: te paso estos datos que tengo en caché
2.- el RAID dice: OK, ya se lo he pasado a los discos
3.- el disco dice: OK, ya lo he escrito
4.- el RAID le dice a la controladora: el disco ya lo ha escrito
5.- la controladora dice: OK, marco ese dato como "stale" en mi caché
Si os fijáis, en el paso 3, el disco dice que lo ha escrito, pero está en la caché, no en el disco físico (platter). Si ese disco no llega a escribir de su caché al platter (fallo en la corriente), la paridad no sirve de nada porque no hay que reconstruir nada. Teóricamente el dato está en disco. Pero realmente no está por lo que el RAID no reconstruye nada y nunca lo hará. Sólo verás este error cuando vayas a recuperar el fichero y veas que está corrupto.
Me parece que aquí el raid por software tiene ventaja, porque manda los datos por separado a cada disco. >:-)
Sí, pero los datos que se envíen a un disco que falle ... no se pueden recuperar. Ten en cuenta que el disco ha dicho: "Ya lo tengo, ya lo he guardado", pero no es cierto. Dicho "OK" se envía cuando llega a la caché del disco, no cuando el firmware del disco hace un flush de la caché al platter. Luego el sw de RAID "pensará" que el dato es correcto y se ha guardado correctamente. Sólo te das cuenta de que el dato no se ha guardado correctamente al recuperarlo.
Es decir, el disco fallado tendrá unos datos, pero el resto tendrán otros.
Luego el fichero está corrupto :(
El RAID sólo reconstruye cuando sabe que hay un fallo (cuando el disco le dice: no puedo escribir o el disco simplemente no contesta), pero en esta situación, para el RAID todo ha salido bien.
Solución: desactivar las cachés propios de los discos, no de la controladora RAID. Problema nuevo: pierdes rendimiento. Ventaja: ganas en seguridad.
- Cachés con pila.
Discos más grandes y más caros ;) Pero es una solución.
- Añadir comando PATA/SATA para volcado de cache de disco de emergencia. El sistema operativo sabe que se va la corriente, o que va a apagar el sistema. Es el momento de ordenarle volcar la caché.
Existen esos comandos y/o funciones: sync, fsync(), O_SYNC, ... Que hacen un flush de la RAM del servidor/PC/estación al disco (realmente se envía a la cahcé del disco). Pero cuando llegas al disco ... te encuentras con el firmware del disco. Los fabricantes de discos tendrían que implementar un comando a nivel de firmware que se pueda llamar desde cualquier sistema operativo (aka estándar ... BIEN!!!, Otro "estándar" ;) Es una idea interesante.
- Añadir comando para volcado rutinario de cache de disco, que sería usado por el kernel como parte de un "sync".
Hay una cosa que se llama "barriers" que facilita algo la tarea. Al activar los barriers. El sistema d eficheros lo qu ehace es decirle al disco: "No puedes mezclar los datos entre este barrier y este otro" Es decir, facilita de alguna manera una escritura ordenado de los datos. ütil, por ejemplo para bases de datos y vídeo o audio en los qu eel orden de escritura de los datos es importante.
La Sai, pos no da pa mas el presupuesto.
Ya, hay veces que (la gran mayoría de ellas) que es un problema económico. En tu caso, no lo sé, pero en otros que sí sé, se gastan un dineral en SAI y alta disponibilidad ... y luego resulta que lo enchufan todo al mismo sitio y sólo tienen 1 proveedor de electricidad, están en una zona de mucha humedad, ... Por lo que está mal invertido el dinero.
Eso también. Pero una SAI te puede salvar la "vida": no se trata de mantener el centro funcionando, sino de poder cerrar (o mejor hibernar) el sistema adecuadamente.
"Sacto". Un SAI, "pequeñajo" que dé el tiempo justo para guardar los datos y apagar. Lo siento Carlos, a mi eso de hibernar ... me pilla ya mayor ;)
La curiosidad :que solo se ha perdido el tamaño de los iconos y la configuracion de las cuentas de correo, de las 4, pero el resto de configuraciones del kontac esta bien, asi como las carpetas.
Puede ser porque determinados ficheros sí se han escrito o porque a lo mejor KDE no manda guardar determinados ficheros hasta que se cierra la sesión y otros sí. Esto ya es cosa propia de la aplicación y de cómo y cuándo guarda los ficheros.
Si, yo creo que es más fallo de la aplicación que del sistema de ficheros. Es probable que tuviera las cosas en memoria, no en disco, o en fichero temporal.
En fin las volveremos a meter y que no pase otra vez.
Al menos hay que hacer backup de las configuraciones y datos. Es mucho menos que copiar todo.
Hay backups baratos (sw libre) y el almacenamiento cada día está más barato. 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