Почему такая большая разница между «Размер» и «Размер на диске»?

Как вы можете видеть ниже, между полями « Размер» и « Размер» в моей папке очень много различий . Почему это?

Я знаю, что размер на диске должен быть немного больше, чем размер из-за выделения единиц в Windows, но почему такая большая разница? Может ли это быть из-за большого количества файлов?

Кстати, эта папка находится на SD-карте моего телефона Android. В этом приложении мое карты хранит свои кэшированные карты, а приложение получает свою карту из Google Maps.

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

Если у вас много маленьких файлов, это, безусловно, возможно. Учти это:

• 50000 файлов.

• Размер кластера 32 кБ (единицы выделения), что является максимумом для FAT32

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

Если бы каждый файл занимал в среднем 2 КБ, вы получили бы около 100 МБ общего объема, но вы также теряли в 15 раз больше (30 КБ на файл) в среднем из-за размера единицы размещения.

Подробное объяснение

Почему это происходит? Что ж, файловая система FAT32 должна отслеживать, где хранится каждый файл. Если бы он вел список каждого байта, таблица (например, адресная книга) росла бы с той же скоростью, что и данные, - и тратила бы много места. Поэтому они используют «единицы выделения», также известные как «размер кластера». Том разделен на эти единицы размещения, и что касается файловой системы, они не могут быть разделены - это самые маленькие блоки, которые он может адресовать. Так же, как у вас есть номер дома, но вашему почтальону все равно, сколько у вас спален или кто в них живет.

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

Почему существуют разные размеры единиц размещения? Что ж, это становится компромиссом между наличием большого стола (адресная книга, например, говоря, что Джон владеет домом на 123 Фэйк-стрит, 124 Фэйк-стрит, 666 Сатана-лейн и т. Д.) Или большим количеством неиспользуемого пространства в каждой единице (доме). Если у вас есть файлы большего размера, имеет смысл использовать большие единицы размещения - потому что файл не получает новый блок (дом), пока все остальные не будут заполнены. Если у вас много маленьких файлов, то в любом случае у вас будет большая таблица (адресная книга), поэтому они могут также дать им небольшие блоки (дома).

Большие единицы размещения, как правило, будут занимать много места, если у вас много маленьких файлов. Обычно нет веской причины превышать 4 кБ для общего использования.

Дробление?

Что касается фрагментации, фрагментация не должна тратить пространство таким образом. Большие файлы могут быть фрагментированы, т. Е. Разделены, на несколько единиц размещения, но каждая единица должна быть заполнена до запуска следующей. Дефрагментация может сэкономить немного места в таблицах размещения, но это не ваша конкретная проблема.

Возможные решения

Как и предположил gladiator2345 , на данный момент ваши единственные реальные варианты - жить с ним или переформатировать с меньшими единицами распределения.

Ваша карта может быть отформатирована в FAT16, который имеет меньшее ограничение на размер таблицы и, следовательно, требует гораздо больших единиц выделения для адресации большего объема (с верхним пределом в 2 ГБ с 32 кБ единицами выделения). Источник любезно предоставлен Брайаном . Если это так, вы все равно сможете безопасно форматировать как FAT32.

Это одна из тех ситуаций, когда может помочь сжатие / архивирование в один файл. То, что Боб сказал в своем ответе, верно, но решение может быть проще, чем переформатирование диска, как предлагают другие ответы. Если вы сжимаете или архивируете каталог (используя zip, tar или любой другой метод), файловая система увидит, что у вас есть один большой файл, а не несколько меньших. Даже без сжатия вы получите обратно почти 1,4 ГБ места назад, потому что все эти «маленькие файлы» будут учитываться как один большой файл.

В этом приложении мое карты хранит свои кэшированные карты, а приложение получает свою карту из Google Maps.

Возможно, вам следует обсудить с разработчиком использование архива или базы данных вместо нескольких файлов. Это, вероятно, также поможет сделать диск менее фрагментированным и, безусловно, сэкономит место, особенно если это флэш-накопитель 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

В блокноте мы можем увидеть содержимое ADS:

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-карты).

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

Во-вторых, я бы посоветовал вам сообщить об ошибке разработчикам Google Map, поскольку именно они здесь виноваты. Они должны использовать превосходный метод хранения. Исправление также должно ускорить работу приложения на многих устройствах из-за меньшего количества операций ввода-вывода и активности файловой системы.

Это общая проблема со многими файловыми системами. Здесь действуют два фактора: максимальное количество «блоков», которые файловая система может обработать на логический том, и физические ограничения носителя. Только один файл может быть выделен для любого данного блока (файлы обычно занимают столько блоков, сколько им нужно). Таким образом, текстовый файл с 64 байтами часто может занимать что угодно от 4k до 32k, в зависимости от размера блока файловой системы, в которой он находится.

Один из способов думать об этом - думать о каждом блоке в файловой системе как о блоке, а файловая система - как о комнате. Все ваши коробки имеют одинаковый размер, и вы пытаетесь уместить в комнате столько, сколько сможете. Если вы поместите их все вместе с большим количеством оставшегося места, вы должны получить большие коробки, чтобы комната была полностью заполнена коробками.

Одно из правил размещения вещей в коробках заключается в том, что нельзя помещать две несвязанные вещи в коробку. Они должны быть частью одного и того же документа. Так что, если бы я напечатал страницу текста, у нее была бы своя коробка. Если бы в моем напечатанном тексте было так много страниц, что я не смог бы уместить все это в одном блоке, я просто нашел бы другой блок и продолжал бы вставлять туда страницы, повторяя, пока я не заполню все свои страницы. Я также записал бы ящики, которые я использовал для этого документа, и порядок ящиков, чтобы прочитать его по порядку.

В зависимости от того, как я буду организовывать ящики, в моем манифесте может быть достаточно места только для определенного количества ящиков. Поэтому, если бы у меня была большая комната для заполнения, но только небольшое количество ящиков, я бы использовал очень большие ящики, чтобы достичь вместимости комнаты.

Таким образом, в этом случае мой одностраничный документ по-прежнему занимал бы одно поле, и ничто другое не делило его.

Те же самые ситуации разыгрываются среди различных решений для хранения. FAT32 может управлять только тем, что считается небольшим количеством «ящиков» на современных огромных жестких дисках, поэтому в итоге у него есть очень большие «ящики», чтобы компенсировать это.

Помимо размеров кластера, вы также можете иметь несоответствие из-за следующих условий:

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

Вы должны взглянуть на запись Block Suballocation в Википедии. Это именно то, что происходит с вами. Использование файловой системы с поддержкой Tail Packaging - решение этой проблемы на уровне файловой системы, помимо изменения размера кластера выделения.

Всем неудобно переформатировать диск.

В некоторых случаях простое хранение этих файлов в архиве решило бы проблему (и маленькие файлы также были бы сжаты помимо остановки потери места в конце файлов). Это неудобно тратить некоторое время на декомпрессию.

Другой вариант, если у вас так много маленьких файлов из-за какой-то конкретной проблемы, связанной с приложением, - это сохранить данные вашего программного обеспечения другим способом (может быть в базе данных). Но, конечно, это решение для программистов, а не конечных пользователей.

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

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