Torvalds mantiene i propositi e pone Bcachefs nello stato di “externally maintained”, mantenuto fuori dal Kernel Linux

Nuova puntata della telenovela argentina “Bcachefs: un amore impossibile nel Kernel Linux“.

Nelle puntate precedenti, Kent Overstreet aveva pensato di poter rimuovere la dicitura “experimental” dal proprio codice, di propria iniziativa, senza curarsi della rimozione dal Kernel 6.17 da parte di Linus Torvalds.

Il creatore di Linux è ritornato in scena con una patch nella quale il file MAINTAINERS contenente appunto le informazioni sui responsabili del progetto:

(da notare la mail “torbalds”, con la “b”, chissà se un errore)

Ed in effetti la patch semplicemente corregge S: Supported in S: Externally maintained, dove la S sta appunto per il tipo di supporto.

Pertanto, così come aveva annunciato, ecco che Torvalds mantiene la parola ed esclude, non si sa per quanto tempo, Bcachefs dagli sviluppi del Kernel.

Questo significa comunque che, al momento, il codice Bcachefs è ancora presente nella linea principale del kernel Linux, il che, come racconta Phoronix, probabilmente impedirà agli utenti di avere qualsiasi ricaduta immediata nei file-system di Bcachefs che potrebbero già utilizzare (ma al momento non ci sono dati di utilizzo).

La palla passa a questo punto a Overstreet, o quantomeno, nella prossima puntata è più che legittimo attendersi la reazione dell’amante tradito, come in ogni telenovela che si rispetti.

Ci vediamo su Rete 4!

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

13 risposte a “Torvalds mantiene i propositi e pone Bcachefs nello stato di “externally maintained”, mantenuto fuori dal Kernel Linux”

  1. Avatar JustATiredMan
    JustATiredMan

    a parte la discussione con il creatore di bcachefs, è incredibile che in linux, non si riesca a fare un fs di livello enterprise stile zfs.
    Voglio dire che btrfs, nonostante gli anni che ci vanno dietro, resta ancora immaturo e bcachefs con queste diatribe non andrà lontano.
    In Linux alla fine, di nativo, resta ext4 e XFS che certamente, pur con tutto il rispetto che nutro, non possono competere con Zfs in certi ambiti.

  2. Avatar Alessandro Scarozza
    Alessandro Scarozza

    di preciso Externally maintained cosa implica ? un flusso diverso per inviare patch ?

  3. Avatar JustATiredMan
    JustATiredMan

    significa che il codice in questione non è mantenuto direttamente nel tree principale del kernel da chi lo ha scritto, ma è seguito in un repository esterno.
    In pratica, le patch o i bug fix sono nel repository esterno dello sviluppatore.
    Di solito il kernel principale integra una versione “snapshot” o “mirror” di quel codice.
    i maintainer del kernel non garantiscono supporto diretto; eventuali problemi vanno sollevati al progetto esterno.
    Ad esempio, in passato anche il NTFS-3G era un externally maintained

  4. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Puoi per favore indicare cosa ha di immaturo Btrfs? Visto che è il filesystem predefinito di molte distro.

    Puoi specificare il perché Btrfs non lo ritieni di "livello Enterprise"? Affermando automaticamente che tutti quelli che lo stanno usando in produzione sono dei matti a usare un filesystem che TU ritieni non maturo, in base alle tue valutazioni da esperto di filesystem.

  5. Avatar Gandalf Corvotempesta
    Gandalf Corvotempesta

    1 fra tutti: il raid56 instabile e non production ready da……..10 anni?

  6. Avatar Gandalf Corvotempesta
    Gandalf Corvotempesta

    predefinito in molte distro ovvero quali, a parte forse Suse (per ovvi motivi, in caso) e derivate?

  7. Avatar JustATiredMan
    JustATiredMan

    prima cosa, visto il tono he mi pare abbia il tuo post (se poi sbaglio mi scuso in partenza)
    La mia osservazione non vuole essere polemica in nessun modo. Le polemiche o guerre di religione non mi interessano.
    Veniamo al merito.

    1) Capita spesso, che per ragioni di storage di dati freddi e/o backup si facciano nas dai 30 ai 200 Tb. Magari duplicati in disaster recovery. In quel caso non servono grandi prestazioni, ma un certo grado di sicurezza si. Un raid6 e quindi 2 dischi a perdere, sono un buon compromesso. Zfs con raid-z3 ne permette 3 dischi di parità.
    Questa cosa, su Btrfs è ancora instabile a più di 10 anni di distanza:
    https://btrfs.readthedocs.io/en/latest/Status.html
    Voglio dire, in tutta onestà, tu ti fideresti a tenere 100 Tb di dati di un azienda in qualcosa che anche se estremamente raro, può darti quel problema che è ancora li ?

    2) zfs ha meccanismi di cache più granulari, per situazioni particolari. l' Arc, la cache di primo livello è in ram, puoi configurare la l2arc per andare su ssd, e/o zil-slog per la gestione sincrona/asincrona delle scritture, che possono aumentare le prestazioni sui db:
    https://www.45drives.com/community/articles/zfs-caching
    non credo ci siano funzionalità simili su btrfs… ma forse sbaglio.

    3) zfs ha supporto nativo per l'invio e ricezione degli snapshot (zfs send / zfs receive)
    https://docs.oracle.com/cd/E18752_01/html/819-5461/gbchx.html
    utile appunto se devi replicare storages frà di loro. Non sono sicuro, ma non mi pare ci sia in btrfs, salvo usando tools terzi.

    4) deduplica: si è vero, richiede un botto di memoria e cpu, e in molti casi, il guadagno di spazio non giustifica la complessità… però in ambienti di virtualizzazione, qualche volta aiuta.

    queste sono quelle che mi vengono in mente perchè più usate… poi se qualcuno ne conosce altre.

  8. Avatar Valerio
    Valerio

    È vistosamente più lento di ext4

  9. Avatar Black_Codec

    La deduplica non tanto in ambienti di virtualizzazione ma in ambienti ee per i documenti è una manna dal cielo, la gente non ha idea di quanti "doppioni" ci siano… Non parlo di stesso file ma di file simili e li la deduplica è fantastica. In aziende con documenti standard, vedi aziende logistiche, guadagni fino al 60% di spazio in più…

  10. Avatar lion1810
    lion1810

    CachyOS

  11. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Le polemiche o guerre di religione non mi interessano.

    Nessuna guerra di religione, non mi interessano e mai interessate, quello che mi da fastidio è il FUD. Anzi, se il tono della discussione dovesse trasformarsi in questo modo, sono il primo a non rispondere più.

    Poi ci si può confrontare argomentando, con rispetto, e spero che questa discussione vada in questa direzione.

    1) Capita spesso, che per ragioni di storage di dati freddi e/o backup si facciano nas dai 30 ai 200 Tb. Magari duplicati in disaster recovery. In quel caso non servono grandi prestazioni, ma un certo grado di sicurezza si. Un raid6 e quindi 2 dischi a perdere, sono un buon compromesso. Zfs con raid-z3 ne permette 3 dischi di parità.

    Questa cosa, su Btrfs è ancora instabile a più di 10 anni di distanza:

    Scusami, ma su grossi storage metti i dati in RAID 6 e poi mi parli di disaster recovery? Soprattutto in contesti dove non servono prestazioni elevate. Ti rendi conto di quanto tempo richiede la ricostruzione della parità su volumi così grandi in RAID 6? Al massimo può andare bene per piccole realtà.
    Btrfs ha il Raid 1 a 2, 3 o 4 copie: Raid 1; Raid1C3 e Raid1C4.

    Comunque, il Raid parity sarà risolto dal RAID stripe tree, attualmente è nascosto tramite flag sperimentale

    Voglio dire, in tutta onestà, tu ti fideresti a tenere 100 Tb di dati di un azienda in qualcosa che anche se estremamente raro, può darti quel problema che è ancora li

    Scusami, non capisco che problema possa dare Btrfs rispetto a qualasiasi FS se si usano le sue funzionalità stabili; a pensarci, non più di qualsiasi altro filesystem.

    Anche perché ti garantisco che viene usato in produzione, sia da piccole che da grandi realtà, per non citare solo il caso di Meta, che di sicuro non può permettersi di affidarsi a un filesystem immaturo o che possa causare perdite di dati o altri problemi. Anche se hanno risorse e sviluppatori, restano sempre limitati. Dai dati pubblici, comunque, sembra che abbiano tratto molti benefici nell’adottarlo.

    2) zfs ha meccanismi di cache più granulari, per situazioni particolari. l' Arc, la cache di primo livello è in ram, puoi configurare la l2arc per andare su ssd, e/o zil-slog per la gestione sincrona/asincrona delle scritture, che possono aumentare le prestazioni sui db

    Cosa c'entrano le funzionalità con la maturità di un filesystem? Chiedo, perché ZFS ha i suoi vantaggi che Btrfs non ha e viceversa. (comunque, ci sono delle Patch RFC, ma evidentemente sono casi d'uso non importati e con bassa priorità per gli sviluppatori Btrfs). Ma, ripeto, non ci azzecca niente con la maturità di un filesystem.

    3) zfs ha supporto nativo per l'invio e ricezione degli snapshot (zfs send / zfs receive)

    Praticamente "send|receive" è stato introdotto nel kernel Linux 3.6, rilasciato il 30 settembre 2012. Questo dimostra che stai valutando un filesystem non avendolo mai usato e sconoscendone le funzionalità e lo stato di sviluppo.
    PS: Sono passati due formati e un V3 in sviluppo.

    4) deduplica: si è vero, richiede un botto di memoria e cpu, e in molti casi, il guadagno di spazio non giustifica la complessità… però in ambienti di virtualizzazione, qualche volta aiuta.

    Btrfs supporta il caso della deduplica "out-of-band", puoi eseguirlo con un software come Bees, duperemove, dduper ecc. Oppure te ne crei uno tu in base al caso d'uso ( l'implementazione tramite IOCTL è all'interno del filessystem). Per la deduplica "in-band", in base a quello che leggo in giro non ha molto senso perché richiede un eccessivo uso di risorse. Sono state presentate delle patch nel 2013 ma mai unite, da quel che ho letto la motivazione è che non è molto vantaggioso.

  12. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Evidentemente non è una funzionalità prioritaria per gli sviluppatori di Btrfs. Questo non ha niente a che vedere con la maturità di un filesystem, è solo una funzionalità dichiarata instabile. Che comunque, ripeto, sarà risolto dal RAID stripe tree.
    Perché vi attaccate sempre a UNA funzionalità come il Raid 5/6, ogni volta? Lo usate tutti? sui vostri desktop e in qualsiasi situazione? Sapete almeno i pro e i contro del raid parity? come e perché usarlo?

  13. Avatar Emanuele Cavallaro
    Emanuele Cavallaro

    Fedora, openSUSE/SUSE, Valve Steam Deck (solo rootfs), CachyOS, Manjaro Linux, CentOS Hyperscale

Lascia un commento

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