Parliamo di Btrfs

Il ritrovo della comunità dove confrontarsi e discutere sulle notizie dal mondo dell'informatica, di Ubuntu e di tutto quello che la riguarda, novità, pettegolezzi e quant'altro.
Avatar utente
PC ZERO
Scoppiettante Seguace
Scoppiettante Seguace
Messaggi: 449
Iscrizione: sabato 26 febbraio 2011, 12:06
Desktop: Xfce
Distribuzione: Manjaro
Sesso: Maschile

Re: Parliamo di Btrfs

Messaggio da 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. :ciao:
HP 290 G4 Microtower PC Intel i3-10100 (8) @ 4.300GHz Intel CometLake-S GT2 [UHD Graphics 630] Ram 7776 MiB
Manjaro Xfce 64bit
korda
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1786
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Parliamo di Btrfs

Messaggio da korda »

korda ha scritto:
martedì 21 maggio 2024, 14:24
emanuc ha scritto:
martedì 21 maggio 2024, 14:01
È 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?
emanuc ha scritto:
martedì 21 maggio 2024, 14:01
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?
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
emanuc
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1347
Iscrizione: sabato 1 giugno 2013, 0:32
Desktop: KDE plasma
Distribuzione: Fedora Linux
Sesso: Maschile
Località: Catania

Re: Parliamo di Btrfs

Messaggio da emanuc »

korda ha scritto:
mercoledì 22 maggio 2024, 14:13

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
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1786
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Parliamo di Btrfs

Messaggio da korda »

emanuc ha scritto:
mercoledì 22 maggio 2024, 14:39
korda ha scritto:
mercoledì 22 maggio 2024, 14:13

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).
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
saxtro
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 2969
Iscrizione: domenica 4 giugno 2006, 13:16
Distribuzione: Kubuntu 20.04

Re: Parliamo di Btrfs

Messaggio da saxtro »

korda ha scritto:
mercoledì 22 maggio 2024, 14:58
....
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
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1347
Iscrizione: sabato 1 giugno 2013, 0:32
Desktop: KDE plasma
Distribuzione: Fedora Linux
Sesso: Maschile
Località: Catania

Re: Parliamo di Btrfs

Messaggio da 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
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1786
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Parliamo di Btrfs

Messaggio da korda »

emanuc ha scritto:
mercoledì 22 maggio 2024, 15:11
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)
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
saxtro
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 2969
Iscrizione: domenica 4 giugno 2006, 13:16
Distribuzione: Kubuntu 20.04

Re: Parliamo di Btrfs

Messaggio da saxtro »

korda ha scritto:
mercoledì 22 maggio 2024, 16:10
...
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
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1786
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Parliamo di Btrfs

Messaggio da korda »

saxtro ha scritto:
mercoledì 22 maggio 2024, 17:09
korda ha scritto:
mercoledì 22 maggio 2024, 16:10
...
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 :shy: (che anche se backuppo ogni 2/3 giorni va bene uguale)
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
emanuc
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1347
Iscrizione: sabato 1 giugno 2013, 0:32
Desktop: KDE plasma
Distribuzione: Fedora Linux
Sesso: Maschile
Località: Catania

Re: Parliamo di Btrfs

Messaggio da emanuc »

korda ha scritto:
mercoledì 22 maggio 2024, 16:10
emanuc ha scritto:
mercoledì 22 maggio 2024, 15:11
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
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1786
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Parliamo di Btrfs

Messaggio da korda »

emanuc ha scritto:
mercoledì 22 maggio 2024, 20:41
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
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
emanuc
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1347
Iscrizione: sabato 1 giugno 2013, 0:32
Desktop: KDE plasma
Distribuzione: Fedora Linux
Sesso: Maschile
Località: Catania

Re: Parliamo di Btrfs

Messaggio da 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.
Immagine
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.
Immagine
emanuc
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1347
Iscrizione: sabato 1 giugno 2013, 0:32
Desktop: KDE plasma
Distribuzione: Fedora Linux
Sesso: Maschile
Località: Catania

Re: Parliamo di Btrfs

Messaggio da 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
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1786
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Parliamo di Btrfs

Messaggio da 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
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
emanuc
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1347
Iscrizione: sabato 1 giugno 2013, 0:32
Desktop: KDE plasma
Distribuzione: Fedora Linux
Sesso: Maschile
Località: Catania

Re: Parliamo di Btrfs

Messaggio da 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
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 2969
Iscrizione: domenica 4 giugno 2006, 13:16
Distribuzione: Kubuntu 20.04

Re: Parliamo di Btrfs

Messaggio da saxtro »

Quando si "freeza"/rallenta, verifica se tra i processi c'è kcompacd0 e quanto stia consumando.
korda
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1786
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Parliamo di Btrfs

Messaggio da korda »

saxtro ha scritto:
giovedì 23 maggio 2024, 15:00
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
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
korda
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1786
Iscrizione: giovedì 24 dicembre 2020, 15:58

Re: Parliamo di Btrfs

Messaggio da korda »

korda ha scritto:
venerdì 24 maggio 2024, 9:10
saxtro ha scritto:
giovedì 23 maggio 2024, 15:00
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) :ciao:
Io non sono Bagheera né Akela, io non frequento la Rupe.
Io sono Kaa: faccio ballare le scimmie alle Tane Fredde.
emanuc
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1347
Iscrizione: sabato 1 giugno 2013, 0:32
Desktop: KDE plasma
Distribuzione: Fedora Linux
Sesso: Maschile
Località: Catania

Re: Parliamo di Btrfs

Messaggio da 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. :D

    La mia configurazione:
    Immagine
saxtro
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 2969
Iscrizione: domenica 4 giugno 2006, 13:16
Distribuzione: Kubuntu 20.04

Re: Parliamo di Btrfs

Messaggio da 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.
Scrivi risposta

Ritorna a “Bar Ubuntu”

Chi c’è in linea

Visualizzano questa sezione: 0 utenti iscritti e 17 ospiti