RE: [suse-linux-s] Sistema de ficheros similar a una BBDD
Hola :)
Reiser tiene un problema y es que los ficheros con los que trabaja óptimamente son de 4KB. En el caso que tenemos entre manos, el cliente tiene ficheros de más de 4 KB (entre 128 KB y 524 MB). Además, no actúa como base de datos :(
No directamente, pero según sus desarrolladores está pensado para eso: la idea es grabar directamente los datos en ficheros del tamaño que quieras sin necesidad de que el motor de la base de datos tenga que situarlos dentro del fichero enorme de la base de datos. Eso lo explican en su web. El problema es encontrar una base de datos que lo use, pero cuando pregunté sobre eso hará como un año en la lista inglesa me dijeron que Perl ya tenía algo de eso. Abajo te lo copio.
Eso ya me alegra más saberlo :) Si con Perl se puede hacer algo ...
Según el manual de SuSE ;-) trabaja con bloques de cualquier tamaño, no 4kB (Ch 20.2.1 del admin de 9.3); mejor dicho, el bloque tiene el tamaño exacto del fichero.
Sí, reiserfs creo que puede "cambiar el tamaño del bloque on the fly" o algo así leí, pero no me acuerdo (otra cosa buena que tiene ;). Lo que pasa es que su tamaño de fichero óptimo es de 4 KB, no me refería al tamaño de bloque escrito a disco ;) [...]
no permitía snapshots,
¿dump? No, no va.
Según el man: "DESCRIPTION Dump examines files on an ext2/3 filesystem and determines which files need to be backed up. [...]"
tamaño de filesystem y tamaño de fichero máximo pequeño,
El tamaño máximo de fichero son 64GB, y del sistema de ficheros 8 EB (ReiserFS v3). ¿Eso es pequeño para ti? :-p
XFS: 18 EB como filesystem y 9 EB como fichero ;)
Pero el kernel impone otro limite: 2 TB por fichero, y 2^73 por sistema (que todavía no lo soporta ningún FS).
Eso es otra ;) La verdad es que límites tan grandes, por ahora no conozco, aunque nuestros clientes me sorprenden cada día más :)
no es bueno/aconsejable en sistemas de ficheros con mucha lectura-escritura (/var, por ejemplo), ...
Eso no lo se.
He intentado encontrar dónde lo leí, pero no lo encuentro. Daban una explicación técnica de por qué no era bueno que se usara reiserfs en un sistema de ficheros de mucha escritura/lectura. Lo más seguro es que hayan corregido esto ya en la versión 4.
Lo que sí me gusta (en la versión 4):
Es experimental todavía.
- compresión de ficheros
Me encanta eso :-)
La única duda que me queda es el tema de benchmark: ¿cuánta CPU se consume por KB/MB? ¿memoria RAM requerida? ¿rendimientos? Hoy en día, al precio que están los discos ... creo que poco se va a utilizar. Aunque en lo que se llama "Data Lifecycle Management", puede ser muy útil y aque trabajar con discos es más rápido y fiable que con cintas. Creo que me voy a poner a pensar seriamente en reiserFS :)
- cifrado de ficheros - plugins (aunque a algunos desarrolladores del kernel no les guste)
Eso ya estaba previsto, precisamente para bases de datos.
Me va gustando más ;) ... A que al final me hago converso ;)
- cómo organiza ficheros pequqeños cuando no ocupan el bloque entero
Eso ya estaba en la 3.
Sip :) A ver si se empieza a incluir en distribuciones de forma oficial (en la 9.3 está en el DVD, pero no aparece durante la selección de paquetes de YaST ;). Según tentgo entendido hay alguna discrepancia entre los de Namesys y los del kernel ... si alguien sabe cómo está actualmente esta relación ... que nos ponga al día :) [...]
Y si quieres más, pues posiblemente tenga el hilo entero, o lo puedas ver en el archivo html.
Muchas gracias, voy a ver si puede resultar interesante y ya me meto rebuscar en el hilo :) Rafa
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-07-18 a las 13:27 +0100, Rafael Griman escribió:
El problema es encontrar una base de datos que lo use, pero cuando pregunté sobre eso hará como un año en la lista inglesa me dijeron que Perl ya tenía algo de eso. Abajo te lo copio.
Eso ya me alegra más saberlo :) Si con Perl se puede hacer algo ...
Estan todos empezando, imagino.
no permitía snapshots,
¿dump? No, no va.
Según el man:
"DESCRIPTION
Dump examines files on an ext2/3 filesystem and determines which files need to be backed up. [...]"
Ese es el problema, que reiserfs es muy prometedor, tiene cosas muy avanzadas, y en cambio cosas basicas no las han hecho. > > > tamaño de filesystem
y tamaño de fichero máximo pequeño,
El tamaño máximo de fichero son 64GB, y del sistema de ficheros 8 EB (ReiserFS v3). ¿Eso es pequeño para ti? :-p
XFS: 18 EB como filesystem y 9 EB como fichero ;)
En SuSE, 8 y 8 solamente :-p Ah, pero el de sistema de reiserfs v3 son 32 TB, me equivoqué al transcribir. (Ch 20.4 admin book).
Pero el kernel impone otro limite: 2 TB por fichero, y 2^73 por sistema (que todavía no lo soporta ningún FS).
Eso es otra ;) La verdad es que límites tan grandes, por ahora no conozco, aunque nuestros clientes me sorprenden cada día más :)
Si, como los de IBM con sus discos grandes de 32 megas hace unos cuantos años ;-)
no es bueno/aconsejable en sistemas de ficheros con mucha lectura-escritura (/var, por ejemplo), ...
Eso no lo se.
He intentado encontrar dónde lo leí, pero no lo encuentro. Daban una explicación técnica de por qué no era bueno que se usara reiserfs en un sistema de ficheros de mucha escritura/lectura. Lo más seguro es que hayan corregido esto ya en la versión 4.
Será bonito verlo, pero me esperaré unos añitos ;-)
Lo que sí me gusta (en la versión 4):
Es experimental todavía.
- compresión de ficheros
Me encanta eso :-)
La única duda que me queda es el tema de benchmark: ¿cuánta CPU se consume por KB/MB? ¿memoria RAM requerida? ¿rendimientos?
Hoy en día, al precio que están los discos ... creo que poco se va a utilizar. Aunque en lo que se llama "Data Lifecycle Management", puede ser muy útil y aque trabajar con discos es más rápido y fiable que con cintas. Creo que me voy a poner a pensar seriamente en reiserFS :)
Depende de los usos y de quien lo use. Yo, por ejemplo, me gusta mucho comprimir, aunque el espacio sea barato: digamos que lo contrario me parece desperdiciar recursos. El correo ocupa mucho, y como es texto se comprime muy bien - y me da rabia no poder comprimirlo aunque sea en modo sólo lectura. Me parece que una cosa ideal sería comprimir cosas que se escriban poco, como ejecutables, o los ficheros que no se hayan modificado en un tiempo determinado. En cambio, fichero de mucho uso no hace falta. Mira, el OO comprime sus ficheros, son archivos zip, lo cual hace la carga lenta. Si pudiera trabajar con un sistema de ficheros comprimido, no haría falta comprimirlo excepto cuando se envian al exterior. La cuestión es que el formato de fichero interno usado por el OO (XML), y que se está poniendo de moda, es muy poco eficiente en terminos de espacio usado. Por eso comprimirlos tiene mucho sentido, y si es el disco el que es comprimido en lugar del fichero, el conjunto será más rápido y al mismo tiempo eficiente.
- cifrado de ficheros - plugins (aunque a algunos desarrolladores del kernel no les guste)
Eso ya estaba previsto, precisamente para bases de datos.
Me va gustando más ;) ... A que al final me hago converso ;)
Si, pos yo lo quité de algunas particiones O:-) Soy ambivalente: me gusta mucho, y me fio poco.
- cómo organiza ficheros pequqeños cuando no ocupan el bloque entero
Eso ya estaba en la 3.
Sip :)
A ver si se empieza a incluir en distribuciones de forma oficial (en la 9.3 está en el DVD, pero no aparece durante la selección de paquetes de YaST ;).
No, y a propósito, para que nadie lo instale por error sin saber lo que está haciendo.
Según tentgo entendido hay alguna discrepancia entre los de Namesys y los del kernel ... si alguien sabe cómo está actualmente esta relación ... que nos ponga al día :)
Ni idea.
[...]
Y si quieres más, pues posiblemente tenga el hilo entero, o lo puedas ver en el archivo html.
Muchas gracias, voy a ver si puede resultar interesante y ya me meto rebuscar en el hilo :)
Por cierto, que los hilos ingleses se pueden encontrar fácilmente, están numerados. Los nuestros no. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFC3ZZZtTMYHG2NR9URAnWoAJ4mwCC9k3Fp99GKEq5g+RVCfBPjYACdFaou n267pPck5oKav6X/02U8cIM= =BmQT -----END PGP SIGNATURE-----
participants (2)
-
Carlos E. R. -
Rafael Griman