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