De cele mai multe ori, valorile pentru "Dimensiune" și "Dimensiune pe disc" vor fi foarte apropiate de potrivirea la verificarea dimensiunii unui dosar sau a unui fișier, dar ce se întâmplă dacă există o discrepanță enormă între cele două? Postul de astăzi SuperUser Q & A se uită la răspunsul la această problemă confuză.
Sesiunea de întrebări și răspunsuri din ziua de astăzi vine de la amabilitatea SuperUser - o subdiviziune a Stack Exchange, o grupare bazată pe comunitate a site-urilor Q & A.
Cititorul SuperUser thelastblack vrea să știe de ce există o diferență atât de mare între "Dimensiune" și "Dimensiune pe disc" pentru un dosar de pe cardul SD al telefonului său:
După cum puteți vedea mai jos, există o diferență atât de mare între câmpurile "Dimensiune" și "Dimensiune pe disc" pentru acest dosar. De ce este asta?
Știu că "Dimensiune pe disc" ar trebui să fie mai mult decât "Dimensiune" din cauza unităților de alocare în Windows, dar de ce există o diferență atât de mare? Ar putea fi din cauza numărului mare de fișiere?
BTW, acest dosar se află pe cardul SD al telefonului meu Android. În interiorul său, aplicația mea pentru hărți stochează hărțile memorate în cache, iar aplicația își preia hărțile din Hărți Google.
Privind la captura de ecran, există cu siguranță o discrepanță enormă între "Dimensiune" și "Dimensiune pe disc", deci ce sa întâmplat aici pentru a provoca acest lucru?
Contributor SuperUser Bob are răspunsul pentru noi:
Voi presupune că utilizați aici sistemul de fișiere FAT / FAT32, deoarece menționați că acesta este un card SD. NTFS și exFAT se comportă similar în ceea ce privește unitățile de alocare. Este posibil ca alte sisteme de fișiere să fie diferite, dar, oricum, acestea nu sunt acceptate pe Windows.
Dacă aveți o mulțime de fișiere mici, acest lucru este cu siguranță posibil. Gandeste-te la asta:
- 50.000 de fișiere
- 32 KB dimensiunea clusterului (unități de alocare), care este maximul pentru FAT32
Bine, acum minim spațiul luat este de 50.000 * 32.000 = 1.6 GB (folosind prefixele SI, nu binare, pentru a simplifica matematica). Spațiul pe care fiecare fișier are pe disc este întotdeauna un multiplu al mărimii unității de alocare - și aici presupunem că fiecare fișier este într-adevăr suficient de mic pentru a se potrivi într-o singură unitate, cu un spațiu (pierdut) rămas.
În cazul în care fiecare fișier a avut o valoare medie de 2 KB, ați obține aproximativ 100 MB total - dar pierdeți, de asemenea, de 15 ori (30 KB per fișier), în medie, din cauza dimensiunii unității de alocare.
Explicație în profunzime
De ce se întâmplă acest lucru? Ei bine, sistemul de fișiere FAT32 trebuie să țină evidența locului în care este stocat fiecare fișier. Dacă ar trebui să păstreze o listă a fiecărui octet, masa (ca o agendă de adrese) ar crește la aceeași viteză ca și datele - și va pierde o mulțime de spațiu. Deci, ceea ce fac ei este utilizarea "unităților de alocare", de asemenea cunoscute sub numele de "dimensiunea clusterului". Volumul este împărțit în aceste unități de alocare, iar în ceea ce privește sistemul de fișiere, acestea nu pot fi subdivizate - acestea sunt cele mai mici blocuri pe care le poate aborda. Ca și cum ai un număr de casă, dar poștașului tău nu-ți pasă cât de multe dormitoare ai sau care trăiește în ele.
Deci, ce se întâmplă dacă aveți un dosar foarte mic? Ei bine, sistemul de fișiere nu are grijă dacă fișierul este 0 KB, 2 KB sau chiar 15 KB, îi va oferi cel mai mic spațiu posibil - în exemplul de mai sus, care este de 32 KB. Fișierul dvs. utilizează doar o cantitate mică din acest spațiu, iar restul este practic irosit, dar totuși aparține fișierului - la fel ca un dormitor pe care îl lăsați neocupat.
De ce există diferite dimensiuni de unități de alocare? Ei bine, devine un compromis între a avea o masă mai mare (carte de adrese, de exemplu, spunând că John deține o casă în Strada Fake Street, Fake Street 124, 666 Satan Lane etc.) sau mai mult spațiu pierdut în fiecare unitate (casă) . Dacă aveți fișiere mai mari, este mai logic să utilizați unități de alocare mai mari - deoarece un fișier nu obține o nouă unitate (casa) până când toate celelalte sunt completate. Dacă aveți o mulțime de fișiere mici, veți avea oricum o masă mare (agendă), deci ar putea să le dați unități mici (case).
Unitățile de alocare mari, ca regulă generală, vor pierde o mulțime de spațiu dacă aveți o mulțime de fișiere mici. De obicei, nu este un motiv bun să mergeți peste 4 KB pentru utilizare generală.
Fragmentarea?
În ceea ce privește fragmentarea, fragmentarea nu ar trebui să piardă spațiul în acest mod. Fișierele mari pot fi fragmentate, adică împărțite, în mai multe unități de alocare, dar fiecare unitate trebuie umplută înainte ca următoarea să fie lansată. Defragmentarea ar putea salva un spațiu mic în tabelele de alocare, dar aceasta nu este problema dvs. specifică.
Solutii posibile
După cum a sugerat gladiator2345, singurele dvs. opțiuni reale în acest moment sunt de a trăi cu el sau de a reformata cu unități de alocare mai mici.
Cardul dvs. ar putea fi formatat în FAT16, care are o limită mai mică pentru dimensiunea tabelului și, prin urmare, necesită unități de alocare mult mai mari pentru a aborda un volum mai mare (cu o limită superioară de 2 GB, cu unități de alocare de 32 KB). Sursă de amabilitate a lui Braiam. În acest caz, ar trebui să puteți să vă formatați în siguranță ca FAT32 oricum.
Aveți ceva de adăugat la explicație? Sunați în comentarii. Doriți să citiți mai multe răspunsuri de la alți utilizatori de tehnologie Stack Exchange? Check out discuția completă aici.
