Parliamo di Btrfs

[PC ZERO]

Io ci capisco poco anche perché sono pigro ed ho lasciato tutto com'era già impostato...mi iscrivo solo per ricordarmi che devo mettermi a leggere come fare e mettermi in pari.

[korda]

È importante ricordare che se hai abilitato la compressione e desideri mantenerla durante la deframmentazione, devi aggiungere il flag per la ricompressione dei dati, che è "-czstd" per l'algoritmo Zstd.
Vale la stessa cosa per le copie che sfruttano il "reflink".

Ho la compressione abilitata in fstab (compress=zstd:1), devo editare il file o metto quella opzione sul comando di defrag?

PS: Dai una lettura a questo post: https://wiki.tnonline.net/w/Btrfs/Defrag

Grazie della risorsa, ora la leggo...

Ciao @emanuc, ho deframmentato come indicato nel link fornito. MI sorgono ora però un paio di dubbi a riguardo:

1. Il comando di deframmentazione prende come opzione l'algoritmo (nel mio caso -czstd) mentre nel file fstab è indicato pure il livello di compressione (io ho scelto compress=zstd:1 quando il default è 3). E' possibile che vengano impattate le prestazioni in qualche modo?
2. Allo stesso modo, come si comporterà Borg durante la creazione del nuovo snapshot di backup quando troverà il file del disco virtuale deframmentato? Allocherà spazio su disco come se fosse un file completamente nuovo?

[emanuc]

Ciao @emanuc, ho deframmentato come indicato nel link fornito. MI sorgono ora però un paio di dubbi a riguardo:

1. Il comando di deframmentazione prende come opzione l'algoritmo (nel mio caso -czstd) mentre nel file fstab è indicato pure il livello di compressione (io ho scelto compress=zstd:1 quando il default è 3). E' possibile che vengano impattate le prestazioni in qualche modo?
2. Allo stesso modo, come si comporterà Borg durante la creazione del nuovo snapshot di backup quando troverà il file del disco virtuale deframmentato? Allocherà spazio su disco come se fosse un file completamente nuovo?

1. No, perché durante la deframmentazione hai già scritto quei file comprimendoli con il livello 3. Quando accederai a quei file, sarà solo per la lettura. I nuovi file che verranno scritti saranno compressi in base all'opzione di mount, nel tuo caso con il livello 1.
2. Per Borg non cambierà nulla, perché ha il suo algoritmo di compressione e deduplicazione, e il proprio archivio per la gestione dei dati.

[korda]

Ciao @emanuc, ho deframmentato come indicato nel link fornito. MI sorgono ora però un paio di dubbi a riguardo:

1. Il comando di deframmentazione prende come opzione l'algoritmo (nel mio caso -czstd) mentre nel file fstab è indicato pure il livello di compressione (io ho scelto compress=zstd:1 quando il default è 3). E' possibile che vengano impattate le prestazioni in qualche modo?
2. Allo stesso modo, come si comporterà Borg durante la creazione del nuovo snapshot di backup quando troverà il file del disco virtuale deframmentato? Allocherà spazio su disco come se fosse un file completamente nuovo?

1. No, perché durante la deframmentazione hai già scritto quei file comprimendoli con il livello 3. Quando accederai a quei file, sarà solo per la lettura. I nuovi file che verranno scritti saranno compressi in base all'opzione di mount, nel tuo caso con il livello 1.
2. Per Borg non cambierà nulla, perché ha il suo algoritmo di compressione e deduplicazione, e il proprio archivio per la gestione dei dati.

Il dubbio su Borg mi viene appunto perché l'algoritmo di backup lavora su segmenti, e non sui file in sé. Non conoscendone l'algoritmo mi era sorto il dubbio che la deframmentazione possa alterare i contig dei segmenti (il loro ordine e/o sequenzialità). Per questo chiedevo, appunto (dal momento che già così Borg con gli snapshot dei dischi virtuali è piuttosto vorace di spazio su disco).

[saxtro]

....
Per questo chiedevo, appunto (dal momento che già così Borg con gli snapshot dei dischi virtuali è piuttosto vorace di spazio su disco).

Questo è vero per tutti i software di backup (dedup e incrementali che siano).
Considera che solo accendere una macchina virtuale genera già decine di mega di differenza rispetto a un backup appena finito,
e che a mano a mano che ci lavori arrivi a modificare tutto il disco in tempi piuttosto brevi.

In pratica ogni backup (full o incrementale che sia) salvi tutto il disco virtuale (o quasi)

[emanuc]

Se vuoi inviare al backup le immagini VM e sei su Btrfs:

• Crea un subvolume per le immagini VM
• Scegli le immagini RAW e non QCOW. Cosi eviti la problematica delle performance su COW <> COW.
• Inviali al backup con snap ro (dopo aver chiuso la vm) > btrfs send|receive in modo incrementale

PS: Creare uno script custom da avviare manualmente è abbastanza banale

[korda]

Se vuoi inviare al backup le immagini VM e sei su Btrfs:

• Crea un subvolume per le immagini VM
• Scegli le immagini RAW e non QCOW. Cosi eviti la problematica delle performance su COW <> COW.
• Inviali al backup con snap ro (dopo aver chiuso la vm) > btrfs send|receive in modo incrementale

PS: Creare uno script custom da avviare manualmente è abbastanza banale

Cosa intendi con le immagini RAW e non QCOW?
Cerco di disambiguare il più possibile, lato mio...

Quando parlavo di snapshot dei dischi virtuali con Borg intendevo dire la copia di backup, alla tal data, presente sul disco di backup di destinazione (non uno snapshot Btrfs).

Il subvolume @home non ha snapshot Btrfs ora (ho disabilitato Timeshift su quel subvolume) mentre il disco virtuale (un file .vdi di una vm Windows) viene backuppato a vm spenta as is verso un HDD di destinazione formattato Ext4 (quindi non so bene se sussista la problematica COW <> COW menzionata)

[saxtro]

...
Cosa intendi con le immagini RAW e non QCOW?
...

RAW e QCOW2 sono i formati disco utilizzati da kvm/qemu.
RAW è un contenitore "grezzo", suggerito per sistemi in cui siano richieste performance per operazioni I/O (ad esempio database server)
QCOW2 è un formato Copy On Write e permette di prendere le snapshots delle macchine virtuali, tramite le funzionalità dell'hypervisor (ultima volta che mi sono informato, le RAW non supportavano la snapshot a livello di vm).

Quello che ti suggeriva @emanuc (immagino supponendo tu avessi un subvolume dedicato per le vm, o cmq le vm su un subvolume sotto snapshot) era di fare una snapshot read only con le vm spente, e utilizzare la snapshot ro per salvarti il backup tramite btrfs send / receive.
Il vantaggio è che le macchine devono stare spente, solo mentre prendi la snapshot. Subito dopo puoi riaccenderle e fare il backup mentre le utilizzi.

La problematica COW <> COW sulle performance potrebbe presentarsi anche senza fare snapshots, in pratica hai due livelli di COW, quello nativo di btrfs, che quello embedded di qemu che appunto lavora su quello di btrfs, operazioni che hanno un costo in termini di I/O e potrebbero impattare le performance.

[korda]

...
Cosa intendi con le immagini RAW e non QCOW?
...

RAW e QCOW2 sono i formati disco utilizzati da kvm/qemu.
RAW è un contenitore "grezzo", suggerito per sistemi in cui siano richieste performance per operazioni I/O (ad esempio database server)
QCOW2 è un formato Copy On Write e permette di prendere le snapshots delle macchine virtuali, tramite le funzionalità dell'hypervisor (ultima volta che mi sono informato, le RAW non supportavano la snapshot a livello di vm).

Quello che ti suggeriva @emanuc (immagino supponendo tu avessi un subvolume dedicato per le vm, o cmq le vm su un subvolume sotto snapshot) era di fare una snapshot read only con le vm spente, e utilizzare la snapshot ro per salvarti il backup tramite btrfs send / receive.
Il vantaggio è che le macchine devono stare spente, solo mentre prendi la snapshot. Subito dopo puoi riaccenderle e fare il backup mentre le utilizzi.

La problematica COW <> COW sulle performance potrebbe presentarsi anche senza fare snapshots, in pratica hai due livelli di COW, quello nativo di btrfs, che quello embedded di qemu che appunto lavora su quello di btrfs, operazioni che hanno un costo in termini di I/O e potrebbero impattare le performance.

Ugh... i file .vdi sono dischi gestiti da VirtualBox7 come hypervisor (non ho prestato attenzione se ci fossero flag analoghi). In realtà non avrei bisogno di spegnere le vm per riaccenderle subito dopo: in pratica io stacco da lavoro, spengo le vm e faccio partire il backup di Borg overnight (in realtà dura anche meno ). La vm Windows non è un server che abbia bisogno di continuità (quello è il linux baremetal della macchina host ), ma solo la postazione di lavoro diurna per mansioni routinarie (che anche se backuppo ogni 2/3 giorni va bene uguale)

[emanuc]

Se vuoi inviare al backup le immagini VM e sei su Btrfs:

• Crea un subvolume per le immagini VM
• Scegli le immagini RAW e non QCOW. Cosi eviti la problematica delle performance su COW <> COW.
• Inviali al backup con snap ro (dopo aver chiuso la vm) > btrfs send|receive in modo incrementale

PS: Creare uno script custom da avviare manualmente è abbastanza banale

Cosa intendi con le immagini RAW e non QCOW?
Cerco di disambiguare il più possibile, lato mio...

Quando parlavo di snapshot dei dischi virtuali con Borg intendevo dire la copia di backup, alla tal data, presente sul disco di backup di destinazione (non uno snapshot Btrfs).

Il subvolume @home non ha snapshot Btrfs ora (ho disabilitato Timeshift su quel subvolume) mentre il disco virtuale (un file .vdi di una vm Windows) viene backuppato a vm spenta as is verso un HDD di destinazione formattato Ext4 (quindi non so bene se sussista la problematica COW <> COW menzionata)

Sulla parte raw vs cow ti ha spiegato tutto @saxtro
Btrfs send|receive ha la funzionalità "incrementale", ed è questa parte che ti consiglio di provare per confrontare le performance e le dimensioni dei backup.

https://wiki.ubuntu-it.org/Hardware/Dis ... 7C_receive
https://wiki.tnonline.net/w/Btrfs/Send

[korda]

Sulla parte raw vs cow ti ha spiegato tutto @saxtro
Btrfs send|receive ha la funzionalità "incrementale", ed è questa parte che ti consiglio di provare per confrontare le performance e le dimensioni dei backup.

https://wiki.ubuntu-it.org/Hardware/Dis ... 7C_receive
https://wiki.tnonline.net/w/Btrfs/Send

Le funzionalità di Btrfs send | receive sono certamente intriganti, che suggerisce certamente di provarle...
...ma con i dovuti tempi, dal momento che dovrei cambiare un bel po' di roba sullo status quo del mio sistema attuale come:

• cambiare hypervisor (o quantomeno capire se e come VirtualBox permetta di creare dischi virtuali in formato RAW piuttosto che QCOW)
• formattare il disco di backup di destinazione, da ext4 a Btrfs
• ripensare lo schema dei subvolumi attuali dedicandone uno esclusivo per le vm (possibilmente non annidato almeno per il momento, giusto?)

Prima di provare un benchmark tra Borg vs Btrfs send | receive dovrò prendere in considerazione tutto ciò credo.
Anche perché, come ha sottolineato giustamente @saxtro, non è poi così improbabile stravolgere il contenuto di un disco virtuale (o come si presenterebbe ad un backup) con una sessione d'uso di vm neanche troppo intensiva.

In ogni caso vi ringrazio: state facendo un lavoro ben coinvolgente a portare e divulgare qui (forum e wiki) l'argomento Btrfs.

Grazie

[emanuc]

Devi tenere in considerazione che se usi lo schema di backup con Btrfs send|receive sei obbligato, appunto, lato destinazione a Btrfs.
Se le VM le crei da Linux, ti consiglio di valutare kvm/qemu con l'api|gestore delle VM libvirt, puoi usare anche una GUI: VIrt Manager per una gestione avanzata delle VM o GNOME Boxes per una gestione semplificata. Comunque, puoi usarle entrambe: Virt Manager per una gestione avanzata e Boxes per avviare semplicemente le VM, io le gestisco cosi.
Come puoi vedere dallo screen, posso visualizzare le VM su entrambe le GUI.

Da questo screen, si vede che ho creato un percorso per inserire le VM su un disco SSD dedicato alle VM.
Di default Virt Manager crea le immagini su: "/var/lib/libvirt" e Boxes su: "/home/user/.local/share/gnome-boxes/images"
Anche se ho un subvolume dedicato per la cartella sul rootfs di libvirt, preferisco comunque dedicare un SSD per non occupare spazio sul disco di sistema.

[emanuc]

Condivido un benchmark interessante tra Btrfs con vari algoritmi e livelli di compressione, XFS e Ext4: https://gist.github.com/braindevices/fd ... 77562aafec

[korda]

In ogni caso il defrag ha migliorato decisamente la situazione. Quello che davvero non capisco ancora è la notevole differenza di performance tra due sistemi molto simili.

1. Il PC desktop che ho ha casa è un Kubuntu 22.04 con una vm Win10 su VirtualBox7.
   Il disco di sistema, dove ci sono i .vdi in @home (su cui autodefrag è ancora abilitato), è un SSD WDBlue da 512GB.
   La CPU è un Intel i3 4th, RAM 16GB.
   
   _
2. Il PC desktop che ho a lavoro è un Kubuntu 22.04 con una vm Win10 su VirtualBox7.
   Il disco di sistema, in cui stavolta ho disabilitato l'auto defrag è un SSD WDBlue da 256GB,
   inxi mi dice questo:

   Codice: Seleziona tutto

   CPU: 6-core Intel Core i5-8500 (-MCP-) speed/min/max: 900/800/4100 MHz
   Kernel: 6.5.0-35-generic x86_64 Up: 12h 32m Mem: 13807.0/15807.2 MiB (87.3%)
   Storage: 1.14 TiB (45.2% used) Procs: 267 Shell: Bash inxi: 3.3.13
   

Nonostante tutto, la vm del PC di casa sembra decisamente più performante e soffre notevolmente meno di lag con freeze mooolto più rari e brevi (pochi secondi e molto raramente, sul PC di casa è stato sufficiente settare Timeshift senza quote ed escludere @home). I freeze sono probabilmente associati ad alto I/O su disco, guardando il led sul frontalino e su btop: CPU e RAM non sembrano sotto stress.

Oltre alla capienza dell'SSD (sono entrambi WDBlue SATA3) e alla CPU, lato software la vm Windows di lavoro è joinata a dominio (quella di casa no, ma la uso comunque per lavoro via vpn, quando sto in smartworking).

Non riesco davvero a capire...

P.S.: non posso postare l'inxi del PC di casa perché, al momento, non posso fisicamente accederci

[emanuc]

Sincermaente non ho idea di quale potrebbe essere la differenza di performance, forse la differenza è lato Windows guest? NTFS è un filesystem soggetto a frammentazione, ma so che nelle ultime release ha un defrang automatico. Non ne ho idea perché lato WIndows non sono molto aggiornato.

[saxtro]

Quando si "freeza"/rallenta, verifica se tra i processi c'è kcompacd0 e quanto stia consumando.

[korda]

Quando si "freeza"/rallenta, verifica se tra i processi c'è kcompacd0 e quanto stia consumando.

Quel processo non lo vedo, però in occasione dei lag da btop salgono tra i primi dieci processi Btrfs-transaction e kworker/ul2:3-btrfs-endio: entrambi comunque presentano dal monitor pochi punti percentuali in termini di CPU e RAM

[korda]

Quando si "freeza"/rallenta, verifica se tra i processi c'è kcompacd0 e quanto stia consumando.

Quel processo non lo vedo, però in occasione dei lag da btop salgono tra i primi dieci processi Btrfs-transaction e kworker/ul2:3-btrfs-endio: entrambi comunque presentano dal monitor pochi punti percentuali in termini di CPU e RAM

Al momento (tra venerdì e oggi) la configurazione di deframmentare manualmente sul PC di lavoro sta mitigando i freeze agli stessi livelli del PC di casa, che è settato con l'autodefrag in fstab (molto rari e di pochi secondi).
Bene così (anche se non saprei ancora spiegarmi la differenza di comportamento)

[emanuc]

Segnalo una funzionalità interessante che automatizza la gestione dello spazio, particolarmente utile per chi ha partizioni con poco spazio o esegue molte operazioni di scrittura. Si tratta di una funzionalità automatica che si attiva al raggiungimento di una certa soglia, e consiglio di abilitarla comunque.
Personalmente l'ho abilitata solo ieri, anche se so della funzionalità fin dalla sua implementazione.
Requisiti: Kernel 5.19 o superiore
Funzionalità disponibile tramite interfaccia "sysfs", al smontaggio della partizione o al reboot del sistema il parametro viene azzerato, per questo sarà utile fare in modo di abilitarlo in automatico al boot tramite service systemd o tramite regola udev.
Spiegazione della funzionalità: Per impostazione predefinita, i gruppi di blocchi completamente vuoti vengono recuperati automaticamente nello spazio libero. Utilizzando la manopola sysfs bg_reclaim_threshold è ora possibile impostare una soglia diversa da 0. Il percorso completo di sysfs è .

Codice: Seleziona tutto

/sys/fs/btrfs/<FSID>/allocation/<PROFILE>/bg_reclaim_threshold

Per vedere l'impostazione corrente:

Codice: Seleziona tutto

# cat /sys/fs/btrfs/c3c00bf0-73a6-4aca-91bb-b5e32e76a08c/allocation/data/bg_reclaim_threshold
0

Utilizzare echo per modificare l'impostazione.

Codice: Seleziona tutto

# echo 10 > /sys/fs/btrfs/c3c00bf0-73a6-4aca-91bb-b5e32e76a08c/allocation/data/bg_reclaim_threshold

Qui, 10, significa una soglia del 10%. Il kernel ora prenderà in considerazione i gruppi di blocchi che scendono al di sotto di questa quantità di utilizzo per il recupero automatico.

Il kernel controllerà periodicamente ed emetterà comandi di bilanciamento secondo necessità. L'avanzamento viene mostrato nel registro del kernel.
Preso da: https://wiki.tnonline.net/w/Btrfs/Balan ... ic_Balance

Creare una regola udev, per averlo in modo permanente:

1. Script:

   Codice: Seleziona tutto

   sudo nano /usr/local/bin/config_btrfs_bg-data.sh
   

2. Copiare questa riga, con il relativo UUID della partizione:

   Codice: Seleziona tutto

   #!/bin/bash
   
   echo 10 > /sys/fs/btrfs/UUID_PARTIZIONE/allocation/data/bg_reclaim_threshold

   Una soglia tra 10 e 40 va bene, io personalmente l'ho messa a 10 perché ho molto spazio a disposizione, per chi ne ha di meno può mettere un valore più alto
3. Regola udev:

   Codice: Seleziona tutto

   sudo nano /etc/udev/rules.d/99-udev-btrfs-bg-data.rules
   

4. Copiare questa riga:

   Codice: Seleziona tutto

   ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="btrfs", RUN+="/usr/local/bin/config-btrfs-bg-data.sh"

   Generalmente è raccomandato di non bilanciare i metadati, tranne per un cambio di profilo.
   
   PS: Quando avrò tempo, ho intenzione di integrare questa parte nella WIKI di Btrfs. A meno che qualcuno non mi anticipi.
   
   La mia configurazione:
   

[saxtro]

@emanuc, interessante.
Condivido la scelta per la regola udev, cosi gestisci anche device rimovibili.
Renderei meno dispositivo-dipendente la parte udev:

Codice: Seleziona tutto

ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="btrfs", RUN+="/usr/local/bin/config-btrfs-bg-data.sh %E{ID_FS_UUID}"

Codice: Seleziona tutto

#!/bin/bash

echo 10 > /sys/fs/btrfs/$1/allocation/data/bg_reclaim_threshold

In questo modo non devi manutenere gli UUID nello script.
Forse la sintassi è da rivedere, ma stando al man di "udev" dovrebbe funzionare ( sezione RUN, OPTIONS .... $env{key}, %E{key} | A device property value.