Home   2026-08-03 17:31:33

←

Windows 11 verwijdert grote, gefragmenteerde bestanden sneller na Insider-update

Original article

Windows 11 kan sneller grote, gefragmenteerde bestanden verwijderen. De verbetering zit in de Windows 11 Insider Experimental Preview Build 26300.8935, die op 20 juli verscheen. Microsoft rolt de update geleidelijk uit in het Experimental-kanaal voor Windows Insiders.

Als een harde schijf begint vol te raken, slaat Windows bestanden gefragmenteerd op. In zo'n geval kan een groot bestand in duizenden kleinere stukjes op verschillende plekken op de harde schijf belanden. Als een gebruiker zo'n bestand vervolgens verwijdert, duurt dat lang. Windows moet elk fragment opzoeken en verwijderen.

In Build 26300.8935 verloopt dat proces sneller, meldt Windows Latest. Wat Microsoft precies heeft gewijzigd om dit voor elkaar te krijgen, heeft het bedrijf niet bekendgemaakt.

Andere wijzigingen

De nieuwe build laat het Home-tabblad van de Verkenner sneller opstarten en reageren. Dat punt pakte Microsoft ook al aan met KB50095093 in juni, maar het heeft dit nu verder verbeterd. Ook kunnen gebruikers nu op touchscreens scrollen door de Aanbevolen-sectie met recent gebruikte bestanden.

Windows 11 logo

Door Eveline Meijer

Nieuwsredacteur

Feedback • 27-07-2026 16:05 68

27-07-2026 • 16:05

68

Lees meer

Reacties (68)

Dat er nog aandacht wordt besteed aan opslag op harde schijven is toch een klein wonder. In deze tijd van SSDs maakt fragmentatie praktisch niets meer uit.
Dat fragmentatie niet uitmaakt klopt niet. Sequentieel data lezen en schrijven is ook op SSD's nog altijd veel sneller dan random I/O, en dat zelfde geld trouwens ook voor RAM geheugen, en theoretisch gezien ook voor de caching mechanismes in de CPU.

Dus ook op SSD's kan deze optimalisatie merkbaar verschil geven. Al is het merkbare verschil wel veel minder groot dan met HDD's, waarbij random I/O echt onzettend traag is.
Random I/O is absoluut niet hetzelfde als een gefragmenteerde file lezen.

En ram fragmentatie is ook totaal iets anders.
Semantisch gezien heb je een punt. Er is inderdaad een verschil tussen random I/O en fragmentatie wat betreft de oorzaak.

Bij random I/O worden verspreid gelegen logische blokken gelezen of geschreven. Fragmentatie is daarentegen een ongewenste opslagindeling waarbij data die logisch sequentieel is, niet in één aaneengesloten extent kan worden opgeslagen.

Mijn punt was echter dat het effect voor het opslagsysteem vergelijkbaar kan zijn: in beide gevallen moeten veel verspreide lees- en schrijfbewerkingen worden uitgevoerd, in plaats van dat data in grote aaneengesloten reeksen kan worden benaderd.

Ook CPU’s en RAM-geheugen verwerken aaneengesloten databewerkingen doorgaans efficiënter, onder meer door caching, prefetching en een betere benutting van cachelijnen. Die vergelijking is niet volledig één-op-één, maar het onderliggende principe van data lokaliteit is vergelijkbaar.
Veel verspreide reads op een SSD zijn juist vaak sneller vanwege pagination etc.
Tja, ramdom I/O, of fragmentatie. Voor de opslag (harddisk of ssd) is het vergelijkbaar: Een stukje hier en een stukje daar.

Voor het operating systeem is het dat de random i/o binnen de file-fragmentatie leeft. Dus is het vooral nog meer over de schijf heen hoppen.

Tel daarbij de huidige disk-indelingen met zfs of logical-volumes en dergelijke en er zit nog een laag bij waarop de data versnippert over de opslag verdeeld is.
Jawel, want een gefragmenteerd bestand neemt veel ruimte in beslag in je bestandstoewijzingstabel, en ook daar moet je alles goed opkuisen en weer herordenen om de vrijgekomen ruimte weer beschikbaar te maken voor andere bestanden. En het is net dat wat dus tijd kost.

En die tabel moet goed op orde blijven, want als daar iets corrupt in is kan je wel eens heel je bestandssysteem verliezen.
In principe hoef je, als je een bestand wist, niks te doen op de HDD of SDD. Alleen de bestandstoewijzingstabel bijwerken is voldoende. Voor mijn gevoel zou een bestand wissen, ongeacht de grote, bijna instant moeten zijn.
Ik weet of dat er mee te maken heeft, maar ik zie, wanneer ik een bestand verwijder, vaak een progress balk die een tijjde op 99% blijft staan. Vooral op een HDD.
Magnetische opslag is nog best veel in gebruik op storage servers. Sommigen daarvan draaien windows.
Jij gaat 20TB aan data allemaal opslaan op solid state?
Het zal best jij geen HDD meer in gebruik hebt, maar er zijn talloze mensen (en bedrijven!) die met grote hoeveelheden data werken. Beetje bijzonder dat je je dat niet kunt indenken.
Al die bedrijven gebruiken daar geen windows voor. Hoogstens op de workstations. De storage arrays in enterprise settings waar je serieuze disk capaciteit ziet zijn meestal FreeBSD gebaseerd met daarboven heel veel proprietary BS (NetApp) of Linux met dingen zoals CEPH.

Zeker als het high speed is, is Windows vaak niet het OS of choice.
Al die bedrijven
Ik denk dat je nogal overschat hoeveel bedrijven een dedicated storage server hebben met Linux. Er zijn er genoeg die Windows server draaien op alles, inclusief storage. Dat is immers wat hun sysadmin nu eenmaal kent en waar hij/zij de certificaten voor heeft.

Ik zeg niet dat het allemaal even handig of verstandig is, enkel dat het nog vrij veel voor komt.
Er zijn er genoeg die Windows server draaien op alles, inclusief storage.
Oh dat zeg ik ook niet, ik denk alleen dat de aantallen fors lager tot verwaarloosbaar zijn als je kijkt per TB.

En dergelijke partijen gebruiken dan windows storage server en niet windows 11. Windows storage server heeft een vergelijkbaar probleem als hier wordt beschreven als je bestanden verwijderd vanaf SMB shares, maar dat is vooral een NTFS dingetje. Met ReFS heb je dat issue niet en dat werkt met WSS OOTB. met Windows server 2025 kun je zelfs ook booten van ReFS dus kun je NTFS volledig overslaan. Windows 11 met ReFS op je secundaire opslag heeft dit issue ook niet. Sterker nog, als je via commandline verwijdert heb je dit ook niet.

Dit specifieke issue ga je dus alleen ondervinden op de workstations. Windows Storage Server heeft dit al wel opgelost (en je wil ook eigenlijk geen NTFS gebruiken op de storage laag) en de rest draait op Linux.

Als je bijvoorbeeld HyperV virtualisatie doet op je server dan wil wel een stabiel FS eronder hebben wat hier tegen kan. .VHDX bestanden worden heel snel groot en dan is fragmentatie echt niet fijn.

Ook MS SQL server draait goed op ReFS, maar ook gewoon op ext3 en 4.
Ik zou mijn HD's graag willen vervangen door SSD's. Maar 40TB SSD (en nog zoiets extern) van buiten budget. En ja, zelfs bedrijven hebben nog lang niet alles gemigreerd zoals blijkt uit de capaciteiten van de nieuwste, steeds grotere, magnetische media.
Ik zal waarschijnlijk niet populair worden van deze reactie maar wil hier toch op reageren.

Het verbaasd me dat wanneer er resources genoeg zouden zijn er geen optimalisaties meer zouden mogen plaatsvinden. Dit is net dezelfde redenering als software optimaliseren als overbodig bestempelen omdat er toch voldoende cpu is.

Elke optimalistie is welkom, hoe klein dan ook.
Even FYI, dit is kennelijk een besloten topic. Ik kan het iig niet zien.
Is inderdaad een HK topic, had ik me niet zo snel gerealiseerd, maar hier is hij ook nog een keer:

https://starecat.com/cont...half-white-half-black.jpg
Hoezo sneller verwijderen? Windows verwijdert toch helemaal niets? NTFS wijzigt toch alleen de bitmap en zet alle gebruikte clusters weer als leeg. De data zelf blijft toch gewoon staan?

Hoe kan je anders ooit bestanden recoveren?
Ik was ook onder de indruk dat dit inderdaad zo werkt, met uitzondering van SSDs met de trim-functie?
Er gebeuren meerdere dingen waaronder het updaten van de $Bitmap file, en als het bestand groot en gefragmenteert is is het updaten van die $Bitmap file een enorme klus.
Die $Bitmap file is er enkel om van een schijf (niet bestand!) te weten welke clusters er vrij zijn of niet. Er staat geen file-informatie in, enkel de gebruiksstatus (wel/niet in gebruik) van alle clusters op de schijf.

Als een bestand erg groot en gefragmenteert is dan moeten er heel veel bitjes in die $Bitmap file worden aangepast. De file zelf, dus de datastructuur waarin o.a. de naam en de clusters die bij een file horen worden bijgehouden, is snel weg te halen maar dan moet dus nog die $Bitmap worden bijgewerkt.

[Reactie gewijzigd door koelpasta op 28 juli 2026 13:09]

Of je nu 1000 consecutive bits cleared of 1000 losse maakt dus niets uit.

U heeft echt geen idee waar u over praat.
U heeft echt geen idee waar u over praat.
Ik denk echt dat je hiermee moet ophouden want je zet jezelf alleen maar voor schut.
Kan je niet verdragen dat uw onkunde duidelijk wordt?
Kan je niet verdragen dat uw onkunde duidelijk wordt?
Je moet wel heel speciaal zijn als je eerst zelf onzin opschrijft en vervolgens andere mensen beschuldigt van onkunde.. Beetje sneu en onzeker ook..

Verder maakte ik mijn onkunde zelf al duidelijk in een andere post hier waarin ik vragen had over het tweakers-artikel. Ik snap dus niet helemaal wat je probeert te bereiken met je opmerkingen. :?
Ergens een deftige uitleg van al die zaken te vinden?
Want ik weet verder voor geen hol hoe NTFS intern werkt, FAT werd ons nog aangeleerd maar dat is al lang niet meer relevant.
Er zal een verschil zijn tussen 1 cluster als leeg markeren, en 1000.
Het enige dat er gebeurt is de bitmap herschrijven. Als nu blijkt dat dit efficiënter kan dat zegt dit vooral iets over de laksheid van Microsoft de laatste 25+ jaar.
Het enige dat er gebeurt is de bitmap herschrijven.
Dit is niet waar aangezien de $Bitmap file geen idee heeft van bestanden. Het is enkel een 'kaart' van alle clusters met informatie of ze momenteel ergens voor gebruikt worden of niet. Per cluster is het 1 bit aan informatie (wel/niet in gebruik). De eigenlijke fileinformatie (dus o.a. hoe het bestand heet en welke clusters er allemaal bij horen) staat in een heel andere datastructuur.
De MFT wordt aangepast en de bitmap wordt herschreven met die aangepaste bit settings.

U begrijpt echt niet hoe het werkt.

[Reactie gewijzigd door MontyMole op 28 juli 2026 12:53]

De MFT wordt aangepast en de bitmap wordt herschreven met die aangepaste bit settings.

U begrijpt echt niet hoe het werkt.
LOL, ik zou het toch even checken als ik jou was.
$MFT en $Bitmap zijn twee totaal verschillende bestanden met totaal andere doelen.
$MFT bevat de eigenlijke informatie over de bestanden met o.a. welke clusters er horen bij elk bestand.
$Bitmap bevat een kaart van alle clusters op de schijf (dus zonder informatie over bestanden) waarin staat aangegeven of die clusters gebruikt worden of niet. Dit wordt gedaan omdat anders bij het zoeken naar vrije clusters er door de $MFT structuur zou moeten worden gelopen en dat is ontzettend inefficient omdat de informatie over clusters verspreid staat over alle aanwezige bestanden.
Met die $Bitmap file kan het filesystem dus snel zoeken naar vrije sectoren om te gebruiken voor een schrijfactie.
Waar zeg ik dat die hetzelfde zijn?

Ik zeg dat die 2 zaken worden aangepast bij een delete.

Uw snelle AI opzoeking moet u natuurlijk wel niet zomaar napraten als je niet begrijpt hoe het werkt.
Probleem is dat je jezelf tegenspreekt:
NTFS wijzigt toch alleen de bitmap en zet alle gebruikte clusters weer als leeg.
...
De MFT wordt aangepast en de bitmap wordt herschreven met die aangepaste bit settings.
Je zegt hier dus twee verchillende dingen over hetzelfde proces.
Maar goed, wat je wilt..
Ik zeg dat die 2 zaken worden aangepast bij een delete.
Nee, er worden ook nog andere zaken aangepast.
Uw snelle AI opzoeking moet u natuurlijk wel niet zomaar napraten als je niet begrijpt hoe het werkt.
Zo sneu,.., en nog brak Nederlands ook...

[Reactie gewijzigd door koelpasta op 28 juli 2026 18:17]

U weet dus niet dat het probleem niet op vlak van NTFS zelf zit?

Daarin moet enkel de MFT en bitmap aangepast worden.

Het probleem zit elders

Je kan immers altijd al veel sneller dingen deleten via de command prompt of met kleine tools.
U weet dus niet dat het probleem niet op vlak van NTFS zelf zit?
Het probleem is dat alle artikelen spreken van clusters etc. De enige softwarelaag die met clusters te maken heeft is de NTFS driver. Explorer hoeft zelf niks over clusters te weten of er iets mee te doen.
En daar zit het probleem ook niet, want deleten via de console ging altijd al stukken sneller en beter.

En kijk het is dus een Explorer verbetering..

https://www.windowslatest.com/2026/07/26/windows-11s-file-explorer-is-now-faster-at-deleting-large-files-in-a-rare-speed-win-from-microsoft/

[Reactie gewijzigd door MontyMole op 29 juli 2026 16:15]

Wanneer bewerkingen op het bestandssysteem goed en betrouwbaar werkt. Dan moet je wel héél veel vertrouwen in je eigen kunnen hebben wanneer je daar voor een marginale efficiëntie-verbetering aan gaat sleutelen.
Dan moet de efficiëntie-verbetering inmiddels flink substantieel zijn, en/ of de wijziging is inmiddels het best geteste stukje software van de laatste 25 jaar.

Een "Oeps, uw bestandssysteem is corrupt en de gegevens zijn niet meer te herstellen." is niet iets dat Microsoft zich kan permiteren.
(Al zal de eerste die door een totaal ongerelateerde oorzaak zijn HDD crasht uiteraard deze wijziging van Microsoft de schuld geven.)
Dit klinkt eerder als het fixen van een al dertig jaar bestaande bug dan een verbetering, al snap ik waarom Microsoft het niet zo beschrijft...
Nee toch? Dit zijn toch de verbeteringen door inzet van AI?
De vriendjes van de marketing afdeling vonden dit waarschijnlijk beter klinken ;)
Huh? Hoe moet dit werken? Als je een bestand verwijdert dan wordt toch enkel de eerste index die verwijst naar alle sub-chunks weggehaald en de rest wordt dan automatisch vrijgegeven? Waarom moeten de fragemnten appart worden weggehaald? En hoe kan het dat er dan in eerste instantie zo veel fragmenten worden geproduceert dat het lang moet duren? Zit het eigenlijke probleem niet in hoe de beschikbare ruimte in eerste instantie wordt toegewezen aand een bestand?
De laatste vraag is het meest simpel. Als je disk bijna vol is, dan heb je vaak geen keuze. En als Windows begint met een file te schrijven dan is de grootte vaak onbekend.

Je eerste idee over "subchunks die automatisch worden vrijgegeven" is niet hoe een OS werkt. Er is niets automatisch op dat nivo, Windows moet alle chunks vrijgegeven.
Je eerste idee over "subchunks die automatisch worden vrijgegeven" is niet hoe een OS werkt.
Jawel hoor, in de basis is dit hoe NTFS werkt (heeft niks met het OS te maken overigens). Er gebeurt echter nog iets waardoor er een probleem kan ontstaan. :)

Ik ben er een beetje ingedoken en het blijkt dat NTFS redundante informatie bijhoudt in de vorm van $Bitmap . Dit is blijkbaar een file waarin ze bijhouden welke clusters er in gebruik zijn.
Deze file staat los van de file-system abstractielaag en is bedoelt om snel vrije ruimte te vinden zonder door de file-boom heen te lopen.

En hier gaat het volgens mij 'mis'. Deze $Bitmap file moet bij elke file aanmaak en delete actie bijgewerkt worden.
Zonder deze file zou het deleten van een bestand heel makkelijk en snel zijn omdat dan alleen de eerste index van de file weggehaald hoeft te worden en dan ziet het OS de rest van de bijbehorende clusters niet.
Maar omdat ze ook nog die $Bitmap bijhouden moeten vervolgens alle clusters die bij de verwijderde file horen ook nog eens vrijgegeven worden in de $Bitmap file. En dat kost bij een groot en gefragmenteert bestand noemenswaardige tijd.

Het gaat er dus niet zozeer om dat het verwijderen van het bestand zelf lang duurt alswel dat er naast de filestrctuur ook nog een clustermap wordt bijgehouden die ook geupdate moet worden.

[Reactie gewijzigd door koelpasta op 28 juli 2026 11:25]

Dit lijkt wel het gedrag te ondersteunen ja. Het issue lijkt namelijk dat verkenner de fragmenten gaat vrijgeven op een afzonderlijk niveau. Met commandline deletion heb je het probleem namelijk. Dan mag NTFS het zelf uitzoeken.
Het issue lijkt namelijk dat verkenner de fragmenten gaat vrijgeven op een afzonderlijk niveau. Met commandline deletion heb je het probleem namelijk. Dan mag NTFS het zelf uitzoeken.
Je lijkt zaken door elkaar te halen. Een file deleten in verkenner of CMD is precies hetzelfde. In beide gevallen worden dezelfde FS Api-functies aangeroepen.
Waar verschil ik kan zitten tussen de twee interfaces is hoe ze omgaan met een opdracht om meerdere files weg te halen. Maar daar gaat dit artiekel niet over.
Nee dat lijkt het niet te zijn. Ja ze roepen onder water mogelijk dezelfde API aan voor de daadwerkelijke verwijdering alleen gaat verkenner eerst uitzoeken waar en hoe het bestand er daadwerkelijk staat. Er zit nog een hele engine tussen die dit voor Explorer.exe doet. Dit artikel legt het wat beter uit:

https://www.windowslatest.com/2026/07/26/windows-11s-file-explorer-is-now-faster-at-deleting-large-files-in-a-rare-speed-win-from-microsoft/
The company notes: “File deletion in File Explorer is now faster in certain scenarios when deleting large, fragmented files.”
Deze fix is expliciet in verkenner en het direct onderliggende systeem.
According to reporting from Windows Latest, the company is now focusing not just on the interface but also on the underlying file operation engine that handles tasks like delete, copy, and transfer. One of the first major improvements under testing is bulk file deletion.
Dat zit dus nog boven de API call.
Waar verschil ik kan zitten tussen de twee interfaces is hoe ze omgaan met een opdracht om meerdere files weg te halen. Maar daar gaat dit artiekel niet over.
Maar is wel waar het artikel over zou moeten gaan. De fixes zijn in explorer, niet het onderliggende filesystem. Het is immers geen update voor NTFS, maar een update aan de bovenliggende engine.

Het gaat er om dat File explorer allerlei metadata op gaat vragen die I/O blocking voor het verwijderproces plaatsvinden. Het gaat echt om de file explorer wijzigingen en de onderliggende engine die de deletion doet. De metadata afhandeling en "past het in prullenbak" check zijn nu asynchroon naast het starten van de deletion ipv er voor. De API call wordt dus veel later pas echt gedaan. Op CMD is het instant.

`Remove-Item` maakt geen gebruik van de `IFileOperation`-engine en praat rechtstreeks met de kernel. Hetzelfde geldt voor `del` en `rmdir`, maar die zijn nog sneller omdat ze niet eerst een .NET object aanmaken.
... According to reporting from Windows Latest, the company is now focusing not just on the interface but also on the underlying file operation engine that handles tasks like delete, copy, and transfer. One of the first major improvements under testing is bulk file deletion. ...

Dat zit dus nog boven de API call.
Eeh,. die quote lijkt je tegen te spreken. Er staat letterlijk dat het om 'the underlying file operation engine' gaat. Dat is dus de NTFS driver en die zit verpakt in API calls.
Explorer heeft volgens mij echt helemaal niks met clusters en fragmenten te maken.
Er staat ook:
"NTFS still has to look up every fragment and clear it from the drive’s free space records one by one, and with a badly fragmented file, it is enough to slow things down."
NTFS doet dit 'clearen' middels de $Bitmap file.
Het gaat er om dat File explorer allerlei metadata op gaat vragen die I/O blocking voor het verwijderproces plaatsvinden. Het gaat echt om de file explorer wijzigingen en de onderliggende engine die de deletion doet. De metadata afhandeling en "past het in prullenbak" check zijn nu asynchroon naast het starten van de deletion ipv er voor. De API call wordt dus veel later pas echt gedaan.
Het artiekel dat je linkt heeft het hier helemaal niet over. Ik zeg niet dat je ongelijk hebt over wat er verbeterd is, maar het artiekel dat je linkt bevestigt je verhaal niet.

En eerlijk gezegt vind ik dat het artiekel dat je gelinkt hebt echt heel erg vaag is en niet echt op technische basis uitlegt wat er precies veranderd is.
Eeh,. die quote lijkt je tegen te spreken. Er staat letterlijk dat het om 'the underlying file operation engine' gaat. Dat is dus de NTFS driver en die zit verpakt in API calls.
Nee die engine zit er nog tussen. Die is namelijk FS agnostisch en werkt ook voor FAT en ReFS.

De NTFS driver is niet aangepast.
Het artiekel dat je linkt heeft het hier helemaal niet over. Ik zeg niet dat je ongelijk hebt over wat er verbeterd is, maar het artiekel dat je linkt bevestigt je verhaal niet.
Nee maar andere artikelen wel ;) er is nog geen officiële bekendmaking vanuit MS wat er precies is aangepast, maar gezien het echt Explorer.exe en onderliggen routines zijn en niet de NTFS driver (want dit is ook bij andere Filesystems een ding, maar minder), lijkt het niet perse $bitmap te zijn.

De snelheid van acties via cmd en powershell is namelijk hetzelfde. Het lijkt een algehele fix voor metadata afhandeling. Dus de engine die explorer gebruikt om ongeacht het FS de delete te starten.

[Reactie gewijzigd door supersnathan94 op 28 juli 2026 14:22]

Hmm, ok, ik geloof je. :)
Het lijkt een algehele fix voor metadata afhandeling.
Zou wel een keertje tijd worden dat ze explorer fixen ;)
Maar dan lijkt het dus niet zoveel met het omgaan met clusters en fragmentatie binnen het FS te maken te hebben maar met wat explorer doet met die informatie o.i.d.. Nou ja, we gaan het meemaken.
Nee zeker waar. Dit is natuurlijk wel een beetje raar ook dat het zo lang heeft moeten duren, maar het is wel goed dat ze nu een volledige reconciliatie doen. Er gaan namelijk allerlei processen en zaken op de schop. Ook oude UI dingen die al een decennium hetzelfde zijn.

Ik hoop alleen dat ze het goed testen.
Ja, technisch gesproken is $bitmap redundant. Maar zonder die file moet je bij elke schrijfactie alle bestaande files aflopen om te kijken wat er nog vrij is. Dat duurt dagen, tegenwoordig.

En $bitmap wordt niet "automatisch" bijgehouden, dat moet het OS doen.
Ja, technisch gesproken is $bitmap redundant. Maar zonder die file moet je bij elke schrijfactie alle bestaande files aflopen om te kijken wat er nog vrij is. Dat duurt dagen, tegenwoordig.
Nou ja, zo dramatisch is het ook weer niet maar het kost wel veel tijd omdat de informatie over de door een file gebruikte clusters verspreid staat over het bestandssysteem. Vandaar dat ze in 1 bestand ($Bitmap) bijhouden waar op de schijf er nog vrije clusters zijn. Er staat dus verder geen bestandsinformatie in die $Bitmap file, alleen een bitje dat zegt of een cluster in gebruik is of niet. Maar gevolg is dus dat als je een bestand verwijdert dat deze $Bitmap file ook aangepast moet worden en dat kan veel operaties opleveren als er veel fragmentatie is.
En $bitmap wordt niet "automatisch" bijgehouden, dat moet het OS doen.
Eeh, niks in een filesysteem wordt 'automatisch' door de schijf gedaan. :) Het loopt allemaal via de file system driver in het OS.
Als men in de 'daluren' defragmenteerd is dat probleem al veel kleiner. Of wordt er niet meer gedefragmenteerd omdat SSD?
Windows doet dit automatisch voor sdd's, handmatig ssd's defrafmenteren wordt afgeraden.
Misschien zijn ze eindelijk gestart met het herbouwen van verkenner? (sneller opstarten en reageren)
Af en toe intypen op een Admin-prompt:

defrag c: /v

Probleem opgelost :)
Het defragmenteren van een SSD is niet nodig en wordt sterk afgeraden. Het levert geen snelheidswinst op en vermindert de levensduur van de schijf
Is dit heden ten dage nog een relevante kwestie? Op SSD’s heb je dit probleem niet toch?
Ook op SSD's heb je dit probleem.

Het is een artefact van het filesysteem, niet van het opslag medium. Zelfs het soort filesysteem of OS maakt niet uit elk OS elk FS heeft hier in meer of mindere mate last van.
ik heb aardig wat 'linux iso's' die ik magnetisch opsla op een server die op windows draait. Voor mij nog wel relevant dus :)
Ik neem aan dat je die niet vaak random aanpast en herschrijft en er voldoende vrije ruimte is op de schijf? Dan is dit een praktisch non-issue.
Dit gaat niet over de performance issue dat je een gefragmenteerd bestand minder snel kan lezen van een draaiende harde schijf, maar over het verwijderen van een zwaar gefragmenteerd bestand. Intern wordt een lijst bijgehouden welke blokken er vrij zijn en welke niet en deze lijst updaten is meer werk als bestanden over de hele schijf verspreid zijn.
Hmzz, ik dacht dat de MFT op voorhand gereserveerd wordt en dus niet gefragmenteerd kan worden, zonder tweaking en dergelijke. Dus op zowel mageet als chips zouden die fysiek dicht bij elkaar moeten staan.

Er kan wel wat aan geprutst worden, hier uitleg e.d. in het Nederlands: https://www.itfaq.nl/snelheid-windows-ntfs-bestandssysteem-verbeteren-sneller-toegang-tot-bestanden/

Maar ik vind het knudde dat we nog steeds geen ander bestandssysteem kunnen kiezen dan NTFS, of ReFS op servers. Laat ons toch gewoon iets anders kiezen, op andere kan dit al jaren dus het is niet dat ze onbetrouwbaar of traag zijn.
Het gaat waarschijnlijk dus niet om $MFT maar om het bijwerken van $Bitmap.

Om te kunnen reageren moet je ingelogd zijn