[Nuovo Wiki]Filesytem Btrfs

[emanuc]

Ho milgiorato e corretto la guida del backup con btrfs send|receive.
https://wiki.ubuntu-it.org/Hardware/Dis ... 7C_receive
Nel tempo si può mettere anche verificato per 22.04 perché non è cambiato nulla che potrebbe influire sulla wiki.

Grazie!
Non ho capito: può considerarsi valida per 22.04 tutta la guida oppure solo il paragrafo "Btrfs send | receive"?

Tutta la guida, perché non ci sono cambiamenti che influiscono sui comandi/argomenti trattati sulla guida.

[xavier77]

Ho milgiorato e corretto la guida del backup con btrfs send|receive.
https://wiki.ubuntu-it.org/Hardware/Dis ... 7C_receive
Nel tempo si può mettere anche verificato per 22.04 perché non è cambiato nulla che potrebbe influire sulla wiki.

Grazie!
Non ho capito: può considerarsi valida per 22.04 tutta la guida oppure solo il paragrafo "Btrfs send | receive"?

Tutta la guida, perché non ci sono cambiamenti che influiscono sui comandi/argomenti trattati sulla guida.

OK inserita verifica con 22.04

[emanuc]

Ho una proposta di modifica per semplificare:

Prima:

== Gestione subvolume ==
* Subvolume flat: È un subvolume secondario del subvolume di livello superiore, top level (ID 5). Per creare, eliminare un subvolume flat, il filesystem radice deve essere montato in modo che i subvolumi siano visibili. È consigliato creare un subvolume '''flat''' su cartelle fisse di sistema, ad esempio:'''/var/cache'''. Per montare un subvolume '''flat''' deve essere specificato nelle opzioni di fstab.
* Subvolume nested: Un subvolume nested è un subvolume dentro un altro subvolume. Per creare, eliminare un subvolume nested, basta specificare il percorso sul filesystem, ad esempio: '''sudo btrfs subvolume create /nuovosubvolume'''. È consigliato creare un subvolume '''nested''' su cartelle che potrebbero essere rimosse, ad esempio: '''/var/lib/flatpak''', questo perché quando andiamo a dare un '''apt purge flatpak''' va ad eliminare la cartella di flatpak, con un subvolume '''flat''', '''apt'''va in errore perché non può rimuovere la cartella '''/var/lib/flatpak'''.
Un subvolume '''nested''' può essere rimosso come una semplice cartella, inoltre non dobbiamo specificare nessuna opzione di mount su '''/etc/fstab''' perché si montano in automatico. Anche un subvolume '''nested''' viene escluso dagli snapshot del subvolume superiore, gli snapshot non sono ricorsivi su altri subvolumi.

Dopo:

== Gestione subvolume ==
* Subvolume flat: È un subvolume secondario del subvolume di livello superiore, top level (ID 5). Per creare, eliminare un subvolume flat, il filesystem radice deve essere montato in modo che i subvolumi siano visibili. È consigliato creare un subvolume '''flat''' su cartelle fisse di sistema, ad esempio:'''/var/cache'''. Per montare un subvolume '''flat''' deve essere specificato nelle opzioni di fstab.
* Subvolume nested: Un subvolume nested è un subvolume dentro un altro subvolume, per creare, eliminare un subvolume nested basta specificare il percorso sul filesystem, ad esempio: '''btrfs subvolume create Cartella''' il subvolume "Cartella" viene creato dentro la home dell'utente.
È consigliato creare un subvolume '''nested''' su subvolumi dove non si effettuano snapshot per evitare che al ripristino non si perde il subvolume nidificato, questo perché gli snapshot non sono ricorsivi, invece è utile nel caso si voglia creare snapshot di una determinata cartella: un esempio utile di dove creare un subvolume nested è dentro la home dell'utente, generalmente sulla home non è consigliato effettuare snapshot ma è consigliato fare un backup con strumenti standard come Pika backup.
Un subvolume '''nested''' può essere rimosso come una semplice cartella, inoltre non dobbiamo specificare nessuna opzione di mount su '''/etc/fstab''' perché si montano in automatico. Anche un subvolume '''nested''' viene escluso dagli snapshot del subvolume superiore.
.

Non ci sono cambiamenti sul kernel o brtrfs progs che influiscono sulla guida, quindi si può aggiungere: Verificato per la 22.10

[xavier77]

@emanuc
Ciao, se le modifiche sono solo queste, puoi agire in completa autonomia.
Valuta tu anche se è il caso di aspettare il feedback di altri oppure no.

[frapox]

È consigliato creare un subvolume '''nested''' su subvolumi dove non si effettuano snapshot per evitare che al ripristino non si perde il subvolume nidificato,

Questa frase secondo me non significa proprio quello che realmente vorresti intendere, quindi suggerirei di modificarla così per maggiore chiarezza:

È utile creare un subvolume '''nested''' solo su subvolumi di cui non si effettuano snapshot per evitare che al ripristino si perda il subvolume nidificato al suo interno (questo perché gli snapshot non sono ricorsivi). Invece, è utile nel caso si voglia creare snapshot di una determinata cartella: ad esempio di una sottocartella nella home dell'utente.

Io eviterei l'uso troppo frequente di "si consiglia" o "è consigliato" laddove non ci siano chiare evidenze di ciò che si consiglia. Per cui adempio: "generalmente sulla home non è consigliato effettuare snapshot ma è consigliato fare un backup con strumenti standard come Pika backup." lo taglierei. Uno può o non può volere fare uno snapshot della sua home, e farlo non mi pare sia un'operazione che compromette in alcun modo il sistema o l'esperienza utente, per cui da "sconsigliare".

[emanuc]

È consigliato creare un subvolume '''nested''' su subvolumi dove non si effettuano snapshot per evitare che al ripristino non si perde il subvolume nidificato,

Questa frase secondo me non significa proprio quello che realmente vorresti intendere, quindi suggerirei di modificarla così per maggiore chiarezza:

È utile creare un subvolume '''nested''' solo su subvolumi di cui non si effettuano snapshot per evitare che al ripristino si perda il subvolume nidificato al suo interno (questo perché gli snapshot non sono ricorsivi). Invece, è utile nel caso si voglia creare snapshot di una determinata cartella: ad esempio di una sottocartella nella home dell'utente.

Io eviterei l'uso troppo frequente di "si consiglia" o "è consigliato" laddove non ci siano chiare evidenze di ciò che si consiglia. Per cui adempio: "generalmente sulla home non è consigliato effettuare snapshot ma è consigliato fare un backup con strumenti standard come Pika backup." lo taglierei. Uno può o non può volere fare uno snapshot della sua home, e farlo non mi pare sia un'operazione che compromette in alcun modo il sistema o l'esperienza utente, per cui da "sconsigliare".

La guida è orientata all'utente comune, non tecnico, se non sono consapevoli su come funzionano gli snapshot su Btrfs potrebbero avere questi problemi:
1) Aumento dello spazio occupato: i dati sulla home cambiano frequentemente
2) Perdita di dati in caso di un ripristino: al suo ripristino non troveresti i dati aggiunti dopo.
Ci sono alcuni casi d'uso per lo snapshot sulla home: proteggersi da eliminazione o modifiche accidentali o se usi btrfs send|receive.
Un backup classico è molto più semplice ed efficiente nella maggior parte dei casi e creare snapshot della home potrebbe compromettere l'esperienza dell'utente.
Stessa nota è scritta dagli sviluppatori di Timeshift: Note: It is not recommended to include user data in backups as it will be overwritten when you restore the snapshot.
Quindi lascerei il consiglio di non usare snapshot btrfs sulla home.

È utile creare un subvolume '''nested''' solo su subvolumi di cui non si effettuano snapshot per evitare che al ripristino si perda il subvolume nidificato al suo interno (questo perché gli snapshot non sono ricorsivi). Invece, è utile nel caso si voglia creare snapshot di una determinata cartella: ad esempio di una sottocartella nella home dell'utente.

Si, questa frase è formula meglio. Perché metti "utile" rispetto al "consigliare" ?

[frapox]

La guida è orientata all'utente comune, non tecnico, se non sono consapevoli su come funzionano gli snapshot su Btrfs potrebbero avere questi problemi:
1) Aumento dello spazio occupato: i dati sulla home cambiano frequentemente
2) Perdita di dati in caso di un ripristino: al suo ripristino non troveresti i dati aggiunti dopo.

E beh ma sono delle premesse un tantino ardite a mio parere.

1) Lo spazio è aumentato in tutti i casi di snapshot, non solo nella home, e non solo con Btrfs. Che i dati nella home cambino frequentemente non è detto o non lo possiamo sapere, così come non è detto che anche cambiando frequentemente la mole di dati che cambia sia consistente.
2) I dati correnti non li perdi in fase di snapshot ma appunto in fase di ripristino, se ripristini tutto "alla brutto" (senza selezionare), cosa che per altro potrebbe essere anche voluta e intenzionale.

Secondo me la wiki va bene com'è ora, con il warning che c'è ora "Se si effettua un ripristino da uno snapshot con tool come timeshift..." e basta.

Un backup classico è molto più semplice ed efficiente nella maggior parte dei casi e creare snapshot della home potrebbe compromettere l'esperienza dell'utente.

Posso anche essere d'accordo che ci sono tool più mirati e specifici per fare i backup (dei dati personali) ma Pika backup non è uno "strumento standard", almeno non su Ubuntu. Non vedo quindi l'opportunità di inserire in quel punto, in quella guida consigli o "sconsigli" del genere.

Stessa nota è scritta dagli sviluppatori di Timeshift: Note: It is not recommended to include user data in backups as it will be overwritten when you restore the snapshot.

Quindi non è raccomandato fare gli snapshot di dati personali (non necessariamente la home) se si utilizza Timeshift, perché questo ripristina l'intero snapshot e cosi facendo sovrascrive tutta la home. Ok, e ci sta, e questo è già specificato.

Ma se io o chiunque altro volesse farsi degli snapshot della home (o di qualsiasi altra cartella contenente dati personali) per poi andare a ripristinarsi manualmente solo alcune sottocartelle o file dallo snapshot, non vedo dov'è il problema o la compromissione dell'esperienza utente. L'utente va avvertito, informato, non indirizzato verso un programma che non c'entra niente con Btrfs o con la gestione degli snapshot.

PS. ma poi chi sarebbe l'utente "comune"? Nelle linee guida della wiki vengono specificati solo utenti "nuovi" ed "esperti". Questa pagina sicuramente non è per utenti nuovi o, come penso tu voglia intendere, utenti senza alcun bagaglio tecnico. Teniamo presente anche questo fattore, perché pensare che un novizio si metta a smanettare con Btrfs è abbastanza irrealistico.

Si, questa frase è formula meglio. Perché metti "utile" rispetto al "consigliare" ?

Primo perché è la formula che era già presente nella seconda parte, secondo perché il consiglio lo dai se qualcuno te lo chiede. Se no in una guida è meglio limitarsi a evidenziare i pro (l'utilità), i contro (i pericoli o gli svantaggi) senza condire di preferenze e opinioni se non laddove è proprio indispensabile.

[emanuc]

Ma se io o chiunque altro volesse farsi degli snapshot della home (o di qualsiasi altra cartella contenente dati personali) per poi andare a ripristinarsi manualmente solo alcune sottocartelle o file dallo snapshot, non vedo dov'è il problema o la compromissione dell'esperienza utente. L'utente va avvertito, informato, non indirizzato verso un programma che non c'entra niente con Btrfs o con la gestione degli snapshot.

Era un esempio di software backup efficiente, semplice e stabile (dejadup predefinito su Ubuntu a molti e a me personalmente ha dato problemi) ed è per quello che ho menzionato Pika, ma potrei menzionare Vorta o altro, oppure "un classico backup dati".

Ma se io o chiunque altro volesse farsi degli snapshot della home (o di qualsiasi altra cartella contenente dati personali) per poi andare a ripristinarsi manualmente solo alcune sottocartelle o file dallo snapshot, non vedo dov'è il problema o la compromissione dell'esperienza utente. L'utente va avvertito, informato, non indirizzato verso un programma che non c'entra niente con Btrfs o con la gestione degli snapshot.

Puoi anche selezionare dallo snapshot di recuperare file o cartelle selettivamente, basta andare nel percorso dello snapshot(anche se RO) .
I tuoi punti sono validi, quindi in conclusione possiamo solo specificare il problema del ripristino se si effettua uno snapshot della home.
Puoi scrivere la tua proposta di modifica in modo da valutarla per intero?
Nel tempo che ci sei e se ti va puoi controllare il resto della WIKI?

[frapox]

Ma se io o chiunque altro volesse farsi degli snapshot della home (o di qualsiasi altra cartella contenente dati personali) per poi andare a ripristinarsi manualmente solo alcune sottocartelle o file dallo snapshot, non vedo dov'è il problema o la compromissione dell'esperienza utente. L'utente va avvertito, informato, non indirizzato verso un programma che non c'entra niente con Btrfs o con la gestione degli snapshot.

Era un esempio di software backup efficiente, semplice e stabile (dejadup predefinito su Ubuntu a molti e a me personalmente ha dato problemi) ed è per quello che ho menzionato Pika, ma potrei menzionare Vorta o altro, oppure "un classico backup dati".

Secondo me puoi omettere in toto esempi di software di backup. Siamo nella wiki di Btrfs e stiamo parlando di subvolume, un esempio di un subvol nested ci può stare, il resto non serve. Oltre al caso di home puoi fare altri esempi, come /var/cache, /var/log. Io ce li ho tutti come nested perché tanto li stanno, non li devo montare altrove.

Ecco, forse può valer la pena evidenziare che un subvol flat lo puoi montare dove vuoi nell'albero del filesystem ma va inserito in /etc/fstab o montato manualmente, mentre un subvol nested rimane "fisso" dov'è (stato creato o spostato) e non va montato.

Puoi anche selezionare dallo snapshot di recuperare file o cartelle selettivamente, basta andare nel percorso dello snapshot(anche se RO) .
I tuoi punti sono validi, quindi in conclusione possiamo solo specificare il problema del ripristino se si effettua uno snapshot della home.
Puoi scrivere la tua proposta di modifica in modo da valutarla per intero?
Nel tempo che ci sei e se ti va puoi controllare il resto della WIKI?

Dunque io stavo guardando la pagina che attualmente è pubblicata:
https://wiki.ubuntu-it.org/Hardware/Dis ... ume_nested

E per me com'è scritta ora va già benissimo. Poi non ho capito bene dove sono le modifiche che hai fatto, io nella pagina pubblicata non le vedo.

[emanuc]

Ma se io o chiunque altro volesse farsi degli snapshot della home (o di qualsiasi altra cartella contenente dati personali) per poi andare a ripristinarsi manualmente solo alcune sottocartelle o file dallo snapshot, non vedo dov'è il problema o la compromissione dell'esperienza utente. L'utente va avvertito, informato, non indirizzato verso un programma che non c'entra niente con Btrfs o con la gestione degli snapshot.

Era un esempio di software backup efficiente, semplice e stabile (dejadup predefinito su Ubuntu a molti e a me personalmente ha dato problemi) ed è per quello che ho menzionato Pika, ma potrei menzionare Vorta o altro, oppure "un classico backup dati".

Secondo me puoi omettere in toto esempi di software di backup. Siamo nella wiki di Btrfs e stiamo parlando di subvolume, un esempio di un subvol nested ci può stare, il resto non serve. Oltre al caso di home puoi fare altri esempi, come /var/cache, /var/log. Io ce li ho tutti come nested perché tanto li stanno, non li devo montare altrove.

Ecco, forse può valer la pena evidenziare che un subvol flat lo puoi montare dove vuoi nell'albero del filesystem ma va inserito in /etc/fstab o montato manualmente, mentre un subvol nested rimane "fisso" dov'è (stato creato o spostato) e non va montato.

Puoi anche selezionare dallo snapshot di recuperare file o cartelle selettivamente, basta andare nel percorso dello snapshot(anche se RO) .
I tuoi punti sono validi, quindi in conclusione possiamo solo specificare il problema del ripristino se si effettua uno snapshot della home.
Puoi scrivere la tua proposta di modifica in modo da valutarla per intero?
Nel tempo che ci sei e se ti va puoi controllare il resto della WIKI?

Dunque io stavo guardando la pagina che attualmente è pubblicata:
https://wiki.ubuntu-it.org/Hardware/Dis ... ume_nested

E per me com'è scritta ora va già benissimo. Poi non ho capito bene dove sono le modifiche che hai fatto, io nella pagina pubblicata non le vedo.

Non è un problema solo del mount point ma se ripristini il subvolume rootfs al riavvio avresti un sistema rotto, perché non ti ritroveresti le cartelle "var/cache e var/log".
rootfs > /, <nested subvol var/cache, var/log>
snap_rootfs > /
Se ripristini snap_rootfs non avresti var/cache e var/log e non puoi eliminare il subvolume padre perché all'interno hai subvolumi nidificati.
Per semplificare questo caso d'uso si creano i subvolumi flat sul toplevel.
Puoi gestire snapper e gli snapshot con i subvolumi nested ma dovresti avere il layout FS di openSUSE: https://rootco.de/2018-01-19-opensuse-btrfs-subvolumes/

La mia proposta di modifica la trovi qui (prima e dopo): viewtopic.php?p=5316387#p5316387

[frapox]

Non è un problema solo del mount point ma se ripristini il subvolume rootfs al riavvio avresti un sistema rotto, perché non ti ritroveresti le cartelle "var/cache e var/log".

Ricreo i due subvolume al ripristino. Non sono due cartelle vitali per fare il boot.

Ma lo stesso discorso si applica per qualsiasi cartella nested, anche sotto home. Se per esempio mi "subvolumizzo" ~/.cache o ~/.local/share/trash, se faccio uno snapshot di ~/ queste due vengono escluse, e ad un eventuale ripristino le devo ricreare (o me forse le ricrea la prima app desktop che ne fa uso).

rootfs > /, <nested subvol var/cache, var/log>
snap_rootfs > /
Se ripristini snap_rootfs non avresti var/cache e var/log e non puoi eliminare il subvolume padre perché all'interno hai subvolumi nidificati.

Qui non ho capito quello schemino.

Per semplificare questo caso d'uso si creano i subvolumi flat sul toplevel.
Puoi gestire snapper e gli snapshot con i subvolumi nested ma dovresti avere il layout FS di openSUSE: https://rootco.de/2018-01-19-opensuse-btrfs-subvolumes/

Ok, per semplicare l'uso con tool come quello, posso capire sia preferibile il layout flat; ma visto che mi gestisco i subvolume a mano (non ho bisogno di automatizzare il processo, quando voglio fare uno snapshot lo faccio col classico comando) non ho l'obbligo di usare i toplevel; capisco anche che nella guida generica per tutti si voglia semplificare il discorso.

La mia proposta di modifica la trovi qui (prima e dopo): viewtopic.php?p=5316387#p5316387

Vabè allora è quella che abbiamo già discusso qui.

[emanuc]

Ma lo stesso discorso si applica per qualsiasi cartella nested, anche sotto home. Se per esempio mi "subvolumizzo" ~/.cache o ~/.local/share/trash, se faccio uno snapshot di ~/ queste due vengono escluse, e ad un eventuale ripristino le devo ricreare (o me forse le ricrea la prima app desktop che ne fa uso).

Per queste cartelle non hai problemi perché vengono ricreate, ma se vuoi fare snapshot della home non è meglio farlo selettivamente solo nelle cartelle di interesse? Ad esempio ti crei un subvol di "Documenti" o di altro.
Ma capisci che spiegare tutto nella WIKI è complesso e ci ritroveremo una guida troppo lunga, quindi per essere più breve si guida l'utente nel caso d'uso più semplice.

[emanuc]

Ho apportato alcune piccole migliorie:
- https://wiki.ubuntu-it.org/Hardware/Dis ... _montaggio
Ho diviso l'opzione di mount su "autodefrag" tra hard disk e disco a stato solido.

- https://wiki.ubuntu-it.org/Hardware/Dis ... nutenzione
Nota sull'abilitazione in automatico di "discard=async" dal kernel Linux 6.2 se rileva un disco a stato solido.

- https://wiki.ubuntu-it.org/Hardware/Dis ... _su_Ubuntu
Rimosso l'opzione di mount su "fstab" di "autodefrag"
Ho aggiunto una nota su "Subvolume VM gestite da VirtManager" di non disattivare "COW" in caso di mirroring

[xavier77]

Ho apportato alcune piccole migliorie:
- https://wiki.ubuntu-it.org/Hardware/Dis ... _montaggio
Ho diviso l'opzione di mount su "autodefrag" tra hard disk e disco a stato solido.

- https://wiki.ubuntu-it.org/Hardware/Dis ... nutenzione
Nota sull'abilitazione in automatico di "discard=async" dal kernel Linux 6.2 se rileva un disco a stato solido.

- https://wiki.ubuntu-it.org/Hardware/Dis ... _su_Ubuntu
Rimosso l'opzione di mount su "fstab" di "autodefrag"
Ho aggiunto una nota su "Subvolume VM gestite da VirtManager" di non disattivare "COW" in caso di mirroring

Grazie!

[wilecoyote]

) Salve, @emanuc le modifiche sono in cagione di questa discussione Btrfs, snapper e occupazione snapshots, in cui t'ho evocato per dare aiuto, nevvero ?

:: Ciao

[emanuc]

) Salve, @emanuc le modifiche sono in cagione di questa discussione Btrfs, snapper e occupazione snapshots, in cui t'ho evocato per dare aiuto, nevvero ?

:: Ciao

Si

[wilecoyote]

) Salve, ottimo effetto collaterale, allora ti ringrazio dell'intervento d'aiuto nell'altra discussione e l'ulteriore l'integrazione nella wiki.

:: Ciao

[GjMan78]

Vorrei fare presente un dettaglio.

Come avrete visto ho seguito da poco la guida, specialmente il paragrafo riguardo l'ottimizzazione.

Controllando i log di sistema ho trovato una serie di warning, uno per ogni subvolume creato seguendo la guida.

mar 04 23:09:55 hp-manjaro systemd[1]: var-log.mount: Directory /var/log to mount over is not empty, mounting anyway.
░░ Subject: Il punto di montaggio non è vuoto
░░ Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░
░░ La directory /var/log è specificata come punto di montaggio (secondo campo
░░ in /etc/fstab o nel campo Where= del file unità di systemd) e non è vuoto.
░░ Questo non interferisce con il montaggio, ma i file pre-esistenti in questa
░░ directory diventano inaccessibili. Per visualizzare i file, si suggerisce
░░ di montare manualmente il file system indicato in una posizione secondaria.

Nulla di preoccupante ovviamente. Però si potrebbe evitare di intasare i log di boot con questi messaggi aggiungendo un passaggio per l'eliminazione dei file originali dopo la copia.

Ad esempio per la cartella /var/log :

Subvolume cartella /var/log
Montare la radice su /mnt (la cartella montata è di esempio, si può scegliere o creare altre cartelle per il montaggio):

Codice: Seleziona tutto

sudo mount -t btrfs -o --options-source /dev/sda2 /mnt

Creare subvolume della cartella:

Codice: Seleziona tutto

sudo btrfs subvolume create /mnt/@varlog

Copiare il contenuto della cartella nel subvolume:

Codice: Seleziona tutto

sudo cp -a /mnt/@/var/log/* /mnt/@varlog/

Io aggiungerei

Codice: Seleziona tutto

 sudo rm -rf /mnt/@/var/log/*

[wilecoyote]

) Salve, aspetto che passi @emanuc e valuti la proposta, non vorrei far altri danni.

:: Ciao

[xavier77]

Vorrei fare presente un dettaglio.

Come avrete visto ho seguito da poco la guida, specialmente il paragrafo riguardo l'ottimizzazione.

Controllando i log di sistema ho trovato una serie di warning, uno per ogni subvolume creato seguendo la guida.

mar 04 23:09:55 hp-manjaro systemd[1]: var-log.mount: Directory /var/log to mount over is not empty, mounting anyway.
░░ Subject: Il punto di montaggio non è vuoto
░░ Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░
░░ La directory /var/log è specificata come punto di montaggio (secondo campo
░░ in /etc/fstab o nel campo Where= del file unità di systemd) e non è vuoto.
░░ Questo non interferisce con il montaggio, ma i file pre-esistenti in questa
░░ directory diventano inaccessibili. Per visualizzare i file, si suggerisce
░░ di montare manualmente il file system indicato in una posizione secondaria.

Nulla di preoccupante ovviamente. Però si potrebbe evitare di intasare i log di boot con questi messaggi aggiungendo un passaggio per l'eliminazione dei file originali dopo la copia.

Ad esempio per la cartella /var/log :

Subvolume cartella /var/log
Montare la radice su /mnt (la cartella montata è di esempio, si può scegliere o creare altre cartelle per il montaggio):

Codice: Seleziona tutto

sudo mount -t btrfs -o --options-source /dev/sda2 /mnt

Creare subvolume della cartella:

Codice: Seleziona tutto

sudo btrfs subvolume create /mnt/@varlog

Copiare il contenuto della cartella nel subvolume:

Codice: Seleziona tutto

sudo cp -a /mnt/@/var/log/* /mnt/@varlog/

Io aggiungerei

Codice: Seleziona tutto

 sudo rm -rf /mnt/@/var/log/*

Domanda banale. E mi scuso anticipatamente se dico una cavolata perché non ho mai usato brtfs.
Ma se il problema è solo il possibile intasamento dei file di log, non si può ovviare modificando le impostazioni per la rotazione?