A mi juego me han llamado. En mi siguiente respuesta a ese tema en la lista de Venezuela, le cuestionaba a Ernesto, el hecho de que mi pregunta se refería a la versión 4 de Reiserfs, y el respondió con citas de un sitio de IBM, cuya información es del año 2001, y están referidas a las primeras versiones usadas de Reiserfs. http://www.namesys.com/v4/v4.html http://www.namesys.com/benchmarks.html http://www.namesys.com/bad-block-handling.html http://www.academicdb.com/this_research_paper_will_present_research_on_vario... http://fsbench.netnation.com/ Por ahora (todavía se encuentra en desarrollo), en el unico caso que se desaconseja su uso, es en servidores de producción con bases de datos de unos cuantos Gigabyte de tamaño. Yo lo estoy usando desde la versión 8.2 de SuSE, sin inconvenientes. Si Reiserfs, no fuese un sistema de archivos confiable, SuSE, no lo pondría por defecto, ya que está en juego su prestigio. Hipolito A. Gonzalez M. wrote:
manolo wrote:
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??
Reproduzco un par de Emails de la lista de Venezuela:
Son de Ernesto Henrandez novich los emails (por coypright)
On Wed, 10 Mar 2004, Juan Erbes wrote:
Mensaje citado por: Ernesto Hernandez-Novich
: [...]
¿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.
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...
Sin comentarios.
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
-- ------------------------------------------------------
Una prensa libre es el gran enemigo de los dictadores. Independientemente de sus abusos, sus debilidades, sus errores. Una prensa libre es la gran aliada y defensora de la democracia.
Charlos S. Shapiro Embajador de USA en la Rep. de Venezuela Martes, 20 de Mayo 2003