Dlaczego istnieje tak duża różnica między „rozmiarem” a „rozmiarem na dysku”?

Jak widać poniżej, istnieje ogromna różnica między rozmiarem i rozmiarem na polach dysku w moim folderze. Dlaczego?

Wiem, że rozmiar na dysku powinien być nieco większy niż rozmiar ze względu na jednostki alokacji w systemie Windows, ale dlaczego 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 tego moja aplikacja map przechowuje swoje buforowane mapy, a aplikacja pobiera swoją mapę z Google Maps.

^{Zakładam, że używasz tutaj systemu plików FAT / FAT32, ponieważ wspominasz, ż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 minimalna zajmowana przestrzeń to 50 000 * 32 000 = 1,6 GB (użycie prefiksów SI, a nie binarnych, aby uprościć matematykę). Przestrzeń, jaką każdy plik zajmuje na dysku, jest zawsze wielokrotnością wielkości jednostki alokacji - i tutaj zakładamy, że każdy plik jest wystarczająco mały, aby zmieścił się w jednej jednostce, z pozostałą (zmarnowaną) przestrzenią.

Jeśli każdy plik ma średnio 2 kB, uzyskasz łącznie około 100 MB - ale marnujesz także 15x (30 kB na plik) średnio ze względu na rozmiar jednostki alokacji.

Szczegółowe wyjaśnienie

Dlaczego to się dzieje? System plików FAT32 musi śledzić miejsce przechowywania każdego pliku. Gdyby miał zachować listę każdego bajtu, tabela (podobnie jak książka adresowa) rozwijałaby się z tą samą prędkością co dane - i marnowałaby dużo miejsca. Dlatego używają „jednostek alokacji”, zwanych również „rozmiarem klastra”. Wolumin 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żna rozwiązać. Podobnie jak masz numer domu, ale listonosz nie dba o to, ile masz sypialni i kto w nich mieszka.

Co się stanie, jeśli masz bardzo mały plik? System plików nie dba o to, czy plik ma 0 kB, 2 kB, a nawet 15 kB, da mu najmniej miejsca, jakie może - w powyższym przykładzie jest to 32 kB. Twój plik zajmuje tylko niewielką ilość tego miejsca, a reszta jest zasadniczo zmarnowana, ale nadal należy do pliku - podobnie jak sypialnia, którą opuszczasz.

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.), Albo więcej zmarnowanego miejsca w każdej jednostce (domu). Jeśli masz większe pliki, sensowniejsze jest użycie większych jednostek alokacji - ponieważ plik nie otrzymuje nowej jednostki (domu), dopóki wszystkie inne nie zostaną wypełnione. Jeśli masz dużo małych plików, to i tak będziesz mieć duży stół (książkę adresową), więc możesz również 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 dobrego powodu, aby przekraczać 4 kB do ogólnego użytku.

Podział?

Jeśli chodzi o fragmentację, fragmentacja nie powinna marnować miejsca w ten sposób. Duże pliki mogą być pofragmentowane, tj. Podzielone na wiele jednostek alokacji, ale każda jednostka powinna zostać wypełniona przed uruchomieniem następnej. Defragmentacja może zaoszczędzić trochę miejsca w tabelach alokacji, ale to nie jest twój konkretny problem.

Możliwe rozwiązania

Jak sugeruje gladiator2345 , jedynymi prawdziwymi opcjami w tym momencie są życie z nim lub formatowanie przy użyciu mniejszych jednostek alokacji.

Twoja karta może być sformatowana w systemie plików FAT16, który ma mniejszy limit wielkości tabeli i dlatego wymaga znacznie większych jednostek alokacji w celu zajęcia się większym wolumenem (z górnym limitem 2 GB z jednostkami alokacji 32 kB). Źródło dzięki uprzejmości Braiam . W takim przypadku powinieneś być w stanie bezpiecznie sformatować jako FAT32.

Jest to jedna z tych sytuacji, w których kompresja / archiwizacja w jednym pliku może pomóc. To, co powiedział Bob w swojej odpowiedzi, jest prawdą, ale rozwiązanie może być łatwiejsze niż sformatowanie dysku, jak sugerują inne odpowiedzi. Jeśli skompresujesz lub zarchiwizujesz katalog (używając zip, tar lub innej metody), system plików zobaczy, że masz jeden duży plik zamiast kilku mniejszych. Nawet bez kompresji odzyskasz prawie 1,4 GiB miejsca, ponieważ wszystkie te „małe pliki” będą liczone jako jeden duży plik.

Wewnątrz tego moja aplikacja map przechowuje swoje buforowane mapy, a aplikacja pobiera swoją mapę z Google Maps

Może powinieneś porozmawiać z deweloperem, aby użyć archiwum lub bazy danych zamiast wielu plików. Pomoże to prawdopodobnie zmniejszyć fragmentację dysku i na pewno pozwoli zaoszczędzić miejsce, zwłaszcza jeśli jest to dysk flash NAND. Jeśli wyjaśnisz absurdalną sytuację, w której 100 MB ładunku / przydatnych danych zmienia się na 1,4 GiB, coś jest nie tak z tym, jak dane są przechowywane, a programiści powinni zaproponować lepsze rozwiązanie.

W przypadku, gdy ktoś napotka ten problem, warto również wiedzieć, że kolejnym powodem, dla którego można zobaczyć dużą różnicę w rozmiarze pliku / przestrzeni na dysku, jest użycie alternatywnych strumieni danych (ADS)

Według mojej wiedzy dotyczy to tylko NTFS. Reklamy są znane zarówno z dozwolonych, jak i niezgodnych z prawem zastosowań:

• aby oznaczyć plik jako pobrany z Internetu
• do przechowywania metadanych (Microsoft chciał uwzględnić niektóre funkcje systemu Apple OS, takie jak nieużywanie rozszerzenia pliku do określania typu pliku)
• aby ukryć dane lub kod w kontekście złośliwego oprogramowania .

ADS po prostu: każdy plik NTFS może przechowywać wiele strumieni danych (rozumie się „podfile”). Jednym z nich jest główny strumień używany przez Eksploratora Windows i inne narzędzia Windows, który przechowuje zwykłą zawartość pliku. Alternatywne strumienie danych mogą zawierać inne informacje, dokładnie jak główny strumień, ale nie mogą być obsługiwane bezpośrednio przez narzędzia Windows (w szczególności Eksplorator wyświetla rozmiar pliku równy rozmiarowi głównego strumienia, niezależnie od wielkości ADS), musisz używać specjalistycznych narzędzi lub kodu do pisania, czytania i lokalizowania ADS.

Chodzi przede wszystkim o to, że w przypadku zaobserwowanej dużej różnicy wielkości pliku, nie przeocz możliwości ADS i ukrytego złośliwego oprogramowania.

Kolejny link .

Aby bezpiecznie eksperymentować z ADS, wypróbuj to na poziomie DOS / CMD ...

Utwórz, a następnie wyświetl zawartość pliku w katalogu głównym C:

C:\> echo The main data stream> test.txt
C:\> type test.txt

Wynik:

C:\> The main data stream

Teraz dodaj ADS tą samą metodą, po prostu podaj nazwę ADS oprócz nazwy pliku:

C:\> echo The secret message> test.txt:secret

Właśnie ukryłeś tajną wiadomość w pliku. Zauważ, że rozmiar pliku w Eksploratorze nie zmienił się pomimo dodania bajtów w „tajnym” ADS.

Spróbuj wyświetlić zawartość ADS:

C:\> type test.txt:secret

Wynik:

The filename, directory name, or volume label syntax is incorrect.

CMD typenie jest w stanie wyświetlić zawartości ADS. Zamiast tego użyjemy Notatnika:

notepad test.txt:secret

W Notatniku możemy zobaczyć zawartość ADS:

The secret message

Możesz również ukryć pełny plik wykonywalny w ADS niewinnego pliku tekstowego i uruchomić go w dowolnym momencie. Bogactwo nie szkodzi hakerom :-)

Problem może wynikać z rozmiaru klastra.

Według Microsoft :

Jeśli nie używasz kompresji NTFS do żadnych plików lub folderów zawartych w woluminie, różnica między SIZE a SIZE ON DISK to marnowane miejsce z powodu większego niż to konieczne rozmiaru klastra. Powinieneś spróbować użyć optymalnego rozmiaru klastra, aby wartość SIZE ON DISK była jak najbliższa wartości SIZE. Nadmierna rozbieżność między SIZE ON DISK a wartością SIZE wskazuje, że domyślny rozmiar klastra jest zbyt duży w stosunku do średniego rozmiaru pliku przechowywanego na woluminie i że należy go zmniejszyć. Można to zrobić tylko poprzez utworzenie kopii zapasowej woluminu, a następnie sformatowanie woluminu za pomocą polecenia format i przełącznika / a w celu określenia odpowiedniego rozmiaru alokacji: IE: format D: /a:2048 (W tym przykładzie użyto rozmiaru klastra o wielkości 2 KB).

Spróbuj sformatować dysk przy użyciu mniejszego rozmiaru klastra.

Widzę wiele osób, które zalecają sformatowanie dysku przy użyciu mniejszego rozmiaru klastra. Ponieważ jest to karta SD, należy pamiętać, że wielu dostawców wstępnie formatuje kartę do zalecanego rozmiaru klastra, aby dopasować go do rozmiaru klastra NAND (utrzymanie synchronizacji obu jest bardzo ważne dla optymalnej wydajności odczytu / zapisu i zmniejszenia zużycia)

Nie możesz zmienić rozmiaru klastra NAND (jest to fizyczny atrybut sprzętu karty SD).

Najpierw uruchom scandisk / chkdsk na karcie SD, aby upewnić się, że problem z raportem rozmiaru nie leży w uszkodzonym systemie plików.

Po drugie, sugeruję, abyś zgłosił błąd twórcom Google Map, którzy są tutaj winni. Powinny stosować lepszą metodę przechowywania. Naprawienie go powinno także sprawić, że aplikacja będzie działać szybciej na wielu urządzeniach ze względu na mniejszą liczbę operacji we / wy i sterowników systemu plików.

Jest to ogólny problem dotyczący wielu systemów plików. Działają tutaj dwa czynniki: maksymalna liczba „bloków”, które system plików może obsłużyć na wolumin logiczny i ograniczenia fizyczne nośnika pamięci. Tylko jeden plik może być przypisany do dowolnego bloku (pliki zwykle zajmują tyle bloków, ile potrzebują). Tak więc plik tekstowy z 64 bajtami często może zająć od 4k do 32k, w zależności od wielkości bloku systemu plików, w którym się znajduje.

Jednym ze sposobów myślenia o tym jest myślenie o każdym bloku w systemie plików jak o pudełku, a system plików o pokoju. Wszystkie twoje pudełka są tego samego rozmiaru, a ty próbujesz zmieścić jak najwięcej w pokoju. Jeśli zmieścisz je wszystkie, pozostawiając więcej miejsca, musisz zdobyć większe pudełka, aby pokój był całkowicie wypełniony pudełkami.

Jedną z zasad umieszczania rzeczy w pudełkach jest to, że nie można umieścić dwóch niepowiązanych rzeczy w pudełku. Muszą być częścią tego samego dokumentu. Więc gdybym napisał stronę tekstu, miałby własne pole. Gdyby mój wpisany tekst zawierał tak wiele stron, że nie zmieściłbym się w jednym polu, po prostu znajdowałbym inne pole i kontynuowałbym umieszczanie tam stron, powtarzając do momentu wypełnienia wszystkich stron. Zapisałbym również pola, których użyłem dla tego dokumentu, i kolejność pól, aby przeczytać je kolejno.

W zależności od tego, jak zorganizuję skrzynki, w moim manifeście mogę mieć wystarczająco dużo miejsca na określoną liczbę pudeł. Więc gdybym miał duży pokój do wypełnienia, ale tylko niewielką liczbę pudeł, musiałbym użyć bardzo dużych pudełek, aby osiągnąć pojemność pokoju.

W takim przypadku mój jednostronicowy dokument nadal zajmowałby jedno pudełko i nic innego go nie udostępniał.

Te same sytuacje mają miejsce w różnych rozwiązaniach do przechowywania. FAT32 może zarządzać tylko niewielką liczbą „pudeł” na dzisiejszych ogromnych dyskach twardych, więc kończy się to bardzo dużymi „pudełkami”, aby to zrekompensować.

Oprócz rozmiarów klastra możesz mieć również rozbieżności z powodu następujących warunków:

• Pliki skompresowane lub zaszyfrowane mogą zajmować miejsce inne niż rozmiar pliku logicznego.
• Połączone pliki będą raportować n razy liczbę łączy razy rozmiar pliku dla logicznego rozmiaru pliku, ale zwykle używana przestrzeń fizyczna jest mniejsza.

Powinieneś rzucić okiem na wpis Blokuj alokację w Wikipedii. Właśnie to się z tobą dzieje. Korzystanie z systemu plików z obsługą Tail Packaging jest rozwiązaniem tego problemu na poziomie systemu plików oprócz zmiany rozmiaru klastra alokacji.

Wszystkie mają niewygodną potrzebę formatowania dysku.

W niektórych przypadkach samo przechowywanie tych plików w archiwum rozwiązałoby problem (a małe pliki byłyby również skompresowane obok zatrzymania utraty miejsca na końcu plików). Jest to niewygodne w spędzaniu czasu na dekompresję.

Inną opcją, jeśli masz tak wiele małych plików z powodu określonego problemu związanego z aplikacją, jest przechowywanie danych oprogramowania za pomocą innej metody (może znajdować się w bazie danych). Ale oczywiście jest to rozwiązanie dla programistów, a nie użytkowników końcowych.

http://en.wikipedia.org/wiki/Tail_packing

Zauważyłem ogromne rozbieżności wielkości pliku w systemie Windows 10 w pojedynczym pliku, ale jeśli spojrzę na właściwości pliku SAME z tej samej lokalizacji (dysku sieciowego), w systemie Windows XP, nie ma dużej rozbieżności; tylko niewielka różnica, której można się spodziewać. Myślę, że w systemie Windows 10 jest błąd. Plik o wielkości 449 MB prawdopodobnie nie zajmuje 3,99 GB, co mówi mi Windows 10.