-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-04 a las 15:08 +0200, Rafa Grimán escribió:
Los benchmark no es todo lo que hay. No porque un coche sea el que gane las pruebas de velocidad te va a resultar mejor en el uso diario: a lo mejor peta más, o tiene menos talleres, o es un monoplaza.
Creo que ha quedado claro en algún que otro correo que no soy amante/creyente de los benchmarks por lo que coincido con Carlos.
Personalmente nunca he tenido problemas con XFS y creo que es el que más herramientas tiene para trabajar con el sistema de ficheros, pero reconozco que tiene algunos inconvenientes como puede ser que se ha desarrollado para sistemas de ficheros grandes, sistemas con grandes cargas, ...
O sea, que no es un "genérico". Le echan en cara que su código es enorme (implicando mayor dificultad de mantenimiento), lo cual quizás explique que su carga de cpu también sea grande. Yo lo uso para home, por ejemplo, es un buen sistema.
Hay una cosa que veo en casi todas las personas y es la "manía" de pensar que "esto o aquello es mejor" a nivel global/universal cuando (IMHO) no es así. Un filesystem puede ser muy bueno para una cosa puntual, pero no para otra. No penséis que hay uno mejor que otro, sino más bien en situaciones. Por eso les tengo tanta manía a los benchmarks, porque muestran información de una situación determinada y si cambias de situación, posiblemente el benchmark no sirva de nada.
Claro. Por ejemplo, si instalas mythTV, un sistema cliente servidor para ver la tele en diferido y grabar, recomiendan usar xfs porque es capaz de borrar ficheros enormes instantaneamente, y eso les hace falta.
Otra cosa muy importante, todos los sistemas de ficheros tienen sus opciones y parámetros tuneables por lo que NO deberíamos simplemente pasar un:
mkfs -t <fs> /dev/<dispositivo>
porque puede ser como el que tose y se rasca las orejas ... es decir, inútil. Según la aplicación que se esté manejando, puede interesarnos que el bloque sea mayor o menor, reservar más o menos espacio a root, ... Por ejemplo:
Pero todas esas opciones son sofisticadas y no explicadas. En el momento en que vas a formatear no te puedes parar con esas cosas; pero es que ni aún tomandote tu tiempo, lo que no podemos hacer todo el mundo es leernos un críptico manual que simplemente nos describe las opciones que hay, dándonos la lista, pero sin explicar como se combinan unas con otras y dando ejemplos de aplicación real. Es decir, los que no hemos estudiado a fondo el tema (yo entre ellos) no tenemos ni idea de qué opciones nos pueden venir mejor. Por ejemplo, uno de los comentarios de Jeff Mahoney al respecto de ext3, es que tiene características que por defecto no están activadas; y que si se activan ya no es compatible con ext2. Me he ido a mirar en el "man tune2fs" para ver que hacían esas opciones, y me he visto alguna interesante: -O [^]feature[,...] ... The following filesystem features can be set or cleared using tune2fs: dir_index Use hashed b-trees to speed up lookups in large directories. filetype Store file type information in directory entries. has_journal Use a journal to ensure filesystem consistency even across unclean shut- downs. Setting the filesystem feature isequivalent to using the -j option. sparse_super Limit the number of backup superblocks to save space on large filesystems. Acto seguido me he ido a mirar las opciones con la que están creadas mis particiones ext3 (mediante yast): dumpe2fs -h /dev/hdd6 ... Filesystem features: has_journal ext_attr filetype needs_recovery sparse_super Y uno de los benchmarks mencionados esta mañana dice precisamente que generaban el sistema de ficheros con las opciones por defecto; bueno, pues da la casualidad que si hubieran activado dir_index el rendimiento de ext3 al hacer operaciones en arboles grandes debería cambiar.
- en el caso de XFS, puedes separar la zona de datos, log y Real Time, tamaño y número de allocation groups, stripe unit, cantidad de i-nodos, alineamiento de los i-nodos, ...
Ni idea.
- en el caso de reiserfs, puedes tamaño de bloque, hash function, dispositivo donde guardar el journal, tamaño del journal, ...
Si los discos duros tuvieran asociados una memoria ram con respaldo de batería que se pudieran usar como almacenamiento del journal, la mejora de rendimiento sería apreciable.
Con estas opciones conseguiremos mejorar el rendimiento de nuestro sistema de ficheros.
Si, pero desconocemos en que sentido.
De todas maneras, los sistemas de ficheros van a tener que cambiar en breve (dentro de 1 ó 2 años empezaremos a ver los cambios) porque los discos duros cada vez son mayores, pero hay problemas de velocidad de acceso a datos ya que la velocidad de rotación no aumenta ... :( Para mi que está cada vez más cerca la desaparición del disco duro tal y como lo conocemos.
Yo ya lo comenté un dia: espero ver pronto discos duros con varios cabezales independientes; como mínimo, uno por plato, pero pueden ser uno por cara, e incluso más. A mi me parece un paso obvio. ¿No hay memorias de doble bus? Pues esto es mucho más sencillo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFI7/7tTMYHG2NR9URAiOyAJ9W2RemV8WGqsLqzKKmJ5hVe0u0LwCfXNPz BiKTyVzRAlVeg3oESq0G2tA= =ztVM -----END PGP SIGNATURE-----