Поделиться через

Общие сведения о размерах каталогов в Azure NetApp Files

  • Статья

При создании файла в каталоге запись добавляется в скрытый файл индекса в томе Azure NetApp Files. Этот файл индекса помогает отслеживать существующие иноды в каталоге и ускорить запросы поиска для каталогов с большим количеством файлов. При добавлении записей в этот файл размер файла увеличивается (но никогда не уменьшается) примерно в 512 байтах на запись в зависимости от длины имени файла. Более длинные имена файлов добавляют больше размера в файл. Символьные ссылки также добавляют записи в этот файл. Эта концепция называется размером каталога, который является общим элементом во всех файловых системах под управлением Linux. Размер каталога не является максимальным общим количеством файлов в одном томе Azure NetApp Files. Это определяется значениемmaxfiles.

По умолчанию при создании нового каталога используется 4 КиБ (4096 байт) или восемь 512-байтовых блоков. Размер только что созданного каталога из клиента Linux можно просмотреть с помощью команды stat.

# mkdir dirsize 
# stat dirsize 
File: ‘dirsize’ 
Size: 4096            Blocks: 8          IO Block: 32768  directory

Размеры каталогов зависят от одного каталога и не объединяются в размерах. Например, если в томе есть 10 каталогов, каждый может приблизиться к ограничению размера каталога 320-MiB в одном томе.

Определение того, что размер каталога приближается к предельному

Для каталога 320-MiB число блоков составляет 655360, при этом каждый размер блока составляет 512 байт. (То есть 320x1024x1024/512.) Это число преобразуется примерно в 4-5 миллионов файлов максимум для каталога 320-MiB. Однако фактическое число максимальных файлов может быть меньше, в зависимости от таких факторов, как количество файлов с символами, отличными от ASCII в каталоге.

В клиенте вы можете выполнить команду stat, чтобы определить, приближается ли каталог к максимальному допустимому размеру метаданных каталога (320 МБ). Если достигнуто максимальное ограничение размера для одного каталога для Azure NetApp Files, возникает ошибка No space left on device .

Для каталога размером 320 МБ число блоков составляет 655 360, при этом каждый размер блока составляет 512 байт. (т. е. 320×1024×1024/512). Это число позволяет поддерживать приблизительно 4 000 000 файлов в каталоге размером 320 МБ. Однако фактическое число максимальных файлов может быть меньше, в зависимости от таких факторов, как количество файлов с символами, отличными от ASCII в каталоге. Сведения о мониторинге maxdirsize см. в разделе "Мониторинг maxdirsize".

Рекомендации по размеру каталога

При работе с средой с высоким числом файлов рассмотрите следующие рекомендации:

  • Тома Azure NetApp Files поддерживают до 320 МиБ для размеров каталогов. Это значение нельзя увеличить.
  • После превышения размера каталога тома клиенты отображают ошибку вне места, даже если в томе доступно свободное место.
  • Для обычных томов размер каталога 320 MiB соответствует примерно 4-5 миллионам файлов в одном каталоге. Это значение зависит от длины имени файла.
  • Большие тома имеют архитектуру, отличную от обычных томов.
  • Большое количество файлов в одном каталоге может представлять проблемы с производительностью при поиске. По возможности ограничьте общий размер одного каталога до 2 МиБ (примерно 27 000 файлов) при необходимости частого поиска.
    • Если требуется больше файлов в одном каталоге, настройте ожидания производительности поиска соответствующим образом. Хотя Azure NetApp Files индексирует список файлов каталога для повышения производительности, поиски могут занять некоторое время с высоким количеством файлов.
  • При проектировании файловой системы избежать неструктурированных макетов каталогов. Сведения о различных подходах к макетам каталогов см. в разделе "Сведения о макетах каталогов".
  • Чтобы устранить проблемы с превышением размера каталога, а новые файлы не могут быть созданы, удалять или перемещать файлы из соответствующего каталога.

Сведения о макетах каталогов

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

Неструктурированный каталог — это один каталог с несколькими файлами под одним каталогом.

Схема плоской структуры каталогов.

Широкая структура каталогов содержит множество каталогов верхнего уровня с файлами, распределенными по всем каталогам.

Схема широкой структуры каталогов.

Глубокая структура каталогов содержит меньше каталогов верхнего уровня с большим количеством подкаталогов. Хотя эта структура предоставляет меньше файлов на папку, длина пути к файлам может стать проблемой, если макеты каталогов слишком глубокие, а пути к файлам становятся слишком длинными. Дополнительные сведения о длине пути к файлу см. в разделе "Общие сведения о длине пути к файлу" в Azure NetApp Files.

Схема глубокой структуры каталога.

Влияние неструктурированных структур каталогов в Azure NetApp Files

Неструктурированные структуры каталогов (многие файлы в одном или нескольких каталогах) оказывают негативное влияние на широкий массив файловых систем, томов Azure NetApp File или других. Возможные проблемы:

  • Нехватка памяти
  • загрузка ЦП;
  • Производительность сети и задержка (особенно во время массовых запросов файлов, GETATTR операций, READDIR операций)

Благодаря проектированию больших томов Azure NetApp Files влияние maxdirsize уникально. Большой объем maxdirsize Azure NetApp Files влияет уникально из-за его дизайна. В отличие от обычного тома, большой том использует удаленные жесткие связи внутри Azure NetApp Files для перенаправления трафика на разных устройствах хранения, чтобы обеспечить больший масштаб и производительность. При использовании неструктурированных каталогов существует более высокое соотношение внутренних жестких ссылок на локальные файлы. Эти удаленные жесткие ссылки учитывают общее maxdirsize значение, поэтому большой том может приблизиться к его maxdirsize ограничению быстрее, чем обычный том.

Например, если в одном каталоге есть миллионы файлов и создается примерно 85% удаленных жестких ссылок для файловой системы, можно ожидать maxdirsize , что он будет исчерпан почти в два раза больше, чем обычный том.

Для получения наилучших результатов с размерами каталогов в Azure NetApp Files:

  • Избегайте неструктурированных структур каталогов в Azure NetApp Files. Широкие или глубокие структуры каталогов лучше всего работают, если длина пути файла или папки не превышает стандарты протокола NAS.
  • Если неструктурированные структуры каталогов неизбежны, следите maxdirsize за каталогами.

Монитор maxdirsize

Для одного каталога используйте stat команду для поиска размера каталога.

# stat /mnt/dir_11/c5

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

# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn

Примечание.

Размер каталога, сообщаемый командой статистики, находится в байтах. Размер, указанный в команде find, находится в KiB.

Пример

# stat /mnt/dir_11/c5 

  File: ‘/mnt/dir_11/c5’ 

  Size: 322396160       Blocks: 632168     IO Block: 32768  directory 
 
# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn 
316084 /mnt/dir_11/c5 

3792 /mnt/dir_19 

3792 /mnt/dir_16

В предыдущем случае размер /mnt/dir_11/c5 каталога составляет 316 084 КиБ (308,6 МиБ), который приближается к ограничению 320-МиБ. Это соответствует примерно 4,1 миллионам файлов.

# ls /mnt/dir_11/c5 | wc -l
4171624

В этом случае рассмотрите возможность исправления таких действий, как перемещение или удаление файлов.

Дополнительные сведения