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 (45)

[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

[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.

[Nightscope]

Thanks voor de uitleg!

[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.

[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]

[batjes]

Nou, op linux is het al snel een feest wanneer je filetable oid corrupt raakt.

Ntfs gaat daar heel wat beter mee om, zou mooi zijn als Linux dat ook beter gaat doen.

[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

[RiDo78]

Dat gebeurt je alleen wanneer je dat bestand nieuw aanmaakt of het bestand sluit tussen het lezen en schrijven. Wil je een bestand openen (om te lezen en/of te schrijven) dan moet die mount intact zijn, anders wordt dat bestand niet gevonden. In de meeste user-case scenario's zal een bestand read-write geopend worden waarna het open blijft om te voorkomen dat een andere user of proces hetzelfde bestand onderwater aanpast. Door het open te houden blijft het gelocked. Al hebben sommige programma's (zoals vi) hun eigen manier van locken.

Wanneer je probeert om te unmounten zal de kernel zien dat er een file gelocked is en blokkeert het unmounten. In het hypothetische geval dat een mountpoint spontaan verdwijnt maakt het ook verschil hoe de file geopend is. Bij het bovenstaande voorbeeld zal een userspace-proces (zoals een applicatie) onderuit gaan met een I/O error, die de programmeur kan afvangen, maar een kernel-space proces zal bevriezen en wachten tot hij antwoord krijgt; antwoord dat nooit meer komt.

Dus schrijven op de bovenliggende mount (bijvoorbeeld het rootfs) gebeurd alleen als het bestand tussen het lezen en wegschrijven gesloten is geweest, of als het een nieuw bestand is.

Overigens kun je in Windows ook dergelijke mounts maken (bijvoorbeeld je D: schijf koppelen als C:\Users) en daar geldt exact hetzelfde voor. Als de D-schijf ineens ontkoppeld wordt, wordt C:\Users weer gewoon C:\Users, met soortgelijke problemen als bij Linux.

[goarilla]

In mijn geval ging het over /dev nodes die wegvallen. Nu dit was ook wel in de context van disk recovery/scraping (ddrescue, photorec/testdisk, ...) of image deployment (dd, cat, ntfsclone, partwhatever, ...).

fuser, lsof, hdparm, umount [-l] -f en user-errors zijn mij dus niet onbekend.

[rbr320]

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.

Heb je hier bronnen voor? Mijn ervaring is namelijk exact het tegenovergestelde. Ik heb thuis met een fileserver gewerkt waarvan de storage niet helemaal stabiel was en als mijn Linux installatie zijn NFS shares kwijt was dan hing het systeem wel als daar een file vandaan moest komen of naar toe moest, maar als de shares weer terug kwamen draaide alles gewoon vrolijk verder. Als mijn Windows installatie zijn SMB shares vanaf diezelfde server kwijt was dan werd het systeem steeds trager tot het uiteindelijk hing en moest ik een harde reset uitvoeren.

Maar dat is slechts mijn ervaring en ik heb geen harde data om er meer over te kunnen zeggen.

[RiDo78]

Nee, dat is puur eigen ervaring. Maar jij hebt het over netwerk-storage, dat is heel wat anders. Hoewel, je hebt je NFS-shares waarschijnlijk 'soft' gemount. Maak maar eens een 'hard'-mount, open wat files van NFS (of start een binary van die share) en herstart dan je NFS-server eens...

Wat ik meer bedoelde is de storage die lokaal op het systeem aanwezig is en dan met name het systeemvolume. Als je de (hotswap) SATA-kabel van je PC per ongeluk lostrekt als hij bezig is dan bevriest Windows. Sluit dat ding opnieuw aan en je hebt kans dat hij het weer oppakt en verder gaat. Onder Linux.. zie boven.

Hetzelfde geldt bij virtuele machines. Als de storage bijvoorbeeld NFS of VMFS is en hij hikt even (Netwerk of FC dipje) dan draaien de Windows VM's door zodra de storage terug komt en alle Linux VM's zijn hun storage definitief kwijt.

En geloof me, ik werd niet vrolijk toen ik 's nachts uit bed werd gebeld vanwege die storage-hik, mijn Windows collega's na een uurtje ofzo hun nest weer opzochten en wij Linux beheerders allehande tot in de vroege ochtend VM's moesten herstarten en databases herstellen... En vooral die opmerkingen van die 'ramenwassers' daags daarop.. Dat vergeet je niet snel.

[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.

[Alfa1970]

FYI: Je kan in NTFS wel degelijk case sensitive aanzetten met fsutil, in Windows staat het by default uit vanwege backward compatibility.

Je kan ook symlinks maken en mountpoints net als in Linux, dus geen drive letters.

Wat betreft de permissies, ja inderdaad, dat is idd (D/S)ACL based.

En hoewel het geen echte executable flag is, je kan met een flag voorkomen dat een executable kan worden uitgevoerd. (In ieder geval moet je door een heel access dialoog heen worstelen ervoor).

[ATS]

NTFS is wel notoir traag. Dat merk je bijvoorbeeld als je met software development bezig bent en gaat compileren (veel file IO). Niet ideaal.

[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...

[Ed Vertijsment]

Hoewel je gelijk hebt over verschillende data systemen vind ik het gek dat je een systeem wilt dat niet faalt bij een power outage.

[bzzzt]

Wat ik bedoel met 'minder goed' is niet dat het per definitie faalt, maar wel dat er - afhankelijk van het gebruiksdoel van een systeem - andere keuzes qua redundantie en self-healing zijn gemaakt.

[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.

[ffha]

Lees je even in over BTRFS, ZFS, XFS etc.

[demianmonteverd]

Je kunt met ext4 data=journaling aanzetten. Dan heb je volledige journaling, maar het is niet de default en veel mensen gebruiken dan liever een alternatief fs. Voor het probleem dat jij hier aangeeft is het echter wel een oplossing.

[Ed Vertijsment]

Ik weet niet zo goed of het gaat om wat je zegt of hoe je het zegt.

Ook weet ik verder de details niet, wel weet ik dat, dit van filesystem tot filesystem verschilt en Linux meer dan een ondersteund.

Aangezien je de wens hebt dat dit aangepast wordt zou dit file system weleens interessant kunnen zijn (al weet ik de details niet). Maar zoals @ffha al aangaf zou je eens kunnen kijken of zfs wat voor je is wat zeer ver gaat in data bescherming.

[RiDo78]

Het is mij nog nooit overkomen met een journalling filesystem als EXT3/4 of XFS. Maar wel eens bij EXT2, en daar heb ik prima van kunnen herstellen door een ander superblock te kiezen bij het mounten.

root@:/root >dumpe2fs /dev/sda2 | grep -i superblock
dumpe2fs 1.46.5 (30-Dec-2021)
Primary superblock at 0, Group descriptors at 1-1
Backup superblock at 32768, Group descriptors at 32769-32769
Backup superblock at 98304, Group descriptors at 98305-98305

Dus ik weet niet wat er bij jouw exact mis ging, maar mocht het nog eens gebeuren, probeer dan eens...
sudo fsck.ext4 -b <backup superblock nummer> /dev/sdXY
Let wel, backups maken is je eigen verantwoordelijkheid.

[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?

[TyzzyT]

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

[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.

[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.

[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.

[NostraDavid]

Ik zeg: Doe lekker een bericht, elke major version update, dus 6.x, 7.x, 8.x.

Elke versie zou teveel ruis geven, en de major versies ook skippen betekent dat je nooit wat hoort.

Dit is was mij betreft een nette midden-moot.

[markg85]

en de major versies ook skippen

Je snapt het niet.

Linux heeft geen major versies. Of beter gezegd, elke release is een major versie. De nummers zijn nietszeggend. Torvalds heeft het een tijdje geleden (grappig) uitgelegd. Het eerste nummertje moet omhoog als hij niet meer genoeg tenen en vingers heeft om het versienummer te tellen. Dus 6.19 -> 7.0
En 7.19 -> 8.0
etc...

En wanneer ze op versie 19.19 aankomen verzinnen ze weer wat nieuws.

Features die nu in 7.0 komen hadden net zo goed in 6.19 of 7.1 kunnen zitten. Het is geen semver en het is geen normale klassieke versienummering.

Zo heb je ook een softwarepakket wat heet erg dol is op het Pi getal (3.14....) en met elke release 1 nummer verder gaat in de decimalen achter de komma.

[goarilla]

Je hebt gelijk maar ooit was dit anders. De 2.x en eerste 3.x versies waren wel redelijk semver. Met de oneven minor numbers de branches waar features werden getest vooraleer ze in de even minor release branches werden gemerged als ik het me nog goed kan herrineren ? 2.1 -> 2.2, 2.3 -> 2.4, 2.5 -> 2.6, etc ...

Ik vind het dan ook niet zo erg dat ze warrig en/of onwetend verslag geven. Het is ook tweakers he en niet phoronix of lkml.org of kernel.org zelf.

[markg85]

Ook die oude nummering was geen semver. In semver heb je geen concept als even nummers is stabiel en oneven is onstabiel. Daarnaast denk ik, niet nagekeken, dat die versienummering ruim bestond voor er uberhoupt een semver term bestond. Semver is naar mijn idee pas ingekomen zo rond de web 2.0 hype.

Je heb helemaal gelijk dat dit tweakers is en niet een linux specifieke site. Maar juist hier, op tweakers, verwacht ik wel dat we het technologisch gezien bij de juiste naam noemen. Dat sommige mensen, ook hier, deze versieverhoging zien als een major version bump is een gebrek aan linux kennis waar juist bij een artikel over een versie wel een voetnoot bij mag staan die beknopt uitlegt hoe het zit. Het zou ook meerwaarde geven.

[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.

[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 ?

[Juice2000]

"de veiligere programmeertaal Rust"

Wellicht ten overvloede: Rust verkeert nog in een zeer vroeg stadium voor een programmeertaal, en is zeker veelbelovend op het gebied van veiligheid, maar heeft zich op dat gebied nog zeker niet bewezen als andere, meer volwassen programmeertalen zoals C/C++.