Linux-kernel 7.0 brengt zelfgenezend bestandssysteem en omarmt Rust nu officieel

De zevende versie van de Linux-kernel is officieel uitgebracht en brengt een reeks kleinere verbeteringen. Het gaat onder meer om zelfherstellende mogelijkheden voor het bestandssysteem XFS, omarming van de veiligere programmeertaal Rust en ondersteuning voor nieuwere hardware.

Linux 7.0 ondersteunt bijvoorbeeld de Zen 6-processors van AMD en de Nova Lake-processors van Intel. Daarnaast bevat de kernel nu optimalisaties voor AMD's krachtige Epyc-processors en schakelt hij de TSX-functie van Intel standaard in op processors waar dat geen beveiligingsprobleem is. Deze Transactional Synchronization Extensions van Intel kunnen een prestatieverhoging geven, maar bleken in oudere chips te misbruiken voor zogeheten sidechannelaanvallen.

Verder is de programmeertaal Rust nu officieel opgenomen in Linux. Deze taal, die betere beveiliging biedt tegen geheugenlekken, was al sinds 2022 aanwezig in het besturingssysteem. Tot op heden was het een experimentele optie. Ook al jaren beschikbaar in Linux is het bestandssysteem XFS, dat nu autonome mogelijkheden krijgt voor zelfreparatie. Dit biedt proactieve bescherming tegen datacorruptie, waarbij de kernel het bestandssysteem monitort op fouten.

Van 6.19 naar 7.0

De ophoging van het releasenummer naar 7.0 is niet vanwege ingrijpende veranderingen, schrijft Phoronix, maar vanwege de voorkeur van Linux-ontwikkelaar Linus Torvalds. De oorspronkelijke maker van het besturingssysteem wil na negentien kernelreleases over naar het volgende hoofdgetal. De Linux-kernel gaat nu dus van versie 6.19 naar 7.0.

Linux-mascotte Tux. Bron: Larry Ewing and The GIMP

Reacties (28)

[Nightscope]

Ik vraag me af hoe dat zelfgenezing werkt. Wanneer is iets corrupts? Als ik mijn distro rice ziet hij de bestanden in mijn root nu als potentieel gevaar?

Klinkt wel tof in de oren maar vind het interessant om onder de motorkap te kijken

[Cilph]

Bestanden in je root is gewoon valide gebruik, al is het ongewoonlijk. Corruptie slaat meer op wanneer de interne datastructuren van het bestandssysteem niet meer consistent zijn. A impliceert B maar B is er niet. Denk aan hashing van blokken, ontbrekende blokken, circulaire verwijzingen, incorrecte verwijzingen, ... hangt een beetje af van hoe XFS technisch werkt, dat heb ik niet in mijn hoofd.

[youridv1]

in plaats van je dat af te vragen, kun je ook op de de hyperlink onder "proactieve bescherming" klikken.
vaak als een term een linkje is, zit er meer informatie achter die link

[RoestVrijStaal]

Die link linkt naar heise.de met een irritante cookiepaywall. Dus zo gek is de vraag ook niet.

Van alle FOSS-nieuwswebsites die erover bericht hebben, uitgerekend die ene pakken die zo'n paywall heeft

Volgens Phoronix gaat het om deze patch.

[youridv1]

Daar heb ik de browser extensie "i still don't care about cookies" voor

[marktweakt]

Misschien dezelfde checks en repairs die bijvoorbeeld fsck nu ook al doet maar dan on-the-fly?

[goarilla]

Van wikipedia:

Linux kernel 5.10, released in December 2020, included the new on-disk format XFS v5. This was a hard break, since the deprecated XFS v4 can not be converted to XFS v5. Data on partitions formatted with XFS v4 has to be backed up to another partition or media in order to restore it after formatting the old partition with XFS v5, which completely wipes all data on it. The support for XFS v4 will be removed from the Linux kernel in September 2030.[23][24]

XFS v5 introduced "bigtime", to store inode timestamps as a 64-bit nanosecond counter instead of the traditional 32-bit seconds counter. This postpones the previous Year 2038 problem until the year 2486.[5] It also introduced metadata checksums.

Dus metadata checksums en periodisch scrubben ?

[Reactie gewijzigd door goarilla op 14 april 2026 17:04]

[laurxp]

Als je zoekt op "xfs online fsck", dan kom je een héél uitgebreid artikel tegen in de officiële kernel docs.

Kort samengevat:

De metadata in moderne bestandssystemen heeft een hoop redundantie. Zo slaat een folder op welke bestanden deze bevat, maar een bestand slaat óók op in welke folder deze staat. Als XFS de bestanden van folder A aan het ophalen is, en het ziet dat bestand X zegt dat het in folder B staat, dan is er iets corrupt.

De grote vraag is wat je vervolgens doet. Traditioneel kan je niet verder met een corrupt bestandssysteem, dus is je enige optie om de hele computer te laten crashen. Vervolgens kan de systeembeheerder offline het bestandssysteem proberen te repareren - maar dat zorgt voor een hele hoop downtime, en zal lang niet altijd op een gepast moment plaats vinden.

Het idee van "zelfgenezing" is dat het bestandssysteem zichzelf terug kan brengen in een consistente staat, waardoor het in principe verder kan draaien. Bij het eerder genoemde voorbeeld kan je natuurlijk gewoon de folders A en B geheel verwijderen: sure, je verliest wat data, maar je kan wél verder draaien, en folders C, D, E... blijven beschikbaar! Vervolgens zou het systeem een mailtje kunnen sturen naar de beheerder om de folders terug te halen van een backup.

In de praktijk zal dit niet héél nuttig zijn voor thuisgebruikers, maar voor een universiteit die een XFS-cluster van tientallen petabytes met tienduizenden gebruikers draait is het toch wel een killer feature.

[bzzzt]

Je statement gaat helemaal nergens over omdat 'op Linux' over honderden distributies en tientallen filesystems kan gaan. Natuurlijk zijn die niet allemaal even goed, maar dat is soms ook helemaal niet de bedoeling.
Bovendien is het corrupt raken van metadata geen dagelijkse situatie tenzij je een bijzonder brak systeem hebt...

[RiDo78]

Er zijn genoeg zaken waar Windows beter mee om gaat. Zoals een hik in de beschikbaarheid van je storage. Waar Windows bevriest en kan recoveren van een tijdelijke onderbreking, draait Linux rustig door, maar vindt de storage niet terug. Dus Linux gaat door tot er iets van of naar disk moet en klapt dan.

Daar staat tegenover dat Linux op een aantal fronten weer beter is dan Windows. Welk OS beter is hangt daarom vooral van de toepassing af.

En geloof mij, als dat het niet uitmaakt welk filesystem je gebruikt, als je filetable corrupt raakt dan ben je verder van huis. Gelukkig is het iets wat je tegenwoordig nauwelijks meer ziet want het is vooral een ding bij de non-journalling filesystems zoals FAT of EXT2. Met de komst van de journalling filesystems is dat een stuk minder. Ik ben op een journalling-filesystem nog geen onherstelbare problemen tegen gekomen, terwijl ik continu met EXT3, EXT4 of XFS bezig ben. Natuurlijk komt het voor, maar misschien net zo vaak als corruptie binnen NTFS?! Zonder harde cijfers is dat lastig te zeggen.

Maar ik heb het stuk op heisse even gescanned en volgens mij komt het er gewoon op neer dat fouten in het filesystem nu vroegtijdig door de kernel worden opgemerkt waardoor die door een userspace-component gefixed kunnen worden. Het is dus ook een userspace-component wat moet beslissen wat er mee gedaan moet worden. En ik denk dat het in hoofdlijnen overeenkomt met wat de repair-tools nu al zelfstandig doen. Maar in plaats van een grote fix waarbij alle fouten worden opgezocht en hersteld, wordt hier alleen de fout hersteld die de kernel heeft gemeldt. Veel kleinschaliger dus en zonder de noodzaak om het volume offline te halen.

offtopic:
Voor de Windows-beheerders onder ons, kernelspace is de omgeving waar de kernel draait, tezamen met (gesigneerde) drivers en waar geen rechtenstructuur aanwezig is; alle software mag alles doen. Userspace daarentegen is waar de rest draait en waar alles wat niet onder de root-user (normaliter) beperkt is door een rechtenstructuur. De userspace-component kan dus reageren op de kernel maar zal waarschijnlijk de kernel vragen om een bepaalde fix toe te passen omdat het zelf de rechten niet heeft om op dat niveau bij het filesystem te komen.

[goarilla]

Er zijn genoeg zaken waar Windows beter mee om gaat. Zoals een hik in de beschikbaarheid van je storage. Waar Windows bevriest en kan recoveren van een tijdelijke onderbreking, draait Linux rustig door, maar vindt de storage niet terug. Dus Linux gaat door tot er iets van of naar disk moet en klapt dan.

Of de filenode verdwijnt en je bent ineens naar een gewoon bestand op je rootfs aan het schrijven

[delphium]

"Op Linux" heb je de keuze tussen zo'n 25 verschillende bestandssystemen, waaronder ntfs, als je dat zou willen. Leg even uit wat je precies bedoelt en waarom ntfs volgens jou zo goed is.

[goarilla]

NTFS is een pak minder slecht dan iedereen laat uitschijnen maar NTFS gebruiken op Linux als main fs is zowiezo een nogo want het heeft NTFS ACE/ACL's en Windows metadata en geen Unix permissies etc ...
Het is ook case preservative maar case insensitive.

[goarilla]

Doel jij nu op de $MFT kopie ? Is die niet beperkt ?

[ffha]

Even vragen bij je sysadmin vrienden of ze lievers ZFS of NTFS hebben.

[batjes]

Nee. Het is gewoon een feit dat de meeste Linux bestandssystemen weinig tot geen meta data, recovery data of andere data opslaan en de indexering zo minimaal mogelijk is.

NTFS doet veel van die zaken wel, is daarmee logger en slomer.

Ik ben nu al een paar keer mijn Ext3-4 file index kwijt geraakt door een powerloss crash en dat is gewoon super kut want elke file is een random string.

Ik ben er fanatiek positief over dat men bij Linux dit soort zwakheden van Unix filesystems eens gaat aanpakken en natuurlijk word ik gedownvote met een bijdehande opmerking er achteraan geslingerd.

[SnoipaH]

als zen 6 officieel ondersteund wordt kunnen we daaruit halen dat deze bijna uit gaat komen?

[laurxp]

Nee, het is vrij normaal dat de drivers al een tijdje van tevoren grotendeels klaar zijn. Je heb ze tenslotte als AMD toch nodig om alles te kunnen testen, en je wil er voor zorgen dat de ondersteuning mee is genomen in de grote OS-release vóór de verkoop start zodat je op dag 1 gewoon direct je nieuwe PC kan booten.

Daarnaast is Zen 6 volwassen genoeg dat eigenlijk alle features al wel publiek bekend zijn. Je wint d'r weinig mee door wat triviale details langer geheim te houden.

[TyzzyT]

Klinkt mooi, zo’n zelfgenezend bestandssysteem, maar ik blijf voorlopig gewoon back-ups maken

[Blue_Airplane]

Sowieso verstandig, ook als iets zelfgenezend is kan het nog steeds voorkomen dat je bestanden gelockt worden met een ransomware aanval of iets dergelijks.

Zelfgenezend is geen backup.
Net zo min als ZFS een backup is.

Ik ben groot fan van dit soort systemen en heb tot nu toe geen issues er mee ondervonden.
Maar dat kan net zo goed meer geluk dan wijsheid van mijn kant zijn.

[Grakist]

Dat helpt niet persé, want als een bestand of map corrupt is geraakt; dan neem je dat dus corrupt mee in je backup. Want je weet niet dat het corrupt is geraakt totdat je het nodig hebt. En dan blijken je backups ook de corrupte versie van het bestand of map te bevatten.

Self healing filesystems gebruiken checksums om data te controleren en zo te bepalen of het corrupt is. XFS doet dat (volgens mij) alleen op metadata terwijl ZFS het ook op de data zelf doet.

Als eenmaal bepaald is dat er corruptie heeft plaatsgevonden dan kan XFS blijkbaar de metadata zelfstandig repareren? Mijn ervaring met ZFS is dat het corruptie automatisch repareert tijdens lezen of tijdens de wekelijkse scrubs mits er redundantie voorhanden is.

Silent corruptie kan zomaar optreden. Geheugenfouten (als je geen ECC hebt), instabiele hardware, maar ook gewoon draaiende disks waar zo heel af en toe een bitje omvalt zonder dat je daarvoor een reden kunt aanwijzen.

Daarnaast zijn backups inderdaad je primaire beveiliging tegen dataverlies. Self healing filesystems zijn geen vervanging voor backups.

[Reactie gewijzigd door Grakist op 14 april 2026 16:46]

[goarilla]

Persoonlijk gebruik ik geen XFS meer nadat ik data corruptie heb gekregen
op een externe usb schijf na een hard lock. En xfs_fck of xfs_repair meer
geheugen nodig dan ik had.

[markg85]

Als je niet veel van linux releases begrijpt schrijf er dan a.u.b. geen nieuwsbericht over. Het bericht leest als een "wow, eerste nummertje is opgehoogd, nu is het nieuwswaarde en moeten we erover schrijven"...

Als je dan echt wil weten welke veranderingen er in 7.0 zitten kan je beter hier kijken. En wat rust betreft. Daar is feitelijk niets verandert. Het is meer dat binnen de Linux ontwikkeling Rust nu wordt gezien als een blijvertje en het experimentele er nu vanaf is. Dat vervolgens de helft van die nieuwsbericht, inclusief vermelden in de titel, daar over gaat is wat nieuwswaarde betreft wel heel teleurstellend.

[goarilla]

Uit de heisse link

The difference between the classic and the new approach can be reduced to a fundamental shift: proactive rather than reactive. Previously, the system reacted to damage that had already occurred. The new approach, on the other hand, focuses on early detection and automated reaction. While xfs_repair serves more as an “emergency tool,” the self-healing approach is understood as a continuous monitoring and reaction system in the background.

Persoonlijk vind ik dit wel een gemiste kans:
- enkel metadata checksums maar wel breken met een nieuw on-disk formaat.
- proactief lijkt goed maar is dit niet een vals gevoel van veiligheid, als alles automagisch wordt
"opgelost" zeker zonder redundantie en data checksums, hoe weet je dan dat je data aan het bitrotten
is zonder waarschuwingen ? En hoe weet je of het niet fout gefixed is en kan je dan nog terug naar het origineel ?