-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Posiblemente ese disco falle en bastantes más grabaciones, el software se dará cuenta, y lo retirará, reconstruyendo todo a partir de los otros.
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.
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.
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.
- 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.
- 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...
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 ;)
Ya te vale. Tendrías que probarlo. Yo tengo mi sai de esa guisa, a los dos minutos hiberna. Cuando vuelvo, lo despierto y en menos de un minuto tengo todo funcionando en el mismo estado que estaba, con el openoffice abierto y el cursor esperándome. Y claro, cada día, en vez de apagar, lo hiberno. En cambio, resetear tarda varios minutos. Es realmente práctico. Fíjate que lo considero tan importante para mi manera de usar el ordenador, que en la 11.1, después del ultimo parche, la hibernación falla en tanto que no es capaz de apagar el ordenador al terminar: pues ya no puedo actualizar a la 11.1, para mi es un "blocker". Si algún día consiguen eso de botar en segundos... ya me lo pensaré.
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.
Pues yo, la verdad, echo de menos algo tan eficiente como el antiguo backup de las pctools. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm+W6IACgkQtTMYHG2NR9VvHQCfZ24PdBpn0qDltlevBFcye+bB AFIAn2SvWDOcevRhsFBTs9CcSpyyg0jf =1+Bq -----END PGP SIGNATURE-----