SuSE por defecto te propone formatear en Reiser y no en Ext3 o Ext2, por 
ejemplo.
¿Que ventajas o inconvenientes tiene Reiser sobre Ext3, o viceversa? ¿Que 
sistema de archivos es mejor o mas conveniente, teniendo en cuenta que soy un 
usuario domestico digamos normal??
¿Cual usais vosotros??
  

On Wed, 10 Mar 2004, Juan Erbes wrote:

> Mensaje citado por: Ernesto Hernandez-Novich <emhn@telcel.net.ve>:
  

[...]

¿Por que citas todo un texto que no es relevante a tu pregunta?

> ¿Hay algun test o estadistica sobre estabilidad, comparativo de
> Reiserfs 4.0 con respecto al resto de los File System?
  

Varios. Y ReiserFS sigue siendo el peor de todos en peak performance
cuando hay grandes volúmenes de datos; y es generalmente el mejor
cuando hay archivos pequeños (< 4k). Particularmente no me interesa éste
último escenario porque en los sistemas Unix hay dos sitios en los
cuales me enfrentaría con eso:

1. En un servidor NNTP (que no tengo).
2. En un servidor de correo con Maildir y una cantidad grosera de
   buzones en un sólo mailspool (que no tendría instalado así .

Siempre resultan XFS y JFS primeros, ext3 segundo y ReiserFS tercero...
pero un tercero "lejos" porque la diferencia entre primero y segundo es
de menos del 5%, pero la diferencia entre segundo y tercero es casi 30%.
De todos modos, puedes hacer tus propias pruebas con dbench [1],
bonnie++ o IOZone.

Un problema con ReiserFS es que trata de "emular" lo que hace un NTFS [2], y
por muchas razones técnicas eso no es una buena idea cuando se quieren
manejar archivos muy grandes; más allá de eso, que afecta un aspecto
específico del almacenamiento, ReiserFS puede optimizar la velocidad _o_
el uso de espacio en disco; pero es un _o_ exclusivo. Entonces, se puede
tener un ReiserFS que es sumamente rápido en comparación con cualquier
otro sistema de archivo, pero que consume _mucho_ más espacio para
metadata; no fue diseñado con un "punto medio" en mente como es el caso
de XFS, JFS y ext2/3. Eso, para un administrador serio, es un
inconveniente grande cuando tiene que optimizar particiones en las
cuales se necesita alta velocidad y bajo consumo de metadata (por
ejemplo, las particiones para bases de datos y/o multimedios).

Es muy importante separar dos escenarios diferentes, cada uno con dos
variaciones (cada '>' indica mejor).

- Sistema de archivo con archivos _pequeños_ (sin bloques indirectos).
  * Configuración por defecto: XFS >> ReiserFS > Ext3
  * Configuración ajustada: XFS > Ext3 > ReiserFS
- Sistema de archivo con archivos _grandes_ (con bloques indirectos
  y doble indirectos).
  * Configuración por defecto: XFS ~ Ext3 >> ReiserFS
  * Configuración ajustada: XFS > Ext3 >>> ReiserFS

XFS y ext3 tienen _muchísimos_ más parámetros de configuración que
ReiserFS [3], por tanto se pueden ajustar con mucha más precisión a la
cantidad, tamaño y modalidad de uso de los archivos que contenga el
sistema de archivos, he ahí la diferencia. Un usuario "normal" que
simplemente instala una estación de trabajo, probablemente no note la
pequeña diferencia; un administrador con un servidor que maneja gran
volumen de datos, transacciones y concurrencia, seguro.

Otro escenario fundamentalmente negativo para ReiserFS son los archivos
esparcidos (aquellos que tienen bloques disgregados con mucha
fragmentación interna... adivinaron, los de una base de datos). Es
_inevitable_ que ReiserFS sea mediocre y malo para manejarlos. Y uno que
es _vergonzoso_ es cuando la aplicación hace muchos stat() en secuencia,
e.g. usar un lector de correo sobre un buzón maildir que tenga muchos
mensajes... Por último, nadie prueba los sistemas de archivo explotando
las características modernas necesarias para operación de servidor de
archivo avanzado (ACLs, listas de atributos, etc.) que en ext3 y en XFS
existen hace rato y son muy estables, cuando en ReiserFS están comenzado
a aparece (con los mismos problema que tiene stat()).

Eso sin contar que es difícil recuperar un sistema ReiserFS dañado.
No existe una herramienta como debugfs para ReiserFS [4].

El trabajo más serio que conozco, y además realizado en un entorno
académico, está en http://oregonstate.edu/~kveton/fs/;
desafortunadamente, es un trabajo para un sistema de archivo que tiene
que tener muchísimos archivos _pequeños_, con muchos enlaces entre sí
(porque es para NNTP). Precisamente todo lo contrario al almacenamiento
de una base de datos o multimedios. Así mismo, está basado en versiones
de ext3 que eran notablemente lentas (pre-2.4.20 es terrible). En todo
caso, en ese mismo artículo hay enlaces a toda una serie de documentos
de IBM que son muy ilustrativos de lo que ha sido la evolución de los
sistemas de archivo y, si uno lee entre líneas, se puede ver que
ReiserFS siempre ha estado por detrás de ext3, XFS y JFS en lo que
refiere a escalabilidad y rendimiento en grandes instalaciones (nunca
fue su objetivo, claro está).

Es un hecho que ReiserFS es el proyecto más ambicioso de sistema de
archivo que existe, y eso hace que lo observe con mucha atención y
curiosidad. Sin embargo, en lo estrictamente profesional y siendo
objetivo, me parece _irresponsable_ utilizarlo en cualquiera de mis
sistemas en producción y personales. "Journaling" no es blanco o negro,
tiene muchos matices de gris que en XFS y ext3 están cubiertos
completa y correctamente, y ReiserFS está recién comenzando a mezclar
blanco y negro: quizás lo hagan muy bien en el futuro, pero _hoy_ tengo
que garantizar estabilidad, escalabilidad y seguridad, por eso NO lo
uso.

[1] Que es un clon libre de la suite NetBench. No es una prueba de "vida
    real" sino algo más intensa (pero predecible). Si diseñas una prueba
    de vida real donde los archivos almacenados sean muy grandes y/o
    tengan mucho acceso concurrente (e.g. bases de datos, streams
    multimedia) entonces ReiserFS queda aún peor.
[2] Btrees con algunas cochinadas adicionales. Es como tener un engendro
    resultado de cruzar un índice de bases de datos con un sistema de
    archivo basado en extents, pero con la fragmentación interna
    manejada con listas cruzadas. Es como tratar de sacar las mejores
    ideas de cada sistema, pero el resultado es un tanto caótico de
    ajustar para rendimiento.
[3] http://www-106.ibm.com/developerworks/linux/library/l-fs7/
    http://www-106.ibm.com/developerworks/linux/library/l-fs8/

    Sólo un ejemplo, ext3 en modo data=ordered no tiene vida al lado
    de ReiserFS. Pero le pones data=journal y es 800% más rápido que
    ReiserFS (ocho CIENTOS).

[4] No digo que todo usuario quiera ni deba usar debugfs, pero los que
    lo hemos necesitado y utilizado sabemos que nos ahorró, no sé, ¿30
    horas de restauración de datos? En ReiserFS para una falla similar,
    ni modo, reformatear y recuperar.
-- 
Ernesto Hernández-Novich - On Linux 2.6.3 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't apt-get it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3

On Thu, 11 Mar 2004, Juan Erbes wrote:

> Perdón Ernesto, pero se te pasó por alto un detalle relevante de la
> pregunta, que se refería a la  _versión 4_ de _Reiserfs_, y la
> información que suministraste, se refiere a las primeras versiones de
> Reiserfs ya que tienen tienen 3 años de antigüedad, por lo que carecen
> de relevancia.
  

> http://www.namesys.com/v4/v4.html
> http://www.namesys.com/benchmarks.html
  

¡Oh no! No se me pasó por alto... precisamente como los _únicos_
benchmarks disponibles para V4 son producto de la propia gente de ReiserFS,
sería absurdo primero confiar en ellos y segundo citarlos como benchmark
"válido". Vvisita la página de MySQL a ver si encuentras un benchmark donde
diga que es peor que PostgreSQL  Es como preguntarle al carnicero si el
pescado está fresco (si, el pescado).

En todo caso, el benchmark está hecho precisamente para directorios con
archivos _pequeños_. Por otro lado, y como lo dice en la propia página,
son benchmarks que no reflejan la vida real, simplemente hacen
operaciones masivas secuenciales.

Y si bien ReiserFS V4 es más eficiente en uso de espacio para metadata
que V3, sigue siendo más costoso que XFS, JFS y ext3.

Noten que ReiserFS _nunca_ es probado con archivos gigantescos, mucho
menos con archivos gigantescos que reciben muchas lecturas/escrituras
concurrentes y además puede ser esparcido (como los de bases de datos o
multimedios).

¿Que si yo he hecho pruebas? Seguro. ¿Que si las puedo mostrar?
Lamentablemente no, porque son pruebas hechas con Oracle, y la licencia
de Oracle _prohibe_ explícitamente mostrar resultados de benchmarks donde
se use su producto si tal prueba no ha sido autorizada por escrito por
Oracle. ¿Cuáles son los resultados? XFS es mejor que ext3 y ReiserFS (en
cualquiera de sus versiones) es patético; y si los sistemas de archivo
están sobre un RAID por software o un LVM, la diferencia es aún mayor.
Pero mi prueba es con un sistema de archivo de 200Gb, donde hay un
archivo de 100Gb, un archivo de 50Gb, un archivo de 25Gb, diez archivos
de 2Gb y unos trocitos sueltos; todo en un sólo directorio porque se
trata de una base de datos Oracle. No es una pruebita de decenas de
miles de archivitos porque eso no existe en una base de datos grande, y
tampoco es con operaciones masivas de creación, borrado, porque eso
tampoco existe en una base de datos grande (ni siquiera en un sistema de
archivo regular, a menos que sea... ¡oh cielos! Un proxy, un NNTP, o un
mailspool con Maildir.

> http://www.namesys.com/bad-block-handling.html
  

Poco tiene que ver con un benchmark... ahora, están descubriendo el agua
tibia, realmente.

> http://www.academicdb.com/this_research_paper_will_present_research_on_vario_7248/
  

Sin comentarios.

> http://fsbench.netnation.com/
  

La primera línea es lo más interesante.

Pero dice lo mismo que en mi mensaje anterior: para sistemas con muchos
archivos muy pequeños, ReiserFS sale mejor parado en una instalación por
defecto; para sistemas con archivos gigantescos o con I/O sostenido
concurrente, XFS va por encima. La posición de ext3 depende no solamente
de como esté configurada la meta-data, sino de la distribución de los
datos dentro. Nada que no se haya dicho antes.

Nuevamente, usan bonnie++ que NO ES una prueba de vida real.
-- 
Ernesto Hernández-Novich - On Linux 2.6.3 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't apt-get it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3