Question

Buenas!

Estoy en la necesidad de actualizar algunos servicios, y en el espacio asignado, estoy en la duda del File System a utilizar.

Especialmente, me interesa la deduplicación y punto adicional para la compresión

Luego, quisiera implementarlo para el File System del mailserver (postfix, 600 GB a hoy)

Estos servicios están virtualizados.

¿qué recomendarían para cada caso?

Answer 1

Buenas, yo probé deduplicación y compresion sobre unos 100Gb de Maildir y tuve mejor resultado con compresion usando un algoritmo barato que con dedup, basicamente lo deduplicable era despreciable asi que no vale el gasto de ram y cpu. (al menos en mi caso)

Lo realmente útil para mi fueron los snapshots y la replicacion a un storage remoto. Mas de una decena de veces fui a recuperar emails borrados a un snapshot, es super rapido y económico.

en mi opinion y por lo que se escucha en sysarmy nadie tiene BRTFS en producción y si hay mucho ZFS.

Comments

Voy a intentar con ambos..
Con compresión solamente, pude aprovechar mejor un 40% de 5GB que usé de testigo.

Creo que el snapshot remoto podría estar  bueno.. no lo había tenido en cuenta

Answer 2

ZFS toda la vida, tengo los dos corriendo y btrfs nunca andubo bien, en cambio ZFS con compresion es buenisimo. Para el fs de un postfix donde el espacio este ocupado por los mailboxes o maildir con la compresion deberias ganar mucho espacio con poco consumo de procesador.

Deduplicacion sobre zfs no lo probe nunca.

 

Saludos

Comments

Para el FTP estoy haciendo la prueba posta con compress y dedup.

En la prueba 1, compress me arrojaba un ratio de 1.4

En la prueba actual (compress+dedup):

[email protected]:/srv/ftp/prueba# zpool get dedupratio srv ; zfs get compressratio srv
NAME  PROPERTY    VALUE  SOURCE
srv   dedupratio  1.15x  -
NAME  PROPERTY       VALUE  SOURCE
srv   compressratio  1.57x  -

Answer 3

De una ZFS! Aunque también me inclino por compresión (podés ir probando con distintos algoritmos). La deduplicación es muy costosa en términos de RAM, creo que en general se calcula 25GB RAM por 1TB disco. Es cuestión de poner en la balanza según los recursos que tengas disponibles y la escalabilidad que necesites.

Comments

Terminé con zfs, compresión LZ4

La dedup es costosa, pero no tanto.
Son 5GB de RAM por TB.

En este FTP, estoy recibiendo 150 mensajes menores a 20K por minuto y tengo desde el año 2013.
Como no hubo mucha coordinación entre los sectores, tengo la data cuatriplicada al menos.

Bacula no está muy contento :/ ...

Answer 4

Mirá, yo tuve un mailserver sobre btrfs durante unos años, sobre un LUN de SAN IBM. Todo bien hasta que tuve problemas "Writing index update: No space left on device",  y tuve que hacer "balanceos" vía cron, para mantener el filesystem funcionando, pues el problema eran los metadatos de brtfs

mda:~# btrfs filesystem df /var/spool/cyrus/
Data, single: total=1.26TiB, used=349.31GiB
System, DUP: total=8.00MiB, used=160.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=3.50GiB, used=2.99GiB
Metadata, single: total=8.00MiB, used=0.00B

# btrfs balance start -v -dusage=5 /var/spool/cyrus/
Dumping filters: flags 0x1, state 0x0, force is off
  DATA (flags 0x2): balancing, usage=5
Done, had to relocate 213 out of 1302 chunks


Inicialmente suponía que el problema era del soft MDA, y recibí esta respuesta que -por supuesto- me hizo sentir un pelotudo:

"

Why would anybody ever run production data on btrfs?

https://btrfs.wiki.kernel.org/index.php/Main_Page

"The Btrfs code base is under heavy development."

https://btrfs.wiki.kernel.org/index.php/Gotchas

"Files with a lot of random writes can become heavily fragmented (10000+ extents) causing trashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM."

"

En fin. Volví a ext4.


Javier.-

 

Comments

Seta pul está más maduro, y muy, muy eficiente. Con compresión, es mi fav para los logs.