RE: [suse-linux-s] Ext3 y ReiserFS

newer
red entre suse 10 y windows

older
Ati Radeon Mobile x200 en SuSE 10...

Rafael Griman

17 Oct 2005 17 Oct '05

10:34

Wenas :)

...

Permanece la limitación con los subdirectorios.

Al final tendré que dividir toda la información creando directorios y solo añadir en estos hasta 32.000 subdirectorios.

Yo lo partiría en 4 sistemas de ficheros mínimo, no 2. Así consigues mejores resultados y disminuir el número de ficheros por filesystem.

...

He decidido mantener EXT3, ya que FSReiser es algo lento para el acceso a millones de archivos (comprobado) y consume bloques de 4Bytes, en vez de 1Kbytes que necesito.

Los ficheros que manejo son de 1Kbyte, son millones de ficheros. Alguien preguntaba por curiosidad que estoy realizando para manejar tanta información, el proyecto es un buscador. Se crean millones de pequeños archivos de 1Kbytes.

Dos cosas: - si montas un buscador, ¿por qué no usar una BBDD? Sé que una BBDD con 1 K de info no es útil, es sólo curiosidad - Carlos comentó en un correo este verano que reiserfs permite (mediante PERL) hacer que el FS actúe a modo de BBDD, puede que te interese

...

Tambien me he dado cuenta que EXT3 da problemas a la hora de guardar ficheros pequeños en discos duros externos USB, mientras que con FSReiser no pero el acceso es bastante lento.

¿Alguna sugerencia?

No se me ocurre nada más 0:) Rafa

Show replies by date

Carlos E. R.

17 Oct 17 Oct

12:01

New subject: [suse-linux-s] Ext3 y ReiserFS

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-10-17 a las 11:34 +0100, Rafael Griman escribió:

...

...
He decidido mantener EXT3, ya que FSReiser es algo lento para el acceso a millones de archivos (comprobado) y consume bloques de 4Bytes, en vez de 1Kbytes que necesito.

No estoy seguro de eso. Me sospecho que reiser empaquetará varios ficheros en cada uno de los bloques. Mira, de la propia documentación del reiserfs: ReiserFS is more space efficient. If you write 100 byte files, we pack many of them into one block. Other filesystems put each of them into their own block. We don't have fixed space allocation for inodes. That saves 6% of your disk. Y un poco antes habla de directorios gigantes: ReiserFS is based on fast balanced trees. Balanced trees are more robust in their performance, and are a more sophisticated algorithmic foundation for a filesystem. When we started our project, there was a consensus in the industry that balanced trees were too slow for filesystem usage patterns. We proved that if you just do them right they are better. We have fewer worst case performance scenarios than other filesystems and generally better overall performance. If you put 100,000 files in one directory, we think its fine; many other filesystems try to tell you that you are wrong to want to do it. La web se llama "namesys", por cierto. Un poco más (lo tengo guardado en fichero, es del 2002): Speaking more technically: -------------------------- ReiserFS is a filesystem using a plug-in based object oriented variant on classical balanced tree algorithms. The results when compared to the ext2fs conventional block allocation based filesystem, running under the same operating system and employing the same buffering code, suggest that these algorithms are overall more efficient and every passing month are becoming yet more so. Loosely speaking, every month we find another performance cranny that needs work; we fix it. And every month we find some way of improving our overall general usage performance. The improvement in small file space and time performance suggests that we may now revisit a common OS design assumption that one should aggregate small objects using layers above the filesystem layer. Being more effective at small files does not make us less effective for other files. This is truly a general purpose FS. Our overall traditional FS usage performance is high enough to establish that. ReiserFS has a commitment to opening up the FS design to contributions; we are now adding plug-ins so that you can create your own types of directories and files. Ahora bien, me sospecho que para ser eficiente debe necesitar bastante memoria.

...

...
Los ficheros que manejo son de 1Kbyte, son millones de ficheros. Alguien preguntaba por curiosidad que estoy realizando para manejar tanta información, el proyecto es un buscador. Se crean millones de pequeños archivos de 1Kbytes.

Dos cosas: - si montas un buscador, ¿por qué no usar una BBDD? Sé que una BBDD con 1 K de info no es útil, es sólo curiosidad

...

- Carlos comentó en un correo este verano que reiserfs permite (mediante PERL) hacer que el FS actúe a modo de BBDD, puede que te interese

Es que el propio sistema de ficheros reiser es en si mismo una base de datos. Lo cuenta en su web.

...

...
Tambien me he dado cuenta que EXT3 da problemas a la hora de guardar ficheros pequeños en discos duros externos USB, mientras que con FSReiser no pero el acceso es bastante lento.

¿Alguna sugerencia?

No se me ocurre nada más 0:)

Buscar en la web de reiserfs, hay bastante información. E incluso preguntarles. Es posible que digan de usar reiserfs 4, pero a mi me parece que no está maduro, eso dicen. Ojo: A mi reiser me ha dado algún problema; funciona muy bien, pero cuando casca, lo hace de verdad. Me sospecho que precisamente por ese algoritmo de arbol balanceado que no entiende nadie, no hay herramientas perfectas de recuperación. Me dice un amigo que una partición reiser que quiso salvaguardar con Ghost (windoze) le ocupa una barbaridad, mucho más que la de windows, a pesar de contener menos cosas. Claro, porque los de ghost deben estar guardando todo a lo bruto, no entienden el algoritmo y no son capaces de hacer una imagen de unicamente lo util - o algo parecido, me sospecho :-p Pero no burlaros de los del Ghost, porque en Linux tampoco se puede. Todavía no hay un dump para particiones reiser. No obstante lo cual, me parece que reiserfs es el tipo de partición ideal para lo que el PO está buscando. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDU5KJtTMYHG2NR9URApH1AJsFeoL7OQQzn+rhOsp+Wffv1plJAgCgkOZX STc7M63YmFL3gCsolpkIIrk= =v+p0 -----END PGP SIGNATURE-----

csalinux

18:40

New subject: [suse-linux-s] Ext3 y ReiserFS

Carlos E. R. escribió:

...

No obstante lo cual, me parece que reiserfs es el tipo de partición ideal para lo que el PO está buscando.

No obstante, a mí reiser, me ha cascado de verdad de verdad de verdad, varias veces, y pienso que para un uso doméstico es mejor ext3. Por: 1.- El ordenador doméstico suele ser compartido... por lo que si le casca a alguien el home... y no está el "admnistrador" el susto es morrocutudo. 2.- Para usuarios noveles, como yo, pues es un fastidio buscar los comandos de recuperación... que por cierto. Una de las veces me equivoqué y se los apliqué a otra partición :D. 3.- El ext3 tiene herramientas más automatizadas para el que no sabe. 4.- El HP de mi portátil HP, cascaba sistemáticamente el home con reiser y con ext3 no, es un ZE4200, o sea tiene menos de un año y medio... :(, pero supongo que es problema de hardware, pero con ext3 va bien bien.

Carlos E. R.

21:58

New subject: [suse-linux-s] Ext3 y ReiserFS

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-10-17 a las 20:40 +0200, csalinux escribió:

...

...
No obstante lo cual, me parece que reiserfs es el tipo de partición ideal para lo que el PO está buscando.

No obstante, a mí reiser, me ha cascado de verdad de verdad de verdad, varias veces,

Y a mi una vez al menos. Era un bug que tuvo la suse... 9.1, que identificaba ciertos nombres de fichero en el directorio raiz de una partición reiser (y no en un directorio de la misma), como nb3001 y mm3001 como siendo el mismo nombre. De resultas de probarlo, me petó la partición raiz - pero también pudo estropearse porque al mismo tiempo creo que me falló un modulo de memoria.

...

y pienso que para un uso doméstico es mejor ext3. Por:

Siempre hay motivos para esas cosas. Yo uso ext3 en la raiz, xfs en home, y reiser en algunas por ahí, como /usr/src, donde va a haber compilaciones pesadas.

...

1.- El ordenador doméstico suele ser compartido... por lo que si le casca a alguien el home... y no está el "admnistrador" el susto es morrocutudo.

Nostamal :-)

...

2.- Para usuarios noveles, como yo, pues es un fastidio buscar los comandos de recuperación... que por cierto. Una de las veces me equivoqué y se los apliqué a otra partición :D.

:-) El disco de rescate creo que lo hace automáticamente.

...

3.- El ext3 tiene herramientas más automatizadas para el que no sabe.

Si, eso si.

...

4.- El HP de mi portátil HP, cascaba sistemáticamente el home con reiser y con ext3 no, es un ZE4200, o sea tiene menos de un año y medio... :(, pero supongo que es problema de hardware, pero con ext3 va bien bien.

Es probable que tengas sectores fastidiados, y eso el reiserfs lo lleva fatal. Estarán remapeados, pero en el interim, te fastidias. Lo puedes ver con smartctl -a /dev/hd? - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDVB6htTMYHG2NR9URAh6FAJ9SbQGNagxqlNSR3V/FsZUMaVIPagCfVM5Z I/18yALSh8bQ3B3qCu1Yy/U= =PZAc -----END PGP SIGNATURE-----

Carlos E. R.

18:46

New subject: [suse-linux-s] Ext3 y ReiserFS

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-10-17 a las 14:01 +0200, Carlos E. R. escribió:

...

Date: Mon, 17 Oct 2005 14:01:11 +0200 (CEST) From: Carlos E. R. Reply-To: suse-linux-s@suse.com To: Lista de Suse Linux Español Subject: RE: [suse-linux-s] Ext3 y ReiserFS

El 2005-10-17 a las 11:34 +0100, Rafael Griman escribió:

...
...
He decidido mantener EXT3, ya que FSReiser es algo lento para el acceso a millones de archivos (comprobado) y consume bloques de 4Bytes, en vez de 1Kbytes que necesito.

No estoy seguro de eso. Me sospecho que reiser empaquetará varios ficheros en cada uno de los bloques. Mira, de la propia documentación del reiserfs:

ReiserFS is more space efficient. If you write 100 byte files, we pack many of them into one block. Other filesystems put each of them into their own block. We don't have fixed space allocation for inodes. That saves 6% of your disk.

Y un poco antes habla de directorios gigantes:

ReiserFS is based on fast balanced trees. Balanced trees are more robust in their performance, and are a more sophisticated algorithmic foundation for a filesystem. When we started our project, there was a consensus in the industry that balanced trees were too slow for filesystem usage patterns. We proved that if you just do them right they are better. We have fewer worst case performance scenarios than other filesystems and generally better overall performance. If you put 100,000 files in one directory, we think its fine; many other filesystems try to tell you that you are wrong to want to do it.

La web se llama "namesys", por cierto. Un poco más (lo tengo guardado en fichero, es del 2002):

Speaking more technically: --------------------------

ReiserFS is a filesystem using a plug-in based object oriented variant on classical balanced tree algorithms. The results when compared to the ext2fs conventional block allocation based filesystem, running under the same operating system and employing the same buffering code, suggest that these algorithms are overall more efficient and every passing month are becoming yet more so. Loosely speaking, every month we find another performance cranny that needs work; we fix it. And every month we find some way of improving our overall general usage performance.

The improvement in small file space and time performance suggests that we may now revisit a common OS design assumption that one should aggregate small objects using layers above the filesystem layer. Being more effective at small files does not make us less effective for other files. This is truly a general purpose FS. Our overall traditional FS usage performance is high enough to establish that. ReiserFS has a commitment to opening up the FS design to contributions; we are now adding plug-ins so that you can create your own types of directories and files.

Ahora bien, me sospecho que para ser eficiente debe necesitar bastante memoria.

...
...
Los ficheros que manejo son de 1Kbyte, son millones de ficheros. Alguien preguntaba por curiosidad que estoy realizando para manejar tanta información, el proyecto es un buscador. Se crean millones de pequeños archivos de 1Kbytes.

Dos cosas: - si montas un buscador, ¿por qué no usar una BBDD? Sé que una BBDD con 1 K de info no es útil, es sólo curiosidad

...
- Carlos comentó en un correo este verano que reiserfs permite (mediante PERL) hacer que el FS actúe a modo de BBDD, puede que te interese

Es que el propio sistema de ficheros reiser es en si mismo una base de datos. Lo cuenta en su web.

...
...
Tambien me he dado cuenta que EXT3 da problemas a la hora de guardar ficheros pequeños en discos duros externos USB, mientras que con FSReiser no pero el acceso es bastante lento.

¿Alguna sugerencia?

No se me ocurre nada más 0:)

Buscar en la web de reiserfs, hay bastante información. E incluso preguntarles.

Es posible que digan de usar reiserfs 4, pero a mi me parece que no está maduro, eso dicen.

Ojo: A mi reiser me ha dado algún problema; funciona muy bien, pero cuando casca, lo hace de verdad. Me sospecho que precisamente por ese algoritmo de arbol balanceado que no entiende nadie, no hay herramientas perfectas de recuperación.

Me dice un amigo que una partición reiser que quiso salvaguardar con Ghost (windoze) le ocupa una barbaridad, mucho más que la de windows, a pesar de contener menos cosas. Claro, porque los de ghost deben estar guardando todo a lo bruto, no entienden el algoritmo y no son capaces de hacer una imagen de unicamente lo util - o algo parecido, me sospecho :-p

Pero no burlaros de los del Ghost, porque en Linux tampoco se puede. Todavía no hay un dump para particiones reiser.

No obstante lo cual, me parece que reiserfs es el tipo de partición ideal para lo que el PO está buscando.

-- Saludos Carlos Robinson

------------ Output from gpg ------------ gpg: Signature made Mon 17 Oct 2005 02:01:13 PM CEST using DSA key ID 6D8D47D5 gpg: Good signature from "Carlos E. R. (Carlos) " gpg: aka "Carlos E. R. (Carlos) " gpg: aka "Carlos Robinson (Carlos) " gpg: aka "Carlos E. R. (Carlos) " gpg: aka "Carlos E. R. (Carlos) "

he hecho una probatina en una partición reiserfs: /dev/hdb12 on /Disco40/nuevo type reiserfs (rw,noatime) Es una partición con más de 5 gigas de sitio libre, y en cuyo disco duro no hay más actividad que la probatina. Usando el siguiente script he creado un millón de ficheros: #!/bin/bash HORA=`date --iso=ns` echo "Empezando Gran Prueba $HORA" | tee > registro_GranPrueba time for X in `seq 1 1000`; do HORA=`date --iso=ns` echo "Empezando la serie $X a las $HORA" >> registro_GranPrueba echo "Empezando la serie $X a las $HORA" time for Y in `seq 1 1000`; do echo -n "." dd if=/dev/zero of=/Disco40/nuevo/GranPrueba/Zero_$X"_"$Y bs=1k count=1 2> /dev/null done echo done HORA=`date --iso=ns` echo "Terminada la Gran Prueba a las $HORA" | tee >> registro_GranPrueba echo "Terminada la Gran Prueba a las $HORA" du -h /Disco40/nuevo/GranPrueba | tee >> registro_GranPrueba Cada iteración de 1000 ficheros me tarda unos cinco segundos, aproximadamente; de vez en cuando tarda el doble, pero es posible que una buena parte del tiempo sea la salida a pantalla de los puntitos. Quizás debería haberlos quitado. En el disco no sse ve casi actividad durante la prueba - ah, corrijo, en una ventana había puesto: watch -n30 "/usr/bin/du -h /Disco40/nuevo/GranPrueba/" y eso creaba una cierta actividad de lectura (7Mb/s) que entorpecía la grabación. Acabo de quitarlo. El sistema me tiene bastante memoria ocupada, tengo abiertos el mozilla y el OO. Cierro el OO. Bueno, tengo 120 megas en caché y 62 en buffers. Según "top", el script consume un 10% de cpu, pero algunos otros procesos de usuario hacen llegar el total de usuario al 39%. No identifico cuales son, pueden ser las X, un 5%; otro 5% es el xterm donde está el script. Pero hay un 60% de cpu consumida por el sistema, el proceso total consume bastante. No sobra cpu (P-IV a 1.8), hay algunos procesos en espera (load average: 1.92, 2.13, 1.76). Llevo 200.000 ficheros, 25 minutos a aprox. Lo dejaré un buen rato antes de volver a mirar ;-) [...] Terminó. Czo: 2005-10-17T16:47:40,630259000 Fin: 2005-10-17T18:26:35,940389000 tiempo usado (time): real 98m55.308s user 29m24.673s sys 47m10.789s 1766.39user 2856.10system 1:44:28elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (348major+247597294minor)pagefaults 0swaps cer@nimrodel:~> ls -l /Disco40/nuevo/GranPrueba/ | wc -l 1000001 Bueno, ciertamente hay un millón de ficheros de 1024 bytes en un único directorio, y reiserfs no protesta. Nada de limites de 60 mil ficheros. Eso si, es verdad que cada uno ocupa 4 K, porque si no la salida de "du" no tiene sentido: 3.9G. Un simple "du" es pesado de hacer: cer@nimrodel:~> time du --bytes /Disco40/nuevo/GranPrueba 1055999400 /Disco40/nuevo/GranPrueba real 4m38.736s user 0m1.683s sys 0m24.888s ¿Ahora me dice 1 giga? ¿Se ha compactado el solito cuando ha tenido tiempo? ¿He hecho mal el comando? cer@nimrodel:~> time du -k /Disco40/nuevo/GranPrueba 4031249 /Disco40/nuevo/GranPrueba real 3m55.839s user 0m1.533s sys 0m23.993s Pues lo de --bytes debe significar otra cosa, son 4 gigas. Pues eso no coincide con lo que dice la documentación del reiserfs :-( Y un simple "ls" tarda 5 minutos: real: 5m55.123s user: 0m30.270s sys 0m29.728s Pero un rm * peta: cer@nimrodel:~> time rm /Disco40/nuevo/GranPrueba/* bash: /bin/rm: Argument list too long real 1m11.886s user 0m43.139s sys 0m1.773s Bueno, ¿y ahora como los borro? O:-) Estuvimos hablando de eso no hace mucho, pero no localizo el hilo, y no tengo ganas de pensar. Puedo usar el mismo script para borrarlos... - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDU/GYtTMYHG2NR9URAtlAAJ4zgHSP/WofaxlXwE8wZ2tBfBaYjACfcgbI /vRjndOVzOyXt4WpRpG+NrM= =FefY -----END PGP SIGNATURE-----

Victor Hugo dos Santos

20:53

New subject: [suse-linux-s] Ext3 y ReiserFS

El 17/10/05, Carlos E. R. escribió: [...]

...

Bueno, ciertamente hay un millón de ficheros de 1024 bytes en un único directorio, y reiserfs no protesta. Nada de limites de 60 mil ficheros. Eso si, es verdad que cada uno ocupa 4 K, porque si no la salida de "du" no tiene sentido: 3.9G. Un simple "du" es pesado de hacer:

cer@nimrodel:~> time du --bytes /Disco40/nuevo/GranPrueba 1055999400 /Disco40/nuevo/GranPrueba

real 4m38.736s user 0m1.683s sys 0m24.888s

¿Ahora me dice 1 giga? ¿Se ha compactado el solito cuando ha tenido tiempo? ¿He hecho mal el comando?

cer@nimrodel:~> time du -k /Disco40/nuevo/GranPrueba 4031249 /Disco40/nuevo/GranPrueba

real 3m55.839s user 0m1.533s sys 0m23.993s

Pues lo de --bytes debe significar otra cosa, son 4 gigas. Pues eso no coincide con lo que dice la documentación del reiserfs :-(

deberias de reportar esto al personal de reiserfs !!! apuesto q ellos quedarian muy contentos con estas pruebas q realizastes !!! salu2. -- -- Victor Hugo dos Santos Linux Counter #224399

Juan Carbajal Paxi

21:41

New subject: Instalar Lazarus en Suse 10

Bueno este es un problema que tiene que ver mas con la ubicacion de los distintos paquetes en Suse Linux, estoy buscando el paquete gtk+-devel y pixbuf, y no los he encontrado por tanto no puedo instalar Lazarus. En que directorio deberia instalar estos paquetes para que pueda funcionar bien la instalacion de Lazarus. Saludos Cordiales Juan Carbajal Paxi Analista y Desarrollador de Sistemas Célular: 9639083 E-mail: juan_carbajal_paxi@yahoo.es MSN Contact: juan_carbajal_paxi@hotmail.com ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es

Carlos E. R.

18 Oct 18 Oct

01:00

New subject: [suse-linux-s] Instalar Lazarus en Suse 10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-10-17 a las 23:41 +0200, Juan Carbajal Paxi escribió:

...

Bueno este es un problema que tiene que ver mas con la ubicacion de los distintos paquetes en Suse Linux,

Por favor, no secuestres hilos. Crea el tuyo propio. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDVElItTMYHG2NR9URAqLYAJwMxy3OxDwI4W3t5yXwep1TQcholwCfeE1W FlWeKfnBUIzo4sd/Px1Nz7g= =z9Dp -----END PGP SIGNATURE-----

Carlos E. R.

00:52

New subject: Ocupación de espacio en una part. reiserfs (era: Ext3 y ReiserFS)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-10-17 a las 20:46 +0200, escribí:

...

Bueno, ¿y ahora como los borro? O:-)

Pues lo hice con mc, midnight comander. Tardó media hora, pero lo hizo. Hice otra probatina. Creé 10000 ficheros, que según du ocupan 40 megas. Pero haciendo un df de la partición, la diferencia de espacio usado antes y despues fué: 3575564 - 3587400 = 11836 Kb, u 11.55 megas. ¿Peculiar, no? uno dice que el directorio ocupa 40 megas, pero el disco sólo ha aumentado su ocupación en 11.5 megas - que por otra parte es lo deberían ocupar diez mil ficheros de 1K, más o menos. Con 1000 ficheros (1000 me permite hacer rm y más probatinas) me sale: Filesystem 1K-blocks Used Available Use% Mounted on /dev/hdb12 9526168 3575564 5950604 38% /Disco40/nuevo /dev/hdb12 9526168 3576756 5949412 38% /Disco40/nuevo ---------- ------------------------------------------------ diferencia: 1192 Kb 1192 Kb du dice: cer@nimrodel:~> du /Disco40/nuevo/GranPrueba/ 4031 /Disco40/nuevo/GranPrueba/ cer@nimrodel:~> du -c /Disco40/nuevo/GranPrueba/* ... 4 /Disco40/nuevo/GranPrueba/Zero_9_99 4000 total La única explicación es que "du" indica la ocupación de espacio en disco, no la suma de tamaño de los ficheros, que la da si se usa "--apparent-size", según el manual. En cambio, df parece reportar la suma de espacios... eso es extraño, para hacer eso sería un comando muy lento, y no lo es, es rápido. Debe usar otro sistema. Lo que parece claro es que la idea de que reiser compacta los ficheros pequeños aprovechando los bloques no es totalmente cierta. A ver, otra prueba, si creo 1000 ficheros de 100 bytes, du reporta 4031 Kb Kb, y df lo mismo: Filesystem 1K-blocks Used Available Use% Mounted on /dev/hdb12 9526168 3575564 5950604 38% /Disco40/nuevo /dev/hdb12 9526168 3575804 5950364 38% /Disco40/nuevo 240 240 Kb Los ficheros ocuparían 100 Kbytes, pero la ocupación real es de 4031 Kb. Sigue usando bloques de 4 Kbytes por cada fichero. Repito con ficheros de 10 bytes: Filesystem 1K-blocks Used Available Use% Mounted on /dev/hdb12 9526168 3575564 5950604 38% /Disco40/nuevo /dev/hdb12 9526168 3575712 5950456 38% /Disco40/nuevo 148 du: 4031 Kb /Disco40/nuevo/GranPrueba Me acaban de esclafar mis ideas sobre reiserfs... porque es reiser: /dev/hdb12 on /Disco40/nuevo type reiserfs (rw,noatime) Estoy empezando a pensar que "df" tiene un bug. Calcula la ocupación "real" según el número de bloques que cada fichero tendría asignados, no los que realmente ocupa en el caso de una partición reiser, en el que tendría que recorrer la estructura interna. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDVEc6tTMYHG2NR9URAvfiAKCVmpp3h27hraW/B2s7+W841MDLCwCfWeL2 ohwEOVZb4dg6ey8fPDRZn3c= =D5CA -----END PGP SIGNATURE-----

admin-listas

06:47

New subject: [suse-linux-s] Ocupación de espacio en una part. reiserfs (era: Ext3 y ReiserFS)

Me parece que la unica forma empirica de saber cuantos caben es hacer una particion de 10mb y meter ficheros hasta que se acabe espacio. De esta forma es incuestionable el numero de ficheros y el espacio (sideral) Saludos

miguel gmail

07:09

New subject: [suse-linux-s] Ocupación de espacio en una part. reiserfs (era: Ext3 y ReiserFS)

Hola, On 10/18/05, admin-listas wrote:

...

Me parece que la unica forma empirica de saber cuantos caben es hacer una particion de 10mb y meter ficheros hasta que se acabe espacio. De esta forma es incuestionable el numero de ficheros y el espacio (sideral)

Pues yo creo que no. Una particion de 10 megas tb tendra que tener espacio ocupado por el superbloque y el espacio reservado a los inodos. No tengo ni idea de cuanto puede ser eso, pero habria que tenerlo en cuenta si es que estamos hilando tan fino. No estoy seguro ahora, pero me parece recordar que reiser reservaba ademas cilindros para hacer una copia de seguridad del superbloque. Tb habria que tenerlo en cuenta... De todos modos... me parece impresionante lo que hace Carlos :O -- Saludos, miguel

admin-listas

07:55

New subject: [suse-linux-s] Ocupación de espacio en una part. reiserfs (era: Ext3 y ReiserFS)

El Martes, 18 de Octubre de 2005 09:09, miguel gmail escribió:

...

Hola,

On 10/18/05, admin-listas wrote:

...
Me parece que la unica forma empirica de saber cuantos caben es hacer una particion de 10mb y meter ficheros hasta que se acabe espacio. De esta forma es incuestionable el numero de ficheros y el espacio (sideral)

Pues yo creo que no. Una particion de 10 megas tb tendra que tener espacio ocupado por el superbloque y el espacio reservado a los inodos. No tengo ni idea de cuanto puede ser eso, pero habria que tenerlo en cuenta si es que estamos hilando tan fino. No estoy seguro ahora, pero me parece recordar que reiser reservaba ademas cilindros para hacer una copia de seguridad del superbloque. Tb habria que tenerlo en cuenta...

De todos modos... me parece impresionante lo que hace Carlos :O

-- Saludos, miguel

La verdad es que puse 10 por decir algo, reiser creo que necesita una particion bastante mas grande, creo que el solito se cepilla 30mb de disco como minimo. Bueno, que le vamos a decir a Carlos que no sepa.

Carlos E. R.

12:08

New subject: [suse-linux-s] Ocupación de espacio en una part. reiserfs (era: Ext3 y ReiserFS)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-10-18 a las 09:55 +0200, admin-listas escribió:

...

La verdad es que puse 10 por decir algo, reiser creo que necesita una particion bastante mas grande, creo que el solito se cepilla 30mb de disco como minimo. Bueno, que le vamos a decir a Carlos que no sepa.

Pues muchas cosas X-) Si, el tamaño minimo de una reiser son 100 megas. No sería problema, tengo que ver si puedo crearme una de 100 megas por ahí. Pero también he preguntado en la lista inglesa, a ver que me dicen, y quizás me ahorro el trabajo ;-) - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDVOWztTMYHG2NR9URAvHFAJ9/sJP7fMutC8J8PyOTNGv8ZdYZdACfUSy4 Q9DtHRUyfPPXX+3Q435BF44= =4rSy -----END PGP SIGNATURE-----

Carlos E. R.

15:28

New subject: [suse-linux-s] Ocupación de espacio en una part. reiserfs (era: Ext3 y ReiserFS)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-10-18 a las 14:08 +0200, escribí:

...

Si, el tamaño minimo de una reiser son 100 megas. No sería problema, tengo que ver si puedo crearme una de 100 megas por ahí. Pero también he preguntado en la lista inglesa, a ver que me dicen, y quizás me ahorro el trabajo ;-)

Efectivamente, es un error del "du". me han contestado esto: |Date: Mon, 17 Oct 2005 20:34:35 -0500 |From: Scott Jones |To: suse-linux-e@ |Subject: Re: [SLE] Space used by files on a reiser partitition. | |On Monday 17 October 2005 19:51, Carlos E. R. wrote: | |<snip> | | > So... either reiserfs does not save space when storing small files, as | > the documentation says, or df is calculating space based on a 4 Kb | > granularity, as would be for a "normal" file system. | > | > Is it a bug of df? Am I getting it wrong somewhere? | | From the FAQ at http://namesys.com/faq.html#du: | | "du says ReiserFS makes space efficiency worse. | | Use df not du, or use "raw" option for du if your du supports that. | st_blocks summed up is less accurate than st_size for ReiserFS because | we pack tails, and st_blocks rounds numbers up." | | Note that du as provided in the GNU coreutils doesn't support the "raw" | option. | Lo explica en el FAQ de reiser, du calcula mal el espacio, salvo que se use la opción raw - que no existe en la versión gnu que tenemmos. O sea, reiser si compacta el espacio usado. El programa df si que daba el resultado correcto; entonces, recupereando una de mis probatinas: Filesystem 1K-blocks Used Available Use% Mounted on /dev/hdb12 9526168 3575564 5950604 38% /Disco40/nuevo /dev/hdb12 9526168 3576756 5949412 38% /Disco40/nuevo ---------- ------------------------------------------------ diferencia: 1192 Kb 1192 Kb Esos mil ficheros de 1K ocupaban en realidad 1192Kb, o sea, 1.1Mb, en vez de los 4 megas que ocuparían si se reservara el sector entero de 4Kb. Por tanto, a la pregunta original de David: | He decidido mantener EXT3, ya que FSReiser es algo lento para el acceso | a millones de archivos (comprobado) y consume bloques de 4Bytes, en vez | de 1Kbytes que necesito. hay que decirle que NO consume bloques de 4Kb, sino que aprovecha el espacio metiendo aproximadamente 4 ficheros en un bloque, y que puede meter tranquilamente un millón de ficheros en un único directorio. Si lo nota lento, puede ser porque le falta memoria en el sistema. O porque no lo monta "noatime". Y al fin y al cabo, el algoritmo de reiser para compactar el espacio tiene que gastar su tiempo. Y si no, pues puede intentar usar reiserfs4 (ver el punto 3): [http://www.namesys.com/] Reasons why Reiser4 is great for you: * Reiser4 is the fastest filesystem, and here are the benchmarks. * Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice. * Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down). This makes Reiser4 more space efficient than other filesystems because we squish small files together rather than wasting space due to block alignment like they do. It also means that Reiser4 scales better than any other filesystem. Do you want a million files in a directory, and want to create them fast? No problem. * Reiser4 is based on plugins, which means that it will attract many outside contributors, and you'll be able to upgrade to their innovations without reformatting your disk. If you like to code, you'll really like plugins.... * Reiser4 is architected for military grade security. You'll find it is easy to audit the code, and that assertions guard the entrance to every function. {si quereis la traducción, otro dia} Otros que lo han probado con la 9.3 dicen, sin embargo, que falla. Si SuSE estuviera seguro de su fiabilidad, el particionador de yast lo usaría, y no es así, no todavía. *** Prueba de velocidad comparada ext3 vs reiser. *** Pruebo a crear 30000 ficheros de 1 KB, primero en una reiser: real 2m22.138s user 0m53.819s sys 1m19.976s luego en una ext3: real 3m25.283s user 0m54.181s sys 2m21.413s Se ve claramente que la reiser tarda un 69% del tiempo que tarda la ext3. O sea, demostrado que la partición reiser es más rápido creando miles de ficheros de 1K. ¡Comprobado! El tiempo de proceso en la ext3 empieza por cinco segundos (4.779s), pero va aumentando considerablemente: a los 15000 ficheros ya tarda 6.346s por cada bloque de 1000 y 9.553 los ultimos 1000. Es decir, ext3 se va haciendo progresivamente más lento conforme el directorio tiene más ficheros. En cambio la reiser no mostró este comportamiento, en todo el proceso se mantuvo entre 0m4.589s (serie 13) y 5.330s (serie 19) - incluso parece que va más rápido conforme pasa el tiempo. En realidad es que va oscilando ligeramente en ambas direcciones, quizás según yo escribo estas notas. Ambas particiones están en un disco que no tiene actividad alguna, por lo que es ideal para estas pruebas; ambas están montadas rw,noatime, y ambas estan cercanas en el disco (pistas 2643 a la 3165 la ext3, y 3680 a la 4865 la reiser). Incluso la reiser está más al interior, que es más lento: nimrodel:/Disco40/cosas # hdparm -tT /dev/hdb9 /dev/hdb9: Timing cached reads: 860 MB in 2.01 seconds = 428.78 MB/sec Timing buffered disk reads: 72 MB in 3.00 seconds = 23.99 MB/sec nimrodel:/Disco40/cosas # hdparm -tT /dev/hdb12 /dev/hdb12: Timing cached reads: 840 MB in 2.00 seconds = 420.06 MB/sec Timing buffered disk reads: 62 MB in 3.08 seconds = 20.16 MB/sec O sea... clarísimo :-) Respecto a la ocupación: reiser: Filesystem 1K-blocks Used Available Use% Mounted on /dev/hdb12 9526168 3575564 5950604 38% /Disco40/nuevo /dev/hdb12 9526168 3611032 5915136 38% /Disco40/nuevo ----> 35468 Kb ocupa aprox 1.18 Kb por fichero. (du: 120937 Kb, incorrecto) ext3: Filesystem 1K-blocks Used Available Use% Mounted on /dev/hdb9 4134900 2002140 1922712 52% /Disco40/cosas /dev/hdb9 4134900 2122712 1802140 55% /Disco40/cosas ---> 120572 Kb ocupa aprox 4.019Kb por fichero. (du: 120592 Kb, correcto y consistente con df) El sistema ext3 ocupa espacio según su granularidad. El reiser no, pero por contra su estructura de directorios ocupa algo más (el espacio de nombres); es en realidad una base de datos con arbol balanceado - y quien sepa lo que es eso nos lo explique ;-) - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDVRSwtTMYHG2NR9URAhoLAJ92iIjdn0EPz91fS8y0R1a6kWx+1QCbBWk+ OY67/FyPhJXaewBmlIN1QLQ= =T/rI -----END PGP SIGNATURE-----

6831

Age (days ago)

6832

Last active (days ago)

List overview

Download

13 comments

7 participants

participants (7)

admin-listas
Carlos E. R.
csalinux
Juan Carbajal Paxi
miguel gmail
Rafael Griman
Victor Hugo dos Santos