Недостатки небольшого размера единицы размещения

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

Размер блока выделения моего жесткого диска составляет 4 КБ, что означает, что я трачу много места. Когда речь идет о резервном копировании, в частности, я бы хотел избежать потери места.

То, что я хотел бы знать, это каковы недостатки установки наименьшего размера AU. Моя главная проблема заключается в том, что происходит с файлами 8 ГБ, если у меня размер AU 512 байт?

disk-space

— Нит Тёмный Абсол
источник

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

— paradroid

Да, и, кроме того, переходя от настроек по умолчанию, вы немного более подвержены проблемам несовместимости с определенным программным обеспечением, которое напрямую обращается к жесткому диску, таким как клонирование дисков и программное обеспечение для резервного копирования.

— paradroid

Недостатки небольшого блока выделения диска включают в себя:

Большая таблица распределения.

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

Так как на единицу выделяется меньший объем дискового пространства, при записи последовательных файлов будут возникать дополнительные издержки файловой системы (наиболее распространенный метод). Чтобы выделить кластер, файловая система должна получить блокировку мьютекса для обеспечения монопольного доступа, изменить таблицу размещения, освободить мьютекс и затем скопировать таблицу распределения из памяти на диск.
Возможное ограничение в объеме тома

Вероятно, не проблема сегодня с 32- и 64-разрядными процессорами. Но еще во времена 8- и 16-разрядных процессоров и файловых систем, таких как FAT, количество единиц выделения в сочетании с размером выделения фактически накладывало реальное ограничение на размер томов / разделов жесткого диска. Одним из очевидных результатов стала файловая система FAT32, которая увеличила количество возможных единиц выделения.
Больше фрагментации файлов

Для данного размера файла, очевидно, будет больше единиц размещения, назначенных этому файлу. Нет никаких гарантий, что единицы распределения могут / будут смежными. Для чтения файла 8 МБ наихудший сценарий для кластеров 4 КБ будет включать 2048 интервалов поиска плюс интервальные задержки или один полный доступ к диску для каждого кластера в последовательности. Наихудший сценарий для кластеров 512B будет включать 16 364 поиска плюс интервалы задержки вращения! Очевидно, что эта (возможная) фрагментация повлияет на пропускную способность данных.

По мере того, как диски становятся больше, размер распределения часто увеличивается, чтобы уменьшить эти недостатки. Рациональным является то, что на диске больше свободного места, но это круговая логика. В идеале на диске должно быть несколько разделов, каждый из которых должен иметь формат, выделенный для «типичного» файла. Например, я оставляю диск / раздел C: по умолчанию размером 4 КБ. Но раздел, в котором записаны телевизионные записи, имеет кластеры 64 КБ, поскольку обычная часовая запись составляет около 6 ГБ.

— опилки
источник

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

— Niet the Dark Absol

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

— Гравитация

Здравствуйте, я нашел этот Q по собственному желанию. Что вы имеете в виду под более крупной таблицей распределения? Какова обратная сторона большей таблицы размещения?

— Karolinger,

@Karolinger - Файловая система должна поддерживать состояние каждой единицы размещения, независимо от того, свободна она или используется, помечена как плохая или перемещена. Размер этой таблицы распределения прямо пропорционален количеству единиц распределения. Для дискового раздела заданного размера, если вы вдвое уменьшите размер размещения, то количество записей в таблице размещения удваивается . Большая таблица распределения может потенциально потребовать более длительного времени поиска, чтобы найти свободную единицу, так как там просто больше записей для сканирования. Некоторые из этих проблем более актуальны для носителей малой емкости, например, для дискет.

— опилки