Чому існує велика різниця між «розміром» і «розміром на диску»?
Велику частину часу значення для "Size" (Розмір) і "Size on disk" (Розмір на диску) будуть дуже близькими до відповідності під час перевірки розміру папки або файлу, але що, якщо існує величезне розходження між ними? Сьогоднішня посада SuperUser Q & A розглядає відповідь на цю проблему.
Сьогоднішня сесія запитань та відповідей приходить до нас люб'язно SuperUser - підрозділ Stack Exchange, групування веб-сайтів із запитаннями та відповідями на рівні спільноти..
Питання
Читач SuperUser thelastblack хоче знати, чому існує така велика різниця між "Size" і "Size on disk" для папки на SD-карті свого телефону:
Як ви можете бачити нижче, існує велика різниця між полями "Розмір" і "Розмір на диску" для цієї папки. Чому так?
Я знаю, що "Розмір на диску" має бути трохи більшим, ніж "Розмір" через розподільні одиниці в Windows, але чому існує велика різниця? Це може бути через велику кількість файлів?
Нарешті, ця папка знаходиться на SD-карті мого телефону Android. Всередині цієї програми мої карти зберігають свої кешовані карти, і програма отримує свої карти з Карт Google.
Дивлячись на знімок екрана, існує величезна розбіжність між "Розмір" і "Розмір на диску", так що сталося тут, щоб викликати це?
Відповідь
Співробітник SuperUser Боб має відповідь для нас:
Я припускаю, що ви використовуєте файлову систему FAT / FAT32 тут, оскільки ви згадали, що це SD-карта. NTFS і exFAT поводяться аналогічно щодо розподільних одиниць. Інші файлові системи можуть відрізнятися, але вони не підтримуються у Windows.
Якщо у вас багато невеликих файлів, це, безумовно, можливо. Розгляньте це:
- 50 000 файлів
- Розмір кластера 32 Кб (розподільні одиниці), що є максимальним для FAT32
Добре, тепер мінімум простір займає 50 000 * 32 000 = 1,6 ГБ (використовуючи префікси СІ, а не двійкові, щоб спростити математику). Простір кожного файлу на диску завжди кратний розміру одиниці виділення - і тут ми припускаємо, що кожен файл є достатньо малим, щоб поміститися в межах однієї одиниці..
Якщо кожен файл складав 2 КБ, ви отримали б близько 100 МБ, але ви також витрачаєте 15x, що (30 Кб на файл) в середньому через розмір одиниці розміщення.
Поглиблене пояснення
Чому це відбувається? Файлова система FAT32 повинна відстежувати, де зберігається кожен файл. Якщо б він містив список кожного окремого байта, таблиця (як адресна книга) зростала б з тією ж швидкістю, що й дані - і витрачала б багато місця. Отже, що вони роблять, це використання “розподільних одиниць”, також відомих як “розмір кластера”. Обсяг ділиться на ці розподільні одиниці, і що стосується файлової системи, вони не можуть бути розділені - це найменші блоки, до яких він може звертатися. Багато чого, як у вас є номер будинку, але ваш поштальн не хвилює, скільки спалень у вас є або хто живе в них.
Так що ж станеться, якщо у вас дуже маленький файл? Ну, файлова система не хвилює, якщо файл становить 0 Кбайт, 2 Кб, або навіть 15 Кб, це дасть йому найменший простір, який він може - у наведеному вище прикладі це 32 Кб. Файл використовує лише невелику кількість цього простору, а решту в основному даремно, але все ще належить до файлу - подібно до спальні, яку ви залишили незайнятими.
Чому існують різні розміри блоків розподілу? Ну, це стає компромісом між наявністю більшої таблиці (адресна книга, наприклад, що Джон володіє будинком у 123 Fake Street, 124 Fake Street, 666 Satan Lane і т.д.), або більше витраченого місця в кожній одиниці (будинку) . Якщо у вас є великі файли, має сенс використовувати великі одиниці розподілу - тому що файл не отримує нову одиницю (дому), поки всі інші не будуть заповнені. Якщо у вас є багато невеликих файлів, то ви все одно матимете великий стіл (адресну книгу), тому можете також надати їм невеликі одиниці (будинки).
Великі розподільні одиниці, як правило, витратять багато місця, якщо у вас багато невеликих файлів. Зазвичай, не існує вагомих причин перевищувати 4 Кб для загального користування.
Фрагментація?
Що стосується фрагментації, фрагментація не повинна витрачати простір таким чином. Великі файли можуть бути фрагментовані, тобто розділені на декілька одиниць розподілу, але кожна одиниця повинна бути заповнена до початку наступного. Дефрагментація може заощадити трохи місця в таблицях розподілу, але це не є вашим конкретним питанням.
Можливі рішення
Як запропонував gladiator2345, ваші єдині реальні варіанти на цьому етапі - жити з ним або переформатувати з меншими одиницями розподілу.
Ваша картка може бути відформатована у FAT16, яка має менший розмір на розмір таблиці і тому вимагає набагато більших розподільних одиниць для вирішення більшого обсягу (з верхньою межею 2 ГБ з 32 КБ виділення). Джерело люб'язно надане Braiam. Якщо це так, ви повинні бути в змозі безпечно форматувати FAT32 в будь-якому випадку.
Маєте щось додати до пояснення? Звучить в коментарях. Хочете прочитати більше відповідей від інших технологічних користувачів Stack Exchange? Перегляньте повний потік обговорення тут.
