Hola :) El Monday 16 March 2009, Carlos E. R. escribió:
El 2009-03-16 a las 08:33 +0100, Rafa Grimán escribió:
Hola :)
El Friday 13 March 2009, Carlos E. R. escribió:
El 2009-03-13 a las 11:57 +0100, Rafa Grimán escribió:
...
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.
Pero la paridad no coincide.
Sí coincide. La paridad se ha calculado cuando el disco ha dicho: "OK, ya lo tengo", aunque no lo haya escrito al platter.
Posiblemente ese disco falle en bastantes más grabaciones, el software se dará cuenta, y lo retirará, reconstruyendo todo a partir de los otros.
Pero es que el disco no ha dado fallo de grabación. Todo lo contrario. Dice que sí lo tiene (lo tiene en la caché), pero justo antes de escribirlo al platter ... pierde un poco de electricidad y la caché se borra. El disco no está defectuoso. Puede que lo defectuoso se la fuente de alimentación y no le envía potencia suficiente al disco. En el momento que le llegue corriente, sigue como nuevo el disco ... pero sin los datos de la caché :( Estás pensando que el disco está defectuoso, pero no lo está. no es culpa del disco el que no le haya llegado corriente. Es más, no tiene ni que perder toda la corriente, basta que pierda la caché temporalmente la corriente para que se borre. Ya, son casos "raros" o especiales. Pero se dan más habitualmente de lo que pensamos, tanto en empresa como en casa. Fíjate en el caso que ha iniciado este hilo: el disco no ha fallado, no está mal el disco. Ha sido un fallo eléctrico. Si eso mismo le pasa en un RAID, el RAID no hubiera detectado error de paridad ya que el disco ha dicho: "Ya lo tengo".
Es decir, el disco fallado tendrá unos datos, pero el resto tendrán otros.
Luego el fichero está corrupto :(
Depende de si ese disco es reconocido como fallado o no.
Recuerda que el disco está perfectamente, lo que le ha ocurrido es que se ha quedado momentáneamente sin electricidad.
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.
También se puede detectar con grabaciones de control: grabas algo y recuperas todas las copias, para ver si coinciden.
Sí, puedes usar CRCs también.
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.
En servidores me parece razonable. En caseros... pff.
¿Mas grandes? A ver... puede ser una batería de respaldo tipo recargable, que son tamaño botón. No es tanto. O pueden ser condensadores de respaldo, de esos de tamaño "1 F". También puede ser una flash: el condensador usa su carga para grabar una flash a partir de la ram. O incluso a disco, mientras falla la corriente, en una pista reservada para grabar sólo la ram.
Lo de la flash se está empezando a usar. Nosotros (en los servidores) hacemos lo de los condensadores.
- 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.
Es que me refiero a comandos del firmware, en el estándar SATA. No otro estándar, sino una revisión. Y francamente, dudo que eso no exista.
Ni idea.
- 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.
Sí, he oído menciones de "barrier" varias veces, a ver si leo algo con más detalle.
http://en.wikipedia.org/wiki/Barrier_(computer_science)
no es eso...
Una vez vi una página muy buena donde se explicaba con dibujos y todo, pero no me acuerdo cuál es :( 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