señala un error en las pruebas, http://www.debian-administration.org/articles/388#comment_3 pero tener una combinacion de FS es lo mejor. XFS para particiones con alto grado de variabilidad y otro Sistema de Archivos para binarios . Yo uso ext3 para / y XFS para /home, y hasta ahora no he tenido problemas =) Carlos A. PS: no olvidar el FAT32 para mover archivos con el XP

From: "francisco F." To: suse-linux-s@suse.com Subject: Re: [suse-linux-s] OpenSUSE abandona ReiserFS Date: Wed, 4 Oct 2006 08:51:11 +0200

El Miércoles, 4 de Octubre de 2006 05:28, Jaime Andres Velez Osorio escribió:

...

.. solo para comentar eso que lei en vivalinux.com.ar... una lastima reiser ha alcanzado gran estabilidad por lo que leo de reiser es mucho mas innovador que ext3., mi...ercoles caigo en cuenta que mis particiones estan en reiser.. si se que continuara el soporte a reiser, pero bueno, como se le va a hacer larga vida a reiser. (por lo menos en mis particiones) la pagina http://www.vivalinux.com.ar/distros/open-suse-abandona-reiserfs.html

Jaime v Una de comparativas http://www.debian-administration.org/articles/388

aaaa ooooo aggggggggggggggggggggggggggggg y ahora que hago yo? Menos mal que aun no me han traido el servidor nuevo.

-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Hola :) El Sábado, 7 de Octubre de 2006 18:26, Juan Erbes escribió:

Esta semana se volvi� a discutir el tema en la lista de desarrollo de opensuse y a XFS ni lo mencionanaban como posible alternativa en esta ultima semana.

Esto es porque el código es algo complejo y los desarrolladores son principalmente de SGI, la Comunidad ha entrado poco en el desarrollo de XFS.

Toda la apuesta est� en OCFS2. Sin embargo, el mes pasado se toc� el tema, y una de las razones que no lo toman muy en cuenta, es que consume mucha cpu y es lento

Esto ya lo comenté en un correo anterior. Se debe a que el mercado al que iba destinado y las máquinas a las que iba destinado eran de gran capacidad. Teniendo en cuenta la capacidad de los procesadores de hoy en día (dual cores) y el aumento de los anchos de banda de los buses, no creo que esto sea mucho problema ;) Rafa

comparado con otros FS:

...

Copying 260 MByte from Partiton A to Partition B

Ext3 ReiserFS XFS SL 10.1 53s 65s 210s Dapper 54s 71s 200s

----- XFS scales best in terms of parallelization (number of CPUs/cores) but is a very bad choice for a typical desktop, also because it is said to use more CPU time than the other filesystems. - From what I've read, XFS is prolly the best option e.g. for streaming large files when you have a lot of CPUs, but it scales down very badly.

http://www.mail-archive.com/opensuse-factory@opensuse.org/msg04281.html

Salu2

El 7/10/06, Ryouga Hibiki escribi�:

...

se�ala un error en las pruebas, http://www.debian-administration.org/articles/388#comment_3

pero tener una combinacion de FS es lo mejor. XFS para particiones con alto grado de variabilidad y otro Sistema de Archivos para binarios . Yo uso ext3 para / y XFS para /home, y hasta ahora no he tenido problemas =)

Carlos A.

PS: no olvidar el FAT32 para mover archivos con el XP

...

From: "francisco F." To: suse-linux-s@suse.com Subject: Re: [suse-linux-s] OpenSUSE abandona ReiserFS Date: Wed, 4 Oct 2006 08:51:11 +0200

El Mi�rcoles, 4 de Octubre de 2006 05:28, Jaime Andres Velez Osorio

escribi�:

...

.. solo para comentar eso que lei en vivalinux.com.ar... una lastima reiser ha alcanzado gran estabilidad por lo que leo de

reiser

...

es mucho mas innovador que ext3., mi...ercoles caigo en cuenta que mis particiones estan en reiser.. si se que continuara el soporte a reiser, pero bueno, como se le va a hacer larga vida a reiser. (por lo menos en

mis

...

particiones) la pagina http://www.vivalinux.com.ar/distros/open-suse-abandona-reiserfs.html

Jaime v

Una de comparativas http://www.debian-administration.org/articles/388

aaaa ooooo aggggggggggggggggggggggggggggg y ahora que hago yo? Menos mal que aun no me han traido el servidor nuevo.

-- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

-- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

-- "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

Hola :) El Miércoles, 4 de Octubre de 2006 09:34, Camaleón escribió:

El 4/10/06, Jaime Andres Velez Osorio escribi�:

...

la pagina http://www.vivalinux.com.ar/distros/open-suse-abandona-reiserfs.html

Algo escuch� en las listas de Opensuse sobre la decisi�n de abandonar ReiserFS en las pr�ximas versiones...

Pues entre el abandono de ReiserFS y este otro reporte* donde no sale muy bien parado la versi�n de 64 bits, parece que no doy ni una... eleg� SuSE 64 bits con ReiserFS :-/

* http://www.worlds-fastest.com/

No nos preocupemos porque ... tenemos XFS ;) Ahora en serio, no seamos tan alarmistas. El que lleva Reiser en SUSE envió un correo diciendo que la versión 3 de reiserfs no recibe atención por casi nadie (creo que comentó que en total eran 4 personas desarrollando) y que no se añadían mejoras ni novedades. Comentó que todo el esfuerzo se encuentra en reiserfs4 por lo que la idea es que SUSE deje la versión 3, pero no la 4. HTH 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-04 a las 10:30 +0200, Rafa Grimán escribió:

El link donde lo explican todo:

http://lists.opensuse.org/opensuse-factory/2006-09/msg00542.html

Y es una propuesta, no una decisión. Éste párrafo es interesante aclaratorio: | This proposal is only to change the default file system. Ext3 does what | most users need well. It's well tested, is fairly easy to understand, | and is extremely well supported by the community. Users who have | workloads that require, or are even just curious about, other file | systems, are always welcome to use them. I'm not looking to, or at all | interested in, removing file systems from the list of possibilities. | ReiserFS will still be available, as will XFS. Traducción: Esta propuesta es solo para cambiar el sistema de ficheros por defecto. Ext3 hace bien lo que la mayoría de los usuarios necesita. Está bien comprobada, es bastante fácil de entender, y está extremadamente bien soportada por la comunidad. Los usuarios que tienen una carga de trabajo que requiere, o incluso simplemente son curiosos acerca de, otros sistemas de ficheros, son siempre bienvenidos a usarlos. No estoy mirando a, o en modo alguno interesado en, eliminar sistemas de ficheros de la lista de posibilidades. ReiserFS seguirá estando disponible, como lo será XFS. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFI3qctTMYHG2NR9URAt42AJ96N4eKN9Ebi7Ge4+MqAyXNCaeSLACfUXMo WinXnoJFoI+qS6y7dREOM8M= =e7n+ -----END PGP SIGNATURE-----

El 4/10/06, Carlos E. R. escribió:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2006-10-04 a las 09:34 +0200, Camaleón escribió:

...

...

la pagina http://www.vivalinux.com.ar/distros/open-suse-abandona-reiserfs.html

Algo escuché en las listas de Opensuse sobre la decisión de abandonar ReiserFS en las próximas versiones...

Abandonar, abandonar... entre todos los enlaces que habeis puesto, no veo yo que digan que vayan a abandonar el reiserfs. Lo que dicen es que ya no va a ser el sistema de ficheros por defecto de las instalaciones nuevas.

mmmm... o sea, que para el usuario medio/avanzado el soporte a ReiserFS continuara alla.. uno lo podra selecionar igual que XFS,ext2/3 entre otros !!! mmm.. en todo caso, recuerdo que hace un tiempo atras hubo una muy buena pelea/discussion en LKML (http://lkml.org/lkml/2005/9/16/121) sobre el tema de ReiserFS4 y el kernel !!! mmm.. no sabria decir en que estaran ahora.. pero existia (segun declaracciones de personas de peso) la posibilidad de que ReiserFS no fuera incluydo oficialmente en los siguientes kernels !!!! esto si, seria malo.. ya que para utilizarlo seria necesario aplicar parches y recompilar el kernel !!!! uuugggghhhh Pero, por otro lado... como alguien ha comentado mas abajo.. acredito que suse siempre mantendrar/dara soporte a ReiserFS en sus kernels !!! y IMHO, pienso que es una muy buena decision !!!

¿Porqué? Pues no está muy claro, pero fundamentalmente parece ser que porque está estancado. La versión 3 está en modo mantenimiento, no se va a desarrollar nada para ella; todo el progreso se invierte en la versión 4, que promete, pero no llega todavía, y tiene pocos desarrolladores. Es muy interesante, pero tiene bastantes peros en la práctica. Y "detalles" importantes como que no hay manera de convertir de la 3 a la 4 una partición, la tremenda dificultad que tiene de hacer un fsck-reiserfs-4...

Ahora bien, el hecho de que la versión 3 esté estancada tiene otra lectura. El señor Reiser entregó la versión 3 a la comunidad, a los desarrolladores del kernel; depende de ellos. Él y su equipo se pasó por completo a la 4. Si la versión 3 no avanza pues es porque al resto de deasrrolladores tampoco le interesa - y de hecho, parece ser que sólo trabajan en ella dos o tres personas, y en SuSE. Pero tampoco habrá desarrolladores precisamente por la decisión de hacer la versión 3 y 4 incompatibles, no hay un camnino de progreso entre ambas, al contrario de lo que pasa en ext2/3/4.

Es decir, reiserfs se estanca por "política", por tomar la decisión equivocada en un momento dado...

mmm.. pero hombre, se ReiserFS4 es un codigo escrito case que totalmente de zero !!! mantener compatibilidad (segun eh leido) seria algo que tomaria mucho tiempo.. y lo desarrolladores de ReiserFS preferiron hacer algo mas rapido y mejor !!! por ejemplo, se supone que los problemas que mencionaste arriba, ya no afectaran/existiran en la version 4. en todo caso.. concuerdo que es una mala politica esta de la imcopatibilidad.. me suena mucho a guia de desarollo de otras empresas "privadas" y esto molesta a muchos. Talvez huberia sido mejor (marketing ???) iniciar un proyecto nuevo !!! [...]

A efectos prácticos, pues el reiserfs sigue siendo un sistema de ficheros válido, y con ventajas innegables en algunos casos: puedes poner millones de ficheros en un único directorio, y funciona de maravilla con ficheros más pequeños que el tamaño de bloque aprovechando el espacio. Esas ventajas las tenía antes y las seguirá teniendo.

concuerdo !!! :-)

Y ya veremos que pasa con el ext4 :-)

promete harto, cierto ??? :-) salu2 -- -- Victor Hugo dos Santos Linux Counter #224399

Hola :) El Miércoles, 4 de Octubre de 2006 18:36, Victor Hugo dos Santos escribió:

El 4/10/06, Carlos E. R. escribi�:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2006-10-04 a las 09:34 +0200, Camale�n escribi�:

...

...

la pagina http://www.vivalinux.com.ar/distros/open-suse-abandona-reiserfs.html

Algo escuch� en las listas de Opensuse sobre la decisi�n de abandonar ReiserFS en las pr�ximas versiones...

Abandonar, abandonar... entre todos los enlaces que habeis puesto, no veo yo que digan que vayan a abandonar el reiserfs. Lo que dicen es que ya no va a ser el sistema de ficheros por defecto de las instalaciones nuevas.

mmmm... o sea, que para el usuario medio/avanzado el soporte a ReiserFS continuara alla.. uno lo podra selecionar igual que XFS,ext2/3 entre otros !!!

mmm.. en todo caso, recuerdo que hace un tiempo atras hubo una muy buena pelea/discussion en LKML (http://lkml.org/lkml/2005/9/16/121) sobre el tema de ReiserFS4 y el kernel !!!

Es que hay unas "reglas" a la hora de desarrollar para el kernel. Los de Namesys no han seguido estas reglas alegando que su código está más optimizado y que segiur las "reglas" del kenrel daría lugar a un rendimiento peor ... Esto no lo ha demostrado nadie. ¿Quién tiene razón? ... Pues no lo sé :(

mmm.. no sabria decir en que estaran ahora.. pero existia (segun declaracciones de personas de peso) la posibilidad de que ReiserFS no fuera incluydo oficialmente en los siguientes kernels !!!! esto si, seria malo.. ya que para utilizarlo seria necesario aplicar parches y recompilar el kernel !!!! uuugggghhhh

Según el actual "mantenedor", Andrew Morton. Hasta que no sigan las "reglas" del kernel ... no entrará resiserfs v4.

Pero, por otro lado... como alguien ha comentado mas abajo.. acredito que suse siempre mantendrar/dara soporte a ReiserFS en sus kernels !!! y IMHO, pienso que es una muy buena decision !!!

...

�Porqu�? Pues no est� muy claro, pero fundamentalmente parece ser que porque est� estancado. La versi�n 3 est� en modo mantenimiento, no se va a desarrollar nada para ella; todo el progreso se invierte en la versi�n 4, que promete, pero no llega todav�a, y tiene pocos desarrolladores. Es muy interesante, pero tiene bastantes peros en la pr�ctica. Y "detalles" importantes como que no hay manera de convertir de la 3 a la 4 una partici�n, la tremenda dificultad que tiene de hacer un fsck-reiserfs-4...

Ahora bien, el hecho de que la versi�n 3 est� estancada tiene otra lectura. El se�or Reiser entreg� la versi�n 3 a la comunidad, a los desarrolladores del kernel; depende de ellos. �l y su equipo se pas� por completo a la 4. Si la versi�n 3 no avanza pues es porque al resto de deasrrolladores tampoco le interesa - y de hecho, parece ser que s�lo trabajan en ella dos o tres personas, y en SuSE. Pero tampoco habr� desarrolladores precisamente por la decisi�n de hacer la versi�n 3 y 4 incompatibles, no hay un camnino de progreso entre ambas, al contrario de lo que pasa en ext2/3/4.

Es decir, reiserfs se estanca por "pol�tica", por tomar la decisi�n equivocada en un momento dado...

mmm.. pero hombre, se ReiserFS4 es un codigo escrito case que totalmente de zero !!! mantener compatibilidad (segun eh leido) seria algo que tomaria mucho tiempo.. y lo desarrolladores de ReiserFS preferiron hacer algo mas rapido y mejor !!! por ejemplo, se supone que los problemas que mencionaste arriba, ya no afectaran/existiran en la version 4.

en todo caso.. concuerdo que es una mala politica esta de la imcopatibilidad.. me suena mucho a guia de desarollo de otras empresas "privadas" y esto molesta a muchos. Talvez huberia sido mejor (marketing ???) iniciar un proyecto nuevo !!!

Tengamos en cuenta que reiserfs v4 es otro sistema d efichreos nuevo y diferente. Es como ext3 y FAT, no se puede pasar de uno a otro. Personalmente creo que lo tendrían que haber llamado de otra manera para evitar confusiones.

...

A efectos pr�cticos, pues el reiserfs sigue siendo un sistema de ficheros v�lido, y con ventajas innegables en algunos casos: puedes poner millones de ficheros en un �nico directorio, y funciona de maravilla con ficheros m�s peque�os que el tama�o de bloque aprovechando el espacio. Esas ventajas las ten�a antes y las seguir� teniendo.

concuerdo !!! :-)

...

Y ya veremos que pasa con el ext4 :-)

promete harto, cierto ??? :-)

Eso parece ;) 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

2006/10/6, Victor Hugo dos Santos :

2006/10/5, Rafa Grimán :

...

Hola :)

[...]

...

...

mmm.. no sabria decir en que estaran ahora.. pero existia (segun declaracciones de personas de peso) la posibilidad de que ReiserFS no fuera incluydo oficialmente en los siguientes kernels !!!! esto si, seria malo.. ya que para utilizarlo seria necesario aplicar parches y recompilar el kernel !!!! uuugggghhhh

Según el actual "mantenedor", Andrew Morton. Hasta que no sigan las "reglas" del kernel ... no entrará resiserfs v4.

uufff.. se continua asi, esto si sera muy malo !!! :-(

Bueno, pero no hay que ser tan pesimista, porque ya en la versión 2.6.16 del kernel ya está OCFS2. Los de Namesys, no se quisieron abrir a la comunidad de software libre, ni a las reglas del kernel. Creo que lo mejor que pueden hacer todas las distros es dejarlos de lado, a los de Reiserfs. http://oss.oracle.com/projects/ocfs2/ Esperemos que OCFS2 madure pronto. http://www.mail-archive.com/opensuse-factory@opensuse.org/msg04247.html Salu2

Hola :) El Viernes, 6 de Octubre de 2006 18:42, Victor Hugo dos Santos escribió:

2006/10/5, Rafa Grim�n :

...

Hola :)

[...]

...

...

mmm.. no sabria decir en que estaran ahora.. pero existia (segun declaracciones de personas de peso) la posibilidad de que ReiserFS no fuera incluydo oficialmente en los siguientes kernels !!!! esto si, seria malo.. ya que para utilizarlo seria necesario aplicar parches y recompilar el kernel !!!! uuugggghhhh

Seg�n el actual "mantenedor", Andrew Morton. Hasta que no sigan las "reglas" del kernel ... no entrar� resiserfs v4.

uufff.. se continua asi, esto si sera muy malo !!! :-(

Yo creo que no, si hay unos estándares ... deberíamos seguirlos ;) 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

Hola :) El Miércoles, 4 de Octubre de 2006 12:13, aux escribió:

El Mi�rcoles, 4 de Octubre de 2006 05:28, Jaime Andres Velez Osorio escribi�:

...

.. solo para comentar eso que lei en vivalinux.com.ar... una lastima reiser ha alcanzado gran estabilidad por lo que leo de reiser es mucho mas innovador que ext3., mi...ercoles caigo en cuenta que mis particiones estan en reiser.. si se que continuara el soporte a reiser, pero bueno, como se le va a hacer larga vida a reiser. (por lo menos en mis particiones) la pagina http://www.vivalinux.com.ar/distros/open-suse-abandona-reiserfs.html

Jaime v

[...] A partir de su pr�xima versi�n las instalaciones de OpenSUSE ofrecer�n al veterano pero probado y compatible hacia atr�s ext3 como su sistema de archivos preferido. [...]

Parece que vayamos para atras y no hacia adelante. Entre esto de ext3 y el super zen-BUGdater esto va de mal en peor.

Hombre, yo no veo tan malo que hayan pasado del reiserfs v3 al ext3 como filesystem por defecto. Yo he tenido más problemas con reiserfs v3 que con ext3. Además, si no hay desarrolladores ni interés por el propio Namesys ... veo bien que lo dejen (aka un problema menos ;) Además, seguimos teniendo XFS ;)

SUSE ya no es lo que era, tendra la culpa novell?

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-04 a las 13:54 +0200, aux escribió:

Veo en muchos benchmarks que sale muy bien parado siempre XFS. Porque no se ha adoptado XFS por defecto?

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. Pues en el hilo mencionado antes por Rafa lo explican. De memoria, ext3 tiene muchísimo más respaldo en la comunidad linux, más mantenimiento y desarrollo. Es muy facil de comprender, y se adapta perfectamente al uso general que la mayoría de los usuarios necesitan (traducido: le dará menos guerra al servicio de soporte al cliente de SuSE). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFI6iDtTMYHG2NR9URAp43AKCT9vzh3v1kUwsNJLfhNywtcjXlUQCeP58v ssIUsq+wrflRBdpeTf7k1n8= =lQ5v -----END PGP SIGNATURE-----

-----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-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-04 a las 16:59 +0200, Rafa Grimán escribió: (XFS)

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 ;)

Ah... eso explica algunas cosas.

No sabía que MythTV te aconsejaba XFS, es bueno saberlo ;)

Unlike a typical filesystem, a MythTV video partition is usually a very large filesystem filled with a fairly small number of large files. Filesystem I/O is usually not an issue, even in multi-tuner and/or multi-frontend setups. There is however, one aspect of filesystem performance that can have a bearing on the performance of MythTV. In Linux, deleting a file will utilize I/O bandwidth until the deletion has been completed. If deleting the file takes long enough, the video capture buffer may overrun, thereby resulting in dropped frames. Some filesystems are faster at deleting files than others and, for multi-gigbyte MythTV video files, these differences can be significant. Lo cual es una cosa que me llama mucho la atención, porque yo el único sistema de ficheros que conozco en profundidad es el fat, y ahí borrar un fichero son dos operaciones de disco: marcar como borrada la entrada del directorio, y alterar la tabla de adjudicación de ficheros (fat), que se calcula en memoria y se escribe de un golpe - bueno, se escribía. Es una lista ligada mantenida en un array de tamaño fijo, o sea, de acceso rápido. 22.4.4. JFS JFS (Journaling File System) is a journaling filesystem originally developed by IBM for AIX which was later released as open source. While not as common as Ext3 or ReiserFS, it is distributed with RedHat 9 (RH9) and Fedora Core 1 (RHFC1) and Mandrake as well as other distros. According to tests, JFS is the file deletion speed king, deleting virtually any file in under one second, even files as large as 10 gigabytes. 2.4.5. XFS XFS is a journaling file system originally developed by SGI for Irix, and later released as open source. While not a part of the default RedHat Linux 9 or Fedora Core installation (although it is a part of Mandrake and Fedora Core 2), it can be easily installed via ATrpms. XFS provides deletion speeds for large files only slightly slower than JFS. According to the test results shown at (http://aurora.zemris.fer.hr/filesystems/big.html http://aurora.zemris.fer.hr/filesystems/big.html), XFS provide higher I/O rates than JFS, albeit at a higher CPU loading. This may cause issues if you do not have the spare CPU capacity to handle XFS, potentially leading to dropped frames. Lo que no se es porqué los de mythtv no usan una partición raw para el buffer circular de recepción/visionado. Bueno, en realidad recomendaban JFS, pero prefiero XFS. No iba a dedicarle una partición gigante a él solito, y sólo para probarlo. ... ... Una serie de notas muy interesantes que me apunto :-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFI/94tTMYHG2NR9URAkEiAJ0fJEqD1YGmeHghTXC2r6HuI1XSWQCeIq59 BMw83jNS2EAs/07XFJhJOkY= =Et/+ -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-05 a las 10:38 +0200, Rafa Grimán escribió:

...

...

No sab[ed]a que MythTV te aconsejaba XFS, es bueno saberlo ;)

Unlike a typical filesystem, a MythTV video partition is usually a very large filesystem filled with a fairly small number of large files. Filesystem I/O is usually not an issue, even in multi-tuner and/or multi-frontend setups.

There is however, one aspect of filesystem performance that can have a bearing on the performance of MythTV. In Linux, deleting a file will utilize I/O bandwidth until the deletion has been completed. If deleting the file takes long enough, the video capture buffer may overrun, thereby resulting in dropped frames. Some filesystems are faster at deleting files than others and, for multi-gigbyte MythTV video files, these differences can be significant.

Lo cual es una cosa que me llama mucho la atención, porque yo el único sistema de ficheros que conozco en profundidad es el fat, y ahí borrar un fichero son dos operaciones de disco: marcar como borrada la entrada del directorio, y alterar la tabla de adjudicación de ficheros (fat), que se calcula en memoria y se escribe de un golpe - bueno, se escribía. Es una lista ligada mantenida en un array de tamaño fijo, o sea, de acceso rápido.

Pues no te sé decir ...

<pensando> ... yo creo que el problema no es borrar un fichero ya que en Linux se marca como borrado, pero no se tocan los bloques de datos. El problema es entrar en los directorios y borrar los miles (o millones) de ficheros que haya en ese directorio. En este último caso, el algoritmo de acceso y lectura de ficheros en un directorio, es el cuello de botella. Si tu filesystem es bueno manejando árboles de directorios, ganarás mucho.

Otra cosa a tener en cuenta es que XFS cachea muchos datos por lo que algunas operaciones se ven mejoradas y otras no. </pensando>

No, se refieren a borrar un único fichero grande. Observa, voy a probar con 4.4 GiB: *** ext3: (disco de 7200 rpm, 160 GB) (rw,noatime,acl,user_xattr) nimrodel:~ # time dd if=/dev/zero of=/bigfile bs=1M count=4482 4482+0 records in 4482+0 records out 4699717632 bytes (4.7 GB) copied, 154.423 seconds, 30.4 MB/s real 2m34.808s user 0m0.052s sys 0m20.909s nimrodel:~ # time rm /bigfile real 0m4.007s <=== user 0m0.004s sys 0m0.700s *** reiserfs: (rw,acl,user_xattr) nimrodel:~ # time dd if=/dev/zero of=/xtr/bigfile bs=1M count=4482 ; time rm /xtr/bigfile 4482+0 records in 4482+0 records out 4699717632 bytes (4.7 GB) copied, 104.318 seconds, 45.1 MB/s real 1m44.433s user 0m0.032s sys 0m20.525s real 0m1.256s <=== user 0m0.000s sys 0m1.044s *** xfs: (rw,noatime) nimrodel:~ # time dd if=/dev/zero of=/other/bigfile bs=1M count=4482 4482+0 records in 4482+0 records out 4699717632 bytes (4.7 GB) copied, 121.025 seconds, 38.8 MB/s real 2m1.054s user 0m0.060s sys 0m19.721s nimrodel:~ # ls -lh /other/bigfile -rw-r--r-- 1 root root 4.4G Oct 5 13:14 /other/bigfile nimrodel:~ # time rm /other/bigfile real 0m0.484s <=== user 0m0.000s sys 0m0.220s Observa que xfs borra en medio segundo los 4.4 GiB y ext3 tarda 4 segundos. El reiserfs es bastante rápido tanto en la creacion como el borrado, pero sigue ganando xfs. (Me he convertido a los iB ;-) ) Si se observa los tiempos de cpu empleados en el borrado (.7 ext3, .22 xfs) se deduce que el tiempo gastado en ext3 es mayormente tiempo de espera al disco, no tiempo de computación.

[...]

...

Lo que no se es porqué los de mythtv no usan una partición raw para el buffer circular de recepción/visionado.

El usar raw implica "ignorar" las cachés y los buffers y acceder directamente al dispositivo. Esto para vídeo no es tan bueno porque lo que te interesa es que el streaming se haga desde memoria (más rápido y menos latencia) que desde disco. Además, si dos procesos están accediendo a dos sectores diferentes de disco ... el rendimiento (en el caso de raw) caerá vertiginosamente porque el cabezal tiene que bascular mucho :(

Pues curiosamente los de xine creo que usan raw precisamente para evitar el uso de la cache, porque al ser un fichero enorme que se lee una única vez no tiene sentido guardarlo en memoria que es más util para otros ficheros del proceso normal del sistema, que se enlentece globalmente. Creo que en esos casos es más eficaz una caché dedicada al proceso en cuestión, o un bufer de lectura grande; es decir, limitar el tamaño de caché dedicado a ese proceso. En mis tiempos que me ganaba los garbanzos programando en dos lo noté: la copia de ficheros era muy rápida si a la función de lectura de un fichero le asignaba un bufer de 64 KiB (lo normal creo que era menos de un k). En el caso de tener un cache de sistema, el fichero es primero leido en un golpe grande (o varios) al caché del sistema, y de ahí se copia al bufer de lectura, y de ahí una tercera vez a la memoria del programa (las dos ultimas se podrían juntar, en teoría). Sin caché de sistema te ahorras un movimiento de memoria. O dicho de otra forma, el programador del proceso conoce el tipo de entrada/salida que va a necesitar y se puede optimizar. El programador de la caché no: puede orientarla por sectores contiguos de disco, por ficheros completos, por peticiones de procesos, mezclas, algoritmos inteligentes... y todo porque no sabe realmente que es lo que le van a pedir.

...

Bueno, en realidad recomendaban JFS, pero prefiero XFS. No iba a dedicarle una partición gigante a él solito, y sólo para probarlo.

Yo estuve un tiempo probando JFS y no me gustó una cosa: es poco fiable si se compila como módulo :( Si quieres que sea fiable y no perder datos ... inclúyelo en el kernel !!

Lo recuerdo, estuvimos hablando de eso aquí :-) Y puede dar guerra si a SuSE se le ocurre no ponerlo en el disco de rescate. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFJPGetTMYHG2NR9URAkwIAKCY30mxyBdA/NR9XAImmgQepaIiuACfRWuy K2tkZUUO25ecUlNUrttjniw= =p0Sr -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-05 a las 17:21 +0200, Rafa Grimán escribió:

...

Pues curiosamente los de xine creo que usan raw precisamente para evitar el uso de la cache, porque al ser un fichero enorme que se lee una [fa]nica vez no tiene sentido guardarlo en memoria que es m[e1]s util para otros

Siempre y cuando hablemos de un proceso que accede a disco, ¿qué ocurre si son muchos usuarios que acceden a vídeo en tiempo real? Pues que no es sostenible esto. Necesitas cachear todo lo que puedas a memoria porque los cabezales están como locos saltando de un vídeo a otro para satisfacer las peticiones del resto de usuarios y procesos.

Es que es distinto si estás visionando un (uno) video en un ordenador, o si estás procesando video. En el momento que puedas necesitar volver a leer un mismo dato obviamente el caché ahorra trabajo. Pero si simplemente estás viendo una película, mejor no usar el caché de sistema.

...

O dicho de otra forma, el programador del proceso conoce el tipo de entrada/salida que va a necesitar y se puede optimizar. El programador de la cach[e9] no: puede orientarla por sectores contiguos de disco, por ficheros completos, por peticiones de procesos, mezclas, algoritmos inteligentes... y todo porque no sabe realmente que es lo que le van a pedir.

Eso es otra historia: hoy en día el desarrollador de aplicaciones se basa ne lo que hacen los desarrolladores del kernel, pero no piden que se implementen determinadas cosas. Por ejemplo, en Linux, el tamaño de bloque máximo son 16 KB (si no recuerdo mal), ¿qué ocurre si mi aplicación funciona mejor leyendo bloques más grandes?

¿Solo 16Ks? En Dos podía hacer lecturas/escrituras de ficheros de datos con tampón dedicado de 64Kb: y no era más porque eso era un segmento. Que raro. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFJUymtTMYHG2NR9URAhpHAJ469ouSHvkcKFONpuFoLfYf2Uqv2gCgk7GM 8s1y7DWRyeodRR2A8CIu8ks= =egUU -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-04 a las 23:42 -0300, Juan Erbes escribió:

Ya hay discos de estado solido, y creo que ese es el paso logico. La mecania se gasta y falla, la electrónica es mas resistente. http://www.adtron.com/landing/adtron-ssd-adword.html?gclid=CPmi7JL04IcCFUUNO... http://www.bitmicro.com/products_edisksan_2U_JBOD_fc.php

Los conozco desde el año 96 o así, pero del tamaño floppy: es decir, substituyendo a un floppy en ordenadores industriales sin disco. Podías poner dos floppys, pero no tenían de más capacidad - claro, que entonces 64 megas de ram era una barbaridad, sólo podía usarse de caché y en programas especiales que hacían uso de memoria extendida y expandida y otras chuminadas que teníamos que usar por el dos. O tempora. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFJOzNtTMYHG2NR9URAuZFAJ9KmyB+HTsTQL1vmB2RlZ21ZqB7MACeKzF7 HFjxy3BZ0a5nDHc1M4aLDiA= =z6m8 -----END PGP SIGNATURE-----

Hola :) El Miércoles, 4 de Octubre de 2006 14:55, Juan Erbes escribió:

2006/10/4, aux :

...

El Mi�rcoles, 4 de Octubre de 2006 13:26, Rafa Grim�n escribi�:

...

Adem�s, si no hay desarrolladores ni inter�s por el propio Namesys ... veo bien que lo dejen (aka un problema menos ;)

Adem�s, seguimos teniendo XFS ;)

Veo en muchos benchmarks que sale muy bien parado siempre XFS. Porque no se ha adoptado XFS por defecto?

La realidad, parece ser que estan apuntando a sacar OCFS2 cuando est� maduro, y mientras tanto es posible que dejen al usuario elegir el sistema de ficheros por default, entre los cuales pueden llegar a incluir Reiser4.

http://oss.oracle.com/projects/ocfs2/

OCFS2 está teniendo mucho apoyo por parte de SUSE así que habrá que irle echando un vistazo de vez en cuando :) Ya está disponible en SLES 9 SP3 (sin soporte, creo) y el SLES 10 (con soporte). Es un sistema de ficheros en cluster relativamente nuevo. Otros sistemas de ficheros en cluster para Linux son: GFS, GPFS y Lustre como SW libre.

La extensi�n del soporte Reiser estar�a supeditada a la gente que mantiene el kernel, que mientras ellos lo mantengan soportado, Suse continuar� soportandolo tambien.

Salu2

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

El 4/10/06, Carlos E. R. escribió:

O dicho de otra forma: no es en absoluto comparable a reiser, ext234, xfs, jfs, etc. No es un sistema de ficheros que pueda substituir al reiser como sistema por defecto en las instalaciones.

Ya me estoy imaginando la pantalla de instalación de OpenSuSE 10.2: "Bienvenido al asistente de instalación de OpenSuSE. Por favor, seleccione el tipo de servicio que más se ajuste a sus necesidades..." - NOC Center - Sistema Cluster - Sistema de Almacenamiento Masivo (SAN, NAS, iSCSI, Fiber Channel) - ISP (Proveedor de Servicios de Internet) - Proveedor de "Hosting" :-) Saludos, -- Camaleón

Hola :) El Miércoles, 4 de Octubre de 2006 16:40, Carlos E. R. escribió:

El 2006-10-04 a las 15:22 +0200, Rafa Grimán escribió:

...

...

http://oss.oracle.com/projects/ocfs2/

OCFS2 está teniendo mucho apoyo por parte de SUSE así que habrá que irle echando un vistazo de vez en cuando :)

Pues no le veo ninguna utilidad - es un sistema de ficheros en cluster, así que para usuarios normales no nos sirve nada más que para envidia.

Hombre, es útil si quieres que varios equipos compartan un mismo almacenamiento sin tener que montar un servidor de ficheros (aka FTP, NFS, Web, Samba, ...). La pregunta es, ¿te vale la pena? Yo creo que para casa no porque el HW es muy caro y te sale más rentable montar un PC antiguo con Samba.

O dicho de otra forma: no es en absoluto comparable a reiser, ext234, xfs, jfs, etc. No es un sistema de ficheros que pueda substituir al reiser como sistema por defecto en las instalaciones.

Eso es cierto, no es un sistema de ficheros para una máquina, es útil para varias máquinas y en determinadas situaciones: requieres compartir ficheros y necesitas un gran ancho de banda y muy baja latencia. Por ejemplo: 3D, vídeo, audio, simulaciones, ... 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

2006/10/4, Rafa Grimán :

Hola :)

[...]

Además, si no hay desarrolladores ni interés por el propio Namesys ... veo bien que lo dejen (aka un problema menos ;)

pero se no hay muchos desarrolladores es por que no hay muchos usuarios utilizando !!! recuerdo leer, que uno de los grandes problemas de ReiserFS es que nadie reportaba los bugs que iban encontrando y por el tanto era mas dificil arreglarlos !!! y ahora con esto que hace OpenSuse, seran muchas personas menos utilizando.

Además, seguimos teniendo XFS ;)

se nota que trabajas en SGI !!!! :-D

...

SUSE ya no es lo que era, tendra la culpa novell?

y se nota que ya no trabajas en Novell (ya q no contestaste a esta frase) !!! :-) salu2 -- -- Victor Hugo dos Santos Linux Counter #224399

Hola :) El Miércoles, 4 de Octubre de 2006 18:37, Victor Hugo dos Santos escribió:

2006/10/4, Rafa Grim�n :

...

Hola :)

[...]

...

Adem�s, si no hay desarrolladores ni inter�s por el propio Namesys ... veo bien que lo dejen (aka un problema menos ;)

pero se no hay muchos desarrolladores es por que no hay muchos usuarios utilizando !!!

No, lo que pasa es que los de Namesys han decidido es destinar a todos los desarrolladores a la versión 4, ha sido una decisión por parte del fabricante.

recuerdo leer, que uno de los grandes problemas de ReiserFS es que nadie reportaba los bugs que iban encontrando y por el tanto era mas dificil arreglarlos !!! y ahora con esto que hace OpenSuse, seran muchas personas menos utilizando.

Eso de los bugs ya no lo sé 0:)

...

Adem�s, seguimos teniendo XFS ;)

se nota que trabajas en SGI !!!! :-D

0;)

...

...

SUSE ya no es lo que era, tendra la culpa novell?

y se nota que ya no trabajas en Novell (ya q no contestaste a esta frase) !!! :-)

Me has pillado ;) Hombre, uno tiene su corazoncito y sigue "amando" SUSE Linux (en todas sus modalidades), pero discrepo en algunas decisiones que ha tomado Novell. No creo que sea correcto que yo opine ya que he estado allí y no quiero que la gente malinterprete mis palabras y piense que "odio" a Novell o estoy enfadado con ellos 0:) 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

El 4/10/06, csalinux escribió:

...

...

Jaime v

[...] A partir de su próxima versión las instalaciones de OpenSUSE ofrecerán al veterano pero probado y compatible hacia atrás ext3 como su sistema de archivos preferido. [...]

Parece que vayamos para atras y no hacia adelante. Entre esto de ext3 y el super zen-BUGdater esto va de mal en peor. SUSE ya no es lo que era, tendra la culpa novell?

Partiendo de la base de que cuantas más opciones de elección haya mucho mejor, porque, entre muchas otras cosas como bien dicen Rafa y Carlos, para uno puede ser mejor un sistema de archivos que otro.

Dicho esto, mi opinión personal es que para mi uso y mis necesidades reiserfs ha sido NEFASTO.

Todos los fs tienen sus problemas, y a mi personalmente, nunca he tenido problemas con Reiserfs, a pesar de apagones, o lo que sea. Lo que mas se cuestiona a Reiserfs, es el pobre manejo en ACL, y ese es el punto clave. Creo que una de las claves por la que se avecina la defunción de ese FS, es que no se habrió a la comunidad, como se abrió EXT2/3/4, y esa empresa Namesys pretendió hacer su negocio manteniendolo cerrado, y creo que de allí deriva su fracaso.

P.D.: Lo del zen-updater sin comentario... eso si que es un error grave,

¿Porque crees que puedes descargar los isos gratuitamente? Ahora todos somos betatesters, al igual a como hizo Red Hat, que liberó Fedora, para hacer la depuración en esta, para la versión empresarial. Lo del Zenworks, no es un producto nuevo, ya que hace muchos años que se usaba en entornos windows/Novell, pero parece ser que hasta ahora, no se ha adaptado bien a Linux, además está compilado en mono, que pretende emular a .net, y a mi no me convence ni mono, ni .net. Me imagino que habrás visto el demonio zmd.exe... Salu2

El 4/10/06, aux escribió:

El Miércoles, 4 de Octubre de 2006 05:28, Jaime Andres Velez Osorio escribió:

...

.. solo para comentar eso que lei en vivalinux.com.ar... una lastima reiser ha alcanzado gran estabilidad por lo que leo de reiser es mucho mas innovador que ext3., mi...ercoles caigo en cuenta que mis particiones estan en reiser.. si se que continuara el soporte a reiser, pero bueno, como se le va a hacer larga vida a reiser. (por lo menos en mis particiones) la pagina http://www.vivalinux.com.ar/distros/open-suse-abandona-reiserfs.html

Jaime v

[...] A partir de su próxima versión las instalaciones de OpenSUSE ofrecerán al veterano pero probado y compatible hacia atrás ext3 como su sistema de archivos preferido. [...]

Parece que vayamos para atras y no hacia adelante.

instalar algo probado y confibale no es ir para atras !!! por el contrario, es una senal de perfeccionamento y responsabilidad !!! para algunas empresas/personas, los datos que estan en el servidor son algo muy, muy, pero muy importante .. y cuanto mas confiable sea el FS, mejor salu2 -- -- Victor Hugo dos Santos Linux Counter #224399

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-05 a las 10:23 +0200, Rafa Grimán escribió:

Bromas a parte, el filesystem es algo muy importante, al igual que cualquier otra parte del ordenador. Es una lástima que la gente sólo se preocupa en los MHz o el número de CPUs y NO se preocupan de los buses, la caché, ... y aquellas otras partes que no se ven/tocan (latencias, cuellos de botellas, comportamiento de la aplicación, ...) también son importantes y nadie les presta atención :(

je je... lo sufro todos los dias. Mi pc es un P-iv, pero el bus de memoria es lento (133). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFJPMrtTMYHG2NR9URAnfzAJ9xQUkoQXXPhxTkW+P/8FZdzE1SsgCeMVyR PI/y3YIXF3sQfvIuT4mhvDs= =tKWt -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-05 a las 17:21 +0200, Rafa Grimán escribió:

...

je je... lo sufro todos los dias. Mi pc es un P-iv, pero el bus de memoria es lento (133).

Eso no es un cuello de botella, eso es el ojo de una aguja !!! ;)

Hijo, que esto no es SGI :-P Los de 400 eran bastante más caros cuando lo compré. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFJUz8tTMYHG2NR9URAmCLAJ9vNmuWIQ/c0iluE/0En2MqJErx3gCcDJq7 lcKSWe6xvTC9EhjdYopK7u8= =HA3q -----END PGP SIGNATURE-----