W większości przypadków wartości „Rozmiar” i „Rozmiar na dysku” będą bardzo zbliżone do dopasowania podczas sprawdzania rozmiaru folderu lub pliku, ale co zrobić, jeśli między nimi jest duża rozbieżność? Dzisiejszy post z pytaniami i odpowiedziami dla SuperUser przedstawia odpowiedź na ten mylący problem.
Dzisiejsza sesja pytań i odpowiedzi jest dostępna dzięki uprzejmości SuperUser - części Stack Exchange, grupy witryn internetowych z pytaniami i odpowiedziami.
Pytanie
Czytnik SuperUser thelastblack chce wiedzieć, dlaczego istnieje tak ogromna różnica między „rozmiarem” a „rozmiarem na dysku” folderu na karcie SD jego telefonu:
Jak widać poniżej, istnieje duża różnica między polami „Rozmiar” i „Rozmiar na dysku” dla tego folderu. Dlaczego?
Wiem, że „Rozmiar na dysku” powinien być trochę większy niż „Rozmiar” ze względu na jednostki alokacji w systemie Windows, ale dlaczego jest tak duża różnica? Czy może to być spowodowane dużą liczbą plików?
BTW, ten folder znajduje się na karcie SD mojego telefonu z Androidem. Wewnątrz aplikacja moje mapy przechowuje mapy w pamięci podręcznej, a aplikacja pobiera mapy z Map Google.
Patrząc na zrzut ekranu, widać na pewno ogromną rozbieżność między „rozmiarem” a „rozmiarem dysku”, więc co się tutaj stało, aby to spowodować?
Odpowiedź
Współautor SuperUser Bob ma dla nas odpowiedź:
Zakładam, że używasz tutaj systemu plików FAT / FAT32, ponieważ wspomniałeś, że jest to karta SD. NTFS i exFAT zachowują się podobnie w odniesieniu do jednostek alokacji. Inne systemy plików mogą się różnić, ale i tak nie są obsługiwane w systemie Windows.
Jeśli masz dużo małych plików, jest to z pewnością możliwe. Rozważ to:
- 50 000 plików
- Rozmiar klastra 32 KB (jednostki alokacji), który jest maksymalny dla FAT32
Ok, teraz minimum zajmowane miejsce to 50 000 * 32 000 = 1,6 GB (przy użyciu przedrostków SI, a nie binarnych, aby uprościć obliczenia). Miejsce zajmowane przez każdy plik na dysku jest zawsze wielokrotnością rozmiaru jednostki alokacji - i tutaj zakładamy, że każdy plik jest w rzeczywistości wystarczająco mały, aby zmieścić się w pojedynczej jednostce, z pozostałą (zmarnowaną) przestrzenią.
Jeśli każdy plik ma średnio 2 KB, otrzymasz łącznie około 100 MB, ale marnujesz też 15 razy więcej (30 KB na plik) ze względu na rozmiar jednostki alokacji.
Szczegółowe wyjaśnienie
Dlaczego to się dzieje? Cóż, system plików FAT32 musi śledzić, gdzie jest przechowywany każdy plik. Gdyby zachował listę każdego bajtu, tabela (podobnie jak książka adresowa) rosłaby z taką samą prędkością jak dane - i marnowałaby dużo miejsca. Dlatego używają „jednostek alokacji”, znanych również jako „rozmiar klastra”. Wolumen jest podzielony na te jednostki alokacji, a jeśli chodzi o system plików, nie można ich podzielić - są to najmniejsze bloki, które może adresować. Podobnie jak numer domu, ale listonosz nie dba o to, ile masz sypialni ani kto w nich mieszka.
Więc co się stanie, jeśli masz bardzo mały plik? Cóż, system plików nie dba o to, czy plik ma rozmiar 0 KB, 2 KB czy nawet 15 KB, da mu najmniej miejsca, jakie może - w powyższym przykładzie to 32 KB. Twój plik wykorzystuje tylko niewielką ilość tego miejsca, a reszta jest w zasadzie zmarnowana, ale nadal należy do pliku - podobnie jak sypialnia, którą pozostawiasz pustą.
Dlaczego istnieją różne rozmiary jednostek alokacji? Cóż, staje się to kompromisem między posiadaniem większego stołu (książka adresowa, np. Mówiąc, że John jest właścicielem domu przy 123 Fake Street, 124 Fake Street, 666 Satan Lane itp.) Lub bardziej zmarnowanym miejscem w każdej jednostce (domu) . Jeśli masz większe pliki, bardziej sensowne jest użycie większych jednostek alokacji - ponieważ plik nie otrzymuje nowej jednostki (domu), dopóki wszystkie inne nie zostaną zapełnione. Jeśli masz dużo małych plików, cóż, i tak będziesz mieć duży stół (książkę adresową), więc równie dobrze możesz dać im małe jednostki (domy).
Duże jednostki alokacji z reguły marnują dużo miejsca, jeśli masz dużo małych plików. Zwykle nie ma powodu, aby przekraczać 4 KB do użytku ogólnego.
Podział?
Jeśli chodzi o fragmentację, fragmentacja nie powinna w ten sposób marnować miejsca. Duże pliki mogą być pofragmentowane, tj. Podzielone na wiele jednostek alokacji, ale każda jednostka powinna zostać zapełniona przed rozpoczęciem następnej. Defragmentacja może zaoszczędzić trochę miejsca w tabelach alokacji, ale to nie jest twój konkretny problem.
Możliwe rozwiązania
Tak jak sugerował gladiator2345 , jedynymi realnymi opcjami w tej chwili jest życie z tym lub przeformatowanie z mniejszymi jednostkami alokacji.
Twoja karta może być sformatowana w systemie FAT16, który ma mniejszy limit rozmiaru tabeli i dlatego wymaga znacznie większych jednostek alokacji w celu zaadresowania większego wolumenu (z górnym limitem 2 GB z jednostkami alokacji 32 KB). Źródło dzięki uprzejmości Braiam . W takim przypadku i tak powinieneś być w stanie bezpiecznie sformatować jako FAT32.
Masz coś do dodania do wyjaśnienia? Dźwięk w komentarzach. Chcesz przeczytać więcej odpowiedzi od innych zaawansowanych technicznie użytkowników Stack Exchange? Sprawdź cały wątek dyskusji tutaj .
