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 z dużym rozbieżności między nimi? Dzisiejszy post z pytaniami i odpowiedziami dla SuperUser zawiera odpowiedzi na ten mylący problem.
Dzisiejsza sesja pytań i odpowiedzi przychodzi do nas dzięki uprzejmości SuperUser - poddziału Stack Exchange, społecznościowego forum z pytaniami i odpowiedziami.
Czytnik SuperUser thelastblack chce wiedzieć, dlaczego istnieje tak ogromna różnica między "Rozmiar" i "Rozmiar na dysku" dla folderu na karcie SD telefonu:
Jak widać poniżej, jest tak wiele różnic między polami "Rozmiar" i "Rozmiar na dysku" dla tego folderu. Dlaczego?
Wiem, że "Rozmiar na dysku" powinien być nieco większy niż "Rozmiar" z powodu jednostek alokacji w systemie Windows, ale dlaczego jest tak duża różnica? Czy to możliwe z powodu dużej liczby plików?
BTW, ten folder znajduje się na karcie SD mojego telefonu z Androidem. Wewnątrz moja aplikacja do map przechowuje buforowane mapy, a aplikacja pobiera mapy z Map Google.
Patrząc na zrzut ekranu, istnieje zdecydowanie duża rozbieżność między "Rozmiar" i "Rozmiar na dysku", więc co się tutaj stało, aby to spowodować?
Pomocnik SuperUser Bob ma odpowiedź dla nas:
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ą być inne, 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 maksimum dla FAT32
Ok, teraz minimum zajmowana przestrzeń to 50 000 * 32 000 = 1,6 GB (używając prefiksów SI, a nie binarnych, aby uprościć matematykę). Przestrzeń, którą każdy plik przyjmuje na dysku, jest zawsze wielokrotnością rozmiaru jednostki alokacji - i tutaj zakładamy, że każdy plik jest wystarczająco mały, aby zmieścić się w pojedynczej jednostce, z pozostałym (zmarnowanym) miejscem.
Gdyby każdy plik wynosił średnio 2 KB, uzyskałbyś łącznie około 100 MB - ale marnujesz również 15 razy mniej (30 KB na plik) ze względu na rozmiar jednostki alokacji.
Szczegółowe objaśnienie
Dlaczego to się dzieje? Cóż, system plików FAT32 musi śledzić położenie każdego pliku. Gdyby zachować listę wszystkich pojedynczych bajtów, tabela (podobnie jak książka adresowa) rozwijałaby się z taką samą prędkością, jak dane - i marnowała dużo miejsca. Więc to, co robią, to używać "jednostek alokacji", zwanych także "rozmiarem 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, do których można się odnieść. Podobnie jak masz numer domu, ale listonosz nie dba o to, ile masz sypialni lub kto w nich mieszka.
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, zapewni mu jak najmniej przestrzeni - w powyższym przykładzie to 32 KB. Twój plik wykorzystuje tylko niewielką część tej przestrzeni, a reszta jest w zasadzie zmarnowana, ale wciąż należy do pliku - podobnie jak sypialnia, którą pozostawiasz niezajętym.
Dlaczego istnieją różne rozmiary jednostek alokacji? Cóż, staje się kompromisem między posiadaniem większego stołu (książki adresowej, np. Mówiąc, że John jest właścicielem domu przy 123 Fake Street, 124 Fake Street, 666 Satan Lane, itp.) Lub więcej marnowanego miejsca w każdej jednostce (domu) . Jeśli masz większe pliki, lepiej jest użyć większych jednostek alokacji - ponieważ plik nie dostaje nowej jednostki (domu), dopóki wszystkie pozostałe nie zostaną wypełnione. Jeśli masz dużo małych plików, to i tak będziesz miał 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, będą marnować dużo miejsca, jeśli masz dużo małych plików. Zwykle nie ma dobrego powodu, aby przekraczać 4 kB do ogólnego użytku.
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ć wypełniona przed następnym uruchomieniem. Defragmentacja może zaoszczędzić trochę miejsca w tabelach alokacji, ale nie jest to twój konkretny problem.
Możliwe rozwiązania
Zgodnie z sugestią gladiatora2345, jedyne prawdziwe opcje w tym momencie to przeżycie z nim lub sformatowanie za pomocą mniejszych jednostek 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 adresowania większej objętości (z górnym limitem 2 GB z jednostkami alokacyjnymi 32 KB). Źródło dzięki uprzejmości Braiam. Jeśli tak jest, powinieneś być w stanie bezpiecznie sformatować jako FAT32.
Czy masz coś do dodania do wyjaśnienia? Dźwięk w komentarzach. Chcesz przeczytać więcej odpowiedzi od innych użytkowników Stack Exchange, którzy znają się na technologii? Sprawdź cały wątek dyskusji tutaj.
