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.

Reacties (53)

[YoMarK]

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.

[Z-Dragon]

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]

[YoMarK]

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.

[sfranken]

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.

[rookie no. 1]

Voor MS SQL / Exchange DB's en VM VHDx volumes adviseert Microsoft anders wel ReFS te gebruiken.

Voor VM's VHDx volumes gebruiken we al sinds Windows Server 2012R2 en werkt uitstekend. Vanaf Windows Server 2019 in gebruik voor MS SQL DB's en dat werkt ook goed. Sinds Windows Server 2019 zit er ook in ReFS eindelijk data deduplicatie, dus dit konden we ook vaker inzetten sinds die tijd.

Enige is als je gezeur hebt met je ReFS volume is het lastig om het opgelost te krijgen. Beter een nieuw volume maken en data over/terug zetten. Is maar 1x gebeurt ooit in het verleden met, volgens mij, een Windows Server 2012R2 omgeving.

[YoMarK]

In het geval van Exchange is dat advies er ooit geweest kan ik me herinneren, maar volgens mij zijn ze daarop terug gekomen. Sterker nog: hier staan enkele aanbevelingen om bepaalde ReFS features uit te zetten voor de filesystemen waar logs en database files op staan. zie https://learn.microsoft.com/en-us/exchange/plan-and-deploy/deployment-ref/storage-configuration (ik heb wel zo'n vermoeden waarom).

Wij hebben exchange on-prem lange tijd op ReFS gedraaid. Maar je hebt er eigenlijk alleen maar last van.

Wat betreft SQL server zegt Microsoft dat NTFS en ReFS supported zijn. Ik zie nergens dat het "recommended" is. Uiteraard kan je met ReFS meer met snapshotting(in de vorm van, het maken van een snapshot kost veel minder IO's)

Voor VM's (vhdx's) staan de voordelen buiten kijf, maar gezien de ervaringen die ik heb kan ik het niemand aanraden om ReFS te draaien op een Windows server als je daar geen hele goede reden voor hebt.

[spoor12b]

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.

[seppdroid]

Eens, ik was heel snel klaar met CSVFS_Refs, na 2 keer volumes kwijt te zijn geraakt in een productie cluster zat de druppel hem voor mij toen in het feit dat de refsutil tool de laatste spec niet ondersteunde…

dus ik sluit mij aan bij de laatste quote

Context

[Wim Cossement]

Ik vind het nogal primitief dat we nog steeds als consument voor NTFS moeten kiezen in Windows, waarom kan dat ding niet zoals Linux je de keuze geven? We zijn verdorie 2026, NTFS is meer dan 30 jaar oud en werkt gewoon op Linux en anderen...
Als je met redelijk veel bestanden en mappen zit (+10.000 of zo) dan zakt de snelheid in elkaar en die granulariteit van de bestandssysteem instellingen met al die gebruikers en rechten zijn onnodig complex, voor de meeste volstaan de klassieke eigenaar, groep en wereld.

[Llopigat]

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.

[DataGhost]

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]

[MSalters]

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)

[vanaalten]

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?

[MSalters]

HDDs hebben tegenwoordig ook ECC. Dat is ook waarom we 4kB schijven hebben tegenwoordig. Dan is de ECC efficiënter.

[Raymond Deen]

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.

[Olaf van der Spek]

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.

[sympa]

Een van de problemen is een "misaddressed write". Dus dat een block wordt geschreven maar fysiek verkeerd terechtkomt.

Daar hadden ze ooit 520 byte sectors voor bedacht: dan kon elk block een "stempeltje" krijgen waaraan je kon zien dat het niet verdwaald was.

Met een checksum kan dat natuurlijk ook.

[DataGhost]

Ik weet niet hoe dat bij ReFS werkt maar het is niet per se ECC. Sterker nog, bij ZFS worden gewoon checksums van elk blok en elke file bijgehouden en heb je met standaardinstellingen op een enkele schijf geen automatische recovery/"ECC". Met die checksums weet je zeker welke data corrupt en welke correct is. Als je storage medium een blok teruggeeft met een fout erin, bijvoorbeeld doordat het fout geschreven of gelezen is of dat er op een andere manier bitjes zijn omgevallen, en dat wordt niet door de ECC opgemerkt (gebeurt vaak zat) dan heb je een probleem. Als een write is "gedaan" volgens je storage medium, maar er is niks weggeschreven om wat voor reden dan ook, zal bij je de volgende read oude data terugkrijgen die op blokniveau correct is maar op fileniveau niet meer. En als dat deel uitmaakt van een RAID5-set met 3 schijven moet er toch een beslissing gemaakt worden over welke twee van de drie blokken de juiste zijn als geen van de drie een leesfout gaven, daar wens ik je veel succes mee. Ondertussen kan dat met RAIDZ(1/2/3) of het gebruik van "copies" automatisch hersteld worden.

Bijkomend voordeel van de checksums op fs-niveau is dus ook dat je daarmee te weten kan komen welke files precies corrupt zijn geraakt. Dan heb je de data niet per se terug, maar je weet in ieder geval zeker dat je niet met ongeldige data aan de slag gaat. Dus ook als de boel niet automatisch hersteld kan worden zegt het filesystem welke files je als verloren moet beschouwen en uit je backup terug moet zetten. Dit is allemaal een beetje vereenvoudigd opgeschreven dus voor de echte details zal je in ZFS moeten duiken. Ik neem aan dat ze voor ReFS eenzelfde aanpak hebben gebruikt.

[Reactie gewijzigd door DataGhost op 2 maart 2026 12:59]

[Guru Evi]

Om even duidelijk te maken: ZFS gebruikt geen ECC maar een hash zoals SHA256, als meerdere bits omvallen merkt ZFS dat nog steeds op. Daarnaast kan ZFS enkel maar een schijf herstellen als je de schijf vervangt, de data wordt “on the fly” hersteld tov de gebruiker maar de corruptie op de disk is een probleem dat zal groeien.

ReFS aan de andere hand gebruikt nog steeds verouderde model van checksums op metadata, op de data zelf komen er standaard geen checksums, alhoewel je dat wel kan aanzetten, de data checksums zijn allocate-on-write (ze zijn geen deel van de block) waardoor je systeem zwaar kan fragmenteren.

Daarnaast heeft ReFS ook alle soorten kinderproblemen, zoals thin provisioning en datacorruptie ik stel het eerder gelijk aan BtrFS dan dan ZFS.

[Reactie gewijzigd door Guru Evi op 2 maart 2026 14:19]

[kaaas]

Als je een scrub doet in zfs controleert ie op fouten en hersteld deze. Dat herstellen kan alleen als er een vorm van redundantie is. Bijv een mirror of een raidz. Het is dus niet zo dat je alleen maar fouten kunt corrigeren als je de disk vervangt.

[demianmonteverd]

Het zit op verschillende plaatsen, zoals jij al aangeeft, het is nutteloos en inefficient om twee keer ECC te doen op dezelfde 'laag' (een volstaat, mits deze goed uitgevoerd, goed ingeregeld/gekozen/opgezet is natuurlijk), maar door het te doen op de fysieke laag (media), de controller+cache (laag die naar media gaat) en in het host systeem zelf, kun je wel problemen detecteren waar ze voorheen niet zichtbaar zouden zijn.

Plaatje (veel te simpel, er zijn ook allerlei bussystemen met error correction, etc.):
OS / Software
Geheugen host computer
Firmware controller
Media

Als het probleem zit op het OS-niveau (de host computer min of meer), dan zie je dat nooit op de lagen daaronder en heb je gewoon stille bitrot corruptie problemen. Zelfde voor een issue op 'controller/firmware niveau'. Daarom is refs best een stap voorwaarts voor windows.

[MSalters]

Als je issues hebt op OS nivo (driver nivo) dan gaat een checksum je niet redden. Die moet uiteindelijk ook in diezelfde driver worden gecheckt.

[demianmonteverd]

Waarschijnlijk hebben we het beide over een andere checksum. Jij hebt het denk ik over CRC's die inderdaad alleen kunnen detecteren (dat kan ook nog waardevol zijn op OS niveau overigens, daarom zit het bijv. in TCP). Een betere variant kan ECC zijn en dan kun je bijv. enkelvoudige fouten in een codeword oplossen (of meer als je meer redunantie bits in je codeword gooit).

Of je hebt een algemeen punt gemaakt over dat programmeer fouten in je driver of in de manier waarop je de driver gebruikt problemen opleveren, dan helpt een checksum inderdaad ook niet. Al kun je ook dan soms nog profijt hebben van een checksum als deze de fouten kan flaggen zodat je het probleem kunt vinden op basis van de volgorde waarin gebeurtenissen plaatsvinden.

[jeroen3]

NTFS doet niet eens aan een checksum, als de storage layer een slecht blok geeft merk je daar niets van.

[uiltje]

Er zijn nogal wat verschillen tussen error correctie. Ze aan elkaar gelijk stellen is echt verkeerd. De SSD error correctie is meestal op bit niveau (nieuwe SSD's hebben efficiëntere algo's voor grotere fouten). Bestandssystemen als ReFS gebruiken helemaal geen ECC, maar redundant copies. Dat gaat over veel grotere bestanden en meta-data. CRC64 is erg goed in het detecteren van willekeurige fouten. Natuurlijk wil je dit graag draaien op server hardware, want als er een fout in je RAM plaats vindt dan ben je in beide gevallen het haasje; dit soort algos werken op binair niveau, als de data in de memory al gecorrumpeerd is merken ze daar niets van. Dus je moet eigenlijk wel van ECC gebruikmaken.

[MSalters]

Nee, dat is kolder. SSDs en HDDs hebben geen ECC op bit nivo. HDDs zijn zelfs naar 4kB blocks gegaan omdat 512 bytes (4096 bits) al te veel ECC overhead had.

Heel simpel ook. Op bitnivo heb je niet eens genoeg aan RAID1. 1 opslaan als 11 werkt niet. Lees je 10, dan weet je niet of het 00 of 11 moest zijn. Dus voor bit ECC moet je 111 gebruiken.

[uiltje]

Huh? Natuurlijk gaat het met blocks, de error correctie zelf is op bit niveau. Het is niet alsof een heel block opnieuw wordt uitgerekend. Maar goed, probleempje met de interpretatie.

[Reactie gewijzigd door uiltje op 3 maart 2026 14:31]

[MSalters]

Je zou eens naar een moderne implementatie van ECC moeten kijken. Je leest wel degelijk een heel blok aan bits in, en haalt die vector door je ECC functie. Dat geeft je een kleiner aantal bits terug (typisch 32768 voor HDDs) plus een correctie-indicatie. Heeft de ECC een fout gevonden dan wil je de gecorrigeerde bits allemaal terugschrijven.

Het is een verspilling van ECC capaciteit om uit te vissen welke bit er precies fout was.

[CAPSLOCK2000]

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.

[lenwar]

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.

[Tjidde]

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.

[Kirth]

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

[MSalters]

Dat is een driveletter beperking, geen filesysteem. Windows kan al 30 jaar meerdere filesystemen onder C: mounten.

[lenwar]

Dat, en je kunt je %USERDATA% ook ergens kwijt dan je C-schijf.

[Olaf van der Spek]

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.

[MSalters]

Ik denk dat je daar met NTFS reparse points al aan komt. UI moet je nog even vibe coden.

[Olaf van der Spek]

Sowieso zou ik mijn Windows op een andere schijf/array zetten dan mijn echte data.

Want?

[Tjidde]

Als je een server hebt met veel data, is het meestal geen goed idee om je Windows-installatie op dezelfde fysieke schijven te zetten als waar je data op staat. Door het besturingssysteem en de data van elkaar te scheiden, voorkom je dat problemen met Windows direct gevolgen hebben voor je opslag.

In de praktijk zie je daarom vaak dat Windows Server op een aparte SSD of een kleine RAID-array draait. Een SSD is daar erg geschikt voor, omdat Windows continu kleine lees- en schrijfacties doet. Denk aan logging, updates, services en allerlei achtergrondprocessen. Door dat op een aparte snelle schijf te laten draaien, blijft het systeem soepel werken zonder dat het de schijven met je data belast.

Het grootste voordeel merk je eigenlijk pas als er iets misgaat. Een update die fout loopt, een configuratiefout of een corrupte installatie kan altijd gebeuren. Als je OS op een aparte schijf staat, blijft je data-array gewoon onaangetast. In het ergste geval trek je de OS-SSD eruit, stop je er een nieuwe in, installeer je Windows opnieuw en koppel je daarna je data weer aan. Dat maakt herstel een stuk eenvoudiger en verkleint de kans dat problemen met het systeem ook meteen je data raken.

[kujinshi]

Heel veel software parkeert toch graag dingen op de C schijf.

Het kan efficient zijn, maar maakt inderdaad dat de C schijf erg groot nodig is.

[GarBaGe]

Ik ken ReFS eigenlijk niet. Is dit de Microsoft tegenhanger van filesystems, zoals btrfs en/of ZFS ?

[kdekker]

Met een beetje moeite had je dat zelf kunnen vinden:

• Wikipedia: ReFS
• https://learn.microsoft.com/en-us/windows-server/storage/refs/refs-overview

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.

[jeroen3]

Sinds Windows 10 zit er een feature genaamt "Storage Spaces" in Windows, waarmee je disks kan poolen en mirror of (trage) raid-5-achtive redundancy kan doen.

Dat gebruikt ReFS op de volumes.

[Nathilion]

De lage performance van de parity variant van Storage Spaces komt doordat de Windows UI vrijwel altijd compleet verkeerde instellingen toepast. Het beste wat je kan doen is zelf de goede instellingen uitrekenen en dan een parity space maken via de command line.

Ik heb het op mijn computer getest door het eerste via de UI aan te maken en daarna via de command line met de goede parameters. Het was een verschil van dag en nacht. Ik had drie identieke harde schijven opgenomen in de parity en via de UI was het net aan 20MB/s schrijven en lezen. Met de goede instellingen ging ik naar de 100MB/s. Standalone halen de schijven net iets meer dan 100MB/s. Met de juiste instellingen kan je dus een parity space (bijna) net zo goed laten werken als een enkele schijf.

Zie deze link voor een goede uitleg: https://storagespaceswarstories.com/storage-spaces-and-slow-parity-performance/

[jeroen3]

Ik weet het, maar er lijken fundamentele design issues in te zitten. Ook met betrekking tot caching in RAM en wat er gebeurt als dat bijna op is. (dan unmount het volume)

Over het algemeen werkte het niet zo goed, en ik zou het afraden.

Ik het het laatst nog wel gebruikt met 6 externe schijven en mirror (ik moest tijdelijk 30TB bewaren). Dat werkte, en het werd op de proef gesteld want er ging er één stuk. Maar toch lijkt het ver van stabiel en af helaas.

[stresstak]

Sinds Windows 10 zit er een feature genaamt "Storage Spaces" in Windows,

Ik gebruik het in Windows 8.1 sinds 2014. Met drie schijven in een dubbel-schrijven stand.

[arjankoole]

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.

[curkey]

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.

[downtime]

ZFS forken voor Windows? Ik dacht dat het al de nodige moeite heeft gekost om ZFS goed te laten draaien op Linux. Dan wil ik niet weten hoe moeilijk het zou zijn om het betrouwbaar werkend te krijgen op iets wat helemaal geen Unix-achtige is.

[curkey]

Het had ook een lichte tongue-in-cheek insteek, met onderliggend de boodschap dat ze toch elke keer proberen zelf het wiel uit te vinden, maar daar eigenlijk zelden goed in slagen.

[YoMarK]

Heel kort door de bocht: ja.

[Mirano]

Kunnen we ergens een test ISO downloaden? Ben wel benieuwd naar de performance verschillen, als die er zijn.

[MIB75]

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

[beerse]

Voor zover ik weet is dit filesysteem al beschikbaar in msWindows sinds 2012. Daar kan je het in ieder geval activeren voor extra disks/partities.

Als het om performance verschillen gaat, dan moet je eerst bepalen welke performance jij wenst: Veel opslag op weinig ruimte? Snelle opslag op alles wat je hebt? Gaat het om grote bestanden opslaan? Gaat het om database verkeer? Is de database voor veel gegevens en weinig lezen? Of juist weinig schrijven en veel lezen? Komen de gegevens gestaag binnen? Of in horten-en-stoten?

Wat ook verschil maakt is welke onderlaag je gebruikt; Is het 1 schijf?, meer schijven (jbod)? een ssd? meerdere ssd-s? een combinatie van hdd-s en ssd-s? Is het een raid-configuratie? Is het een volume op een san?

In elk geval kan je bij microsoft al jaren kiezen tussen fat, ntfs en refs. Onder linux heb je veel meer keuze.