Hola :) On Thursday 03 December 2009 20:12:30 Carlos E. R. wrote:
El 2009-12-03 a las 17:56 +0100, Rafa Grimán escribió:
Hola :)
On Thursday 03 December 2009 15:55:29 Carlos E. R. wrote:
[...]
Ahora que lo pienso... en la escritura a disco con dd no se hace un flush. Puede afectar a mis mediciones bastante. Las hice grabando un fichero de un giga con dd.
Preguntillas:
- ¿con qué opciones creaste los filesystems? Es decir, ¿todos tienen el mismo tamaño de bloque, ...?
Opciones por defecto. A ver, mirando en el script:
mkfs.ext4 -L test_$X /dev/sdb$X
Los valores por defecto están (o deberían estar) definidos en el fichero: /etc/mke2fs.conf En el mío, por ejemplo, los valores son: base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr blocksize = 4096 inode_size = 256 inode_ratio = 16384 has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize man mke2fs.conf para más info.
mkfs.reiserfs -l test_$X -q /dev/sdb$X
No he encontrado los valores por defecto. ¿Alguien los conoce?
mkfs.xfs -f -L test_$X /dev/sdb$X
The default value is 4096 bytes The mininum (and default) value is 256 bytes Parece que los alores son los mismos en ext4 y xfs. Teniendo en cuenta que han sacado muchas ideas de xfs, es de esperar ;)
- el dd, ¿lo has lanzado de un disco a otro?
Ah, si, por supuesto :-)
case respuesta in
yes) ¿estaban en la misma controladora y/o bus?
Posiblemente. No conozco la arquitectura de esta máquina, pero sospecho que si. Bus sata, distinto cable, controladora de la placa. No se como se lo montan.
Por lo qu edices abajo, esto no es relevante. Era por si hacías un dd de un fichero que tenías en disco a otro disco. Si tienes los discos en la misma controladora, puedes tener cuellos de botella.
no) ¿desde el mismo disco? esac
x)
- dd es monoproceso/thread por lo que no estarás sacando toda la chicha a las CPUs/cores que tengas
- si puedes, haz el dd desde un tmpfs en RAM a disco
- dd es cpu-bound, por lo que la CPU es factor limitante, comprueba el consumo de CPU
Bueno, el dd era este:
time dd if=/dev/zero of=/mnt/test/fichero count=5 bs=200M 2>&1 | tee -a $Nombre
Por lo que la lectura es en memoria y por tanto mucho más rápida, tiempo despreciable, frente al tiempo del disco.
Has usado /dev/zero. No se debería usar porque las cahcés (desde la RAM hasta la del disco) no refrescan datos, es decir, estás leyendo valores de caché y no la velocidad real del disco. Usa mejor random o urandom para que se tengan que borrar las cachés (todas las que tengas por en medio).
Si puedes probar con iozone, mejor. También puedes probar con bonniee++ y otros cuantos que hay por ahí.
¡Humm! Tendría que estudiarmelos.
iozone es bastante complejo, aunque puedes hacer un iozone -a que (IIRC) hace todas las pruebas. Bonnie++ tiene menos opciones y es bastante rápido.
Mi intención era simplemente averiguar el efecto de la distancia al borde, o sea, ver si las primeras particiones eran realmente más rápidas, y cuanto. No hacer un estudio serio :-)
No te lo preguntaba por criticar, más que nada era curiosidad 0:)
Ah, el webpin no encuentra iozone para la 11.2. El bonnie, si.
Jarl. Antes sí lo tenía. Bueno, a lo mejor lo han pasado a software.opensuse.org. 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