Hola :) On Saturday 15 August 2009 21:29:48 Camaleón wrote:
El 2009-08-15 a las 19:52 +0200, Rafa Grimán escribió:
On Sunday 09 August 2009 19:30:17 Camaleón wrote:
La cantidad de datos entre ambos escenarios (disco camaleón/discos del repo del kernel) no es comparable.
Lo de "cantidad de datos", lo importante no es los MB sino el número de ficheros. Cuantos más ficheros -> más tiempo.
Bueeeno. En ese caso 5 minutos lo veo excesivo:
*** hpc02@stthpc:~/data/hpc02> ls -R /home/hpc02/data/hpc02 | wc -l 226 ***
O:-)
¿du -i?
hpc02@stthpc:~> du -i /home/hpc02/data/ du: opción inválida -- i Pruebe `du --help' para más información.
¿No existe? :-?
Perdón, siempre me equivoco 0:) Es: df -i o df -ih
Sin molestar, en efecto - salvo cuando peta, entonces molesta y mucho. Lo hace "realmente", de realeza, no de realidad (del dicho ingles ese).
¿Cuándo peta, por qué peta...?
a) tendencia enfermiza a corromperse solo b) apagón y no hay sai c) apagón inesperado (bloqueo del sistema)
Opción b). Recordemos que todos los sistemas de ficheros de hoy en día acen lo mismo: cachear todo lo que pueden en memoria. Si se te va la luz, lo que había en memoria se pierde. Recordemos que no es sólo cosa del sistema de ficheros, Linux (kernel) hace lo mismo, cachea todo lo que puede.
No cuela >:-)
No tiene que colar, es que son así, y el kernel también ;)
Vale :-)
Sólo digo que unos sistemas de archivos tienen mejor comportamiento que otros, en caso de apagón a lo bruto.
Todos no se comportan igual.
El reiserfs aguanta los apagones a lo bruto como un señor. No digo que no tengas problemas si cierras el equipo (sin apagarlo debidamente) 10 veces al día, pero apagones esporádicos los sobrelleva muy decentemente (rápido y sin problemas mayores).
Y el NTFS también aguanta auténticas barbaridades perpretadas por los usuarios, acostumbrados a apagar los equipos desconectando el cable de corriente (y menos mal que los portátiles llevan batería, que si no, íbamos apañaos :-P).
No tienen todos la misma meta ;)
Eso es cierto.
Yo quiero un MPASBAF ("Multi-Purpose-Anti-Shutdown-Break-All-Filesystem" O:-)
Yo quiero que me toque la lotería ;)
> 2. (ponga aquí su argumento para cambiar de ext3 a xfs dados los > supuestos indicados A. y B.)
Ficheros muy grandes --> usar xfs.
Define "muy grandes".
1 GB.
Yo he puesto 1 GB, pero 100 MB también puede ser grande.
Okis.
Me interesa más ganar velocidad (con respecto al ext3) en escritura que en lectura.
La escritura es muy puñetera, siempre es más lenta que la lectura :( Aquí vuelvo a lo de antes: si tienes varios cores y varios discos (RAID), XFS es más rápido porque es capaz de hacer lecturas/escrituras en paralelo debido a que se diseñó para que sus operaciones fueran en paralelo.
Sí, bueno, el servidor monta dos micros intel xeon "físicos", 4 cores virtuales (son dual-core del año 2.006) y está con un raid5 repartido en 4 discos.
Casi 1 core por disco :)
¿Y eso es bueno o malo? >:-?
Bueno: 1 thread <-> 1 core <-> 1 disco. Te sobra un core para hacer otras cosas :)
Para el servidor tengo que pensarlo. Creo que sí notaría alguna mejoría pasando de un formato en ext3 al xfs.
Como siempre: haz tus pruebas con tus datos, repítelas varias veces, deja que corran durante mucho tiempo (no pares la pruebas, aunque parezca que se haya estabilizado), ...
Una pregunta más ¿se podía pasar "on-the-fly" (convertir) de ext3 a xfs o requiere reformateo completo? :-?
Imposible. Es como pasar de ext[2|3|4] a reiser o a la inversa. Hay que crear el sistema de ficheros desde cero. No te voy a contar nada nuevo y que no sepas, pero es bueno ser pesado a veces: BACKUP. Aunque pudieras pasar de uno a otro sin crear el filesystem de nuevo: BACKUP ;)
P.S. Quien esté interesado en los avances de los discos duros y las memorias SSD, que lea este artículo de la revista Scientific American sobre una nueva técnica de almacenamiento que está en fase experimental que aúna las bases de las memorias en estado sólido -pero sin sus desventajas- junto con las altas densidades de almacenamiento de los discos duros convecionales. Se llama "Racetrack" (el artículo está en inglés, pero al menos el acceso es abierto).
Lo he podido leer en la revista española y es una auténtica pasada, realmente interesante :-}
Racetrack Memory: The Future Third Dimension of Data Storage http://www.scientificamerican.com/article.cfm?id=data-in-the-fast-lanes
Chuli, ahora me lo leo. Gracias !!! Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- 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