☰

Хранение файлов в каталоге... есть ли ограничения?

tag-icon • tag-icon linux filesystems directory limitations
Хранение файлов в каталоге... есть ли ограничения?

Я использую CentOS 5 с Plesk 9 (64-бит), я управляю сайтом, на который пользователи будут загружать изображения. Есть ли какие-либо ограничения на количество хранимых файлов в 64-битной ОС? Все, что меня волнует, это производительность и обслуживание файлов. Я бы предпочел не иметь 4 каталога в глубину разбросанных файлов. Однако я надеюсь, что в какой-то момент у меня будет 200-300 тысяч изображений.

решение1

Если тыиспользуя ext3, Я нашелЭта цитата(предупреждение: сайт на испанском языке)

«Существует ограничение в 32 тыс. (32768) подкаталогов в одном каталоге, ограничение, вероятно, представляет только академический интерес, поскольку у многих людей даже нет такого количества файлов (хотя крупным почтовым серверам, возможно, следует иметь это в виду). Спецификация inode ext2 позволяет размещать более 100 триллионов файлов в одном каталоге»

дальнейшее чтениепоказал, что ext3не делаетимеют ограничение в 32К, что может быть доказано эмпирически с помощью

a=0; i=1; while [ $a == 0 ]; do touch $i; a=$?; let i++; done

но этоимеетограничение на размер папки в 32 КБ, которое можно протестировать с помощью

a=0; i=1; while [ $a == 0 ]; do mkdir $i; a=$?; let i++; done

Это (необоснованное) утверждениеГоворит, что

ReiserFS не испытывает никаких проблем с сотнями тысяч файлов в одном каталоге. flabdablet - 1 февраля 2007 г.

Этот вопросс родственного сайта stackoverflow.com тоже может помочь.

В общем:

  • Тамявляетсяограничение на количество каталогов,
  • Тыдолженсохраняйте размер файлов/каталогов менее 32К, номожетпойти намного дальше,
  • Используемая вами файловая система имеет значение.

решение2

Это во многом зависит от используемой вами файловой системы. Некоторые старые версии ext3 были ужасны с этим, поэтому и появились btrees. Reiser гораздо более производительна с большим количеством таких файлов. В старые времена у меня был каталог Novell NSS на сервере NetWare с 250 000 файлов по 4 КБ из-за ошибки GroupWise, и он работал просто отлично. Перечисление каталога было очень утомительным, но доступ к определенному файлу в этом каталоге работал так быстро, как вы могли бы надеяться. Поскольку это было 8 лет назад, я должен предположить, что современные файловые системы Linux могут справиться с этим без проблем.

решение3

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

Если вы сможете разбить файловую иерархию хотя бы на два (2) уровня, вы увидите лучшую долгосрочную масштабируемость.

решение4

Если вы собираетесь сделать больше нескольких сотен изображений, обязательно учтите две вещи:

  1. Вложенные иерархии с хешированными именами файлов;
  2. Не использую ext3

Я бы рекомендовал использовать XFS или, если это невозможно, ReiserFS с двух- или трехуровневой иерархией каталогов, разделенной двухбайтовыми парами. Например:

11/2f/112f667c786eac323e300632b5b2a78d.jpg
49/2f/49ef6eb6169cc57d95218c842d3dee5c.jpg
0a/26/0a26f9f363f1d05b94ceb14ff5f27284.jpg

Это даст вам 256 каталогов на первых нескольких уровнях, разделив изображения на 65535 отдельных каталогов (что более чем достаточно для 100-200 тыс. изображений и более). Это сделает все намного быстрее и масштабируемее, а также значительно облегчит обслуживание в дальнейшем.

Связанный контент