Hola :) On Tuesday 29 December 2009 21:31:25 Carlos E. R. wrote:
On 2009-12-29 18:29, Camaleón wrote:
El Tue, 29 Dec 2009 17:52:59 +0100, Rafa Grimán escribió:
No del todo cierto, puedes encontrarte lo que se llama "silent data corruption". Si te encuentras con eso ... no hay recuperación de datos
:(
¿Y eso cada cuantos eones pasa? O:-)
Me temo que más frecuentemente de lo que se piensa. Pero no se detecta por lo que cuenta Rafa.
Cuando los discos duros asequibles eran jóvenes, o sea, con el MsDos, este tenía un "setting" global para todo el sistema que era "verify". El sistema operativo verificaba todas las grabaciones de ficheros, leyendo físicamente todo lo que escribía por si había cambiado. Por otra parte, los comandos de copia de ficheros o discos solían tener también la opción "verify" independiente.
Eso se ha olvidado, damos por supuesto que la grabación ha sido correcta y no la verificamos por sistema. De hecho, si hago una copia de seguridad con rsync, no tengo manera fácil de comprobar la copia bit a bit.
Cierto, cada vez/año hay más estudios sobre esto mismo (en las USENIX y Linux Symposium) patrocinados por Universidades (MIT, Berkley, ...), Google y Yahoo, IBM, NetApp, LSI, ... porque las empresas/usuarios cada vez pierden más datos. Aquí hay "pa todos": - en el mundo del hardware, se da por hecho que la tecnología es cada vez más fiable por lo que no se comprueba - en el mundo del software, se da por hecho que el compilador ya ha comprobado ciertas cosas, los del compilador dan por hecho que el kernel verifica otras, los del kernel que el sistema de ficheros, los del sistema de ficheros que el VFS, etc Los del VFS que la caché del disco ... y vuelta a empezar Vamos que unos por otros y la casa sin barrer. Todo va mucho más deprisa y no hay tiempo para verificaciones de ningún tipo. Además, eso de verificar (depurar, probar, ...) es caro y nadie quiere invertir. Cada vez hay más líneas de código (leí hace poco que un firmware de un HDD puede tener 400 mil líneas de código!!!) Un ejemplo de velocidad: Intel sacó hace poco el Nehalem (también conocido como i7). Se espera que saque ahora el Westmere, en el 2010 otro y en el 2011 otro. Y eso que es sólo para Enterprise, porque luego tienes la gama de desktop y luego los Atom. Esto es una salvajada, MHO. También hay tecnologías que no acaban de salir e intentan exprimir hasta el límite más absurdo tecnologías antiguas. Por ejemplo, los 4 kb en discos duros. Hace 10 años (o más) que se lleva hablando de usar bloques de 4 KBytes en vez de 512 bytes en los discos duros. Hasta ahora nadie los había sacado y Western Digital anunció ya una gama de ellos para principios del 2010 (si es que no los acaba de sacar). 10 años hablando paja para sacarlo ahora que tenemos los SSD. Por cierto, los sistemas de ficheros XFS, ext3/4 y el de MacOSX (no sé si usa UFS o HFS+, que alguien me corrija) llevan soportando 4 KBytes bastante tiempo (años). Otro ejemplo es la tecnología RAID. RAID está bien cuando tienes discos <= 500 GBytes. Más que nada porque reconstruir un disco de 1 TB puede suponerte unas 22 horas, 22 horas de périda de rendimiento, de probabilidad de fallo, ... Pues echad números para reconstruir 2 GB de disco. Ahora es cuando se dan cuenta de este problema ... Por cierto, el otro día leí algo de hacer a los programadores responsables de los fallos en el sw que escriben. No me parece mal. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- 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