Varför tömmer diskutrymme fart på datorer?

När du lär dig mer om datorer och hur de fungerar, kommer du ibland att springa över något som inte verkar vara meningsfullt. Med det i åtanke, tömmer diskutrymme faktiskt datorerna? Dagens SuperUser Q & A-post har svaret på en förbryllad läsarens fråga.

Dagens Question & Answer-session kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

Skärmdump med tillstånd av nchenga (Flickr).

Frågan

SuperUser-läsare Remi.b vill veta varför tömma diskutrymme verkar snabba på en dator:

Jag har tittat på många videor och förstår nu hur datorer fungerar lite bättre. Jag förstår vad RAM är, om flyktigt och icke-flyktigt minne, och processen för byte. Jag förstår också varför att öka RAM-hastigheten på en dator.

Vad jag inte förstår är varför rengöring av diskutrymme verkar snabbare på datorn. Hastar det verkligen en dator upp? Om så är fallet, varför gör det det?

Har det något att göra med att söka efter minnesutrymme för att spara saker eller flytta saker runt för att göra tillräckligt länge för att spara något? Hur mycket tomt utrymme ska jag lämna fri på en hårddisk?

Varför tömmer diskutrymme för att påskynda en dator?

Svaret

SuperUser-bidragsgivaren Jason C har svaret för oss:

"Varför tömmer diskutrymme hastigheten på datorer?"

Det gör inte, åtminstone inte ensam. Detta är en riktigt vanlig myt. Anledningen till att det är en vanlig myt är att påfyllning av hårddisken ofta händer samtidigt som andra saker som traditionellt kan sakta ner datorn (EN). SSD-prestanda tenderar att försämras när de fyller, men det här är en relativt ny fråga, unik för SSD, och är inte märkbar för tillfälliga användare. I allmänhet är låg ledigt diskutrymme bara en röd sill.

Till exempel saker som:

1. Fil fragmentering. Fil fragmentering är ett problem (B), men brist på ledigt utrymme, men definitivt en av många bidragande faktorer, är inte den enda orsaken till det. Några viktiga punkter här:

Chanserna att en fil är fragmenterad är inte relaterat till mängden ledigt utrymme kvar på enheten. De är relaterade till storleken på det största sammanhängande blocket av ledigt utrymme på enheten (dvs "hål" i ledigt utrymme), vilket mängden ledigt utrymme händer att lägga en övre gräns på. De är också relaterade till hur filsystemet hanterar filallokering (mer nedan). Överväga: En enhet som är 95 procent full med allt ledigt utrymme i ett enda sammanhängande block har nollprocent chans att fragmentera en ny fil (C) (och chansen att fragmentera en bifogad fil är oberoende av det fria utrymmet). En enhet som är fem procent full men med dataspridning jämnt över enheten har en mycket stor chans att fragmentera.

Tänk på att filfragmentering påverkar bara prestanda när de fragmenterade filerna nås. Överväga: Du har en fin defragmenterad enhet som fortfarande har massor av fria "hål" i den. Ett vanligt scenario. Allt går smidigt. Så småningom kommer du till en punkt där det inte finns några större block med ledigt utrymme kvar. Du laddar ner en enorm film, filen slutar bli allvarligt fragmenterad. Detta kommer inte att sakta ner datorn. Alla dina applikationsfiler och sådana som tidigare var fina blir inte plötsligt fragmenterade. Det kan göra att filmen tar längre tid att ladda (även om typiska filmbithastigheter är så låga jämfört med läshastigheter för hårddiskar som det sannolikt kommer att bli osynligt), och det kan påverka I / O-bundet prestanda medan filmen laddas, men annat än det förändras ingenting.

Medan filfragmentering verkligen är ett problem, ofta tämpas effekterna av OS och hårdvarunivåbuffering och caching. Fördröjd skriver, läs framåt, strategier som prefetcher i Windows, etc., alla hjälper till att minska effekterna av fragmentering. Du brukar inte faktiskt upplever betydande inverkan tills fragmenteringen blir svår (jag skulle till och med vilja säga att så länge som din swap-fil inte är fragmenterad, kommer du förmodligen aldrig att märka).

2. Sökindexering är ett annat exempel. Säg att du har aktiverat automatisk indexering och ett operativsystem som inte hanterar detta graciöst. Eftersom du sparar allt mer indexerbart innehåll till din dator (dokument och liknande) kan indexering ta längre tid och kan börja påverka datorns uppfattade hastighet medan den körs, både i I / O och CPU-användning . Det här är inte relaterat till ledigt utrymme, det är relaterat till hur mycket indexbart innehåll du har. Att springa ut ledigt utrymme går dock hand i hand med att lagra mer innehåll, så att en falsk anslutning dras.

3. Antivirusprogram (liknande sökindexeringsexemplet). Säg att du har antivirusprogram installerat för att göra bakgrundsskanning av din enhet. Eftersom du har mer och mer skannat innehåll tar sökningen mer I / O- och CPU-resurser, vilket eventuellt stör ditt arbete. Återigen är detta relaterat till hur mycket skannbart innehåll du har. Mer innehåll motsvarar ofta mindre ledigt utrymme, men bristen på ledigt utrymme är inte orsaken.

4. Installerad programvara. Säg att du har mycket mjukvara installerad som laddas när datorn startar och därigenom saktar starttiden upp. Denna avbrott händer eftersom mycket mjukvara laddas. Installerad programvara tar dock upp hårddiskutrymme. Därför minskar hårddiskens fria utrymme samtidigt som detta händer, och igen kan en falsk anslutning lätt göras.

5. Många andra exempel längs dessa linjer som, när de tas ihop, dyka upp att nära associera brist på ledigt utrymme med lägre prestanda.

Ovanstående illustrerar en annan anledning till att detta är en sådan vanlig myt: Medan bristen på ledigt utrymme inte är en direkt orsak till att sakta ner, avinstallera olika applikationer, ta bort indexerat eller skannat innehåll etc. ibland (men inte alltid, utanför ramen för detta svar) ökar prestandan igen av anledningar som inte är relaterade till hur mycket ledigt utrymme som återstår. Men det här frigör naturligtvis också hårddiskutrymme. Därför kan igen en tydlig (men falsk) koppling mellan "mer ledigt utrymme" och en "snabbare dator" göras.

Överväga: Om du har en maskin som körs långsamt på grund av massor av installerad programvara etc. klonar du hårddisken (exakt) till en större hårddisk och expanderar sedan dina partitioner för att få mer ledigt utrymme, maskinen kommer inte att öka snabbare. Samma programvara laddas, samma filer är fortfarande fragmenterade på samma sätt, samma sökindexer körs fortfarande, inget ändras trots att det finns mer ledigt utrymme.

"Har det något att göra med att söka efter minnesutrymme för att rädda saker?"

Nej det gör det inte. Det finns två mycket viktiga saker värda att notera här:

1. Din hårddisk söker inte runt för att hitta platser att sätta saker på. Din hårddisk är dum. Det är inget. Det är ett stort block av adresserat lagringsutrymme som blint sätter saker där ditt operativsystem berättar det och läser vad som är fråga om det. Moderna enheter har avancerade cache-och buffermekanismer utformade kring att förutsäga vad operativsystemet kommer att be om baserat på den erfarenhet vi har fått över tiden (vissa enheter är även medvetna om filsystemet som finns på dem), men i huvudsak tänker på din köra som en stor dum förvaring med tillfälliga bonusfunktioner.

2. Dina operativsystem söker inte efter platser att lägga saker också. Det finns ingen sökning. Mycket ansträngning har gått till att lösa detta problem eftersom det är avgörande för filsystemet prestanda. Hur datan faktiskt organiseras på din enhet bestäms av ditt filsystem. Till exempel, FAT32 (gamla DOS och Windows-datorer), NTFS (senare utgåvor av Windows), HFS + (Mac), ext4 (vissa Linux-system) och många andra. Även begreppet "fil" och en "katalog" är bara produkter av typiska filsystem - hårddiskar vet ingenting om de mystiska djuren som heter filer. Detaljerna ligger utanför ramen för detta svar. Men i huvudsak har alla vanliga filsystem sätt att spåra där ledigt utrymme är på en enhet så att en sökning på ledigt utrymme, under normala omständigheter (dvs filsystem i god hälsa), är onödigt. Exempel:

NTFS har ett huvudfiltabell, som innehåller specialfilerna $ Bitmap, etc., och massor av metadata som beskriver enheten. I huvudsak håller det reda på var de nästa fria blocken är så att nya filer kan skrivas direkt till fria block utan att behöva skanna enheten varje gång.

Ett annat exempel: Ext4 har det som kallas bitmap-allokeraren, en förbättring över ext2 och ext3 som i grunden hjälper det direkt att avgöra var fria blockerar istället för att skanna listan över fria block. Ext4 stöder också försenad fördelning, det vill säga buffring av data i RAM av operativsystemet innan du skriver det ut till enheten för att göra bättre beslut om var du ska uttrycka för att minska fragmenteringen.

Många andra exempel.

"Eller med att flytta saker runt för att göra tillräckligt länge för att spara något?"

Nej. Det här händer inte, åtminstone inte med något filsystem jag är medveten om. Filerna slutar bara fragmenteras.

Processen att "flytta saker runt för att skapa ett tillräckligt länge utrymme för att spara något" kallas defragmentering. Detta händer inte när filer skrivs. Detta händer när du kör din diskdefragmenterare. I nyare versioner av Windows sker det åtminstone automatiskt i schema, men det utlöses aldrig genom att skriva en fil.

Att kunna undvika Att flytta saker runt så här är nyckeln till filsystemets prestanda, och det är därför fragmentering händer och varför defragmentering existerar som ett separat steg.

"Hur mycket tomt utrymme ska jag lämna fri på en hårddisk?"

Det här är en svårare fråga att svara på (och detta svar har redan blivit en liten bok).

Tumregler:

1. För alla typer av enheter:

Viktigast, lämna tillräckligt med ledigt utrymme för du använder din dator effektivt. Om du går tom för utrymme för att arbeta, vill du ha en större enhet.

Många diskdefragmenteringsverktyg kräver en minimal mängd ledigt utrymme (jag tror att den med Windows kräver 15 procent, värsta fallet) för att fungera. De använder det här lediga utrymme för att tillfälligt hålla fragmenterade filer eftersom andra saker omordnas.

Lämna utrymme för andra operativfunktioner. Om din maskin exempelvis inte har mycket fysisk RAM, och du har virtuellt minne aktiverat med en dynamiskt stor sidfil, vill du lämna tillräckligt med plats för sidfilens maximala storlek. Eller om du har en bärbar dator som du sätter i viloläge, behöver du tillräckligt med ledigt utrymme för viloläget. Sådana saker.

2. SSD-specifik:

För optimal tillförlitlighet (och i mindre utsträckning prestanda) kräver SSD: er lite ledigt utrymme, som utan att gå in på för mycket detaljer, använder de för att sprida data runt enheten för att undvika att ständigt skriva till samma plats (vilket bär dem ut) . Detta begrepp om att lämna ledigt utrymme kallas över-provisioning. Det är viktigt, men i många SSD finns redan obligatoriskt överutnyttjat utrymme. Det betyder att enheterna ofta har några dussin mer GB än de rapporterar till operativsystemet. Nedre ändenheter kräver ofta att du lämnar manuellt opartitionerat utrymme, men för enheter med obligatorisk OP, du behöver inte lämna ledigt utrymme. En viktig sak att notera här är det Överutnyttjat utrymme tas ofta endast från odelat utrymme. Så om din partition tar upp hela din enhet och du lämnar lite ledigt utrymme på det, så gör det inte alltid räkna. Många gånger kräver manuell över-provisioning att du krymper din partition till att vara mindre än storleken på enheten. Kontrollera din SSDs användarhandledning för detaljer. TRIM, insamling av sopor och liknande har också effekter, men de ligger utanför ramen för detta svar.

Personligen tar jag vanligtvis en större enhet när jag har cirka 20-25 procent ledigt utrymme kvar. Det här är inte relaterat till prestanda, det är bara att när jag kommer till den tiden förväntar jag mig att jag förmodligen kommer att springa tom för utrymme för data snart och det är dags att få en större enhet.

Viktigare än att titta på ledigt utrymme är att se till att schemalagd defragmentering är aktiverad där det är lämpligt (inte på SSD) så att du aldrig kommer till den punkt där det blir tillräckligt för att påverka dig.

Det finns en sista sak att nämna. En av de andra svaren här nämnde att SATA: s halvduplexläge förhindrar läsning och skrivning samtidigt. Medan det är sant, är detta mycket överskattat och är för det mesta orelaterat med de prestationsfrågor som diskuteras här. Vad det här bara betyder är att data inte kan överföras i båda riktningarna på tråden på samma gång. SATA har dock en ganska komplicerad specifikation som involverar små maximala blockstorlekar (ca 8kB per block på tråden tror jag), läs och skriv driftsköer etc., och utesluter inte att skrivningar till buffertar händer medan läsningar pågår, interfolierade operationer etc..

Varje blockering som uppstår skulle bero på att konkurrera om fysiska resurser, vanligtvis mildrad av mycket cache. Duplexläget för SATA är nästan helt irrelevant här.

(EN) "Slow Down" är en bred term. Här använder jag den för att hänvisa till saker som är antingen I / O-bundna (dvs. om datorn sitter där knäckta nummer, innehållet på hårddisken har ingen inverkan) eller CPU-bunden och konkurrerar med tangentiellt relaterade saker som har höga CPU-användning (dvs. skanning av antivirusprogram ton av filer).

(B) SSD: er påverkas av fragmentering, eftersom sekventiella åtkomsthastigheter i allmänhet är snabbare än slumpmässig åtkomst, trots att SSD inte står inför samma begränsningar som en mekanisk enhet (även då garanterar brist på fragmentering inte sekventiell åtkomst på grund av slitstyrning etc.). Men i praktiskt taget varje generellt användningsscenario är detta ett icke-problem. Prestandaförändringar på grund av fragmentering på SSD-enheter är vanligtvis försumbar för saker som att ladda program, starta datorn, etc..

(C) Anta ett sane filsystem som inte fragmenterar filer med syfte.

Se till att läsa igenom resten av den livliga diskussionen hos SuperUser via länken nedan!

Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.