Hola :) El Jueves, 5 de Octubre de 2006 14:10, Carlos E. R. escribió:

El 2006-10-05 a las 10:08 +0200, Rafa Grim�n escribi�:

...

No en que abandonen reiserfs sino que abandonen la versi�n3.

Y tampoco, sino que lo abandonan como opci�n por defecto en el yast al instalar el sistema.

Pero eso es porque reiserfs v4 no está disponible. Yo creo que lo incluirían si Andrew Morton aceptara la v4 en el kernel.

...

...

Tengo entendido que es mas seguro, mas r�pido que los tipos de archivos de Sistema, SuSE lo pone como predeterminado cuando se hace la instalaci�n,

Es m�s "r�pido" para directorios con millones de ficheros peque�os, el tama�o ideal es de 4 KB. Esto lo veo como otra limitaci�n porque ficheros de 4 KB ya no existen ;)

Es muy r�pido comparado con los dem�s en ficheros muy peque�os, de 100 bytes, por ejemplo, aunque sean millones.

Peor me lo pones porque ficheros de 100 bytes ... ;)

...

Muchos pensar�n, "AH!!! Entonces para correos electr�nicos es bueno" ... pues tampoco, no es bueno con sistemas ne los que se producen lecturas Y escrituras simult�neas de forma masiva.

Eso es el otro "detalle". Ser�a bueno entonces con ese tipo de ficheros siempre que la demanda de i/o no sea muy alta.

Efectivamente.

Me ha parecido entender que hay un sub-proceso �nico, no escalable, que es el cuello de botella, incluso aunque tengas varias particiones. No puedo precisar, no s� tanto y el mantenedor no la ha explicado, habla en "su" idioma:

ReiserFS uses the BKL for synchronization everywhere, and since it's system-global lock, the problem doesn't go away when you split the file system into smaller ones. Lock contention alone is one problem, but it's made worse by cache bouncing between processors on larger systems.

Pues eso sí que es chungo, el cache bouncing. Esto se produce cuando un proceso pasa de una CPU a la otra y hay que actualizar la caché de las CPUs. Es un cuello de botella bastante desagradable y merma mucho el rendimiento :( En resumen que reiserfs en sistemas SMP da peores rendimientos ... 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 Jueves, 5 de Octubre de 2006 20:42, Carlos E. R. escribió:

El 2006-10-05 a las 17:26 +0200, Rafa Grim�n escribi�:

...

...

Es muy r[e1]pido comparado con los dem[e1]s en ficheros muy peque[f1]os, de 100 bytes, por ejemplo, aunque sean millones.

Peor me lo pones porque ficheros de 100 bytes ... ;)

Ya, en general son pocos. Pero recuerda que una de las ideas del reiserfs es poder implementar bases de datos directas sobre el sistema de ficheros: es decir, un campo por fichero, o un registro por fichero, dejando que el motor b�sico sea el sistema operativo y no el programa de la base de datos manejando un fichero enorme para todos los datos que tiene que indexar.

Esta idea está chula :)

Pero mira, echando un vistazo en mi "home", tengo 4,160,106 bytes en 8806 ficheros de un tama�o x, 2048 >= x >= 1 bytes, de un total de 4,124,740K bytes in 9349 ficheros. O sea, la mayor�a de mis ficheros cumplen el criterio de ser peque��simos e ideales para una reiser - y los tengo en xfs.

Muchos son symlinks. Una cantidad est�n generados por el beagle. Unos cuantos son indices de ficheros de correo del Mozilla, que tambi�n tiene un mont�n de peque�os en su cach�. El geedit del gnome tambi�n ha dejado unos cuantos cientos, y algunas docenas el OOo - eso en un vistazo por encima.

Me ha picado la curiosidad: currotop:~ # find /home/rgriman/ -type f > list_files currotop:~ # wc -l list_files 48308 list_files Vamos, que tengo 48308 ficheros en mi directorio de trabajo ... currotop:~ # du -sh /home/rgriman/ 11G /home/rgriman/ Que ocupan 11 GB currotop:~ # find /home/rgriman/ \( -type f \) -a \( -size -101c \) | wc -l 2697 De esos 48+K ficheros, tengo 2697 ficheros que pesan menos de 101 bytes currotop:~ # find /home/rgriman/ \( -type f \) -a \( -size 0 \) | wc -l 401 De los cuales 401 pesan 0 bytes !!! Puñeta ... bueno, ya he vuelto, la mayoría son de beagle ... 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 -- 50% of all statistics are inaccurate. OpenWengo: rgriman

Hola :) El Viernes, 6 de Octubre de 2006 12:24, Carlos E. R. escribió: [...]

...

Me ha picado la curiosidad:

O:-)

...

De esos 48+K ficheros, tengo 2697 ficheros que pesan menos de 101 bytes

Me parecen pocos, comparado conmigo. �Te has fijado si tu b�squeda caza los ocultos? No estoy muy ducho en el find, por eso pregunto. Yo los busqu� con el mc.

No, habría que cambiar la línea de comandos ... en cuanto tenga un rato lo pruebo 0;)

...

currotop:~ # find /home/rgriman/ \( -type f \) -a \( -size 0 \) | wc -l 401

De los cuales 401 pesan 0 bytes !!! Pu�eta ... bueno, ya he vuelto, la mayor�a son de beagle ...

Los de 0b no deben ocupar ni siquiera inodo, s�lo entrada de directorio.

Eso sí es verdad, pero tener 401 ficheros vacíos ... ;) 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

Tantos correos hablando del tema me han animado a hablar a mi también. Las pruebas que normalmente realiza la gente sobre los sistemas de ficheros, son de rendimiento normalmente, por ese motivo, hace algunos años, estuve dudando en que sistema de ficheros usar, primero, porque se trataba de usar no solo para datos importantes, si no para actividad frenética con el, con el mínimo riesgo de que quedara corrupto el sistema de ficheros. El problema era leer los tests que hacian de rendimiento sobre los FS, que indicaban que valia la pena pasar del ext2 al ext3, y que el reiserfs aun era demasiado experimental, como para arriesgarse a usarlo. Por esa razon, miré un poco los codigos fuentes de los sistemas de ficheros nuevos para mi, ext3 y reiserfs, y alguno otro con journaling. Aunque parezca mentira no me costó demasiado entender el reiserfs, asi que entiendo que a unos les moleste que no use las directivas tipicas del kernel para acceder a las estructuras y al scheduler, etc... porque en principio ayuda a que los cambios de caracter estructural no afecten tanto a los módulos, pero tampoco es tan grave. El caso es que no me fié de nada en absoluto, y ya habia tenido problemas intentando recuperar algun ext2 corrupto, y que queria tener claro cual de todos ellos era más robusto. Asi que cogí el módulo o block device; loop, y lo transformé de la siguiente manera: 1.daba errores pseudoaleatorios de acceso a algun bloque, repartidos por el disco, y iban creciendo poco a poco, hasta llegar a un 50% del disco. Con esta simple prueba, y las pocas herramientas del reiserfs, vi que la recuperación era compleja pero no me quedó ninguna vez corrupto de las 10 pruebas que hice. En cambio el ext3 y el ext2, el XFS i algun otro, fue desastroso ya con el inicio del test. Con el ext2 no habia manera de solucionar algunos problemas. Hay que tener en cuenta que lo que hacia era llenar a un 25% el disco mientras iba fallando hasta el 50%. Las pruebas eran con sistemas de ficheros de 50 Megas y pude recuperar las 10 particiones (ficheros) con el reiserfs. En cambio con el ext3, consegui recuperar 7 de las 10. Con el ext2 no habia manera de recuperar el disco ni escribir. Durante 4 dias fuí probandolo, y curiosamente empezó a fallar más el reiserfs si petaba borrando ficheros, aun asi, solo me fallaron 2, como máximo en cada test. 2. Después añadí al modulo la posibilidad de desconectarse directamente en un momento aleatorio (para emular apagones, etc). He de decir que con esto el ext2 falló poco pero falló. EN cambio ninguno de los que usaban journaling, falló. excepto el XFS, que perdí 3 de las particiones. Finalmente, aunque con miedo, porque habian pocas herramientas para reiserfs, decidi usarlo porque se habia portado bien, en comparación al ext3, pero me encontré que nunca iba incluido por defecto en el kernel y me dió mucha rabia, porque no tenia discos de arranque con la version del reiserfs actual, tipico error de una persona como yo, pero vi, que los de SuSE te instalaban el reiserfs por defecto y en cambio, no viene por defecto en sus kernels..., todo siempre a traves del initrd.... He de reconocer y para que no penseis que el reiserfs es infalible, que mas adelante probé más el modulo loop modificado, y sobretodo al cambiar de kernel, al 2.6.11 el modulo reiserfs me petaba con el programa algunas veces, y me dió mucha rabia..., quizas no transformé bien el modulo del loop para la 2.6.11, pero entonces probé con el ext3 y el JFS y pasaba exactamente lo mismo, el error venia de más arriba. Así que no me he podido probar que pasa con las nuevas versiones, y desgraciadamente ahora tampoco tengo tiempo... snifff.... NOTA: Ahora han crecido tanto los sistemas de ficheros, que me dan mas miedo, que seguridad. Nunca olvideis de hacer copias de seguridad y recordad que ningun antivirus y ningun firewall puede impedir que un disco duro deje de poder leerse. Y para mi es mas importante que sean robustos a que vayan más rápidos, mientras no sean 10 veces mas lentos claro... Urbez. -- ################################################ #- Urbez Santana i Roma - #- Email: urbez@linuxupc.upc.edu #- Private Web: http://linuxupc.upc.es/~urbez/ ################################################

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

Estoy 100% de acuerdo contigo. Espero que algún jerifalte de alguna empresa española escuche estas sabias palabras porque anda que no hace falta educar que un sistema de copia de seguridad NO ES CARO.

No problemo. Simplemente espera sentadito a que pete, porque petará algún dia... y nos reimos entonces. >;-) Me pasó a mi, así que... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFK3m0tTMYHG2NR9URArs6AJ46UH+RB2ICOu36O9v7auZ/AtaFiACeOm9H 887Zb65f1sNHzIqNVwxo//I= =gfIm -----END PGP SIGNATURE-----

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

...

No problemo.

Simplemente espera sentadito a que pete, porque petar[e1] alg[fa]n dia... y nos reimos entonces. >;-)

Me pas[f3] a mi, as[ed] que...

Pero es que luego viene "el llanto y el rechinar de dientes". Y, ¿quién es el culpable? Tu (yo) porque "con lo que habéis cobrado ya podíais haber incluido un sistema de copia de seguridad".

No, no me echaron la culpa, sino a que no había procedimiento de respaldo de los datos, lo cual era responsabilidad de más arriba. Fueron serios.

Me estoy acordando de un cliente que tiene un sistema bastante monstruoso y le comentamos lo de hacer copias de seguridad y nos dijo que hoy en día eso no era necesario porque los sistemas son muy fiables.

Este cliente tiene un HSM (o DLM o ILM, cada uno lo llama como quiere). Lo que hace este software es migrar a cintas datos que no se usan, dejando los i-nodos en disco de forma que el usuario ve un disco gigantesco (de 1 PB, por ejemplo) pero realmente sólo hay 10 TB en disco y lo demás en cinta.

Curioso.

Pues cuando le dijimos que un HSM _NO_ es un sistema de copia de seguridad, lo que nos dijo fue: "En 40 años que llevo en esta profesión, _nunca_ he visto una cinta estropeada" ... un mes más tarde se quedaba enganchada una cinta en un drive.

Je, je...

Siguen sin sistemas de copia de seguridad, ni disaster recovery, ni nada por el estilo, ...

Ya les vale.

Luego tenemos otro cliente que tiene toda la información duplicada, copias de seguridad, está estudiando un sistema de disaster recovery, ... Menos mal que hay alguno serio ;)

Alguno hay :-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFK4oRtTMYHG2NR9URApWyAJ9cdlCp8GjHHYHZLjZP5+EF5dtPKQCcD7ZX xG9Be83oAyhAC6uGU0zSHpQ= =p56s -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-11 a las 12:43 +0200, Camaleón escribió:

De piedra me he quedado al ver esta noticia:

Hans Reiser Arrested On Suspicion of Murder http://yro.slashdot.org/yro/06/10/11/0142216.shtml

:-O

¡Ostras! :-( Habían comentado en la lista inglesa que tenía problemas serios, pero tanto no me lo imaginaba. Bueno, lo han arrestado con pruebas circunstanciales, ni siquiera hay cuerpo; ojalá simplemente haya desaparecido, la muerte no tiene vuelta atrás. Los programadores son también gente... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFLM6ttTMYHG2NR9URAqFnAKCEWaB/51Vjy7gzlcuSBnj9xda4VgCfZRf0 GiTzNGRz/Q+AtS5Lo6HB7Bk= =7W6i -----END PGP SIGNATURE-----