Tantos correos hablando del tema me han animado a hablar a mi también. Las pruebas que normalmente realiza la gente sobre los sistemas de ficheros, son de rendimiento normalmente, por ese motivo, hace algunos años, estuve dudando en que sistema de ficheros usar, primero, porque se trataba de usar no solo para datos importantes, si no para actividad frenética con el, con el mínimo riesgo de que quedara corrupto el sistema de ficheros. El problema era leer los tests que hacian de rendimiento sobre los FS, que indicaban que valia la pena pasar del ext2 al ext3, y que el reiserfs aun era demasiado experimental, como para arriesgarse a usarlo. Por esa razon, miré un poco los codigos fuentes de los sistemas de ficheros nuevos para mi, ext3 y reiserfs, y alguno otro con journaling. Aunque parezca mentira no me costó demasiado entender el reiserfs, asi que entiendo que a unos les moleste que no use las directivas tipicas del kernel para acceder a las estructuras y al scheduler, etc... porque en principio ayuda a que los cambios de caracter estructural no afecten tanto a los módulos, pero tampoco es tan grave. El caso es que no me fié de nada en absoluto, y ya habia tenido problemas intentando recuperar algun ext2 corrupto, y que queria tener claro cual de todos ellos era más robusto. Asi que cogí el módulo o block device; loop, y lo transformé de la siguiente manera: 1.daba errores pseudoaleatorios de acceso a algun bloque, repartidos por el disco, y iban creciendo poco a poco, hasta llegar a un 50% del disco. Con esta simple prueba, y las pocas herramientas del reiserfs, vi que la recuperación era compleja pero no me quedó ninguna vez corrupto de las 10 pruebas que hice. En cambio el ext3 y el ext2, el XFS i algun otro, fue desastroso ya con el inicio del test. Con el ext2 no habia manera de solucionar algunos problemas. Hay que tener en cuenta que lo que hacia era llenar a un 25% el disco mientras iba fallando hasta el 50%. Las pruebas eran con sistemas de ficheros de 50 Megas y pude recuperar las 10 particiones (ficheros) con el reiserfs. En cambio con el ext3, consegui recuperar 7 de las 10. Con el ext2 no habia manera de recuperar el disco ni escribir. Durante 4 dias fuí probandolo, y curiosamente empezó a fallar más el reiserfs si petaba borrando ficheros, aun asi, solo me fallaron 2, como máximo en cada test. 2. Después añadí al modulo la posibilidad de desconectarse directamente en un momento aleatorio (para emular apagones, etc). He de decir que con esto el ext2 falló poco pero falló. EN cambio ninguno de los que usaban journaling, falló. excepto el XFS, que perdí 3 de las particiones. Finalmente, aunque con miedo, porque habian pocas herramientas para reiserfs, decidi usarlo porque se habia portado bien, en comparación al ext3, pero me encontré que nunca iba incluido por defecto en el kernel y me dió mucha rabia, porque no tenia discos de arranque con la version del reiserfs actual, tipico error de una persona como yo, pero vi, que los de SuSE te instalaban el reiserfs por defecto y en cambio, no viene por defecto en sus kernels..., todo siempre a traves del initrd.... He de reconocer y para que no penseis que el reiserfs es infalible, que mas adelante probé más el modulo loop modificado, y sobretodo al cambiar de kernel, al 2.6.11 el modulo reiserfs me petaba con el programa algunas veces, y me dió mucha rabia..., quizas no transformé bien el modulo del loop para la 2.6.11, pero entonces probé con el ext3 y el JFS y pasaba exactamente lo mismo, el error venia de más arriba. Así que no me he podido probar que pasa con las nuevas versiones, y desgraciadamente ahora tampoco tengo tiempo... snifff.... NOTA: Ahora han crecido tanto los sistemas de ficheros, que me dan mas miedo, que seguridad. Nunca olvideis de hacer copias de seguridad y recordad que ningun antivirus y ningun firewall puede impedir que un disco duro deje de poder leerse. Y para mi es mas importante que sean robustos a que vayan más rápidos, mientras no sean 10 veces mas lentos claro... Urbez. -- ################################################ #- Urbez Santana i Roma - #- Email: urbez@linuxupc.upc.edu #- Private Web: http://linuxupc.upc.es/~urbez/ ################################################