Как вы можете видеть ниже, между полями « Размер» и « Размер» в моей папке очень много различий. Это почему?
Я знаю, что размер на диске должен быть немного больше, чем размер из-за выделения единиц в 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 известны как для законного, так и для нелегального использования:
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.
type CMD не может отображать содержимое 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 байтами часто может занимать от 4 до 32 КБ, в зависимости от размера блока файловой системы, в которой он находится.
Один из способов думать об этом - думать о каждом блоке в файловой системе как о коробке, а о файловой системе как о комнате. Все ваши коробки имеют одинаковый размер, и вы пытаетесь уместить в комнате столько, сколько сможете. Если вы поместите их все вместе с большим количеством оставшегося места, вы должны получить большие коробки, чтобы комната была полностью заполнена коробками.
Одно из правил размещения вещей в коробках заключается в том, что нельзя помещать две несвязанные вещи в коробку. Они должны быть частью одного и того же документа. Так что, если бы я напечатал страницу текста, у нее была бы своя коробка. Если бы мой напечатанный текст содержал так много страниц, что я не смог бы уместить все это в одном блоке, я просто нашел бы другой блок и продолжал бы вставлять туда страницы, повторяя до тех пор, пока я не заполню все свои страницы. Я также записал бы ящики, которые я использовал для этого документа, и порядок ящиков, чтобы прочитать его по порядку.
В зависимости от того, как я бы организовал ящики, в моем манифесте может быть достаточно места только для определенного количества ящиков. Поэтому, если бы у меня была большая комната для заполнения, но только небольшое количество ящиков, я бы использовал очень большие ящики, чтобы достичь вместимости комнаты.
Таким образом, в этом случае мой одностраничный документ по-прежнему занимал бы одно поле, и ничто иное не разделяло его.
Те же самые ситуации разыгрываются среди различных решений для хранения. FAT32 может управлять только тем, что считается небольшим количеством "ящиков" на сегодняшних огромных жестких дисках, поэтому в итоге у него есть очень большие "ящики", чтобы компенсировать это.
Вы должны взглянуть на запись Block Suballocation в Википедии. Это именно то, что происходит с вами. Использование файловой системы с поддержкой Tail Packaging - решение этой проблемы на уровне файловой системы, помимо изменения размера кластера выделения.
Всем неудобно переформатировать диск.
В некоторых случаях простое хранение этих файлов в архиве решило бы проблему (и маленькие файлы также были бы сжаты помимо остановки потери места в конце файлов). Это неудобно тратить некоторое время на декомпрессию.
Другой вариант, если у вас так много маленьких файлов из-за какой-то конкретной проблемы, связанной с приложением, - это сохранить данные вашего программного обеспечения, используя другой метод (может быть в базе данных). Но, конечно, это решение для программистов, а не конечных пользователей.
Помимо размеров кластера, вы также можете иметь несоответствие из-за следующих условий:
Я заметил огромные расхождения в размере файла в Windows 10 для отдельного файла, но если я посмотрю на свойства того же файла из того же места (сетевой диск), то в Windows XP большого расхождения нет; только небольшая разница, чего вы и ожидаете. Я думаю, что есть ошибка в Windows 10. Файл размером 449 МБ, вероятно, не занимает 3,99 ГБ, о чем говорит мне Windows 10.