Чому існує така велика різниця між "Розмір" та "Розмір на диску"?

Як ви бачите нижче, різниця між розміром та розміром на дискових полях у моїй папці є стільки різниці . Чому так?

Я знаю, що розмір на диску повинен бути трохи більше, ніж розмір через розміщення одиниць в Windows, але чому це велика різниця? Це може бути через велику кількість файлів?

До речі, ця папка знаходиться на SD-картці мого телефону Android. Всередині цього додатка мої карти зберігає кешовані карти, і програма отримує свою карту з Карт Google.

^{Я буду вважати, що ви використовуєте тут файлову систему FAT / FAT32, оскільки ви згадуєте про це SD-карту. NTFS та exFAT поводяться аналогічно щодо одиниць розподілу. Інші файлові системи можуть бути різними, але вони все одно не підтримуються в Windows.}

Якщо у вас багато невеликих файлів, це, безумовно, можливо. Врахуйте це:

• 50 000 файлів.

• Розмір кластера 32 кБ (одиниці розподілу), що є максимумом для FAT32

Ок, зараз мінімальний простір займає 50 000 * 32 000 = 1,6 ГБ (використовуючи префікси SI, а не двійкові, щоб спростити математику). Простір, який кожен файл займає на диску, завжди є кратним розміру одиниці розподілу - і тут ми припускаємо, що кожен файл насправді достатньо малий, щоб вміститися в одному блоці, з деяким (витраченим) простором.

Якщо кожен файл в середньому становив 2 кБ, ви отримували б приблизно 100 МБ, але ви також витрачаєте в середньому 15 разів (30 кБ на файл) внаслідок розміру одиниці розподілу.

Поглиблене пояснення

Чому це відбувається? Що ж, файлова система FAT32 повинна відслідковувати, де зберігається кожен файл. Якби вести список кожного байта, таблиця (як адресна книга) зростала б із тією ж швидкістю, що й дані - і витрачала б багато місця. Тому вони використовують "розподільні одиниці", також відомі як "розмір кластера". Об'єм розділений на ці одиниці розподілу, і що стосується файлової системи, то їх не можна розділити - це найменші блоки, на які він може звертатися. Так само, як у вас номер будинку, але вашому пошталью не важливо, скільки у вас є спалень або хто проживає в них.

То що буде, якщо у вас дуже маленький файл? Що ж, файлова система не хвилює, якщо файл становить 0 кБ, 2 кБ або навіть 15 кБ, це дасть йому найменше місця - в прикладі вище, це 32 кБ. Ваш файл використовує лише невелику кількість цього простору, а решта в основному витрачається даремно, але все-таки належить до файлу - так само, як спальня, яку ви залишаєте незайнятою.

Чому існують різні розміри розподільної одиниці? Ну, це стає компромісом між великим столом (адресною книгою, наприклад, говорять, що Джон володіє будинком на 123 Fake Street, 124 Fake Street, 666 Satan Lane тощо), або більше витраченого місця в кожній одиниці (будинку). Якщо у вас є більші файли, є більш доцільним використовувати більші одиниці розподілу, оскільки файл не отримує новий блок (будинок), поки всі інші не заповняться. Якщо у вас багато невеликих файлів, то ви все одно матимете велику таблицю (адресну книгу), і це може також дати їм невеликі одиниці (будинки).

Великі одиниці розподілу, як правило, витратять багато місця, якщо у вас багато невеликих файлів. Зазвичай не є вагомою причиною для загального використання вище 4 кБ.

Фрагментація?

Що стосується фрагментації, то фрагментація не повинна витрачати місця таким чином. Великі файли можуть бути фрагментовані, тобто розділені на кілька розподільних одиниць, але кожну одиницю слід заповнити до початку наступного. Відморожування може заощадити небагато місця в таблицях розподілу, але це не ваша конкретна проблема.

Можливі рішення

Як запропонував gladiator2345 , на даний момент ваші єдині реальні варіанти - жити з ним або переформатувати з меншими одиницями розподілу.

Ваша картка може бути відформатована у FAT16, яка має менший ліміт розміру таблиці, а тому потребує набагато більших розмірів одиниць розподілу для вирішення більшого обсягу (з верхньою межею 2 ГБ з 32 кБ). Джерело люб’язно надано Браяму . Якщо це так, ви все одно можете мати можливість безпечно форматувати FAT32.

Це одна з тих ситуацій, коли стиснення / архівування в один файл може допомогти. Те, що сказав Боб у своїй відповіді, є правдою, але рішення може бути простішим, ніж реформація диска, як підказують інші відповіді. Якщо ви стискаєте або архівуєте каталог (використовуючи zip, tar або будь-який інший метод), файлова система побачить, що у вас є один великий файл, а не кілька менших. Навіть не стискаючи, ви отримаєте майже 1,4 Гб простору назад, тому що всі ці "маленькі файли" будуть рахуватися як один великий файл.

Всередині цього додатка мої карти зберігає кешовані карти, і програма отримує свою карту з Карт Google

Можливо, вам слід поговорити з розробником, щоб використовувати архів або базу даних замість кількох файлів. Це, ймовірно, також допоможе зробити диск менш фрагментарним і, безумовно, заощадить місце, особливо якщо це флешка NAND. Якщо ви поясните смішну ситуацію, коли 100 Мб корисного навантаження / корисних даних стає 1,4 Гбіт, щось не так у тому, як зберігаються дані, і розробники повинні запропонувати приємніше рішення.

Якщо хтось стикається з цією проблемою, може бути корисним також знати, що ще одна причина бачити велику різницю у розмірі / просторі файлів на диску - це використання альтернативних потоків даних (ADS)

Це стосується лише NTFS, наскільки мені відомо. ADS відомі як законним, так і не законним використанням:

• для позначення файлу, завантаженого з Інтернету
• для зберігання метаданих (Microsoft хотіла включити деякі функції Apple OS, наприклад, не використовувати розширення файлу для визначення типу файлу)
• щоб приховати дані чи код у контексті зловмисного програмного забезпечення .

ADS просто: будь-який файл NTFS може вміщувати декілька потоків даних (розуміти "підфайли"). Один - це основний потік, який використовується Провідником Windows та іншими інструментами Windows, він містить звичайний вміст файлу. Альтернативні потоки даних можуть містити іншу інформацію, точно як основний потік, але з ними не можна керувати безпосередньо інструментами Windows (зокрема, Explorer відображає розмір файлу, рівний розміру основного потоку, незалежно від розміру ADS), вам потрібно використовувати спеціалізовані інструменти або код для запису, читання та пошуку ADS.

Головний момент - у випадку, якщо спостерігається велика різниця у розмірі файлу, не забувайте про можливість ADS та прихованого шкідливого ПЗ.

Ще одне посилання .

Щоб безпечно експериментувати з ADS, спробуйте це на рівні DOS / CMD ...

Створіть, а потім покажіть вміст файлу в корені C:

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

Результат:

C:\> The main data stream

Тепер додайте ADS тим же методом, просто вкажіть назву ADS на додаток до імені файлу:

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

Ви щойно приховали секретне повідомлення у файлі. Зауважте, що розмір файлу в Провіднику не змінився, незважаючи на те, що ми додали байти в ADS "секрет".

Спробуйте відобразити вміст ADS:

C:\> type test.txt:secret

Результат:

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

CMD typeне в змозі відображати вміст ADS. Замість цього ми використовуватимемо Блокнот:

notepad test.txt:secret

У Блокноті ми бачимо вміст рекламних оголошень:

The secret message

Ви також можете сховати повний виконуваний файл в ADS невинного текстового файлу та запустити його в будь-який час. Багатство не шкодить хакерам :-)

Проблема може бути через розмір кластера.

За даними Microsoft :

Якщо ви не використовуєте стиснення NTFS для жодних файлів або папок, що містяться в томі, різниця між SIZE та SIZE ON DISK втрачає витрачений простір через більший за необхідний розмір кластера. Спробуйте використати оптимальний розмір кластера, щоб значення SIZE ON DISK було максимально наближеним до значення SIZE. Надмірна розбіжність між розміром SIZE ON DISK і значення SIZE є свідченням того, що розмір кластера за замовчуванням занадто великий для середнього розміру файлу, який ви зберігаєте на томі, і що його слід зменшити. Це можна зробити, лише створивши резервну копію гучності і потім переформатувавши гучність, використовуючи команду форматування та перемикач / a, щоб вказати відповідний розмір розподілу: IE: format D: /a:2048 (У цьому прикладі використовується розмір кластера 2 КБ).

Спробуйте відформатувати диск з меншим розміром кластера.

Я бачу, що багато людей рекомендують переформатувати диск з меншим розміром кластера. Оскільки це SD-карта, зауважте, що багато постачальників попередньо відформатують карту до рекомендованого розміру кластеру, щоб відповідати розміру кластеру розміру NAND (синхронізація обох дуже важлива для оптимальної продуктивності читання / запису та зменшення зносу)

Ви не можете змінити розмір кластера NAND (це фізичний атрибут обладнання вашої SD-карти).

Спершу запустіть scandisk / chkdsk на SD-картці, щоб переконатися, що проблема звіту про розмір не лежить у пошкодженій файловій системі.

По-друге, я б запропонував вам повідомити про помилку в програмі Google Map devs, і саме вони тут винні. Вони повинні використовувати чудовий спосіб зберігання. Виправлення це також повинно змусити програму працювати швидше на багатьох пристроях через меншу активність вводу-виводу та драйвера файлової системи.

Це загальна проблема з багатьма файловими системами. Тут працюють два фактори: максимальна кількість "блоків", яку файлова система може обробляти відповідно до логічного обсягу та фізичних обмежень носія інформації. До будь-якого блоку можна виділити лише 1 файл (файли зазвичай займають стільки блоків, скільки потрібно). Таким чином, текстовий файл із 64 байтами часто може займати що-небудь від 4k до 32k, залежно від розміру блоку файлової системи, на якій він знаходиться.

Один із способів подумати над цим - це уявити кожен блок у файловій системі як поле, а файлову систему - як приміщення. Всі ваші коробки однакового розміру, і ви намагаєтесь помістити стільки, скільки зможете в кімнаті. Якщо ви вмістите їх усе, що залишилося більше місця, вам доведеться отримати більші ящики, щоб кімната була повністю заповнена ящиками.

Одне з правил складання речей у коробки - це те, що ви не можете помістити дві непов'язані речі у коробку. Вони повинні бути частиною одного документа. Тож якби я набрав сторінку тексту, вона мала б це власне поле. Якби в моєму набраному тексті було стільки сторінок, я не міг би вмістити все це в одне поле, я просто знайшов би інше поле і продовжував вводити там сторінки, повторюючи, поки не подав усі свої сторінки. Я також записав би поля, які використовував для цього документа, і порядок скриньки, щоб прочитати його послідовно.

Залежно від того, як я б організував ящики, я можу мати достатньо місця у своєму маніфесті для певної кількості скриньок. Тож якби у мене була велика кімната для заповнення, але лише невелика кількість ящиків, я повинен був використовувати дуже великі ящики, щоб досягти місткості приміщення.

Тож у такому випадку мій документ на одній сторінці все ще займатиметься одним вікном, і більше нічого не ділиться ним.

Такі самі ситуації виникають серед різних рішень для зберігання даних. FAT32 може керувати лише тим, що вважається низькою кількістю "коробок" на сьогоднішніх величезних жорстких дисках, тож він компенсує це дуже великими "коробками".

Крім розмірів кластерів, ви також можете мати розбіжність через такі умови:

• Стислі або зашифровані файли можуть займати інший простір, ніж розмір логічного файлу.
• Пов'язані файли повідомлять n разів більше посилань, розмірів файлу, розміру логічного файлу, але фізичний простір, що використовується, зазвичай менший.

Ви повинні ознайомитись із записом Блокування субалокації у Вікіпедії. Саме це з вами відбувається. Використання файлової системи з підтримкою упаковки Tail - це рішення на рівні файлової системи для цієї проблеми, крім зміни розміру кластеру розподілу.

Усі мають незручні потреби переформатувати диск.

У деяких випадках просто зберігання цих файлів в архіві вирішило б проблему (а невеликі файли також були б стиснуті поруч із зупинкою втрати місця в кінці файлів). Це незручно витрачати певний час на декомпресію.

Інший варіант, якщо у вас стільки невеликих файлів через певну проблему, пов’язану з додатком, - це зберігання ваших програмних даних за допомогою іншого методу (можливо, у базі даних). Але звичайно це рішення для програмістів, а не для кінцевих користувачів.

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

Я відмітив величезні розбіжності розмірів файлів у Windows 10 на окремому файлі, але якщо я дивлюся на властивості файлу SAME з того самого місця (мережевого накопичувача), у Windows XP, великої розбіжності немає; лише невелика різниця, яку ви очікуєте. Я думаю, що в Windows 10. є помилка. Файл розміром 449 Мб, ймовірно, не займає 3,99 ГБ, про що мені розповідає Windows 10.