[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Filesystem con compressione




Il 19/10/21 10:46, Marco Ciampa ha scritto:
On Tue, Oct 19, 2021 at 09:36:33AM +0200, Alessadro Baggi wrote:
Buongiorno a tutta la lista.

Ho un piccolo server di backup con Debian 11 e 2 dischi da 3TB in raid1 con
mdadm. Il backup lo faccio con uno script rsync. Stavo cercando dei
filesystem che avessero la compressione trasparente e ho trovato btrfs e
ZFS. Leggendo sui due, ho preso nota anche di tutte le altre caratteristiche
come deduplicazione, checksumming e relativo recovery, snapshot, COW
filesystem e varie.

Leggendo su btrfs da qui [0] sono rimasto abbastanza sfiduciato dai molti
problemi che presenta btrfs.
In particolare quale problema ti assilla?

La perdita dei dati (anche se sono backup). Leggendo il wiki sembra non sia troppo affidabile, nel senso che ci sono talmente tante raccomandazioni che mi fa pensare di doverlo evitare. Ovviamente non l'ho mai usato come si deve ne per tempi prolungati quindi non posso giudicarlo realmente.

ZFS d'altra parte (se non sbaglio si trova in contrib) è di tutt'altra
pasta, funziona bene
vedo che il marketing di Oracle funziona molto bene...

sappi che btrfs è usato in ambito enterprise da aziende multinazionali.
Se va bene per loro penso possa andare bene anche per te...

Si, ho visto che btrfs è usato un bel po e si credo che vada bene per il mio utilizzo. Non credo  che quelli di SUSE si siano bevuti il cervello usandolo come default. Sono in cerca di esperienze per non incappare in problemi catastrofici. In VM tutto va sempre bene poi quando lo si usa con dati veri iniziano le rogne. Leggendo su Reddit sembra che Oracle stia spingendo anche btrfs perche nella loro versione di EL hanno reintregrato il modulo e le util a differenza di rhel (e di centos, almalinux e rockylinux) che lo hanno completamente tagliato fuori (sia moduli che util).


https://forum.armbian.com/topic/16285-why-i-prefer-zfs-over-btrfs/

il discorso che fa il tipo nella prima risposta, che non è un fan btrfs
ma neanche zfs anche se usa il secondo, è molto onesto...
grazie per la risorsa.

ma (al di fuori della licenza) il sistema deve
compilare un modulo e ad ogni aggiornamento del kernel dkms deve
ricompilarlo e questo mi rende nervoso. Non vorrei che la compilazione con
dkms fallisse e il filesystem non più accessibile.
welcome to the reality...

ZFS l'ho provato in
macchina virtuale con volumi in raid1, e a primo sguardo sembra
eccellente...l'unica cosa che mi lascia perplesso oltre a dkms è che durante
l'installazione viene mostrato una specie di disclaimer dove si dice che si
puo andare incontro a problemi legali per la licenza (sapete quali e in
quali casi ci si va incontro?). Se non ricordo male Ubuntu lo utilizza e
integra senza problemi.
Ubuntu lo ha integrato non senza polemiche. Molti pensano che abbiano
"interpretato" la licenza in modo "creativo". Ovvio(?) che Oracle non
denuncerà mai Canonical ma non è questo il punto... qui siamo in Debian
con una filosofia un "filino" diversa ... o no?

Ora avendo poca esperienza con tutti e due, qualcuno ha avuto a che fare con
questo tipo di filesystem? Avete incontrato particolari problemi? Ci sono
alternative valide?
Io uso da tempo btrfs sia direttamente con Debian che indirettamente (Synology).

Ho letto di Synology e anche sul loro sito ne parlano.

Ora vado un attimo off-topic: sulle distro rhel based ci sta anche il VDO e i relativi tool. Praticamente aggiunge un layer per la compressione e deduplicazione. La cosa che mi lascia un po perplesso è che un volume vdo deve presentare una dimensione logica che il filesystem (xfs) va ad usare. Quindi se un fs XFS risultasse usato al 100%, mentre sul volume magari siamo al 30%, bisogna aumentare la logical size e fare un resize del filesystem per fargli avere più spazio...cosi bisogna monitorare sia il filesystem classico sia il volume vdo. Bo devo approfondire anche se ho visto che su debian non c'è traccia di VDO. Ovviamente VDO non è un fs con cow, con integrity, snapshot e varie.

Grazie per la risposta.



Reply to: