Bestandssysteem ReFS werkt ook op opstartschijven in testversie Windows Server

Microsoft geeft testers de mogelijkheid om Windows Server te booten vanaf het bestandssysteem ReFS. Dat alternatief voor Windows' standaard NTFS is al jaren in ontwikkeling. Het biedt betere bescherming tegen datacorruptie en kan schalen tot opslagvolumes van 35PB.

Het Resilient File System van Microsoft maakte zijn debuut met de komst van Windows Server 2012, maar was niet te gebruiken voor het bootvolume van Windows. Dat moest nog altijd geformatteerd zijn met NTFS. Daarin komt nu verandering. Testers in het Windows Insider-programma van Microsoft kunnen de Insider Preview van Windows Server installeren en dan laten draaien op ReFS-volumes.

Het alternatieve bestandssysteem van Microsoft biedt betere bescherming tegen zogeheten bitrot. Daarbij kan opgeslagen data corrupt raken door verlies van bijvoorbeeld magnetische of elektrische lading van het opslagmedium. Daarnaast brengt ReFS verbeteringen voor het prestatieniveau van opslag en ondersteunt het volumes tot een maximale capaciteit van 35PB. NTFS kan maximaal 256TB aan.

Builds van de testrelease van Windows Server bieden sinds 11 februari de mogelijkheid van ReFS-boot in het installatiemenu. Voor gebruik van ReFS is wel een systeem met UEFI-firmware nodig, merkt Microsoft op. Oudere virtuele machines gebruiken nog een legacybios en kunnen dit alternatieve bestandssysteem dus niet gebruiken voor hun bootvolume.

refs tot 35PB, vs ntfs tot 255TB (beeld: Microsoft)

Door Jasper Bakker

Nieuwsredacteur

02-03-2026 • 09:56

26

Submitter: Mapje

Reacties (26)

Sorteer op:

Weergave:

Hmm als je je boot volume > 256TB wil maken dan doe je toch iets mis vind ik. Een boot volume is voor het systeem zelf. En ja, 640KB is niet voor iedereen genoeg maar de tijd dat een windows installatie niet meer in 256TB past zal nog wel even duren ;)

De bitrot detectie en snellere afhandeling van kleine files vind ik iets veel belangrijkers.
Maximale grootte is niet de enige reden om een bepaald filesystem te kiezen. Andersom staat er ook nergens vermeld dat je volume groter dan 256TB moet zijn voordat je ReFS mag gebruiken.

Zoals het artikel al zegt zit er bescherming in tegen bitrot, een beetje zoals met ZFS al jaar en dag normaal is, maar wat op Windows-platforms tot nu toe eigenlijk altijd al ontbrak. Dat zou voor mij al de enige reden zijn die ik nodig zou hebben om voor ReFS te kiezen over NTFS. Niks is zo kut als corrupte bestanden hebben maar niet weten dat ze corrupt zijn. Als het filesystem je dat kan vertellen kan je gericht de boel terughalen uit een backup, of uit een kloon elders op het FS.

[Reactie gewijzigd door DataGhost op 2 maart 2026 10:44]

De grote vraag is waarom je ECC in het filesysteem zou willen doen. SSDs doen dat al vanaf de eerste commerciële producten in de controller. Bitrot is inherent aan NAND flash.

Het staat me bij dat twee niveaus van ECC altijd inefficiënter zijn dan 1 (in termen van bruto/netto bits bij gelijke bescherming)
Maar ze hebben het ook over grote opslagsystemen - en bij vele petabytes aan opslag denk ik eerder aan traditionele harde schijven dan SSDs. En dan is het wellicht wel zinnig?
Twee verschillende lagen checksum bescherming kunnen elkaar tegen werken en dat is niet zo handig. Ze zullen ook allebei ruimte gebruiken voor die checksums.

Persoonlijk vind ik de bescherming die zfs biedt boven de checksum van een enkele ssd schijf te prevaleren, omdat er ook daadwerkelijk data mee hersteld kan worden als er een schijf uit de set uitvalt.
De grote vraag is waarom je ECC in het filesysteem zou willen doen. SSDs doen dat al vanaf de eerste commerciële producten in de controller. Bitrot is inherent aan NAND flash.
Corruptie op andere lagen. HDDs doen ook aan ECC en volgens mij worden er soms toch problemen gevonden door dit op FS niveau te doen.
Mogelijk heeft het ook voordelen by syncen en deduplicatie.
Ik denk dat de term "boot volume" hier niet op een UEFE-boot-volume slaat maar op het volume waar Windows op geïnstalleerd staat, "C:". Het gaat dan om systemen die geen ingewikkelde partitionering hebben gewoon de hele schijf in een volume zetten, OS en data samen.
Ik vroeg mij het ook al af waarom wil je een boot raid array van 35PB. Ik zou eerder zeggen 200GB ofzo. Wat een verwaarlozing is als je 35PB hebt.

Sowieso zou ik mijn Windows op een andere schijf/array zetten dan mijn echte data.
Sowieso zou ik mijn Windows op een andere schijf/array zetten dan mijn echte data.
Dat is met Windows ook altijd zo'n miserie.. sommige software/installers geven je niet of amper de keus waar je de applicatie-bestanden wilt parkeren, en/of gooien alsnog je C-drive en user folder vol zooi (ik denk bvb aan Adobe CS).
Dat is een driveletter beperking, geen filesysteem. Windows kan al 30 jaar meerdere filesystemen onder C: mounten.
Dat, en je kunt je %USERDATA% ook ergens kwijt dan je C-schijf.
Dat is met Windows ook altijd zo'n miserie.. sommige software/installers geven je niet of amper de keus waar je de applicatie-bestanden wilt parkeren, en/of gooien alsnog je C-drive en user folder vol zooi (ik denk bvb aan Adobe CS).
Zou handig zijn als je meerdere schijven / volumes kon combineren en dan per directory / bestand aangeven op welk volume het opgeslagen moet worden. Kun je zelfs achteraf nog data verplaatsen zonder dat paden veranderen.
Sowieso zou ik mijn Windows op een andere schijf/array zetten dan mijn echte data.
Want?
Klopt, maar het feit dat het achterlijk grote volumes kan vullen, wil niet zeggen dat dat je reden is om het te gebruiken.

XFS kan 8Exibyte (~8000Petabyte) aan. Er zal (vrijwel) niemand zijn, die het om die reden gebruikt.

Als ik naar de specs kijk, zie ik sowieso geen goede reden om ReFS voor een systeemvolume te gebruiken. Voor datavolumes kan het onder bepaalde vervangen wel wat toevoegen als ik het zo zie.
Ik ken ReFS eigenlijk niet. Is dit de Microsoft tegenhanger van filesystems, zoals btrfs en/of ZFS ?
Met een beetje moeite had je dat zelf kunnen vinden:Het is bepaald niet nieuw (bestaat al 10+ jaar, zie de wiki), maar werd in de praktijk (ik heb het nog nooit gebruikt zien worden, voor 10-tallen servers) niet of nauwelijks gebruikt. Een vergelijking met btrfs is tot op zekere hoogte wel te maken (ook ReFS is een journalled file systeem). ZFS is een next-gen file systeem, waar ReFS ook onder geschaard wordt. Dus ook hier ja. Maar de filosofie van ZFS is volgens mij wel anders. Hardware RAID is daar juist niet de bedoeling (wel SAS of SATA expanders en verder een 'dom' filesysteem met losse disks/JBOD).

Ik zit onvoldoende in de ZFS wereld om precies te weten hoe ZFS-van-Oracle (origineel: van SUN) verhoudt tot ZFS-op-Linux. Als er verschillen zijn, dan heb ik ze nu op 1 stapel gegooid wat betreft 'het is een next-gen filesysteem'.

Als ik me goed herinner is er ooit (ook al meer dan 10 jaar geleden) een ronkend event geweest van de introductie van ReFS voor een Windows versie van lang-geleden. Maar dat is een beetje geflopt. Kennelijk ziet Microsoft er nu wel brood om ReFS een nieuwe kans te geven, waar hopelijk de oorzaken van de flop zijn opgelost.
Als ik zo teruglees in de historie is dat ze nog best wat werk hebben op he Re-gedeelte van hun FS :-)
Ze hadden beter hun not invented here syndrome los kunnen laten en ZFS kunnen forken.
wij gebruiken ReFS voor 1 specifieke use case. Daar werkt 't erg goed. (en dat zijn de grote volume machines)

Reguliere windows servers draaien gewoon op NTFS.
Heel kort door de bocht: ja.
We hebben ReFS block cloning(op zich heel mooi, maar niets unieks in de wereld van filesystemen) een hele tijd ingezet, en de ervaringen daarmee waren niet best door een constante stroom aan bugs in de ReFS drivers. Die "betere bescherming tegen datacorruptie", daar heb je niet zoveel aan als ReFS zélf de reden is dat e.e.a corrupt raakt(en die kans is gewoon te groot).
Om eerlijk te zijn kan ik vrij weinig redenen bedenken waarom je ReFS zou willen gebruiken, tenzij het voor iets heel specifieks is natuurlijk. Anders: doe het niet.
Onder welke versie(s) was dat? Sinds 2016 is er nog wel het nodige verbeterd.

[Reactie gewijzigd door Z-Dragon op 2 maart 2026 10:44]

Dat klopt, maar er wordt teveel aan gesleuteld als je even zoekt, dan is het ieder half jaar wel raak met serieuze bugs. Wat ik bedoel te zeggen: ik zou ReFS niet gebruiken omdat het kán, maar alleen als het moet. Windows laten booten van ReFS omdat het kán zou ik niet doen. Het is gewoon minder solide als NTFS.
Zover ik weet en kan lezen is ReFS dan ook nog niet als "1.0" uitgebracht, maar zijn dit nog steeds testbuilds. Dat is hetzelfde als een paar jaar terug BTRFS gebruiken op een productieserver. Nu is dat stabieler, maar zeg 8 jaar terug was dat wel een ander verhaal.
Kunnen we ergens een test ISO downloaden? Ben wel benieuwd naar de performance verschillen, als die er zijn.
"Testers in het Windows Insider-programma van Microsoft kunnen de Insider Preview van Windows Server installeren"

Even lid worden van het Insider-programma van MS.
Jammer dat er nog steeds problemen zijn met de error handling van ReFS. Zie deze al lang lopende thread op Reddit:

https://www.reddit.com/r/DataHoarder/comments/iow60w/testing_windows_refs_data_integrity_bit_rot/

ReFS's checksumming seems reliable
  • ReFS's error handling + self-healing + logging/reporting all suck
  • Storage Spaces sucks
  • The Windows UI + Event Viewer is awful, and you can't tell what's happening with your ReFS drives
Basically, ReFS's checksumming works and is reliable at blocking file access when it actually checks, so you're at least guaranteed to detect all uncorrectable errors and not let bit rot slip through. In other words, I don't think ReFS will ever return corrupted data with integrity streams enabled + enforced. Best of luck with everything else.

I wouldn't use ReFS integrity streams for any business or mission-critical purpose. It seems okay for personal usage as a quick-and-dirty way to detect file corruption, but make extra sure to have a backup. Such a shame—ReFS has been out for almost a decade and I've really hoped for better, but it's still such an immature file system.

Om te kunnen reageren moet je ingelogd zijn