Parliamo di Btrfs

[emanuc]

@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.

Grazie per l'idea. Ma in questo caso il problema è che si applica a tutte le partizioni Btrfs. Però è da tenere in considerazione se si vuole un valore fisso per tutte le partizioni.
L'idea dello script è di creare due variabili, uno per il valore di soglia del blocco di dati e uno per l'uuid della partizione:
- uuid partizione rootfs > valore soglia 10%
- uuid partizioni dati > valore soglia 20%

Principalmente l'ho testato cosi per essere flessibile e configurabile, e l'ho testato per una richiesta di funzionalità che ho aperto per Btrfs Assistant: https://gitlab.com/btrfs-assistant/btrf ... issues/101

[saxtro]

...
L'idea dello script è di creare due variabili, uno per il valore di soglia del blocco di dati e uno per l'uuid della partizione:
- uuid partizione rootfs > valore soglia 10%
- uuid partizioni dati > valore soglia 20%
...

Nel caso non si utilizzino device diversi, essendo l'UUID condiviso da tutti i subvolumi di un dispositivo/partizione, il valore sarà lo stesso per tutti però.

Cioè:
hai un dispositivo con: / e /data1
e un altro con /data2
Sul primo dispositivo, /data1 avrà il valore su 10,
sul secondo dispositivo, /data2 avrà valore 20

Ho notato su Mnajaro, che sui device usb il valore configurato è 75! (vero per 32Gb, vero per 8Gb rispettivamente).

[emanuc]

Nel caso non si utilizzino device diversi, essendo l'UUID condiviso da tutti i subvolumi di un dispositivo/partizione, il valore sarà lo stesso per tutti però.

Cioè:
hai un dispositivo con: / e /data1
e un altro con /data2
Sul primo dispositivo, /data1 avrà il valore su 10,
sul secondo dispositivo, /data2 avrà valore 20

Il valore si applica per l'intera partizione e non per subvolume.

Ho notato su Mnajaro, che sui device usb il valore configurato è 75! (vero per 32Gb, vero per 8Gb rispettivamente).

Strano, sicuro? Di default il valore è 0. Comunque, per i dispositivi USB ha poco senso se vengono montati al bisogno, ha più senso farlo manualmente al bisogno.
Ho montato un dispositivo USV e il valore è 0, come previsto:

Codice: Seleziona tutto

emanu@fedora ~> cat /sys/fs/btrfs/755e8ae5-ac06-433f-9528-4be974f58f8d/allocation/data/bg_reclaim_threshold 
0

[saxtro]

...
Il valore si applica per l'intera partizione e non per subvolume.
...

si, chiaro, ti esprimo il concetto diversamente:
se vuoi avere valori diversi, la strategia di separare i dati dal resto, la devi prevedere per device/partizione e non per subvolumi, possibilmente già dall'installazione

...
Strano, sicuro? Di default il valore è 0. Comunque, per i dispositivi USB ha poco senso se vengono montati al bisogno, ha più senso farlo manualmente al bisogno.
Ho montato un dispositivo USV e il valore è 0, come previsto:

Codice: Seleziona tutto

emanu@fedora ~> cat /sys/fs/btrfs/755e8ae5-ac06-433f-9528-4be974f58f8d/allocation/data/bg_reclaim_threshold 
0

Anche io lo trovo strano.
Controllando il mio filesystem / :

Codice: Seleziona tutto

[titano ~]# echo 10 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
-bash: echo: write error: Invalid argument
[titano ~]# printf "10" > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
-bash: printf: write error: Invalid argument
[titano ~]# echo 75 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
[titano ~]# echo 74 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
[titano ~]# echo 50 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
-bash: echo: write error: Invalid argument
[titano ~]# echo 51 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold

Non riesco a settare valori che non siano compresi tra 51 e 100. Come se fosse un device zoned (se non ricordo male per i zoned è 75).

Però i miei device, non sono zoned ....

Codice: Seleziona tutto

~ cat /sys/block/*/queue/zoned                       
none
none
none

[emanuc]

...
Il valore si applica per l'intera partizione e non per subvolume.
...

si, chiaro, ti esprimo il concetto diversamente:
se vuoi avere valori diversi, la strategia di separare i dati dal resto, la devi prevedere per device/partizione e non per subvolumi, possibilmente già dall'installazione

...
Strano, sicuro? Di default il valore è 0. Comunque, per i dispositivi USB ha poco senso se vengono montati al bisogno, ha più senso farlo manualmente al bisogno.
Ho montato un dispositivo USV e il valore è 0, come previsto:

Codice: Seleziona tutto

emanu@fedora ~> cat /sys/fs/btrfs/755e8ae5-ac06-433f-9528-4be974f58f8d/allocation/data/bg_reclaim_threshold 
0

Anche io lo trovo strano.
Controllando il mio filesystem / :

Codice: Seleziona tutto

[titano ~]# echo 10 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
-bash: echo: write error: Invalid argument
[titano ~]# printf "10" > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
-bash: printf: write error: Invalid argument
[titano ~]# echo 75 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
[titano ~]# echo 74 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
[titano ~]# echo 50 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold
-bash: echo: write error: Invalid argument
[titano ~]# echo 51 > /sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold

Non riesco a settare valori che non siano compresi tra 51 e 100. Come se fosse un device zoned (se non ricordo male per i zoned è 75).

Però i miei device, non sono zoned ....

Codice: Seleziona tutto

~ cat /sys/block/*/queue/zoned                       
none
none
none

Ho tutti i dischi in btrfs. Comunque, la strategia è in base alla stato dei dischi/partizioni, non ha senso qui avere una strategia per avere valori diversi.

/sys/fs/btrfs/1303a99f-b293-4976-91d9-b995faa5950e/bg_reclaim_threshold

Ti manca il percorso del profilo:
Il percorso corretto: /sys/fs/btrfs/755e8ae5-ac06-433f-9528-4be974f58f8d/allocation/data/bg_reclaim_threshold

[saxtro]

...
Ti manca il percorso del profilo:
Il percorso corretto: /sys/fs/btrfs/755e8ae5-ac06-433f-9528-4be974f58f8d/allocation/data/bg_reclaim_threshold

Capperi, me lo sono perso per strada -

Quindi effettivamente stavo diventanto pazzo perchè stavo realmente "smanettando" con il parametro dei zoned device

Lo script parametrico alla fine l'ho fatto cosi:

Codice: Seleziona tutto

#!/bin/bash

echo "$(date), $1" >> /tmp/out

while true; do
    if [ -e /sys/fs/btrfs/$1 ]; then
       echo 10 > /sys/fs/btrfs/$1/allocation/data/bg_reclaim_threshold;
        exit; else
       sleep 2
    fi
done

Sò che non è di tuo interesse (a meno che non si riesca a inserire un $2 che valga il valore desiderato, sul tipo di volume desiderato), però potrebbe tornare utile per generalizzare.
Il ciclo con lo sleep c'è perchè se inserisci un device usb il cambio di parametro potrebbe partire prima del mount (action=add). Il mount su udev risuta change come action.

Ho verificato con

Codice: Seleziona tutto

sudo udevadm test -a add  /sys/dev/block/259\:1
sudo udevadm test -a change  /sys/dev/block/259\:1

Che lo script verrebbe eseguito in entrambi i casi
I "run" che eseguirebbe udev sono:

Codice: Seleziona tutto

run: '/usr/bin/udevadm trigger -s block -p ID_BTRFS_READY=0'
run: '/usr/local/bin/config-btrfs-bg-data.sh 1303a99f-b293-4976-91d9-b995faa5950e'

[emanuc]

Ottimo, grazie! Potrebbe Essere il motivo del perché alcune regole non vengono applicate. Ha senso perché la partizione di sistema e' già pronta, invece i due hard disk e l ssd potrebbe non essere pronto. Domani provo il parametro "change".
Sto testando le regole per uuid e non solo per filesystem.

Rule file:

Codice: Seleziona tutto

/etc/udev/rules.d/99-2c3cd9ff-2940-4388-96af-daa0a3410ada-btrfs-bg-data.rules

Rule:

Codice: Seleziona tutto

 ACTION=="add", ENV{ID_FS_UUID}=="2c3cd9ff-2940-4388-96af-daa0a3410ada", ENV{ID_FS_TYPE}=="btrfs", RUN+="/bin/bash -c 'echo 30 > /sys/fs/btrfs/2c3cd9ff-2940-4388-96af-daa0a3410ada/allocation/data/bg_reclaim_threshold'"

[saxtro]

Con questa regola:

Codice: Seleziona tutto

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

questo script:

Codice: Seleziona tutto

#!/bin/bash

echo "$(date), $1, $2" >> /tmp/out

if [[ $2 =~ "data" ]]; then
    n=30; else
    n=10
fi

while true; do
    if [ -e /sys/fs/btrfs/$1 ]; then
       echo "$n" > /sys/fs/btrfs/$1/allocation/data/bg_reclaim_threshold;
        exit; else
       sleep 2
    fi
done

Se la LABEL del volume contiene la stringa "data", si riesce a settare valori diversi, per volumi diversi

[emanuc]

Con questa regola:

Codice: Seleziona tutto

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

questo script:

Codice: Seleziona tutto

#!/bin/bash

echo "$(date), $1, $2" >> /tmp/out

if [[ $2 =~ "data" ]]; then
    n=30; else
    n=10
fi

while true; do
    if [ -e /sys/fs/btrfs/$1 ]; then
       echo "$n" > /sys/fs/btrfs/$1/allocation/data/bg_reclaim_threshold;
        exit; else
       sleep 2
    fi
done

Se la LABEL del volume contiene la stringa "data", si riesce a settare valori diversi, per volumi diversi

Il problema è che lo script viene avviato incondizionatamente, anche quando non c'è nessuna azione da intraprendere. Se la regola viene avviata per UUID, siamo sicuri che lo script|comando viene avviato quando necessario.

[saxtro]

...

Il problema è che lo script viene avviato incondizionatamente, anche quando non c'è nessuna azione da intraprendere. Se la regola viene avviata per UUID, siamo sicuri che lo script|comando viene avviato quando necessario.

Vero, di certo con lo script proposto.
Dipende da come ti trovi meglio tu:

- manutenere le regole udev in caso di modifiche
- pensare un sistema che gestica i volumi in base a un attributo, che non sia necessario manutenere in caso di modifiche

Mi viene in mente, ad esempio, di fare lo script con "case", in base alla LABEL (che scegli tu)

data10-* --> per settare 10
data30-* --> per settare 30
os10-* --> per settare 10
backup-* --> exit, non settare nulla

[emanuc]

...

Il problema è che lo script viene avviato incondizionatamente, anche quando non c'è nessuna azione da intraprendere. Se la regola viene avviata per UUID, siamo sicuri che lo script|comando viene avviato quando necessario.

- pensare un sistema che gestica i volumi in base a un attributo, che non sia necessario manutenere in caso di modifiche

Si applica all'interofielsystem, parliamo di spostare i blocchi di dati e compattarli.
[quote
Mi viene in mente, ad esempio, di fare lo script con "case", in base alla LABEL (che scegli tu)

data10-* --> per settare 10
data30-* --> per settare 30
os10-* --> per settare 10
backup-* --> exit, non settare nulla
[/quote]

Non viene applicato il paramentro sugli altri dischi al di fuori del rootfs, e mi sta facendo uscire matto

Codice: Seleziona tutto

emanu@fedora ~> cat /sys/fs/btrfs/2c3cd9ff-2940-4388-96af-daa0a3410ada/allocation/data/bg_reclaim_threshold
0
emanu@fedora ~> cat /etc/udev/rules.d/109-2c3cd9ff-2940-4388-96af-daa0a3410ada-btrfs-bg-data.rules
ACTION=="add", ENV{ID_FS_UUID}=="2c3cd9ff-2940-4388-96af-daa0a3410ada", RUN+="/usr/local/bin/bg-data-2c3cd9ff-2940-4388-96af-daa0a3410ada"
emanu@fedora ~> sudo udevadm test /sys/fs/btrfs/2c3cd9ff-2940-4388-96af-daa0a3410ada/allocation/data/bg_reclaim_threshold
[sudo] password di emanu: 
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
=== trie on-disk ===
tool version:          255
file size:        13060414 bytes
header size             80 bytes
strings            2648414 bytes
nodes             10411920 bytes
Loading kernel module index.
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
Using default interface naming scheme 'v255'.
Parsed configuration file "/usr/lib/systemd/network/99-default.link"
Parsed configuration file "/usr/lib/systemd/network/98-default-mac-none.link"
Created link configuration context.
Reading rules file: /usr/lib/udev/rules.d/01-md-raid-creating.rules
Reading rules file: /usr/lib/udev/rules.d/10-dm.rules
Reading rules file: /etc/udev/rules.d/109-2c3cd9ff-2940-4388-96af-daa0a3410ada-btrfs-bg-data.rules
Reading rules file: /etc/udev/rules.d/109-95d14f9d-8717-4ea0-8a79-34603a7269fe-btrfs-bg-data.rules
Reading rules file: /etc/udev/rules.d/109-f265041b-2c7c-4135-b0c9-ab424428b3d1-btrfs-bg-data.rules
- Taglio per semplificare la lettura -
sd-device: the syspath "/sys/fs/btrfs/2c3cd9ff-2940-4388-96af-daa0a3410ada/allocation/data/bg_reclaim_threshold" is not a directory.
Failed to open device '/sys/fs/btrfs/2c3cd9ff-2940-4388-96af-daa0a3410ada/allocation/data/bg_reclaim_threshold': No such device
Unload kernel module index.
Unloaded link configuration context.

Stessi parametri ma nel rootfs funziona come previsto:

Codice: Seleziona tutto

emanu@fedora ~ [1]> cat /sys/fs/btrfs/9c1c4ece-ece6-4c69-8b21-ea85865d2abf/allocation/data/bg_reclaim_threshold
30
emanu@fedora ~> cat /etc/udev/rules.d/89-9c1c4ece-ece6-4c69-8b21-ea85865d2abf-btrfs-bg-data.rules
ACTION=="add", ENV{ID_FS_UUID}=="9c1c4ece-ece6-4c69-8b21-ea85865d2abf", RUN+="/bin/bash -c 'echo 30 > /sys/fs/btrfs/9c1c4ece-ece6-4c69-8b21-ea85865d2abf/allocation/data/bg_reclaim_threshold'"

PS: La differenza dello script sulla regola sopra è perché le sto provando tutte, ma nelle stesse condizioni di conf ho gli stessi risultati. Sembra che l'interfaccia sysfs no nsia disponibile quando viene avviata la regola.
Comunque, il test lo sto facendo principalmente per aiutare l'implementazione su Btrfs Assistant. Io andrei di service systemd.

[emanuc]

Di recente, oltre a CachyOS, anche IPFire sta valutando di migrare su Btrfs per sfruttare gli snapshot e la compressione:

https://www.ipfire.org/blog/ipfire-2-29 ... 6-released
https://www.ipfire.org/docs/roadmap/btrfs

[saxtro]

...
PS: La differenza dello script sulla regola sopra è perché le sto provando tutte, ma nelle stesse condizioni di conf ho gli stessi risultati. Sembra che l'interfaccia sysfs no nsia disponibile quando viene avviata la regola.
Comunque, il test lo sto facendo principalmente per aiutare l'implementazione su Btrfs Assistant. Io andrei di service systemd.

In effetti la regola e lo script che ho riportato prima (quello con due argomenti per intenderci), funzionano sempre con il rootfs, per i device usb, se uso il comando mount, non funzionano.
Se uso il menù "Disk & Device" di KDE, funzionano.
P.S.: Lo script con l'azione "add", parte anche alla discover del device, prima che sia montato. Dopo 3 minuti (è incastrato nel ciclo sleep 2, perchè l'interfaccia sysfs non è disponibile prima del mount), muore insieme all'udev worker. Poi viene rilanciato al mount (da KDE, non da shell con il comando mount), e fa il suo.



Anche con systemd devi tenere conto di:
lo unit file viene generato da fstab?
viene creato a runtime?

dopo il boot, prima che monti i device cosa hai in

Codice: Seleziona tutto

systemctl list-units -t mount

Ci sono già, o appaiono dopo che li monti?

[emanuc]

Per adesso ci ho rinunciato perché c'è in revisione una serie di patch[1]. Se le uniranno a breve (penso nel kernel 6.10 o 6.11), il processo sarà automatico e gestito dal kernel, senza dover avviare servizi o modificare impostazioni su sysfs.

[1] https://lore.kernel.org/linux-btrfs/cov ... is@bur.io/

[emanuc]

Nuove funzionalità in arrivo per btrfs-progs 6.11 o ..
Funzionalità che faciliteranno alcune operazioni alla formattazione del filesystem: creare subvolumi, abilitare la compressione al trasferimento di un immagine, assegnare il subvolume predefinito sia in RW che in RO.

Codice: Seleziona tutto

 --default-subvol <subdir>
        As *--subvol*, except that it also sets the subvolume as the default for the
        filesystem.  This option can only be specified once.
 --default-subvol SUBDIR", "create SUBDIR as subvolume rather than normal directory, and set it as the default     

Codice: Seleziona tutto

 -u|--subvol <subdir>:<flags>
        Specify that *subdir* is to be created as a subvolume rather than a regular
        directory.  The option *--rootdir* must also be specified, and *subdir* must be an
        existing subdirectory within it.  This option can be specified multiple times.

        *flags* is an optional comma-separated list of modifiers. Valid choices are:

        * *default*: create as default subvolume (this can only be specified once)
        * *ro*: create as readonly subvolume

Codice: Seleziona tutto

    --compression <algo>
        Try to compress files when using *--rootdir*.  Supported values for *algo* are
        *none* (the default) and *zstd*.  As with the kernel, :command:`mkfs.btrfs` won't
        write compressed extents when they would be larger than the uncompressed versions,
        and will mark a file as `nocompress` if its beginning is found to be incompressible.

L'altra funzionalità è la rimozione ricorsiva dei subvolumi annidati.

Codice: Seleziona tutto

-R|--recursive
		delete subvolumes beneath each subvolume recursively.

		This requires either `CAP_SYS_ADMIN` or the fs is mounted with
		`user_subvol_rm_allowed` mount option.
		In the unprivileged case, subvolumes which cannot be accessed
		are skipped.
		The deletion is not atomic.
		
-R|--recursive", "delete subvolumes beneath each subvolume recursively"

Edit:
In arrivo anche gli snapshot ricorsivi:

Codice: Seleziona tutto

+*snapshot* [-r|-R] <source> <dest>|[<dest>/]<name>::
 Create a snapshot of the subvolume <source> with the

+-R::::
+recursively snapshot subvolumes beneath the source; this option cannot be
+combined with -r

Ovviamente, non funziona con l'opzione "-r" (snapshot in sola lettura).
Ricapitolando in un layout di subvolumi nidificati sarà possibile creare uno snapshot con all'interno tutti i subvolumi nidificati, ma solo in lettura/scrittura:

• toplevel subvol = @
• nested subvol = @/home
• nested subvol = @/var

Con questo comando:

Codice: Seleziona tutto

 sudo btrfs subvolume snapshot -R @ /destinazione/@_backup

Avrò in un solo comnado tutto i layout nella destinazione:

• toplevel = @_backup
• nested = @_backup/home
• nested = @_backup/var

PS: Pensandoci sarà più utile per il ripristino degli snapshot.

[emanuc]

Segnalo questo software per chi ha molti snapshot e non ha abilitato le quote, per trovare le differenze tra gli snapshot. Ci sono delle patch in attesa di unione che stampa il percorso e l'ID.