{"id":138411,"date":"2025-06-28T11:12:07","date_gmt":"2025-06-28T09:12:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/linus-tovalds-nameren-isklyuchit-bcachefs-iz-yadra-linux-6-17"},"modified":"2025-06-28T11:12:07","modified_gmt":"2025-06-28T09:12:07","slug":"linus-tovalds-nameren-isklyuchit-bcachefs-iz-yadra-linux-6-17","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/linus-tovalds-nameren-isklyuchit-bcachefs-iz-yadra-linux-6-17","title":{"rendered":"Linus Torvalds intende escludere Bcachefs dal kernel Linux 6.17","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Una nuova discussione tra Linus Torvalds e Kent Overstreet, autore di Bcachefs, si \u00e8 conclusa con la volont\u00e0 di Linus di escludere il codice Bcachefs dal kernel Linux 6.17. Tuttavia, Linus ha incluso nel kernel 6.16 le modifiche a Bcachefs, che sono state oggetto di ulteriori disaccordi riguardo le azioni di Kent. Linus ha scritto: <\/p>\n
\n
Credo che le nostre strade si separeranno nella finestra di integrazione 6.17. <\/p>\n
Hai chiaramente fatto capire che non posso mettere in discussione alcuna correzione di bug e devo semplicemente accettare tutto. <\/p>\n
A dire il vero, non mi sento particolarmente a mio agio con tutto questo e l'unica cosa su cui entrambi, apparentemente, concordiamo nella discussione \u00e8 che «abbiamo finito». <\/p><\/blockquote>\n
La corrispondenza precedente a questa dichiarazione con Kent \u00e8 stata privata e i dettagli non sono chiari per il momento. Tuttavia, durante la discussione su questo argomento, Kent ha scritto che le sue parole in una corrispondenza privata potrebbero essere state fraintese e non crede che BcacheFS debba essere escluso dal kernel. \u00c8 comunque aperto a interrompere la fornitura di Bcachefs nel kernel principale Linux e questo non uccider\u00e0 il progetto, anche se rappresenter\u00e0 un enorme problema. Se Bcachefs verr\u00e0 rimosso, lo sviluppo continuer\u00e0 e questo filesystem sar\u00e0 distribuito come modulo DKMS. Kent ha anche sottolineato che escludere BcacheFS dal kernel sarebbe la migliore soluzione per la sua tranquillit\u00e0 con Linus, ma non sar\u00e0 la migliore per gli utenti e la comunit\u00e0 di sviluppatori. <\/p>\n
Le dispute tra Kent e Linus sono causate da continui violazioni delle regole per l'invio di modifiche e correzioni al kernel. Kent ritiene che le correzioni dei problemi nel filesystem debbano essere portate avanti senza indugi e in ogni modo possibile. Linus insiste che i cambiamenti funzionali e le correzioni significative sono ammessi nelle fasi iniziali dello sviluppo di un nuovo ramo del kernel, mentre i candidati tardivi per il rilascio si concentrano esclusivamente sulla correzione dei bug. Kent viola regolarmente questa regola e invia modifiche significative nel momento sbagliato, portando al malcontento di Linus e a una nuova ondata di dispute. In passato, Linus aveva gi\u00e0 avvertito Kent della sua volont\u00e0 di rimuovere Bcachefs dal kernel principale, poich\u00e9 Kent continua a giocare da solo nella sua sabbiera, non si unisce al lavoro di squadra e non desidera seguire le regole del gioco della comunit\u00e0 di sviluppatori del kernel. <\/p>\n
Nel caso del kernel 6.16, Kent ha inviato un insieme di patch per essere incluse nell'aggiornamento RC3, tra cui una patch con l'implementazione della nuova opzione «journal_rewind». Linus ha scritto che Kent si era dimenticato che dopo la chiusura della finestra per l'accettazione delle modifiche funzionali, l'aggiunta di nuove funzionalit\u00e0 nel kernel non \u00e8 consentita, anche se \u00e8 collegata alla risoluzione di altri errori, poich\u00e9 l'aggiunta di nuove opzioni nelle fasi avanzate di formazione del rilascio pu\u00f2 portare a regressioni. Inoltre, Bcachefs continua a essere considerato un file system sperimentale e la rapidit\u00e0 nella risoluzione degli errori non \u00e8 cos\u00ec critica. <\/p>\n
Kent ha risposto che l'obiettivo principale dello sviluppo \u00e8 fornire agli utenti codice funzionante, quindi non intende cedere su questioni relative alla risoluzione di errori che influenzano l'integrit\u00e0 dei dati. A differenza di altri sottosistemi, gli errori nel file system non si risolvono con un riavvio e possono portare alla corruzione dei dati, quindi, secondo Kent, rinviare la loro risoluzione fino alla prossima finestra di accettazione delle modifiche \u00e8 inaccettabile, anche se tali correzioni richiedono modifiche sostanziali. <\/p>\n
La nuova opzione «journal_rewind» riportava indietro le modifiche nel registro per ripristinare il file system a uno stato precedente. Kent ritiene che la nuova opzione debba essere attivata senza indugi, poich\u00e9 risolve il problema di recupero del file system per gli utenti che hanno riscontrato un errore durante l'eliminazione delle sottosezioni e non hanno un backup. Inizialmente, Linus si era rifiutato di accettare il pacchetto di patch contenente questa modifica nel kernel 6.16-RC3, ma dopo una corrispondenza personale con Kent ha cambiato idea e ha accettato le modifiche nel codice base su cui si basa l'aggiornamento 6.16-RC4. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"