Förlorat 200 gb på hårddisk

Är det den uppgivna volymstorleken som blivit 200 GB mindre eller är det 200 GB mindre med ledig plats än vad som förväntas av filsystemet (dvs maxstorleken på filsystemet är samma som innan).

har du kopierat alla dina filer till en backup-disk och sett att det går att läsa dem utan fel (som io-error etc.) - det är läge att göra backup till annan fristående media oavsett när man tycker sig ha lagringsstrul.

I förstnämnda fallet så ha tex partitionmagic, gparted eller andra partitionshanterar eller motsvarande minska på filsystemet för att skapa ledig plats på lagringen för tex. en ytterligare partition.

I det andra fallet så har någon väldigt stor fil skapats i filsystemet av någon orsak och tex med användande av spacesniffer (och körs som administrator) så kan man snabbt visuellt se om någon fil tar enormt med plats i någon mapp.

https://www.jam-software.com/treesize_free brukar jag använda för att hitta vad som tar plats

OK, den är så pass stor och utrymme har försvunnit medans du använt den. Då är nog inte "omräkningen" orsaken (Som växer exponentiellt ju större diskarna blir och är nästan 1.1 TB för din disk. (14.9TB))

Kör du disken som bootdisk eller ren datadisk? Tänker att Windows laddar hem sina uppgraderingar eller har lagt upp en ny "system restore point" sedan du kikade sist.

(Jag använder E: här, om du använder disken som datadisk så heter den kanske något annat.)
Har du någon dold E:\found.000 katalog på din disk, där chkdsk kan lägga borttappade filer som den inte kan koppla till ett namn.. Kan ju vara värt att låta datorn köra en "chkdsk /F /X E:" och se att alla strukturer är ok. (Kör över natten om den tar väldigt lång tid på sig och avbryt den inte!) (/X avmonterar disken, gör en omstart när den är klar.)

Sen göra som "immutable" föreslog och försöka identifiera ökningen med "treesize", men det kräver ju någon sorts historisk referens. Du kanske kan ladda hem https://windirstat.net/ också och jämföra vad de två verktygen säger. PS: Kör dessa verktyg som administrator.

https://www.avg.com/en/signal/how-to-use-chkdsk-windows
Invisible found.000 folder after chkdsk

Att du raderar filer synligt i explorern eller program betyder inte alltid att de försvinner fysiskt från disken/metadatan förrän efter en tid eller ett antal omstarter. En av mekanismerna som kan ta plats är VSS aka "Volyme Shadow Copy" som du inte ser arbetar men lagrar datablock som kan ta en del plats under "System Volume Information" och normalt inte kan inspekteras medans du kör windows (det hindrar access för att kunna se filer eller se storleken på mappen). Du har återställningspunkter - kanske versionshantering av filer i explorer samt kvarvarande filer i papperskorgen varav en del av det använder sig av VSS.

en 16 TB disk som bara har 300 - 100 GB (1-2%) ledigt utrymme kvar är att ses som väldigt full och filutläggningen över ytan när filerna skrivs blir inte lika bra och mer upphackad och ger mer sökningar än när disken är mindre fylld - speciellt på NTFS som är ökänd att lätt fragmentera filer i småbitar över diskytan.

på en systemdisk skall man helst inte fylla disken mer än till ca 80% eftersom filer i olika storlekar skrivs och raderas hela tiden medans typiska medialagringsdiskar som bara fylls på och i bara liten utsträckning ändrar inom filer och ta bort filer så kan man fylla lite mer.

Varit med om sådant ett par gånger på tomma diskar man tagit "bort" allt.
Dvs tömt disken och tömt papperskorgen så är det typ 200gb använt fast det inte finns några filer (även med visa dolda filer valt i explorer).

Formaterar man disken så kommer det tillbaka.

$MFT är en systemfil som alltid växer och aldrig krymper igen och tillväxtakten är ca 1 GB per 1 miljon filer och storleken sätts av hur många filer man har haft i filsystemet samtidigt under hittillsvarande livstid för filsystemet.

Är NTFS formaterad med flaggan /V för att tåla fragmenterade filer med större antal fragment när filer växer för att de hela tiden sakta fylls på med data (som loggfiler eller mappar där det hela tiden fylls på med småfiler som thumbnails av bildarkiv - då även själva mappen (som är en specialfil i filsystemet som hanteras i $MFT på samma sätt som alla andra filer) också blir fragmenterad och defragmenteras normalt inte av MS egna defragmenteringsprogram som körs då och då (typiskt 1 ggr i veckan) och en dag helt plötsligt går det inte att lägga i fler filer i mappen...), så växer $MFT med 4 GB per 1 miljon filer då minsta entryt för en fil är då 4 Kbyte istället 1 Kbyte.

Enda sättet att få bort en stor och svulstig och i en del fall kraftigt fragmenterad $MFT är att sonika formatera om hela lagringen.

---

Som utvikning så måste något vara rejält trasigt prestandamässigt i en nyligen uppdaterad win10 när man kör mot en extern 4TB/5/TB 2.5" USB-snurrdisk av SMR-typ - tänk typisk fall när man vill göra backupper av en systemdisk fil för fil till en långtidslagringstålig snurrdisk.

När man i linux kopierar in från en lite lagom halvmogen windowspartitions root-mapparna som "Programdata, Program Files, Program Files (x86) och Windows" på en NVMe disk till en till ovan nämnda snurrdisk(ar) av SMR-typ till en BTRFS-volym under Linux så tar det 7:56 minute och med komprimerad mapp i BTRFS, 8:16 minuter och mot en likadan disk med NTFS formaterat tog det 9:36 minuter med linux använda kernelbaserade NTFS-stöd.

Det var i detta fall 602369 filer och mappar fördelat på 417989 filer och 184380 mappar och knappt 47 GB i total storlek (ja det ligger väldigt många småfiler och mappar i olika djupa mappträn i dessa mappar varav en stor del är hårdlänkade mot varandra - därför testen med just dessa mappar mot SMR-diskar för att stressa denna)

Därefter tänkte jag köra samma operation i Windows - och det tog tvärstopp och segt som frusen sirap och det började komma en massa varningar om låsta filer mm., bröt det och tänkte att jag kopierar först över dessa ovan nämnda mapp med kopierade systemmappar som fanns på snurrdisken till en mapp på NVMe-lagringen på systemdisken - och sedan köra tillbaka dessa mot SMR-snurrdisken på en ny mapp och se hur fort det gick.

Att kopiera från snurrdisken till NVMe där SMR inte borde ha någon större effekt - gick också segt som sirap och överföringen tog 168 minuter - viss skillnad mot runt 8 minute när det gjordes med linux...

Så varför gick det långsam - tittade i windows 'performance center' medans kopieringen pågick och där det stallade på hela tiden var att att en massa data på $MFT och $LOG skrevs konstant och en del $Bitmap baklänges mot disken fast den egentligen bara skulle läsa från disken - dvs. rev om filsystemets metadata konstant hela tiden med stora mängder skriven data och det körde förstås slut på SMR-diskens PMR-del ganska fort och det var långa perioder det bara skrev data på disken utan att det kopierad något från disken till NVMe-lagringen - på en disk det egentligen bara skulle läsa data ifrån... pausade jag kopieringen så slutade det också att skriva mot disken efter en ganska lång stund, startade jag igen så började det skriva igen mot $MFT och $LOG - så det var ingen bakgrundsindexering av filer av vad jag kunde se...

Tillbakaskrivningen av mapparna som kopierades in innan från NVMe-disken till SMR-disken är ännu inte fullt genomförd då jag inte orkade att vänta på att den skulle bli klar, men efter 86 minuter så hade det hunnit överföra 26014 filer varav 2292 mappar 23722 filer med total storlek av 5241 Mbyte. - med den takten hade det tagit hela dagen att få över dessa 47 GB med data till SMR-snurrdisken...

Kopieringen gjordes med 'time cp -ra X Y ' i båda fallen för att få körtider när det blev slutfört och i windows då under 'gitbash', men kollade innan med total commander och file-explorern där det var mycket tydligt att kopieringen inte gick speciellt fort där heller.

Detta kan inte förklaras med att NTFS är generellt urusel efter som paragons NTFS-implementation i Linux-kärnan faktiskt skrev filerna rätt fort och uppenbarligen i en skrivordning som inte helt tömde SMR-disken PMR-area vid 47 GB total skrivvolym.

Det ser ut som att det är windows själv som har en massa hyss för sig med för många mellanlager från den abstraktionslagren programmet ser när den öppnar, skriver och stänger filer till att det når ned till att skriva fysisk på diskytan/flashblocken

Och en del i detta är den vansinnigt stora mängd med metadata som inflätat med datat skrivs mot lagringen hela tiden - där SSD/NVMe snabba sökning döljer en stor del av detta när det skriver fram och tillbaka på olika delar av $MFT, $LOG och $BITMAP (och var modifiering där måste uppdateras i $MFT igen eftersom dessa är självrefererande) men på magnetisk lagringsmedia blir en svår och tidsfördröjande belastning av de många sökningarna på olika platser hela tiden.

Undrar om VSS (Shadow copy) och defender i from av mellanlager mellan applikationen och fysiska lagringen är en del av problemet varför det är så kostsamt tidmässigt nu att skriva till en mekanisk disk under win10...

Detta måste ha barkat i helt galen väg med skrivstrategier och cachning mot lagring, för så tungdrivet var det inte på windows på 2010-2015 talet och tidigare med winXP och win7 på mekaniska diskar...

Nu har jag inte kollat på andra windatorer för att bekräfta denna beteende men denna windows är rätt sparsamt använd och främst för spel när man väl kör windows - annars snurra bara linux på denna burk till 90% av tiden.