[opensuse-es] [Semi-OT] Enlaces interesantes sobre almacenamiento
Hola :) <http://www.linuxconfig.org/choosing-the-right-linux-file-system-layout-using... a-top-bottom-process> http://www.ibm.com/developerworks/linux/library/l-gpt/index.html 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
El 2009-08-03 a las 10:49 +0200, Rafa Grimán escribió:
Hola :)
<http://www.linuxconfig.org/choosing-the-right-linux-file-system-layout-using... a-top-bottom-process>
http://www.ibm.com/developerworks/linux/library/l-gpt/index.html
Interesantes, sí... Para los que usamos suse: "jfs" y "reiserfs" dejarán de estar disponibles en futuras versiones, cuando termine el soporte de sles/sled 11). Ya te preguntaré por un sustituto del reiserfs dentro de 5 años :-P Pero ahora, dame argumentos (ventajas, mejoras, qué voy a ganar) para cambiar estos dos volumenes del ext3 actual (o de un ext4 futuro) a un formato en xfs para los siguientes escenarios reales: A. Volumen de un servidor en raid5 con 1,2 TB, única y exclusivamente para almacenamiento en backup de datos (copias de seguridad del resto de los equipos de la red (mediante conexiones ethernet gigabit), clientes windows xp que copian a través de samba). Pocos archivos pero pesados (>30 GB.) B. Volumen de mi equipo de trabajo (disco sata de 500 gb) con una única partición, dedicado a backup (de los datos de mi equipo, luego la copia es local). Pocos archivos y no muy pesados (la copia que hago de seguridad ocupa <5 GB.) El primer argumento para cambiar lo pongo yo :-P: 1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días. Pensaba que algo había pasado porque no se iniciaba el sistema y como nunca uso ext3 (uso reiserfs) no estaba acostumbrada a ese "chequeo" (en el servidor no me entero porque accedo en remoto, así que no sé cuánto le cuesta, pero de momento nadie se me ha quejado O:-) ¿Cómo chequea el xfs? ¿Tipo reiserfs, discretamente y sin molestar? :-) 2. (ponga aquí su argumento para cambiar de ext3 a xfs dados los supuestos indicados A. y B.) 3. (...) Saludos, -- Camaleón -- 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
Hola :) On Thursday 06 August 2009 13:33:00 Camaleón wrote:
El 2009-08-03 a las 10:49 +0200, Rafa Grimán escribió:
Hola :)
<http://www.linuxconfig.org/choosing-the-right-linux-file-system-layout-u sing- a-top-bottom-process>
http://www.ibm.com/developerworks/linux/library/l-gpt/index.html
Interesantes, sí...
Para los que usamos suse: "jfs" y "reiserfs" dejarán de estar disponibles en futuras versiones, cuando termine el soporte de sles/sled 11).
Ya te preguntaré por un sustituto del reiserfs dentro de 5 años :-P
Pero ahora, dame argumentos (ventajas, mejoras, qué voy a ganar) para cambiar estos dos volumenes del ext3 actual (o de un ext4 futuro) a un formato en xfs para los siguientes escenarios reales:
A. Volumen de un servidor en raid5 con 1,2 TB, única y exclusivamente para almacenamiento en backup de datos (copias de seguridad del resto de los equipos de la red (mediante conexiones ethernet gigabit), clientes windows xp que copian a través de samba). Pocos archivos pero pesados (>30 GB.)
Aquí el argumento de peso es el tamaño de ficheros. Si vas a trabajar con ficheros >30 GB, XFS es recomendable porque da muy buen rendimiento con ficheros grandes.
B. Volumen de mi equipo de trabajo (disco sata de 500 gb) con una única partición, dedicado a backup (de los datos de mi equipo, luego la copia es local). Pocos archivos y no muy pesados (la copia que hago de seguridad ocupa <5 GB.)
Sinceramente, no creo que notes diferencia al trabajar con diferentes sistemas de ficheros. reiserfs podría dar mejores resultados si son ficheros muy pequeños. Aquí XFS te puede dar buen rendimiento porque paraleliza el acceso a los ficheros ... siempre y cuando tengas suficiente número de cores (recordemos que paralelizar sin cores es como toser y rascarse las orejas ;) No creo que vayas a notar grandes mejoras y tendrías que hacer muchos benchmarks para poder sacar una media significativa ya que (casi) todos los sistemas de ficheros van a dar números similares.
El primer argumento para cambiar lo pongo yo :-P:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
Pensaba que algo había pasado porque no se iniciaba el sistema y como nunca uso ext3 (uso reiserfs) no estaba acostumbrada a ese "chequeo" (en el servidor no me entero porque accedo en remoto, así que no sé cuánto le cuesta, pero de momento nadie se me ha quejado O:-)
¿Cómo chequea el xfs? ¿Tipo reiserfs, discretamente y sin molestar? :-)
Sip, pero ... tenemos clientes con varios cientos de millones de ficheros cuyo xfs puede tardar en chequear. También depende del # de cores (como he dicho antes) y la cantidad de RAM. Como la idea de SGI desde el año 86 (si mal no recuerdo) vendiendo máquinas multiprocesadoras, tenemos la manía de paralelizar todo y así conseguir que todas las CPUs trabajen, se balancee la carga, se mejore el rendimiento, ... Debido a esto, XFS da buen rendimiento cuando hay varios cores ya que paraleliza la E/S, por ejemplo, puedes acceder a dos ficheros al mismo tiempo. Claro, que no sólo de cores vive el XFS, si tienes 50 cores y 1 disco duro ... por mucho que paralelices el sistema de ficheros ... el cuello de botella es el disco duro (sólo hay uno con 1 cabezal) así que la paralelización se va al traste. En cuanto a la memoria, XFS lo que hace es cargar en RAM todo lo que va a hacer junto con todos los inodos y luego empieza a trabajar, de esta forma lee el disco una vez y luego lanza las tareas. Otros sistemas de ficheros leen un poco y trabajan, vuelven a leer, vuelven a trabajar. Si tienes mucha RAM, verás mejoras, de lo contrario, verás el mismo comportamiento que con otros sistemas de ficheros. ¿Cuánto es mucha RAM? Pues depende de cuántos ficheros tienes ;)
2. (ponga aquí su argumento para cambiar de ext3 a xfs dados los supuestos indicados A. y B.)
¿Volver a escribir todo? Ehhhh: 25 GOTO un par de párrafos más arriba ;)
3. (...)
Otras razones: - las herramientas que tiene para trabajar con el sistema de ficheros - la gente tan simpática que trabaja en SGI - que el año pasado (si mal no recuerdo) contribuimos más líneas de código al kernel de Linux (el 2%) que otras compañías que facturan MUUUUUUCHO más y que tienen MUUUUCHA más gente en plantilla y que hacen MUUUUUCHO más marketing que nosotros - que nos llevamos dedicando al mundo del almacenamiento desde hace muuuucho tiempo - XFS lleva en el mercado mucho tiempo y muchos tipos de clientes diversos (media, ciencias, manufacturing, enterprise, ...) lo llevan usando desde que ha salido - si quieres puedes pasar de XFS a CXFS sin reformatear - soporte DMAPI para HSM HTH 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
El 6 de agosto de 2009 09:41, Rafa Griman
Hola :)
On Thursday 06 August 2009 13:33:00 Camaleón wrote:
El 2009-08-03 a las 10:49 +0200, Rafa Grimán escribió:
Hola :)
<http://www.linuxconfig.org/choosing-the-right-linux-file-system-layout-u sing- a-top-bottom-process>
http://www.ibm.com/developerworks/linux/library/l-gpt/index.html
Interesantes, sí...
Para los que usamos suse: "jfs" y "reiserfs" dejarán de estar disponibles en futuras versiones, cuando termine el soporte de sles/sled 11).
Ya te preguntaré por un sustituto del reiserfs dentro de 5 años :-P
Pero ahora, dame argumentos (ventajas, mejoras, qué voy a ganar) para cambiar estos dos volumenes del ext3 actual (o de un ext4 futuro) a un formato en xfs para los siguientes escenarios reales:
A. Volumen de un servidor en raid5 con 1,2 TB, única y exclusivamente para almacenamiento en backup de datos (copias de seguridad del resto de los equipos de la red (mediante conexiones ethernet gigabit), clientes windows xp que copian a través de samba). Pocos archivos pero pesados (>30 GB.)
Aquí el argumento de peso es el tamaño de ficheros. Si vas a trabajar con ficheros >30 GB, XFS es recomendable porque da muy buen rendimiento con ficheros grandes.
B. Volumen de mi equipo de trabajo (disco sata de 500 gb) con una única partición, dedicado a backup (de los datos de mi equipo, luego la copia es local). Pocos archivos y no muy pesados (la copia que hago de seguridad ocupa <5 GB.)
Sinceramente, no creo que notes diferencia al trabajar con diferentes sistemas de ficheros. reiserfs podría dar mejores resultados si son ficheros muy pequeños.
Aquí XFS te puede dar buen rendimiento porque paraleliza el acceso a los ficheros ... siempre y cuando tengas suficiente número de cores (recordemos que paralelizar sin cores es como toser y rascarse las orejas ;)
No creo que vayas a notar grandes mejoras y tendrías que hacer muchos benchmarks para poder sacar una media significativa ya que (casi) todos los sistemas de ficheros van a dar números similares.
El primer argumento para cambiar lo pongo yo :-P:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
Pensaba que algo había pasado porque no se iniciaba el sistema y como nunca uso ext3 (uso reiserfs) no estaba acostumbrada a ese "chequeo" (en el servidor no me entero porque accedo en remoto, así que no sé cuánto le cuesta, pero de momento nadie se me ha quejado O:-)
¿Cómo chequea el xfs? ¿Tipo reiserfs, discretamente y sin molestar? :-)
Sip, pero ... tenemos clientes con varios cientos de millones de ficheros cuyo xfs puede tardar en chequear. También depende del # de cores (como he dicho antes) y la cantidad de RAM.
Como la idea de SGI desde el año 86 (si mal no recuerdo) vendiendo máquinas multiprocesadoras, tenemos la manía de paralelizar todo y así conseguir que todas las CPUs trabajen, se balancee la carga, se mejore el rendimiento, ... Debido a esto, XFS da buen rendimiento cuando hay varios cores ya que paraleliza la E/S, por ejemplo, puedes acceder a dos ficheros al mismo tiempo.
Claro, que no sólo de cores vive el XFS, si tienes 50 cores y 1 disco duro ... por mucho que paralelices el sistema de ficheros ... el cuello de botella es el disco duro (sólo hay uno con 1 cabezal) así que la paralelización se va al traste.
En cuanto a la memoria, XFS lo que hace es cargar en RAM todo lo que va a hacer junto con todos los inodos y luego empieza a trabajar, de esta forma lee el disco una vez y luego lanza las tareas. Otros sistemas de ficheros leen un poco y trabajan, vuelven a leer, vuelven a trabajar. Si tienes mucha RAM, verás mejoras, de lo contrario, verás el mismo comportamiento que con otros sistemas de ficheros. ¿Cuánto es mucha RAM? Pues depende de cuántos ficheros tienes ;)
2. (ponga aquí su argumento para cambiar de ext3 a xfs dados los supuestos indicados A. y B.)
¿Volver a escribir todo? Ehhhh:
25 GOTO un par de párrafos más arriba
;)
3. (...)
Otras razones:
- las herramientas que tiene para trabajar con el sistema de ficheros
- la gente tan simpática que trabaja en SGI
- que el año pasado (si mal no recuerdo) contribuimos más líneas de código al kernel de Linux (el 2%) que otras compañías que facturan MUUUUUUCHO más y que tienen MUUUUCHA más gente en plantilla y que hacen MUUUUUCHO más marketing que nosotros
- que nos llevamos dedicando al mundo del almacenamiento desde hace muuuucho tiempo
- XFS lleva en el mercado mucho tiempo y muchos tipos de clientes diversos (media, ciencias, manufacturing, enterprise, ...) lo llevan usando desde que ha salido
- si quieres puedes pasar de XFS a CXFS sin reformatear
Como se hace? Que diferencia hay entre XFS y CXFS? Salu2 -- 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
Hola :)
2009/8/6 Juan Erbes
El 6 de agosto de 2009 09:41, Rafa Griman
escribió:
[...]
Como se hace?
Que diferencia hay entre XFS y CXFS?
CXFS es XFS en cluster (Cell XFS, aunque algunos lo llaman Cluster XFS). Es similar a GFS de Red Hat o el OCFSv2. Está orientado a entornos de alto rendimiento: - televisiones - postproducción - HPC - servidores de ficheros de alto rendimiento - Fat node SANs: esto es cuando tienes estaciones de trabajo/servidores muy grandes (aka fat node -> 32 cores + GB de RAM) conectadas a un mismo sistema de ficheros. - clientes heterogéneos que tienen que compartir datos, pero un NAS no te da el rendimiento (ancho de banda y/o latencia) NO usar con BBDD. Es decir, permite que dos o más equipos puedan usar un mismo sistema de ficheros. Está basado en un servidor (o más, si quieres alta disponibilidad) llamado MDS (MetaData Server) y lo que se llama MDC (MetaData Client). El MDS es el que gestiona todo el sistema de ficheros y el que establece los permisos para acceder o no a un fichero. Los MDC serían las estaciones de trabajo, por ejemplo. Aquí puedes ver un diagrama: http://www.abishpc.co.za/images/cxfs_diagram.gif El almacenamiento (cabina de discos) se conecta mediante FibbreChannel a todos los MDS y MDC (mediante switches de fibra) y cada MDC cree que es el dueño único del sistema de ficheros, cuando en realidad lo comparte con otros MDC. Para más info: http://www.sgi.com/products/storage/software/cxfs.html En cuanto a la otra pregunta de cómo se hace. Muy sencillo: 1.- tienes un equipo conectado a una cabina de discos, la cabina tiene un sistema de ficheros XFS 2.- lo apagas 3.- conectas lo que será(n) el MDS y configuras todo 4.- conectas lo que será(n) los MDC 5.- arrancas el/los MDS 6.- compruebas que todo es correcto 7.- arrancas el/los MDC 8.- sigues trabajando Alguien que sabe de CXFS lo tiene todo montado en 1 jornada de trabajo. Los MDS tienen que ser obligatoriamente SLES (x86_64 o IA64) y los MDC pueden ser Linux (32/x86_64/IA64), MacOS, MS-Windows, AIX, Irix, Solaris. Aunque XFS es GPL, el código del MDS es sw cerrado (hay que pagar licencia y no tienes el código fuente). Se ha hablado mucho de liberarlo, pero por ahora no hay quorum :( HTH Rafa -- 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
Hola. No me pude resistir... On Jueves, 6 de Agosto de 2009 18:03:25 Rafa Griman escribió:
Hola :)
2009/8/6 Juan Erbes
: El 6 de agosto de 2009 09:41, Rafa Griman
escribió: Que diferencia hay entre XFS y CXFS?
CXFS es XFS en cluster (Cell XFS, aunque algunos lo llaman Cluster XFS). Es similar a GFS de Red Hat o el OCFSv2. Está orientado a entornos de alto rendimiento: - televisiones
Mi nueva tele no tiene CXFS!!!!! otra vez me habran timado? -- Un saludo. Carlos Lorenzo Matés clmates AT mundo-r.com -- 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
Hola :)
2009/8/6 Carlos Lorenzo Matés
Hola.
No me pude resistir...
On Jueves, 6 de Agosto de 2009 18:03:25 Rafa Griman escribió:
Hola :)
2009/8/6 Juan Erbes
: El 6 de agosto de 2009 09:41, Rafa Griman
escribió: Que diferencia hay entre XFS y CXFS?
CXFS es XFS en cluster (Cell XFS, aunque algunos lo llaman Cluster XFS). Es similar a GFS de Red Hat o el OCFSv2. Está orientado a entornos de alto rendimiento: - televisiones
Mi nueva tele no tiene CXFS!!!!! otra vez me habran timado?
ROFL !!! ¡¿Que no tiene CXFS?! =:0 Aaaaaaaaaaahhhhhhhhhhhh !!!! Pero ... ¿cómo es esto? Es como decir que tienes TV en blanco y negro o que no tienes TV de 60" con tecnología LED. Anda, anda, ... ábrela y mira a ver si ves un cable que pone: "CXFS, no quitar si quieres ver las telenovelas" xD Rafa -- 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
El 6 de agosto de 2009 08:33, Camaleón
El 2009-08-03 a las 10:49 +0200, Rafa Grimán escribió:
Hola :)
<http://www.linuxconfig.org/choosing-the-right-linux-file-system-layout-using... a-top-bottom-process>
http://www.ibm.com/developerworks/linux/library/l-gpt/index.html
Interesantes, sí...
Para los que usamos suse: "jfs" y "reiserfs" dejarán de estar disponibles en futuras versiones, cuando termine el soporte de sles/sled 11).
Ya te preguntaré por un sustituto del reiserfs dentro de 5 años :-P
Pero ahora, dame argumentos (ventajas, mejoras, qué voy a ganar) para cambiar estos dos volumenes del ext3 actual (o de un ext4 futuro) a un formato en xfs para los siguientes escenarios reales:
A. Volumen de un servidor en raid5 con 1,2 TB, única y exclusivamente para almacenamiento en backup de datos (copias de seguridad del resto de los equipos de la red (mediante conexiones ethernet gigabit), clientes windows xp que copian a través de samba). Pocos archivos pero pesados (>30 GB.)
B. Volumen de mi equipo de trabajo (disco sata de 500 gb) con una única partición, dedicado a backup (de los datos de mi equipo, luego la copia es local). Pocos archivos y no muy pesados (la copia que hago de seguridad ocupa <5 GB.)
El primer argumento para cambiar lo pongo yo :-P:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
5 minutos...Cuantos gigabytes tiene ocupados esa partición? A mi, con una partición home en ext3 de 160 GB, ocupada al 86%, me tarda mas de 20 minutos. El disco, ya tiene un par de años, es un Western Digital de 2 mb de cache. Veré si lo cambio en estos dias, por uno de la misma marca que me regalaron de 320 GB y 8 mb de cache, y justo estaba viendo que FS le ponía. El ext3, y sus chequeos ya me tiene harto, justo hace unos dias cuando puse en funcionamiento el mobo con micro y memorias nuevas, se me dio por experimentar un poco para activar el cuarto core del Phenom X3, pero parece ser que ese cuarto core está pinchado en el mio, y tenia que resetear la cmos, y cada vez que se cambiaba la fecha en la bios, entraba el maldito fsck: http://www.guru3d.com/news/phenom-ii-x3--enable-the-4th-core/ Veré si pruebo con Opensuse 11.2 M4: http://news.opensuse.org/2009/07/27/ready-to-rumble-opensuse-112-milestone-4... Salu2 -- 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
El 2009-08-06 a las 11:32 -0300, Juan Erbes escribió:
El 6 de agosto de 2009 08:33, Camaleón escribió:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
5 minutos...Cuantos gigabytes tiene ocupados esa partición?
Pues no mucho: *** hpc02@stthpc:~> df -H /dev/sdb1 S.ficheros Tamaño Usado Disp Uso% Montado en /dev/sdb1 493G 125G 343G 27% /home/hpc02/data ***
A mi, con una partición home en ext3 de 160 GB, ocupada al 86%, me tarda mas de 20 minutos. El disco, ya tiene un par de años, es un Western Digital de 2 mb de cache. Veré si lo cambio en estos dias, por uno de la misma marca que me regalaron de 320 GB y 8 mb de cache, y justo estaba viendo que FS le ponía.
Este disco que tengo tiene 16 MB de caché, creo :-? El disco es rápido (gama empresa de seagate), el micro también y la cantidad de ram, decente (aunque tengo pinchados 8 GB, sólo veo 4 por el kernel de 32 bits "default" que tengo :-P): *** stthpc:~ # smartctl -i /dev/sdb | grep Model Device Model: ST3500320NS stthpc:~ # cat /proc/cpuinfo | grep name model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stthpc:~ # cat /proc/meminfo | grep MemTotal MemTotal: 3106816 kB ***
El ext3, y sus chequeos ya me tiene harto, justo hace unos dias cuando puse en funcionamiento el mobo con micro y memorias nuevas, se me dio por experimentar un poco para activar el cuarto core del Phenom X3, pero parece ser que ese cuarto core está pinchado en el mio, y tenia que resetear la cmos, y cada vez que se cambiaba la fecha en la bios, entraba el maldito fsck: http://www.guru3d.com/news/phenom-ii-x3--enable-the-4th-core/
Veré si pruebo con Opensuse 11.2 M4: http://news.opensuse.org/2009/07/27/ready-to-rumble-opensuse-112-milestone-4...
A mí también me fastidia :-/ No sólo por lo que tarda en hacerlo sino por el "momento" en que lo hace (al iniciar) y la poca utilidad real de hacerlo basado en el "tiempo" transcurrido del último chequeo (2 meses de manera predeterminada) y no en problemas reales que pueda tener el disco, debido a un mal cierre del sistema, apagón, etc... Saludos, -- Camaleón -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-08-06 a las 13:33 +0200, Camaleón escribió:
El primer argumento para cambiar lo pongo yo :-P:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
¿5 minutos? Eso es poco. A la gente del repositorio del kernel (el oficial) le tardó horas una vez que se les fué la luz.
Pensaba que algo había pasado porque no se iniciaba el sistema y como nunca uso ext3 (uso reiserfs) no estaba acostumbrada a ese "chequeo" (en el servidor no me entero porque accedo en remoto, así que no sé cuánto le cuesta, pero de momento nadie se me ha quejado O:-)
¿Cómo chequea el xfs? ¿Tipo reiserfs, discretamente y sin molestar? :-)
Sin molestar, en efecto - salvo cuando peta, entonces molesta y mucho. Lo hace "realmente", de realeza, no de realidad (del dicho ingles ese).
2. (ponga aquí su argumento para cambiar de ext3 a xfs dados los supuestos indicados A. y B.)
Ficheros muy grandes --> usar xfs. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkp7Qq0ACgkQtTMYHG2NR9XxowCcCtveDURuHtnzkKaEfp31OhLn 5s4An0Tc43rE24weCMchW9BDMZKO+2RX =XtrJ -----END PGP SIGNATURE-----
El 2009-08-06 a las 22:52 +0200, Carlos E. R. escribió:
El 2009-08-06 a las 13:33 +0200, Camaleón escribió:
El primer argumento para cambiar lo pongo yo :-P:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
¿5 minutos? Eso es poco. A la gente del repositorio del kernel (el oficial) le tardó horas una vez que se les fué la luz.
La cantidad de datos entre ambos escenarios (disco camaleón/discos del repo del kernel) no es comparable.
Pensaba que algo había pasado porque no se iniciaba el sistema y como nunca uso ext3 (uso reiserfs) no estaba acostumbrada a ese "chequeo" (en el servidor no me entero porque accedo en remoto, así que no sé cuánto le cuesta, pero de momento nadie se me ha quejado O:-)
¿Cómo chequea el xfs? ¿Tipo reiserfs, discretamente y sin molestar? :-)
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) Hum... ¿de qué dicho inglés? :-?
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". Me interesa más ganar velocidad (con respecto al ext3) en escritura que en lectura. Saludos, -- Camaleón -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-08-06 a las 23:02 +0200, Camaleón escribió:
El 2009-08-06 a las 22:52 +0200, Carlos E. R. escribió:
El 2009-08-06 a las 13:33 +0200, Camaleón escribió:
El primer argumento para cambiar lo pongo yo :-P:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
¿5 minutos? Eso es poco. A la gente del repositorio del kernel (el oficial) le tardó horas una vez que se les fué la luz.
La cantidad de datos entre ambos escenarios (disco camaleón/discos del repo del kernel) no es comparable.
No creas que es tan grande el almacenamiento. Pero resulta malvadamente interesante que esa gente se diera cuenta de que hay un problema con ext3 cuando lo sufrieron en sus propias carnes >;-)
¿Cómo chequea el xfs? ¿Tipo reiserfs, discretamente y sin molestar? :-)
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)
Vete a saber. En mi caso hubo algún tipo de fallo hardware (no recuerdo que fué exactamente) y se corrompió. Encima, el comprobador/reparador tenía un bug no corregido que le hacía petar a media corrección, estropeándolo aún más. Ese mismo fallo hardware afectó a más particiones, pero la xfs fué la más afectada, y con diferencia. Son sistemas que guardan muchas estructuras en memoria. Imagino que si están haciendo grandes cambios y se cae el sistema antes de que estén escritos del todo, pues... la lían gorda.
Hum... ¿de qué dicho inglés? :-?
When it [expletive] it [expletive] royaly. En esa categoría también está el reiserfs.
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".
Gigas. No se, con 100 megas ya se nota.
Me interesa más ganar velocidad (con respecto al ext3) en escritura que en lectura.
En escritura se nota, porque en vez de reservar espacio poquito a poquito, puede reservar trozos grandes de golpe. Creo que eso lo llaman "extents". - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkp7VVMACgkQtTMYHG2NR9V8/ACfez3xyJkR8UbiQ8ln1T1sQ32n dYwAn2RCQdDtcDq5JYxArRSrtgLyZHhm =8wMb -----END PGP SIGNATURE-----
Hola :) On Thursday 06 August 2009 23:02:26 Camaleón wrote:
El 2009-08-06 a las 22:52 +0200, Carlos E. R. escribió:
El 2009-08-06 a las 13:33 +0200, Camaleón escribió:
El primer argumento para cambiar lo pongo yo :-P:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
¿5 minutos? Eso es poco. A la gente del repositorio del kernel (el oficial) le tardó horas una vez que se les fué la luz.
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.
Pensaba que algo había pasado porque no se iniciaba el sistema y como nunca uso ext3 (uso reiserfs) no estaba acostumbrada a ese "chequeo" (en el servidor no me entero porque accedo en remoto, así que no sé cuánto le cuesta, pero de momento nadie se me ha quejado O:-)
¿Cómo chequea el xfs? ¿Tipo reiserfs, discretamente y sin molestar? :-)
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.
Hum... ¿de qué dicho inglés? :-?
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.
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. HTH 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
El 2009-08-09 a las 19:06 +0200, Rafa Grimán escribió:
On Thursday 06 August 2009 23:02:26 Camaleón wrote:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
¿5 minutos? Eso es poco. A la gente del repositorio del kernel (el oficial) le tardó horas una vez que se les fué la luz.
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:-)
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 >:-) 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).
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.
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. Para el servidor tengo que pensarlo. Creo que sí notaría alguna mejoría pasando de un formato en ext3 al xfs. Saludos, -- Camaleón -- 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
El 9 de agosto de 2009 14:30, Camaleón
El 2009-08-09 a las 19:06 +0200, Rafa Grimán escribió:
On Thursday 06 August 2009 23:02:26 Camaleón wrote:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
¿5 minutos? Eso es poco. A la gente del repositorio del kernel (el oficial) le tardó horas una vez que se les fué la luz.
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:-)
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 >:-)
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).
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.
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.
Para el servidor tengo que pensarlo. Creo que sí notaría alguna mejoría pasando de un formato en ext3 al xfs.
Ni una palabra del ext4? Por lo que vi, en Opensuse 11.2, el FS por defecto es el ext4. Salu2 -- 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
El 2009-08-09 a las 22:08 -0300, Juan Erbes escribió:
El 9 de agosto de 2009 14:30, Camaleón escribió:
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.
Para el servidor tengo que pensarlo. Creo que sí notaría alguna mejoría pasando de un formato en ext3 al xfs.
Ni una palabra del ext4?
De momento no me lo planteo. Es demasiado nuevo.
Por lo que vi, en Opensuse 11.2, el FS por defecto es el ext4.
Sí, eso parece, al menos para las nuevas instalaciones: *** http://en.opensuse.org/OpenSUSE_11.2#Filesystems_and_Partitioning Filesystems and Partitioning - The ext4 filesystem is the new default filesystem for new installations. - Btrfs, the next generation Linux filesystem, has now a stable disk layout and can be configured in the YaST partitioner. - The YaST partitioner has seen many user interface improvements (Add: screenshot of storage graph) - It is now possible to encrypt the complete hard disk. *** Saludos, -- Camaleón -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-08-10 a las 08:21 +0200, Camaleón escribió:
El 2009-08-09 a las 22:08 -0300, Juan Erbes escribió:
Para el servidor tengo que pensarlo. Creo que sí notaría alguna mejoría pasando de un formato en ext3 al xfs.
Ni una palabra del ext4?
De momento no me lo planteo. Es demasiado nuevo.
Eso mismo pienso yo... alguna partición de datos "fungibles", no más.
*** http://en.opensuse.org/OpenSUSE_11.2#Filesystems_and_Partitioning
Filesystems and Partitioning
- The ext4 filesystem is the new default filesystem for new installations.
Es que esta gente cuando dice eso, es como para fiarse. También dijeron eso del reiserfs en su dia, y ya nos han abandonado... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqAB/wACgkQtTMYHG2NR9WwMwCfdB4mWBHufRN2Bn2d+NCdhX0v VC4AoIe9aV+gs3XDbPZjorQg/kSccUgC =RqmN -----END PGP SIGNATURE-----
El 2009-08-10 a las 13:43 +0200, Carlos E. R. escribió:
El 2009-08-10 a las 08:21 +0200, Camaleón escribió:
El 2009-08-09 a las 22:08 -0300, Juan Erbes escribió:
Para el servidor tengo que pensarlo. Creo que sí notaría alguna mejoría pasando de un formato en ext3 al xfs.
Ni una palabra del ext4?
De momento no me lo planteo. Es demasiado nuevo.
Eso mismo pienso yo... alguna partición de datos "fungibles", no más.
*** http://en.opensuse.org/OpenSUSE_11.2#Filesystems_and_Partitioning
Filesystems and Partitioning
- The ext4 filesystem is the new default filesystem for new installations.
Es que esta gente cuando dice eso, es como para fiarse. También dijeron eso del reiserfs en su dia, y ya nos han abandonado...
Sasto. Yo sigo el ciclo de la SLES/SLED: hasta que no pongan el ext4 como predeterminado en esas dos, yo tampoco >:-) Es decir, que aún tengo 5 años de reiserfs... salvo que pete miserablemente con la 11.2 O:-) Saludos, -- Camaleón -- 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
El 10 de agosto de 2009 09:03, Camaleón
El 2009-08-10 a las 13:43 +0200, Carlos E. R. escribió:
El 2009-08-10 a las 08:21 +0200, Camaleón escribió:
El 2009-08-09 a las 22:08 -0300, Juan Erbes escribió:
Para el servidor tengo que pensarlo. Creo que sí notaría alguna mejoría pasando de un formato en ext3 al xfs.
Ni una palabra del ext4?
De momento no me lo planteo. Es demasiado nuevo.
Eso mismo pienso yo... alguna partición de datos "fungibles", no más.
*** http://en.opensuse.org/OpenSUSE_11.2#Filesystems_and_Partitioning
Filesystems and Partitioning
- The ext4 filesystem is the new default filesystem for new installations.
Es que esta gente cuando dice eso, es como para fiarse. También dijeron eso del reiserfs en su dia, y ya nos han abandonado...
Sasto. Yo sigo el ciclo de la SLES/SLED: hasta que no pongan el ext4 como predeterminado en esas dos, yo tampoco >:-)
Es decir, que aún tengo 5 años de reiserfs... salvo que pete miserablemente con la 11.2 O:-)
Todavia sigues con Reiserfs? Yo la verdad que lo extraño, y más cuando tengo menos de media hora para chequear loes emilios, enciendo la pc, y justo ese dia se le da por hacer el fsck periódico, y se comen la media hora que tenía. Es de suponer que el ext4 ya no tiene mas el maldito fsck periódico del ext2 y 3, y en perfomance se acerque al Reiserfs, o me equivoco? Salu2 -- 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
El 2009-08-10 a las 09:11 -0300, Juan Erbes escribió:
El 10 de agosto de 2009 09:03, Camaleón escribió:
Eso mismo pienso yo... alguna partición de datos "fungibles", no más.
*** http://en.opensuse.org/OpenSUSE_11.2#Filesystems_and_Partitioning
Filesystems and Partitioning
- The ext4 filesystem is the new default filesystem for new installations.
Es que esta gente cuando dice eso, es como para fiarse. También dijeron eso del reiserfs en su dia, y ya nos han abandonado...
Sasto. Yo sigo el ciclo de la SLES/SLED: hasta que no pongan el ext4 como predeterminado en esas dos, yo tampoco >:-)
Es decir, que aún tengo 5 años de reiserfs... salvo que pete miserablemente con la 11.2 O:-)
Todavia sigues con Reiserfs?
Sí, ten en cuenta que estoy con la 10.3. Aunque mi idea es seguir con ReiserFS en la 11.2, salvo que aún bug me lo impida.
Yo la verdad que lo extraño, y más cuando tengo menos de media hora para chequear loes emilios, enciendo la pc, y justo ese dia se le da por hacer el fsck periódico, y se comen la media hora que tenía.
Bueno, eso se puede cambiar ¿no? con el tune2fs creo que era.
Es de suponer que el ext4 ya no tiene mas el maldito fsck periódico del ext2 y 3, y en perfomance se acerque al Reiserfs, o me equivoco?
Lo del "fsck" no lo sé :-? Pero aunque el ext4 mostrara unos "benchmarks" excelentes, tampoco lo pondría. No hasta que lleve en el mercado unos años y se le haga el "rodaje" pertinente :-) Saludos, -- Camaleón -- 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
Hola :) On Monday 10 August 2009 14:11:05 Juan Erbes wrote:
El 10 de agosto de 2009 09:03, Camale�n
escribi�: El 2009-08-10 a las 13:43 +0200, Carlos E. R. escribi�:
El 2009-08-10 a las 08:21 +0200, Camale�n escribi�:
El 2009-08-09 a las 22:08 -0300, Juan Erbes escribi�:
[...]
Es decir, que a�n tengo 5 a�os de reiserfs... salvo que pete miserablemente con la 11.2 O:-)
Todavia sigues con Reiserfs?
Yo la verdad que lo extra�o, y m�s cuando tengo menos de media hora para chequear loes emilios, enciendo la pc, y justo ese dia se le da por hacer el fsck peri�dico, y se comen la media hora que ten�a.
Es de suponer que el ext4 ya no tiene mas el maldito fsck peri�dico del ext2 y 3, y en perfomance se acerque al Reiserfs, o me equivoco?
Si mal no recuerdo, con tune2fs puedes quitar lo del fsck en ext2 y 3. 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
Hola :) On Sunday 09 August 2009 19:30:17 Camaleón wrote:
El 2009-08-09 a las 19:06 +0200, Rafa Grimán escribió:
On Thursday 06 August 2009 23:02:26 Camaleón wrote:
1. Hacer el fsck del volumen ext3 en mi equipo (B) demora 5 minutos. Me llevé un susto de cuidado cuando me pasó hace unos días.
¿5 minutos? Eso es poco. A la gente del repositorio del kernel (el oficial) le tardó horas una vez que se les fué la luz.
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?
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 ;)
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 ;)
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.
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 :)
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), ... 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
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? :-?
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:-)
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? >:-?
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? :-? 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 Saludos, -- Camaleón -- 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
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
El 2009-08-15 a las 21:55 +0200, Rafa Grimán escribió:
On Saturday 15 August 2009 21:29:48 Camaleón wrote:
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
Ah O:-). Voy: hpc02@stthpc:~> df -ih /home/hpc02/data S.ficheros Nodos-i NUsados NLibres NUso% Montado en /dev/sdb1 59M 208 59M 1% /home/hpc02/data
Eso es cierto.
Yo quiero un MPASBAF ("Multi-Purpose-Anti-Shutdown-Break-All-Filesystem" O:-)
Yo quiero que me toque la lotería ;)
Jo, no ha colado :-P
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 :)
Ah, vale :-)
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.
Me lo temía.
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 ;)
Sí, bueno, el espacio ocupado en disco es de 252 GB., aún es "backupeable" :-) Saludos, -- Camaleón -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-08-03 a las 10:49 +0200, Rafa Griman escribió:
Hola :)
Me lo imprimí para poder leerlo en ratos de espera en el curro.
<http://www.linuxconfig.org/choosing-the-right-linux-file-system-layout-using... a-top-bottom-process>
Un tanto rebuscado el sistema, ¿no? Y complejo de reparar salvo que te lo sepas al dedillo. ¿Realmente trae ventajas? Y el afinamiento concreto de cada sistema de ficheros para obtener la ventaja en escritura aleatoria contra secuencial (por poner uno de los casos) no lo cuenta. No cuenta los ajustes que hay que hacerle al XFS para conseguir tal o cual afinamiento.
http://www.ibm.com/developerworks/linux/library/l-gpt/index.html
O sea, que no lo podemos usar todavía, salvo que realmente lo necesitemos. Si el PC no sporta el nuevo tipo de bios (efi?) pues tienes que tener una primera partición grub con mbr además de las gpt - y encima te cuentan que al menos una de las aplicaciones de manejo de particiones gpt se carga el mbr cada vez que lo usas, con lo que tienes que volver a instalar grub. Bastantes aplicaciones no soportan gpt, como por ejemplo, el fdisk. Y las que lo soportan no lo hacen completo todas... A mi me gusta GPT, sobre todo por lo del centenar de particiones primarias. Eso me _encanta_. Pero una cosa es la definición, y otra la implementación, el uso... y eso está muy verde. Sin contar que no cuenta que sistemas operativos lo soporta, aparte del linux (que no está claro, nos deja a nosotros comprobarlo distro por distro, y versión). Si haces double boot, ¿arrancaría el 98, 2K, xp, vista, 7? ¿Que parches necesitan, si es que existen? Bastante verde todavía... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqEUiQACgkQtTMYHG2NR9V9AgCfTgdXtcDQ3HIltNm9RY/6z3Ys 9w4An0fOzPd9usNXG9J4jqdiK2YKyXQa =T42m -----END PGP SIGNATURE-----
Hola :) On Thursday 13 August 2009 19:49:22 Carlos E. R. wrote:
El 2009-08-03 a las 10:49 +0200, Rafa Griman escribió:
Hola :)
Me lo imprimí para poder leerlo en ratos de espera en el curro.
<http://www.linuxconfig.org/choosing-the-right-linux-file-system-layout-u sing- a-top-bottom-process>
Un tanto rebuscado el sistema, ¿no? Y complejo de reparar salvo que te lo sepas al dedillo. ¿Realmente trae ventajas? Y el afinamiento concreto de cada sistema de ficheros para obtener la ventaja en escritura aleatoria contra secuencial (por poner uno de los casos) no lo cuenta. No cuenta los ajustes que hay que hacerle al XFS para conseguir tal o cual afinamiento.
Como siempre en el mundo de la informática, yo me lo tomo más ocmo un ejemplo, ideas a tener en cuenta, ... No como una verdad absoluta ;)
http://www.ibm.com/developerworks/linux/library/l-gpt/index.html
O sea, que no lo podemos usar todavía, salvo que realmente lo necesitemos. Si el PC no sporta el nuevo tipo de bios (efi?) pues tienes que tener una primera partición grub con mbr además de las gpt - y encima te cuentan que al menos una de las aplicaciones de manejo de particiones gpt se carga el mbr cada vez que lo usas, con lo que tienes que volver a instalar grub.
Bastantes aplicaciones no soportan gpt, como por ejemplo, el fdisk. Y las que lo soportan no lo hacen completo todas...
A mi me gusta GPT, sobre todo por lo del centenar de particiones primarias. Eso me _encanta_. Pero una cosa es la definición, y otra la implementación, el uso... y eso está muy verde.
Sin contar que no cuenta que sistemas operativos lo soporta, aparte del linux (que no está claro, nos deja a nosotros comprobarlo distro por distro, y versión). Si haces double boot, ¿arrancaría el 98, 2K, xp, vista, 7? ¿Que parches necesitan, si es que existen?
Bastante verde todavía...
Sip. 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
participants (5)
-
Camaleón
-
Carlos E. R.
-
Carlos Lorenzo Matés
-
Juan Erbes
-
Rafa Griman