Hola :) El Miércoles, 4 de Octubre de 2006 16:06, Carlos E. R. escribió:
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.
Yo lo uso para /home también :) En el portátil y en casa. Es un sistema bastante complejo porque te permite gestionar hasta el último detalle, se basa en allocation groups y extents, situar los i-nodos juntos, ... La verdad es que es un comportamiento muy complejo el que tiene. Otra cosa que hay que tener en cuenta es en qué máquinas y mercado se ha desarrollado: HPC y HW Silicon Graphics, es decir, en HW que es muy potente y en el que no suele faltar RAM y/o CPU ;)
Hay una cosa que veo en casi todas las personas y es la "mañana" 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éisque hay uno mejor que otro, sino más bien en situaciones. Por eso les tengo tanta mañana a los benchmarks, porque muestran informaciónde 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.
No sabía que MythTV te aconsejaba XFS, es bueno saberlo ;)
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.
Eso es cierto, pero cuando un cliente intenta (o quiere) sacarle el máximo rendimiento al sistema porque trabaja con vídeo/audio en tiempo real, BBDD en tiempo real, HPC (sea científico o no), ... tienes que sacar hasta el último bit ;) Es muy complejo porque aquí sólo hablamos del filesystem, pero a esto hay que sumar cómo se crean los LUNs, cómo se ha creado el volumen lógico de discos, ... si la aplicación es I/O intensiva, si lo que consume es ancho de banda (RAM - CPU, CPU - disco, red), si los streams son grandes o pequeños, ...
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:
[...]
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.
Benchmarks ... ;)
- 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.
Zona de datos, log y real time son las 3 zonas en las que podemos dividir un filesystem XFS. - Datos: donde se guardan los datos (complejo, ¿eh? ;) - log: donde se guarda el journal (resierfs tiene esta opción también) - Real Time: información para sistemas de fichero en tiempo real Si separas las 3 cosas en diferentes discos consigues una mejora en el rendimiento, más fiabilidad y más flexibilidad. El allocation group es una agrupación de i-nodos y datos. Esto permite una serie de ventajas: puedo crecer el sistema de ficheros de una manera muy sencilla y mientras la máquina está en ejecución, ... Cuando se define un RAID y/o un sistema de volúemenes (LVM, por ejemplo), defino el tamaño mínimo de escritura en disco, algo similar al tamaño de bloque. Lo que hacen los RAIDs y los gestores de volúmenes es intentar escribir un stripe en cada disco de forma que la escritura es en paralelo y se consigue aumentar el rendimiento. Pues el stripe unit de XFS lo que te permite es definirlo igual al del sistema de volúmenes y/o RAID que tienes por debajo. El alineamiento de i-nodos lo que me permite es juntarlos de forma que puedo juntar ficheros relacionados.
- 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.
Esto lo tienen las cabinas de disco. Las baterías te suelen durar una semana y permiten que la caché se mantenga y no se pierdan datos. Los discos que tenemos en nuestros equipos traen caché ... pero sin batería :"(
Con estas opciones conseguiremos mejorar el rendimiento de nuestro sistema de ficheros.
Si, pero desconocemos en que sentido.
Como has dicho antes, es bastante complejo, pero divertido ;) Un caso curioso ... en un cliente montamos 4 servidores con almacenamiento compartido (clustered filesystem) y en uno de los servidores iba TiNa (Time Navigator, un sw de backup). Pues resulta que los de TiNa instalan y hacen una prueba de creación de catálogos (BBDD del sistema de copia de seguridad). Pues en las pruebas que hicieron consiguieron crear catálogos de 35 GB en 5 minutos. Decían que esto no lo habían visto jamás y que era impresonante ... Total que al día siguiente cambiamos una cosa del sistema de ficheros y pasó a tardar 12 minutos ... algo inaceptable. No te puedes imaginar lo divertido que es ;) Pero bueno, aprendimos que "eso" no se hace ... y menos en el cliente 0;)
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.
Me acuerdo que lo comentaste, la idea está chula ... a ver si algún fabricante se anima :) Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman