Waarom is er een groot verschil tussen 'Grootte' en 'Grootte op schijf'?

Meestal zullen de waarden voor 'Grootte' en 'Grootte op schijf' zeer dicht bij de vergelijking komen bij het controleren van de grootte van een map of bestand, maar wat als er een enorm verschil tussen beide is? Het huidige SuperUser Q & A-bericht bekijkt het antwoord op dit verwarrende probleem.

De Question & Answer-sessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een gemeenschapsgedreven groep van Q & A-websites.

De vraag

SuperUser-lezer thelastblack wil weten waarom er zo'n groot verschil is tussen 'Grootte' en 'Grootte op schijf' voor een map op de SD-kaart van zijn telefoon:

Zoals je hieronder kunt zien, is er zoveel verschil tussen de velden 'Grootte' en 'Grootte op schijf' voor deze map. Waarom is dat?

Ik weet dat 'Grootte op schijf' iets meer zou moeten zijn dan 'Grootte' vanwege toewijzingseenheden in Windows, maar waarom is er zoveel verschil? Kan het komen door het grote aantal bestanden?

Tussen haakjes, deze map staat op de SD-kaart van mijn Android-telefoon. Hierin worden de cachemap van mijn kaarten-app opgeslagen en de app haalt zijn kaarten uit Google Maps.

Als je naar de schermafbeelding kijkt, is er absoluut een groot verschil tussen 'Grootte' en 'Grootte op schijf', dus wat hier is gebeurd om dit te veroorzaken?

Het antwoord

SuperUser-bijdrager Bob heeft het antwoord voor ons:

Ik ga ervan uit dat je het FAT / FAT32-bestandssysteem hier gebruikt, omdat je zegt dat dit een SD-kaart is. NTFS en exFAT gedragen zich op dezelfde manier met betrekking tot toewijzingseenheden. Andere bestandssystemen kunnen verschillen, maar ze worden sowieso niet ondersteund door Windows.

Als je veel kleine bestanden hebt, is dit zeker mogelijk. Overweeg dit:

50.000 bestanden

32 KB clustergrootte (allocatie-eenheden), wat het maximum is voor FAT32

Ok, nu de minimum opgenomen ruimte is 50.000 * 32.000 = 1,6 GB (met behulp van SI-voorvoegsels, niet binair, om de wiskunde te vereenvoudigen). De ruimte die elk bestand op de schijf inneemt is altijd een veelvoud van de grootte van de toewijzingseenheid - en hier gaan we ervan uit dat elk bestand eigenlijk klein genoeg is om in een enkele eenheid te passen, met wat (verspilde) ruimte over.

Als elk bestand gemiddeld 2 kB zou zijn, zou je ongeveer 100 MB totaal krijgen - maar je verspilt ook gemiddeld 15x (30 KB per bestand) vanwege de grootte van de toewijzingseenheid.

Uitvoerige uitleg

Waarom gebeurt dit? Welnu, het FAT32-bestandssysteem moet bijhouden waar elk bestand is opgeslagen. Als het een lijst zou bijhouden van elke afzonderlijke byte, zou de tabel (zoals een adresboek) met dezelfde snelheid groeien als de gegevens - en verspillen veel ruimte. Dus wat ze doen is gebruik maken van "allocatie-eenheden", ook wel bekend als de "clustergrootte". Het volume is verdeeld in deze toewijzingseenheden en wat het bestandssysteem betreft, kunnen ze niet worden onderverdeeld: dat zijn de kleinste blokken die het kan adresseren. Net zoals je een huisnummer hebt, maar je postbode geeft er niet om hoeveel slaapkamers je hebt of wie er woont.

Dus wat gebeurt er als je een heel klein bestand hebt? Nou, het bestandssysteem maakt het niet uit als het bestand 0 KB, 2 KB of zelfs 15 KB is, het geeft het de minste ruimte die het kan hebben - in het voorbeeld hierboven is dat 32 KB. Je bestand gebruikt maar een klein deel van deze ruimte, en de rest is eigenlijk verspild, maar hoort nog steeds bij het bestand - net als een slaapkamer die je onbezet achterlaat.

Waarom zijn er verschillende toewijzingseenheden? Nou, het wordt een afweging tussen het hebben van een grotere tafel (adresboek, bijvoorbeeld zeggen dat John een huis bezit op 123 Fake Street, 124 Fake Street, 666 Satan Lane, etc.), of meer verspilde ruimte in elke eenheid (huis) . Als u grotere bestanden hebt, is het logischer om grotere toewijzingseenheden te gebruiken, omdat een bestand geen nieuwe eenheid (huis) krijgt totdat alle andere zijn opgevuld. Als je veel kleine bestanden hebt, dan heb je sowieso al een grote tafel (adresboek), dus kunnen ze net zo goed kleine eenheden (huizen) geven.

Grote toewijzingseenheden zullen in het algemeen veel ruimte verspillen als u veel kleine bestanden hebt. Er is meestal geen goede reden om hoger te gaan dan 4 KB voor algemeen gebruik.

fragmentatie?

Wat fragmentatie betreft, zou fragmentatie op deze manier geen ruimte moeten verspillen. Grote bestanden kunnen gefragmenteerd zijn, d.w.z. opgesplitst, in meerdere toewijzingseenheden, maar elke eenheid moet worden gevuld voordat de volgende wordt gestart. Defragging kan een beetje ruimte in de toewijzingstabellen besparen, maar dit is niet uw specifieke probleem.

Mogelijke oplossingen

Zoals Gladiator2345 suggereerde, zijn je enige echte opties op dit punt om ermee te leven of opnieuw te formatteren met kleinere toewijzingseenheden.

Uw kaart kan zijn geformatteerd in FAT16, die een kleinere limiet voor de tabelgrootte heeft en daarom veel grotere toewijzingseenheden nodig heeft om een groter volume aan te pakken (met een bovengrens van 2 GB met 32 KB-toewijzingseenheden). Bron met dank aan Braiam. Als dat het geval is, zou je in ieder geval veilig als FAT32 moeten kunnen formatteren.

Heb je iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk hier de volledige discussiethread.