openSUSE

[woddy68]

Snapper ha un algoritmo di autoclean, lo stesso Timeshift, quindi no problem.

Però anche Timeshift può avere delle noie.
Leggevo nel forum di Manjaro di qualche utente che gli è capitato che non partisse manco a pagare nel momento del bisogno e non è riuscito a caricare l'immagine dovendo formattare tutto.

Poi oh, se questa è sfiga nera io non lo so...

Cmq ora, dopo averle sentite di tutti i colori per Manjaro, esigo che qualcuno mi dica almeno un difetto di Suse.
Così la vendete troppo bene come miglior distro linux di sempre...e lo fate in un forum della concorrenza

Non esiste distribuzione o sistema operativo senza difetti, uno dei difetti (se così lo vuoi chiamare) è che è molto severa sulla politica di sicurezza e di legalità, è uno dei motivi per cui non si mettono in quell'area grigia con i codecs ad esempio, per cui per averli occorre prenderli dal repository comunitario packman, che è esterno a openSUSE, se si utilizzano i flatpak come faccio io, il problema non esiste.
Recentemente hanno disabilitato il modulo che permette il tethering per motivi di sicurezza, ovviamente è possibile riabilitarlo.

[noel80]

In che senso...di solito si avvia un' istantanea in sola lettura, se è ok la imposti di default lettura-scrittura con snapper rollback, lo fai da terminale ma mi sembra lo puoi fare anche da snapper o altro strumento grafico se esiste.

Non me ne intendo , dove c'era il video postato, dai consigli, sembra che la Deck utilizzi rauc; https://rauc.readthedocs.io/en/latest/
https://github.com/randombk/steamos-tea ... updates.md

[emanuc]

Leggevo nel forum di Manjaro di qualche utente che gli è capitato che non partisse manco a pagare nel momento del bisogno e non è riuscito a caricare l'immagine dovendo formattare tutto.

Potrebbe essere anche un problema EFI o un problema del boot loader se separa la partizione di boot, può essere tutto, ma quello che è certo è che gli snapshot btrfs sono atomici, non hanno uno stato intermedio, o tutto o niente.

Se proprio le vuoi trovare un difetto, che non è un difetto di Suse ma del suo amministratore, è la policy di retention delle snapshot
- un massimo di 10
- anche meno di 10 (mai meno di 4) se lo spazio delle snapshot occupa più del 50%
il problema si pone quando il filesystem (senza snap) occupa più del 65-70%. Ho visto server arrivare a 100% durante gli upgrade. Niente di irrisolvibile, ma su un server di produzione allunga di un paio d'ore la scaletta.
Re: openSUSE

Forse in qualche vecchia versione di openSUSE/SUSE prima del nuovo layout dei subvolumi dove hanno fatto una separazione migliore, per mitigare questo tipo di problemi soprattutto sui server.
Ad oggi mi sembra difficile che il subvolume coinvolto dagli snapshot riesce ad occupare del 50% il filesystem, parliamo di un subvolume di 1/2GB circa.
Ho dato una controllata su openSUSE Leap, tutti quei snapshot stanno occupando solo qualche mb e non il 50% del filesystem:

[woddy68]

Un esempio della comodità di avere regolari istantanee di sistema lo avuta oggi.
Plasma 6 non è ancora arrivato in tumbleweed ufficialmente, quindi ho provato a installarlo da alcuni repository sperimentali...
al riavvio non avevo più alcuna sessione di Plasma, in realtà Tumbleweed di default installa anche una sessione minimale di ICEwm, che in openSUSE è considerata una sessione di emergenza, quindi potevo comunque accedere a strumenti di configurazione, quindi faccio un rollback e il mio sistema è tornato come prima di quel tentativo fallito di installare Plasma 6.
Questa è una grande comodità e in alcuni casi ti salva davvero da una brutta giornata.
Un altro esempio...circa un paio di anni fa, dovevo andare al lavoro in Olanda e avevo l'aereo da prendere, ho pensato di aggiornare il mio portatile dal momento che mi serviva là. Faccio gli aggiornamenti e per qualche strano motivo che non mi era mai successo, durante l'installazione degli aggiornamenti il pc si blocca, forzo il riavvio e ottengo uno schermo nero...panico !
Poi mi ricordo di questa cosa delle istantanee, era la prima volta che lo utilizzavo, ma mi ha salvato...ritento a fare gli aggiornamenti e questa volta terminano senza problemi.
Morale...un sistema operativo moderno rivolto agli utenti comuni, dovrebbe sempre avere un meccanismo di questo tipo e dovrebbe essere impostato e configurato di default. Che Arch non c'è l'abbia non mi stupisce vista la natura dell'utenza a cui si rivolge, che non lo abbia Ubuntu o distribuzioni simili, per me è una grave mancanza.

Edit. Comunque si consiglia sempre una partizione / di almeno 50 Gb che oggi giorno non sono un'esagerazione con dischi da oltre 1 tera. A me personalmente nemmeno sul portatile con un SSD da 125 Gb ho mai riempito il disco, con un'installazione vecchia di anni.
Se si disabilita la quota, forse occorre stare più attenti sullo spazio, ma disabilitarla è una scelta dell'utente.

[PC ZERO]

Potrebbe essere anche un problema EFI o un problema del boot loader se separa la partizione di boot, può essere tutto, ma quello che è certo è che gli snapshot btrfs sono atomici, non hanno uno stato intermedio, o tutto o niente.

Che intendi per tutto o niente?

[GjMan78]

Morale...un sistema operativo moderno rivolto agli utenti comuni, dovrebbe sempre avere un meccanismo di questo tipo e dovrebbe essere impostato e configurato di default. Che Arch non c'è l'abbia non mi stupisce vista la natura dell'utenza a cui si rivolge, che non lo abbia Ubuntu o distribuzioni simili, per me è una grave mancanza.

La penso esattamente come te.
Il giorno in cui Ubuntu offrirà di default il filesystem btrfs con gli snapshot già configurati potrà riguadagnare in un attimo il prestigio perso negli ultimi anni...

[noel80]

Morale...un sistema operativo moderno rivolto agli utenti comuni, dovrebbe sempre avere un meccanismo di questo tipo e dovrebbe essere impostato e configurato di default. Che Arch non c'è l'abbia non mi stupisce vista la natura dell'utenza a cui si rivolge, che non lo abbia Ubuntu o distribuzioni simili, per me è una grave mancanza.

La penso esattamente come te.
Il giorno in cui Ubuntu offrirà di default il filesystem btrfs con gli snapshot già configurati potrà riguadagnare in un attimo il prestigio perso negli ultimi anni...

snapshots e pacchetti snap caricarebbero sul serio le ram mi pare....

[GjMan78]

Non vedo come gli snapshots possano influire sul consumo di ram...

Come ho mostrato qualche post fa ho una macchina virtuale con 4 giga di ram, filesystem btrfs e snapshots configurati e non ho assolutamente nessun problema con il consumo di ram o altro.

[emanuc]

Potrebbe essere anche un problema EFI o un problema del boot loader se separa la partizione di boot, può essere tutto, ma quello che è certo è che gli snapshot btrfs sono atomici, non hanno uno stato intermedio, o tutto o niente.

Che intendi per tutto o niente?

Che non c'è uno stato intermedio, rotto, a causa di svariati motivi.
Btrfs è un=https://it.wikipedia.org/wiki/Copy-on- ... system COW e sfrutta questo design per gli snapshot.

[emanuc]

Morale...un sistema operativo moderno rivolto agli utenti comuni, dovrebbe sempre avere un meccanismo di questo tipo e dovrebbe essere impostato e configurato di default. Che Arch non c'è l'abbia non mi stupisce vista la natura dell'utenza a cui si rivolge, che non lo abbia Ubuntu o distribuzioni simili, per me è una grave mancanza.

La penso esattamente come te.
Il giorno in cui Ubuntu offrirà di default il filesystem btrfs con gli snapshot già configurati potrà riguadagnare in un attimo il prestigio perso negli ultimi anni...

snapshots e pacchetti snap caricarebbero sul serio le ram mi pare....

Cosa c'entra con la ram e i pacchetti snap?

[noel80]

Morale...un sistema operativo moderno rivolto agli utenti comuni, dovrebbe sempre avere un meccanismo di questo tipo e dovrebbe essere impostato e configurato di default. Che Arch non c'è l'abbia non mi stupisce vista la natura dell'utenza a cui si rivolge, che non lo abbia Ubuntu o distribuzioni simili, per me è una grave mancanza.

La penso esattamente come te.
Il giorno in cui Ubuntu offrirà di default il filesystem btrfs con gli snapshot già configurati potrà riguadagnare in un attimo il prestigio perso negli ultimi anni...

snapshots e pacchetti snap caricarebbero sul serio le ram mi pare....

Cosa c'entra con la ram e i pacchetti snap?

Pardon, avevo capito male probabilmente

Se proprio le vuoi trovare un difetto, che non è un difetto di Suse ma del suo amministratore, è la policy di retention delle snapshot
- un massimo di 10
- anche meno di 10 (mai meno di 4) se lo spazio delle snapshot occupa più del 50%
il problema si pone quando il filesystem (senza snap) occupa più del 65-70%. Ho visto server arrivare a 100% durante gli upgrade. Niente di irrisolvibile, ma su un server di produzione allunga di un paio d'ore la scaletta.

[emanuc]

Morale...un sistema operativo moderno rivolto agli utenti comuni, dovrebbe sempre avere un meccanismo di questo tipo e dovrebbe essere impostato e configurato di default. Che Arch non c'è l'abbia non mi stupisce vista la natura dell'utenza a cui si rivolge, che non lo abbia Ubuntu o distribuzioni simili, per me è una grave mancanza.

La penso esattamente come te.
Il giorno in cui Ubuntu offrirà di default il filesystem btrfs con gli snapshot già configurati potrà riguadagnare in un attimo il prestigio perso negli ultimi anni...

snapshots e pacchetti snap caricarebbero sul serio le ram mi pare....

Cosa c'entra con la ram e i pacchetti snap?

Pardon, avevo capito male probabilmente

Se proprio le vuoi trovare un difetto, che non è un difetto di Suse ma del suo amministratore, è la policy di retention delle snapshot
- un massimo di 10
- anche meno di 10 (mai meno di 4) se lo spazio delle snapshot occupa più del 50%
il problema si pone quando il filesystem (senza snap) occupa più del 65-70%. Ho visto server arrivare a 100% durante gli upgrade. Niente di irrisolvibile, ma su un server di produzione allunga di un paio d'ore la scaletta.

Si riferisce allo spazio occupato sul disco e non alla ram.

[saxtro]

EDIT: ripensando anche all'intervento di @GjMan78 , mi viene anche da aggiungere:
ma sarebbe capace a bloccare il caricamento di grub per poter scegliere l'avvio da una snapshot?

Senza cercare il pelo nell'uovo basta configurare grub per essere sempre visibile, bastano 5 secondi di timeout del menu per dare il tempo all'utente di selezionare lo snapshot all'occorrenza.

Vero, senz'altro, ma non è di default (perchè qua si dibatteva su impostazioni default che aiutassero utenti non esperti), sulle distro che sto utilizzando oggi, solo OpenSuse setta un timeout per eventualmente interagire con il grub

[saxtro]

...
Forse in qualche vecchia versione di openSUSE/SUSE prima del nuovo layout dei subvolumi dove hanno fatto una separazione migliore, per mitigare questo tipo di problemi soprattutto sui server.
Ad oggi mi sembra difficile che il subvolume coinvolto dagli snapshot riesce ad occupare del 50% il filesystem, parliamo di un subvolume di 1/2GB circa.
Ho dato una controllata su openSUSE Leap, tutti quei snapshot stanno occupando solo qualche mb e non il 50% del filesystem:

...cut...

Avere tanti subvolume non diminuisce di default le dimensioni delle snapshot. Avere tanti subvolume permette di decidere su quali fare la snapshot e su quali no, permette di settare NOCOW sui subvolume che conterranno file transazionali (datafile di database e macchine virtuali in primis), e che non effettueranno la snapshot. Permette insomma di fare un "fine tuning", che per definizione, non è alla portata dell'utente inesperto

Io ho semplificato di molto la mia installazione, eppure a fronte di un rootfs di 22Gb circa, ho 67Gb allocati (solo / su btrfs, /home è su XFS, da dire che @home non sarebbe stata oggetto di snapshot di default)

Se calcolassi lo spazio occupato dalle snapshots solo basandomi sul campo Exclusive, dovrei giungere alla conclusione che i miei snapshots occupano meno di 3Gb.

Immagina l'utente non esperto, che sà di avere questo tool, ma non sà amministrarlo. Crea/distrugge VM in continuazione, fà editing video, , installa/disinstalla giochi da steamquanto ci mette a finire lo spazio senza sapere come?
(e senza avere piena possibilità di restore, perchè snapper di default quando lo spazio libero è inferiore al 20%, non conserva/prende tutte le snapshot richieste)

Secondo me, al giorno d'oggi, non esiste nessuna distro per utenti non esperti. Sicuramente l'utente non esperto su alcune distro è avvantaggiato per installazione/configurazione, ma è linux stesso che richiede di diventare esperti perchè possa essere utilizzato al meglio.
L'unica eccezione a questa regola, sono gli utenti che utilizzano il PC con poche esigenze generiche (posta, web, streaming, bollette, chat, e cose simili).

Che Suse abbia lo strumento per gestire le snapshot di btrfs più funzionale, è indubbio, ma devi saperlo amministrare.
Conosco persone che provano a cancellare (anche con rm) le snapshot 0 e 1, per poi lamentarsi che linux si è rotto ....

Questo ovviamente è il mio pensiero, riguardo gli utenti non esperti su linux, quando gli metti questo strumento a disposizione.

[emanuc]

Avere tanti subvolume non diminuisce di default le dimensioni delle snapshot.

Certo che diminuisce la dimensione massima. Inoltre dividendo in più subvolumi puoi escludere dal rollback quelle parti del filesystem non necessari per il corretto funzionamento di un rollback, è il caso di"var" dove ci sono molte nuove scritture ed è in questa occasione che la dimensione dello snapshot aumenta.

Avere tanti subvolume permette di decidere su quali fare la snapshot e su quali no

Appunto, quindi ne limiti la dimensione massima occupabile, perché post snapshot non occupa spazio uno snapshot, se non qualche kb.

permette di settare NOCOW sui subvolume che conterranno file transazionali (datafile di database e macchine virtuali in primis),

Sbagliato, non è solo per quello che si creano i subvolumi, perché puoi settare "nocow" per file o cartelle senza creare un subvolume.

Se calcolassi lo spazio occupato dalle snapshots solo basandomi sul campo Exclusive, dovrei giungere alla conclusione che i miei snapshots occupano meno di 3Gb.

Esatto, su 57Gb circa, gli snapshot occupano meno di 3gb ed è pochissimo spazio, non il 50%.

Immagina l'utente non esperto, che sà di avere questo tool, ma non sà amministrarlo. Crea/distrugge VM in continuazione, fà editing video, , installa/disinstalla giochi da steamquanto ci mette a finire lo spazio senza sapere come?
(e senza avere piena possibilità di restore, perchè snapper di default quando lo spazio libero è inferiore al 20%, non conserva/prende tutte le snapshot richieste)

Non avrebbe importanza per l'utente e per lo spazio degli snapshot, perché tutte quelle operazioni sono al di fuori del subvolume di snapshot, quindi l'utente X non avrebbe problemi a fare questo genere di operazioni perché i giochi steam sono sulla home dell'utente, le VM su boxes sono sempre sulla home dell'utente per Virt Manager sono su var che non è incluso negli snapshot.

Che Suse abbia lo strumento per gestire le snapshot di btrfs più funzionale, è indubbio, ma devi saperlo amministrare.
Conosco persone che provano a cancellare (anche con rm) le snapshot 0 e 1, per poi lamentarsi che linux si è rotto ....

Non devi amministare niente perché non c'è ninente da amministrare, perché snapper ha un algoritmo per la contabilità dello spazio e per la priorità degli snap e SUSE/openSUSE lo configura.
L'utente che cerca di eliminare con "rm" gli snap 0/1 si ritroverebbe con un bel warning che non può eliminarli perchè è di sola lettura, poi l'utente manualmente potrebbe anche fare un "rm -r /*" e su questo c'è poco da fare quindi siamo OT perché non ha niente a che vedere snapshot o non snapshot.

[woddy68]

Che Suse abbia lo strumento per gestire le snapshot di btrfs più funzionale, è indubbio, ma devi saperlo amministrare.
Conosco persone che provano a cancellare (anche con rm) le snapshot 0 e 1, per poi lamentarsi che linux si è rotto ....

Questo ovviamente è il mio pensiero, riguardo gli utenti non esperti su linux, quando gli metti questo strumento a disposizione.

@saxtro Non è così...non so da terminale, ma se si utilizza Yast- snapper non ti permette di cancellarlo, se capita è un bug.

Poi è ovvio, se un utente vuole distruggere il suo sistema, in qualche modo ci riuscirà.
Quando si utilizzano strumenti come super utente è scritto ovunque che bisogna sapere quello che si sta facendo.

[saxtro]

Che Suse abbia lo strumento per gestire le snapshot di btrfs più funzionale, è indubbio, ma devi saperlo amministrare.
Conosco persone che provano a cancellare (anche con rm) le snapshot 0 e 1, per poi lamentarsi che linux si è rotto ....

Questo ovviamente è il mio pensiero, riguardo gli utenti non esperti su linux, quando gli metti questo strumento a disposizione.

@saxtro Non è così...non so da terminale, ma se si utilizza Yast- snapper non ti permette di cancellarlo, se capita è un bug.

Poi è ovvio, se un utente vuole distruggere il suo sistema, in qualche modo ci riuscirà.
Quando si utilizzano strumenti come super utente è scritto ovunque che bisogna sapere quello che si sta facendo.

Il "provano" è per snapper delete e per yast2 snapper, poi passano a rm.
Ti ripeto, conosco gente che ha distrutto il sistema in questo modo.
La differenza tra l'utente non esperto e l'utente esperto, la fà il tempo che passi a istruirti su come funzionano le cose.

L'utente inesperto e non volenteroso, sfascia tutto e abbandona linux.
L'utente inesperto, ma volenteroso, sfascia tutto e inizia a studiare per capire cosa ha sbagliato.

Quando l'utente inizia a studiare prima di mettere mano (che dovrebbe essere la norma), già è un passo avanti.

[woddy68]

Che Suse abbia lo strumento per gestire le snapshot di btrfs più funzionale, è indubbio, ma devi saperlo amministrare.
Conosco persone che provano a cancellare (anche con rm) le snapshot 0 e 1, per poi lamentarsi che linux si è rotto ....

Questo ovviamente è il mio pensiero, riguardo gli utenti non esperti su linux, quando gli metti questo strumento a disposizione.

@saxtro Non è così...non so da terminale, ma se si utilizza Yast- snapper non ti permette di cancellarlo, se capita è un bug.

Poi è ovvio, se un utente vuole distruggere il suo sistema, in qualche modo ci riuscirà.
Quando si utilizzano strumenti come super utente è scritto ovunque che bisogna sapere quello che si sta facendo.

Il "provano" è per snapper delete e per yast2 snapper, poi passano a rm.
Ti ripeto, conosco gente che ha distrutto il sistema in questo modo.
La differenza tra l'utente non esperto e l'utente esperto, la fà il tempo che passi a istruirti su come funzionano le cose.

L'utente inesperto e non volenteroso, sfascia tutto e abbandona linux.
L'utente inesperto, ma volenteroso, sfascia tutto e inizia a studiare per capire cosa ha sbagliato.

Quando l'utente inizia a studiare prima di mettere mano (che dovrebbe essere la norma), già è un passo avanti.

Non esiste sistema operativo che non possa essere sfasciato a meno che blocchi root o sudo.
Se l'utente è stupido sfascia tutto, esattamente come l'automobilista stupido sfascia la sua auto, per questo c'è poco da fare...
Se una distribuzione o sistema ti mette a disposizione strumenti grafici che evitano che sfasci il sistema, ma tu vuoi usare il terminale senza esserne capace, sono solo affari tuoi...c'è poco da fare e ha poco da lamentarsi.

Edit. Secondo me, tu confondi l'utente inesperto che vuole usare Linux, con l'utente inesperto che vuole usare Linux per sperimentare e imparare, sono due utenti diversi.
Mio fratello, nel sistema che io gli ho installato, non credo che abbia mai usato su o sudo nel terminale.

[saxtro]

Avere tanti subvolume non diminuisce di default le dimensioni delle snapshot.

Certo che diminuisce la dimensione massima. Inoltre dividendo in più subvolumi puoi escludere dal rollback quelle parti del filesystem non necessari per il corretto funzionamento di un rollback, è il caso di"var" dove ci sono molte nuove scritture ed è in questa occasione che la dimensione dello snapshot aumenta.

Avere tanti subvolume permette di decidere su quali fare la snapshot e su quali no

Appunto, quindi ne limiti la dimensione massima occupabile, perché post snapshot non occupa spazio uno snapshot, se non qualche kb.
,...

Essendo il topic OpenSuse, è vero la distribuzione dei sottovolumi serve ad ottimizzare anche lo spazio, mea culpa sono andato off topic

....

permette di settare NOCOW sui subvolume che conterranno file transazionali (datafile di database e macchine virtuali in primis),

Sbagliato, non è solo per quello che si creano i subvolumi, perché puoi settare "nocow" per file o cartelle senza creare un subvolume.

Non è cosi semplice. Vero puoi settare attributo NOCOW a file e directories, con risultati a sorpresa però.
E' documentato qua: https://wiki.archlinux.org/title/btrfs

Il consiglio dei comptenti è:
vuoi che NOCOW funzioni come atteso? Meglio creare i subvolumes NOCOW su partizioni/device separati. Quanto meno su un subvolume dove si setterà l'attributo subito dopo la creazione (che è quello che fà OpenSuse con @/var).

NOCOW è uno di quei parametri di mount che funziona solo se settato sul primo subvolume montato.
https://btrfs.readthedocs.io/en/latest/ ... ation.html

...

Se calcolassi lo spazio occupato dalle snapshots solo basandomi sul campo Exclusive, dovrei giungere alla conclusione che i miei snapshots occupano meno di 3Gb.

Esatto, su 57Gb circa, gli snapshot occupano meno di 3gb ed è pochissimo spazio, non il 50%.

Non so cosa intenda tu per spazio occupato dalle snapshot, quello che posso dirti io è che su quel sistema se elimino tutte le snapshot e tengo solo 0 e 1, il filesystem /, droppa a 24Gb (57 - 3 =! 24)

...

Immagina l'utente non esperto, che sà di avere questo tool, ma non sà amministrarlo. Crea/distrugge VM in continuazione, fà editing video, , installa/disinstalla giochi da steamquanto ci mette a finire lo spazio senza sapere come?
(e senza avere piena possibilità di restore, perchè snapper di default quando lo spazio libero è inferiore al 20%, non conserva/prende tutte le snapshot richieste)

Non avrebbe importanza per l'utente e per lo spazio degli snapshot, perché tutte quelle operazioni sono al di fuori del subvolume di snapshot, quindi l'utente X non avrebbe problemi a fare questo genere di operazioni perché i giochi steam sono sulla home dell'utente, le VM su boxes sono sempre sulla home dell'utente per Virt Manager sono su var che non è incluso negli snapshot.

Che Suse abbia lo strumento per gestire le snapshot di btrfs più funzionale, è indubbio, ma devi saperlo amministrare.
Conosco persone che provano a cancellare (anche con rm) le snapshot 0 e 1, per poi lamentarsi che linux si è rotto ....

Non devi amministare niente perché non c'è ninente da amministrare, perché snapper ha un algoritmo per la contabilità dello spazio e per la priorità degli snap e SUSE/openSUSE lo configura.
L'utente che cerca di eliminare con "rm" gli snap 0/1 si ritroverebbe con un bel warning che non può eliminarli perchè è di sola lettura, poi l'utente manualmente potrebbe anche fare un "rm -r /*" e su questo c'è poco da fare quindi siamo OT perché non ha niente a che vedere snapshot o non snapshot.

Saper amministrare questo strumento (e quindi conoscerne il funzionamento), è fondamentale.
Sul fatto che si possa ignorarne l'esistenza tanto si automantiene da solo non sono per nulla d'accordo.

Sul forum di opensuse, ci sono parecchi esempi di come sia possibile riempire il disco.
Le richieste di aiuto per filesystem al 100% sono senz'altro di utenti inesperti, ma tant'è che il giocatolo, se non utilizzato come da manuale, si rompe.
es: https://forums.opensuse.org/t/btrfs-dis ... ion/172576

@woddy68 L'utente si può inserire nel gruppo degli utenti che non sanno come funziona btrfs.
Subito dopo lo snapper delete, se esegui il df, lo spazio non è ancora rilasciato, c'è bisogno di un minimo di tempo.
Questo utente preso dal panico che lo spazio era ancora non disponibile, è andato in /.snapshot, ha pensato "qui dovrebbe essere vuoto, ho cancellato tutto", ed ha combinato il pasticcio

[emanuc]

Non è cosi semplice. Vero puoi settare attributo NOCOW a file e directories, con risultati a sorpresa però.
E' documentato qua: https://wiki.archlinux.org/title/btrfs

Non è a sorpresa, perché è ovvio che devi settare "nocow"i fuori dal subvolume selezionato per lo snapshot e comunque "nocow" dovrebbe essere l'ultima spiaggia perché disattiva la maggior parte dei vantaggi che ha Btrfs.

Il consiglio dei comptenti è:
vuoi che NOCOW funzioni come atteso? Meglio creare i subvolumes NOCOW su partizioni/device separati. Quanto meno su un subvolume dove si setterà l'attributo subito dopo la creazione (che è quello che fà OpenSuse con @/var).

Hai interpretato male la lettura della guida su Arch, perché "nocow" per funzionare bene e "come atteso" non ha bisogno di essere su un subvolume separato, la motivazione del farlo su un subvolume separato l'ho scritta sopra.

NOCOW è uno di quei parametri di mount che funziona solo se settato sul primo subvolume montato.
https://btrfs.readthedocs.io/en/latest/ ... ation.html

Di nuovo... Puoi farlo come parametro di mount (sconsigliatissimo) o su cartelle, file o subvolume con l'attributo "nocow":

Codice: Seleziona tutto

sudo chattr +C /file_cartella_o_subvolume 

puoi mettere anche il ricorsivo "-R".

Non so cosa intenda tu per spazio occupato dalle snapshot, quello che posso dirti io è che su quel sistema se elimino tutte le snapshot e tengo solo 0 e 1, il filesystem /, droppa a 24Gb (57 - 3 =! 24)

Lo spazio reale occupato dallo snapshot che è la differenza tra i lsubvolume rootfs e lo snaps:
@rootfs 20gb > snap_rootfs 0GB occupati sul disco > remove 1GB su rootfs ; snap_rootfs occupa 1GB; remove snap_rootfs > recupero quel 1GB
Quindi non capisco da dove prendi quei 24GB e come calcoli lo spazio su Btrfs, ti ricordo che Btrfs non è ext4, xfs ecc perché se gli snapshot nel complesso hanno un diff di 3GB tu recuperi solo quei 3GB.

Sul forum di opensuse, ci sono parecchi esempi di come sia possibile riempire il disco.
Le richieste di aiuto per filesystem al 100% sono senz'altro di utenti inesperti, ma tant'è che il giocatolo, se non utilizzato come da manuale, si rompe.
es: https://forums.opensuse.org/t/btrfs-dis ... ion/172576

Anche in questo Forum o in altri trovi molti utenti con un partizionamento sballato e con una shell di emergenza perché hanno la partizione root ext4 piena, impossibilitati a liberare spazio. Su qualsiasi filesystem avrai problemi.

Subito dopo lo snapper delete, se esegui il df, lo spazio non è ancora rilasciato, c'è bisogno di un minimo di tempo.
Questo utente preso dal panico che lo spazio era ancora non disponibile, è andato in /.snapshot, ha pensato "qui dovrebbe essere vuoto, ho cancellato tutto", ed ha combinato il pasticcio

Perché l'utente dovrebbe mettersi a smanettare con "df" a guardare lo spazio occupato? "df" su Btrfs è lo strumento sbagliato per controllare lo spazio occupato.
Quindi un utente qualsiasi con qualsiasi filesystem preso dal panico inizia a eliminare roba a caso? Che argomentazione è? perché dovrebbe farlo se il filesystem non va in RO per mancanza di spazio? Cosa vuoi dimostrare? non l'ho capito.
Non puoi andare a cercare il caso d'uso peggiore per sostenere la tua tesi, perché potrei farlo anche io con Ubuntu che usa ext4 o chi usa LVm + FS ecc.