Att köra en nära smockfull filsystem är inge bra - program och processer kan stanna mitt i när den tex packar upp filer (många filer är idag komprimerade och packas upp och om temporärt vid modifiering) och det stoppar för att det är slut på diskutrymme och medför också att det kommer göra mer eller mindre permanenta prestandasänkning på filsystem och lagring.
- Eftersom proppfull filsystem också skriver i området som är reserverad för $MFT tillväxt så kan $MFTS tillväxt bli fragmenterad ut på de lediga sektorer som blir kvar, och den fragmenteringen kan inte defragmenteras av de flesta typer av defragmenteringsprogramvara - och hur mycket filsystemet kan minskas vid en resize av en partition sätts av var högsta LBA-nummret på någon av $MFT sektorer har hamnat - under det går inte att krympa hur mycket man än vill.
Man skall aldrig fylla en OS-systemdisk:s filsystem mer än till max 80%, helst inte över 70% vid normal bruk så att det fins plats för temporära filer (tex. windowsuppgradering) utan att disken blir mycket mer än 80% fylld, kör man mer än 87.5% fyllnad så skriver man inom NTFS prioriterade område för $MFT och då börja $MFT fragmentera om antalet filer och extension ökar mycket i antal..
---
Förutom som nämnt titta på SMART-data, kör också memtest86 eller liknande så att det inte är någon RAM-sticka som är grundorsaken till dikes-körningen - att peta i UEFI-partitionen eller GPT-partionen så att det inte är bootbar räknas knappast som en normal beteende för en normalt körande windows med applikationer även om filsystemet är fylld till sista sektorn.
- hade det varit i samband med någon windowsuppdatering (även sådana som går dolda i bakgrunden i förberedelse för den stora svängen under veckan) så kan det ge strul som att dockor, tangentbord och möss och även videobekymmer som tappade externa skärmar mm. genom dockan en nästan en osviklig hint på att nu är det en windows-uppdatering på gång (det beror på att windows försöker byta drivrutiner under drift men reinitieringar av HW mm. går inte som det skall[1]), men sällan att det petar på GPT eller UEFI på lagringen om det inte sker i direkt samband med uppdateringsomstarter av windows.
Var glad att NTFS i alla fall var läsbar och överväg automatisk (helst deduplicerande) backuppogram som kör i bakgrunden mot någon molntjänst/NAS-nätverksenhet eller om det inte finns, inkopplad extern USB-disk då och då när backuppen görs och urkopplad resten av tiden
- själv så återhämtar jag mig från en just RAM-fel som har satt spår på det ena och det andra inklusive att backupsessioner har fått korruption på sina lagrade chunk (med vettig backupprogram så pajar inte hela repositoriet av det men man kan få filer skadade när man försöker återställa - samt att man kan kontrollera repositeriet och reparera de skadade chunken om man har orginalfilerna kvar någonstans och gör en ny backup på dessa så att de skadade segmenten ersätts med korrekt data (avser nu borgbackup - alla är inte lika genomarbetande i avseende när man redan har ett skadad repositorie)
Efter den här svängen har jag insett hur stora skador fel på ramstickor (bitflipp på en byte på en specifik adress i RAM) kan vara och att det kan ställa till mycket elände länge oupptäckt innan man hamnar i något läge där det blir uppenbart och ofta att något fatalt händer....
hade det varit möjligt att köpa laptop med ECC-minne hade jag nog fan betalt för en sådan efter det här...
[1]
Det är sådana ske som gör att jag numera helhjärtat hatar Windows på grejor som skall fungera i 24/7 utan avbrott eller omstarter som inte görs med manuell aktivering
