Varför är det en stor skillnad mellan storlek och storlek på disk?

För det mesta kommer värdena för "Storlek" och "Storlek på disk" att vara mycket nära matchning när du kontrollerar en mapp eller filens storlek, men vad händer om det finns stor skillnad mellan de två? Dagens SuperUser Q & A-inlägg tittar på svaret på det här förvirrande problemet.

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.

Frågan

SuperUser reader thelastblack vill veta varför det finns en så stor skillnad mellan "Size" och "Size on disk" för en mapp på telefonens SD-kort:

Som du kan se nedan är det så mycket skillnad mellan fälten "Storlek" och "Storlek på disk" för den här mappen. Varför är det så?

Jag vet att "Storlek på disken" borde vara lite mer än "Storlek" på grund av fördelningsenheter i Windows, men varför är det så stor skillnad? Kan det vara på grund av det stora antalet filer?

BTW, den här mappen finns på min Android-telefonens SD-kort. Innehållet här lagrar appen i appen sina cachade kartor, och appen får sina kartor från Google Maps.

Titta på skärmdumpen, det finns definitivt en stor skillnad mellan "Storlek" och "Storlek på disk", så vad har hänt här för att orsaka detta?

Svaret

SuperUser-bidragare Bob har svaret för oss:

Jag antar att du använder filsystemet FAT / FAT32 här, eftersom du nämner att det här är ett SD-kort. NTFS och exFAT beter sig på samma sätt med avseende på fördelningsenheter. Andra filsystem kan vara olika, men de stöds inte i alla fall i Windows.

Om du har många små filer är det säkert möjligt. Tänk på följande:

50 000 filer

32 KB klusterstorlek (allokeringsenheter), vilket är max för FAT32

Ok, nu minimum Utrymmet är 50 000 * 32 000 = 1,6 GB (med SI-prefix, inte binärt, för att förenkla matematiken). Utrymmet som varje fil tar på disken är alltid en multipel av fördelningsenhetsstorleken - och här antar vi att varje fil faktiskt är tillräckligt liten för att passa in i en enda enhet, med lite (bortkastat) utrymme kvar.

Om varje fil i genomsnitt uppgår till 2 KB, kommer du att få cirka 100 MB totalt - men du slösar också 15 gånger den (30 KB per fil) i genomsnitt på grund av fördelningsenhetsstorleken.

Fördjupning Fördjupning

Varför händer detta? Tja, FAT32-filsystemet behöver hålla reda på var varje fil är lagrad. Om det skulle finnas en lista över varje byte skulle tabellen (som en adressbok) växa i samma takt som data - och slösa mycket utrymme. Så vad de gör är att använda "allokeringsenheter", även känd som "klusterstorlek". Volymen är uppdelad i dessa fördelningsenheter, och vad gäller filsystemet kan de inte delas upp - det är de minsta blocken det kan adressera. Mycket som om du har ett husnummer, men din brevbärare bryr dig inte hur många sovrum du har eller bor i dem.

Så vad händer om du har en mycket liten fil? Tja, filsystemet bryr sig inte om filen är 0 KB, 2 KB eller till och med 15 KB, det ger det minst utrymme det kan - i exemplet ovan är det 32 KB. Din fil använder bara en liten del av det här utrymmet, och resten är i princip bortkastad men hör fortfarande till filen - ungefär som ett sovrum du lämnar obevakad.

Varför finns det olika fördelningsenhetstorlekar? Tja, det blir en avvägning mellan att ha ett större bord (adressbok, t.ex. att John äger ett hus på 123 Falsk Street, 124 Falsk Street, 666 Satan Lane, etc.) eller mer slösat utrymme i varje enhet . Om du har större filer är det mer meningsfullt att använda större tilldelningsenheter - eftersom en fil inte får en ny enhet (hus) tills alla andra är fyllda. Om du har massor av små filer, ja, du kommer ändå att ha ett stort bord (adressbok), så kan det också ge dem små enheter (hus).

Stora allokeringsenheter kommer som regel att slösa bort mycket utrymme om du har många små filer. Det är vanligtvis inte en bra anledning att gå över 4 KB för allmän användning.

Splittring?

Vad gäller fragmentering bör fragmentering inte slösa bort utrymme på detta sätt. Stora filer kan vara fragmenterade, dvs uppdelade i flera fördelningsenheter, men varje enhet ska fyllas innan nästa startas. Defragging kan spara lite utrymme i fördelningstabellerna, men det här är inte ditt specifika problem.

Möjliga lösningar

Som gladiator2345 föreslog, är dina enda verkliga alternativ på den här tiden att leva med det eller omformat med mindre fördelningsenheter.

Ditt kort kan formateras i FAT16, som har en mindre gräns för tabellstorlek och kräver därför mycket större tilldelningsenheter för att kunna hantera en större volym (med en övre gräns på 2 GB med 32 KB-fördelningsenheter). Källa med tillstånd av Braiam. Om så är fallet borde du säkert kunna formatera som FAT32 ändå.

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.