Il kernel 4.19 non ha pace, problemi anche con il filesystem ext4

18

Qualche problemino con il kernel 4.19 c’è già stato, da performance dati basse dovute al backport di mitigation per gli ormai famosi bug Spectre V2 sino a piccoli bug più che normali in qualsiasi software, la cattiva notizia è che non è finita qui. L’ultimo problema che sta affliggendo alcuni utenti è abbastanza critico: stiamo parlando della corruzione di alcuni filesystem ext4.

A metà Novembre è stato aperto un bug sul Bugzilla di kernel.org riguardo questo problema e questa ultima settimana la discussione si è accelerata quando Guenter Roeck (sviluppatore di lunga data del kernel) ha rilevato il verificarsi del bug anche nella versione stabile del kernel 4.19, riscontrando il problema su almeno due sistemi da lui gestiti. Altri utenti, invece, segnalano di essere in grado di riprodurre il problema ad ogni boot della loro macchina.

Inizialmente si pensava avesse a che fare con il BLK MQ (multi-queue block code) all’interno del kernel, ma pare che la correlazione è stata poi esclusa; sfortunatamente, in tutti questi test, il manutentore del suddetto filesystem Ted Ts’o non è stato in grado di riprodurre questa corruzione sui suoi sistemi.

Ts’o, nella discussione sulla pagina del bug, ha commentato riguardo ai suoi dubbi sull’introduzione del problema tra il kernel 4.18 e 4.19

I’m pretty sure the problem is not in the ext4 changes between 4.18 and 4.19, since the changes are all quite innocuous (and if it was in the ext4 code, the regression testing really should have picked it up).

Sono abbastanza sicuro che il problema non risiede nelle modifiche ad ext4 tra 4.18 e 4.19, visto che le modifiche sono tutte molto innocue (e se fosse nel codice ext4, i test di regressione le avrebbero sicuramente rilevato).

Come contro prova sta chiedendo agli utenti che rilevano il bug di testare un kernel 4.19 con le patch al filesystem ext4 provenienti dalla versione 4.18, ipotizzando quindi che il problema di corruzione del filesystem non provenga direttamente dal codice del driver ext4.

But just to rule things out, I’ve uploaded the contents of fs/ext4 from 4.18. I’ve verified it can be transplanted on top of 4.19 kernel. Could the people who are experiencing problems with 4.19 try building a kernel with the 4.18 fs/ext4 directory? If you still see problems, then the problem has to be elsewhere.

Ma giusto per escludere la cosa, ho caricato [come allegato nel bugzilla, ndt.] il contenuto di fs/ext4 dal 4.18. Ho verificato e può essere tranquillamente trapiantato sopra il kernel 4.19. Possono le persone che hanno avuto i problemi con il 4.19 provare a fare la build di un kernel con la directory fs/ext4 del 4.18? Se continuano ad avere problemi, allora i problemi devono essere da un’altra parte

Quindi, se state programmando di installare un kernel 4.19 e di utilizzare ext4 come filesystem, vi conviene aspettare un attimo, seguire la discussione e vedere se il problema viene risolto in breve tempo, cosa che si spera considerando tutti gli sviluppatori ed utenti che stanno lavorando e testando questo grave problema.

E voi? Avete avuto esperienze a riguardo?

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.

18 risposte a “Il kernel 4.19 non ha pace, problemi anche con il filesystem ext4”

  1. Avatar JustATiredMan
    JustATiredMan

    Ecco… Torvalds fà il buono ed escono fuori le rogne….

  2. Avatar Raoul Scarazzini
    Raoul Scarazzini

    Ahahah… Touché 😀

  3. Avatar JustATiredMan
    JustATiredMan

    :-D… vuoi vedere che è colpa di systemd ?????? 😛

  4. Avatar carlo coppa
    carlo coppa

    Le mie macchine eseguono Tumbleweed con il kernel 4.19, ma fortunatamente utilizzo Btrfs, per cui non dovrebbero esserci problemi.

  5. Avatar Cristiano Donno
    Cristiano Donno

    io ho avuto un sacco di problemi con kde neon (18.04) e tutte le release del kernel 4.19, cosa che su ubuntu unity 18.04 e ubuntu budgie 18.04 non accadeva, il che mi aveva portato a pensare che il problema fosse il sistema operativo in se per se. ora invece è stato svelato l’arcano. ho reinstallato neon senza aggiornare il kernel e, risultato, nessun problema da giorni

  6. Avatar JustATiredMan
    JustATiredMan

    Btrfs ? è abbastanza affidabile ?
    O lo stai usando solo per il tuo pc personale ?

  7. Avatar carlo coppa
    carlo coppa

    E’ il file system di SUSE Enterprise insieme a XFS, non credo che diano ai loro clienti file system inaffidabili, visto che pagano e solitamente sono utilizzati anche su server di grosse dimensioni.
    Inoltre Btrfs è utilizzato sui server di Facebook e di altre grandi aziende.

  8. Avatar JustATiredMan
    JustATiredMan

    Non discuto del contrario, però mi pare non sia del tutto maturo. Mi pare che il supporto ai raid 5-6 non sia del tutto sicuro, e che ancora oggi in quei casi, lo si usa ancora con mdraid. Come pure mi pare abbiano ancora qualche problema con il supporto alle quote.

  9. Avatar carlo coppa
    carlo coppa

    C’erano problemi su raid 5, che ora negli ultimi kernel sono risolti, ma parliamo di cose che comunque sono raramente utilizzati da un normale utente desktop. Le quote possono essere un problema in alcuni casi, non è un caso che di default sono disabilitate, anche se openSUSE ad esempio le abilita, ma ci vuole un attimo a disabilitarle. Le quote servono in un sistema multiutente dove poter creare istantanee divise, anche in questo caso una pratica poco utilizzata. E’ ovvio che la complessità di un file system come BTRFS che ha più funzionalità di EXT4 sia più complesso da gestire.
    Edit. mi sono informato e Raid 5-6 ha avuto il fix dal kernel 4.16. Comunque tornando alla tua domanda, è affidabile Btrfs ? Si come lo sono tutti, dopodiché i backup esistono proprio perchè nulla è mai affidabile al 100%. Ext4 è affidabile ? Si, eppure come vedi qualcuno ci ha rimesso i propri dati. Morale, per me tutti sono affidabili e tutti non lo sono, preferisco però un file system che mi permette di recuperare il mio sistema, se si rompe a causa di un aggiornamento finito male, o semplicemente per un mio errore di configurazione. Questo è il motivo per cui preferisco Btrfs a Ext4, l’affidabilità sui file è sempre meglio metterla nelle mani di sicuri backup.

  10. Avatar JustATiredMan
    JustATiredMan

    Che nulla sia affidabile al 100% e che un backup sia da fare sempre, fin quì sfondi una porta aperta… e ci mancherebbe.
    La mia domanda inziale, forse posta male, era realtivamente all’impiego di btrfs in un server di lavoro.
    In una tale situazione, e da quello che trovo su wiki di btrfs:
    https://btrfs.wiki.kernel.org/index.php/Status
    Mi pare ci siano alcune lacune… tutto li.
    Oppure si può usare, a patto di usarlo come volume liscio senza andare ad attivare alcune opzioni avanzate come appunto le quote o il raid embedded (fatto salvo il mirroring).
    In sostanza, da quello che mi pare di vedere Btrfs non è ancora così maturo da poter sostituire ad esempi ZFS con una distribuzione Bsd.
    Poi sono d’accordo che in un desktop ad uso personale, dove al massimo si usa il mirroring con un paio di hd, allora si può già considerare maturo.

  11. Avatar carlo coppa
    carlo coppa

    Se ti può interessare, uno dei pc server più potenti al mondo, gira con SLE e utilizza Btrfs. Comunque ora è più chiara la tua domanda…alla fine secondo me come ti ho già scritto, tutti i file system presenti nel kernel sono da ritenersi stabili e affidabili, dopodiché a seconda delle esigenze si può scegliere quello più adatto. Ad esempio io utilizzo con openSUSE btrfs, perché mi ha salvato in un paio di occasioni da una perdita di tempo che quando lavori significa soldi. Le istantanee e la modalità con cui sono state predisposte in OS è uno dei motivi che mi ha fatto scegliere openSUSE su Ubuntu o altre distribuzioni. Avere la possibilità di ripristinare il sistema in pochi minuti, quando lavori non ha prezzo. Btrfs con le impostazioni attivate in openSUSE, come anche la quota, funziona bene a patto di avere un buon HD, altrimenti diventa utile disattivare la quota. Se installo openSUSE su un vecchio HD, quasi sicuramente avrò problemi con la quota, ma se ho un buon HD la quota non inciderà sulle prestazioni, tuttavia la quota come ho già scritto per un utente desktop non è importante, in OS è abilitata in quanto OS eredita le impostazioni di SLE. Ciao

  12. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Anche con Ubuntu puoi scegliere Btrfs e fare snapshot in modo semplice come su openSuse, anche se devi installare un software esterno; timeshift.
    Infatti anche io uso Btrfs, ma su Ubuntu + timeshift.

  13. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Si, ci sono alcune feature ancora non pronte o stabili, tra cui il raid 5/6.
    Nel kernel 4.21 ad esempio ci sarà il supporto allo swapfile.
    Come ti hanno detto, Btrfs non è un fs semplice come ext4, ha molte featire, quindi piu complesso e non puoi paragonarlo a un ext4…

    Ecco una lista alle feature su cui stanno lavorando attualmente:

    Features Currently in Development or Planned for Future Implementation
    Online filesystem check
    Object-level mirroring and striping
    Alternative checksum algorithms
    In-band deduplication (happes during writes)
    In-band dedupe design document
    How to use in-band dedupe
    Hot data tracking and moving to faster devices (or provided on the generic VFS layer)
    SMR (zoned block device) support
    DAX/persistent memory support
    The file/directory -level encryption support (fscrypt)

  14. Avatar carlo coppa
    carlo coppa

    Ciao, beh ovviamente anche in Ubuntu puoi usare Btrfs e utilizzare le istantanee, sono una caratteristica di Btrfs non di openSUSE, mi sembrava fosse chiaro. Ovviamente ci sono importanti differenze, in openSUSE è tutto molto integrato…faccio un esempio, se apro Yast e faccio una o più modifiche al sistema, quando chiudo Yast automaticamente si creerà uno snapshot, quindi ne avrò una pre e una post modifiche. Questo perché se ho fatto modifiche che hanno rotto il sistema o creato problemi, posso tornare facilmente a prima delle modifiche e questo è fondamentale, stessa cosa succede quando faccio gli aggiornamenti. Il tutto in modo silenzioso e automatico. Questo in Ubuntu non è possibile, a meno che lo fai manualmente, il che significa che la volta che avrai problemi hai dimenticato di farlo.

  15. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Su Ubuntu hai “apt-btrfs-snapshot” se vuoi ogni modifica quando fai aggiornamenti o installazioni, ma lo trovo scomodo il modo in cui fa snapshot openSUSE e apt-btrfs-snapshot, perché fa troppi snapshot a parer mio inutilmente.
    È molto più comodo per me e ti eviti molti snapshot (anche se inizialmente uno snap non occupa spazio, nel tempo quando ci saranno differenze nei file, aumenterà lo spazio, oltre che un uso di balance quasi d’obbligo)
    fare degli snapshot mensilmente, settimanali o giornalieri.
    Ad esempio io ho 1 snapshot mensile, 1 settimanale, e uso lo snapshot manuale se faccio operazioni rischiose, o cambio D.E.
    Ad esempio sono su Ubuntu 19.04 con gnome, ma ho lo snapshot di Kubuntu 18.04, ed è uno snapshot manaule.

    https://uploads.disquscdn.com/images/58b579034467464a196415ce04f31b4cb16fe708c6e4cf40d27b736a00e5da02.png

  16. Avatar carlo coppa
    carlo coppa

    …si, ma sono incrementali eh…! Mica ogni volta ne crea uno nuovo ! Inoltre puoi decidere da snapper quanti tenerne, se pensi che le impostazioni di default siano troppo conservative. Dopo un mese di Tumbleweed (ho cambiato HD e quindi ho re-installato) ecco quanti ne ho…e saranno sempre lo stesso numero dal momento che lo impostato io così. https://uploads.disquscdn.com/images/a6a545206e11c67177ca4f2690a3b33505d220b9cd30848c63532517ad4cbf41.png

  17. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Gli snapshot non sono incrementali, ma atomici. Ad ogni snapshot ti crea la copia del suo subvol: @home > @home_snap1; @home > @home_snap2 etc
    Tranne che snapper usa i backup incrementali (cosa assurda se vero), ma se fai lo snap veloce e occupi poco spazio, non sono quelli incrementali.

    “Instant, Atomic COW Snapshots
    Since the snapshots are atomic, when a snapshot is restored it appears to applications as if a power loss had occurred (and the filesystem has gone back to an earlier state). Thus it is possible to backup databases without stopping them beforehand.

    Incremental Snapshot Transfer
    Efficiently determining and streaming the differences between two snapshots if they are either snapshots of the same underlying subvolume, or have a parent-child relationship. This is far quicker than e.g. rsync could, especially on large file systems. (For instance, rsync cannot be aware of mere metadata changes like filename, location etc but the FS itself is certainly aware of it.)
    This page presents some approaches to leverage these capabilites.”

  18. Avatar carlo coppa
    carlo coppa

    Al di là di tutto, il concetto non cambia…puoi decidere quante istantanee tenere, per cui il problema di spazio non esiste se non come per qualsiasi altra cosa. Comunque, ci tengo a precisare, io non ho mai detto che per utilizzare le istantanee occorre utilizzare openSUSE, si può fare su qualsiasi distribuzione Gnu/linux. Quello che io ho detto è che in openSUSE è già configurato di default per funzionare, dopodiché ognuno farà le proprie scelte. Io ho utilizzato Ubuntu per anni e ho sempre utilizzato ext4, non sapevo neanche dell’esistenza della possibilità di avere le istantanee. Con KdeNeon sol portatile di mia nipote, gli ho messo btrfs, con la possibilità di fare le istantanee, ma manualmente. Il mondo di Gnu/Linux è bello perché è vario, non esiste solo Ubuntu, come non esiste solo openSUSE. A ognuno il suo !

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *