Mailinglist Archive: opensuse-es (1145 mails)

[Rafa Grimán <rafagriman@xxxxxxxxx>]

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@xxxxxxxxx
--
Para dar de baja la suscripción, mande un mensaje a:
   opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
   opensuse-es+help@xxxxxxxxxxxx