Tra le modifiche previste per Linux 7.3 c'è la rimozione di un pezzo di storia: il driver per il file system EFS, abbandonato a se stesso da oltre vent'anni. Utilizzato originariamente sui sistemi SGI IRIX per CD-ROM non ISO9660 e partizioni disco prima che IRIX 6.0 adottasse XFS, EFS era approdato nel kernel Linux come modulo read-only e senza un maintainer attivo per più di due decenni.

La decisione, per quanto attesa, è significativa per chiunque gestisca infrastrutture che poggiano su componenti kernel: ogni riga di codice non mantenuta è potenzialmente un problema di sicurezza o stabilità. Nel caso di EFS, l'assenza quasi totale di utilizzo moderno rende la rimozione poco controversa, ma il gesto ricorda l'importanza della manutenzione del software di sistema, soprattutto in ambienti dove si fa largo uso di tecnicie come i container e l'orchestrazione, spesso basate su kernel molto recenti.

Dal punto di vista tecnico, EFS (Extent File System) era un file system a 64 bit con alcune caratteristiche avanzate per l'epoca, come il supporto per gli extent, ma venne rapidamente superato da XFS, che offriva scalabilità e prestazioni superiori, e che rimane attivamente mantenuto fino a oggi. Il driver Linux per EFS era di sola lettura, quindi il rischio di corruzione dati era limitato, ma la sua presenza nel kernel rappresentava un debito tecnico che ora viene saldato.

La scelta di rimuovere EFS non è isolata: periodicamente il kernel Linux espunge driver legacy, un processo che accelera con l’introduzione di cicli di rilascio più veloci. Per chi gestisce server bare metal per LLM, questo può tradursi in maggiore prevedibilità degli aggiornamenti e minore necessità di test su percorsi di codice inutilizzati.

Implicazioni per chi valuta deployment on-premise

Per gli amministratori di sistema che gestiscono infrastrutture on-premise, la pulizia del kernel da codice obsoleto è generalmente un segnale positivo. Un kernel più snello riduce la superficie di attacco e semplifica il testing. Chi utilizza distribuzioni Linux con kernel di ultima generazione per hostare carichi di lavoro AI – ad esempio server per inference LLM o storage ad alte prestazioni – beneficerà indirettamente di questa pulizia. Nessuno oggi monterebbe un CD-ROM con file system EFS su un server AI, ma la rimozione è il sintomo di una manutenzione sana del cuore del sistema operativo.

La scelta di eliminare codice inutilizzato tocca anche un nervo scoperto nel dibattito sul "technical debt" nell'open source: da una parte c'è chi sostiene che mantenere tutto garantisce retrocompatibilità infinita, dall'altra chi vede questi driver come fardelli che nessuno controlla. La scelta del kernel Linux è stata pragmatica: se nessuno si offre di mantenere un componente per decenni, è probabile che non serva più a nessuno. Per chi schiera applicazioni in produzione, specialmente in contesti dove la compliance e la certificazione contano (settori regolati, sanità, difesa), sapere che il sistema operativo sottostante rimuove attivamente codice non mantenuto può essere un vantaggio, non una preoccupazione.

La vicenda EFS ci ricorda che le infrastrutture IT, anche quelle più moderne per LLM on-premise, poggiano su fondamenta fatte di scelte vecchie di trent'anni. La capacità di un ecosistema di fare pulizia è un segno di maturità.

Articolo redatto con analisi originale AI-RADAR.