Я использую CentOS 5 с Plesk 9 (64-бит), у меня есть сайт, на котором пользователи будут загружать изображения. Существуют ли ограничения на количество файлов, которые я могу хранить в 64-битной ОС? Все, что меня волнует, - это производительность и обслуживание файлов. Я бы предпочел не иметь 4 каталога разрозненных файлов. Однако я надеюсь, что когда-нибудь у меня будет 200-300 тысяч изображений.
Если ты используя 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 тоже может помочь.
В основном:
Файловые системы в каталоге хранилища Linux в основном двумя способами:
В виде простого списка файлов.
В виде структуры данных (обычно B + Tree или связанной структуры данных).
Первый становится все медленнее по мере добавления файлов. Последнего нет. Обратите внимание, что ls может по-прежнему длиться вечно, так как он должен искать inode всех этих файлов, записи каталога содержат только имя файла и номер inode.
Каталоги Ext3 представляют собой плоские списки с опцией хешированного древовидного индекса для ускорения работы.
XFS использует деревья B +.
Но для любой из этих файловых систем, если вы выполните команду ls -l, потребуется обработать столько инодов, сколько файлов. Для поиска имени (например, при открытии файла) B + Tree и тому подобное будет намного быстрее для больших каталогов.
Однако иерархия каталогов облегчает управление файлами, поэтому вы можете рассмотреть эту возможность. Даже один уровень каталогов, содержащий, скажем, 4000 файлов в каждом, значительно упростил бы управление.
Это зависит от файловой системы, которую вы используете, а не от 64-разрядности операционной системы. В каждой файловой системе наступает момент, когда большие затраты алгоритма, используемого для поиска в каталоге, возьмут верх над компьютером.
Если вы можете разбить иерархию файлов даже на двухуровневую иерархию, вы увидите лучшую долгосрочную масштабируемость.
Это сильно зависит от используемой файловой системы. Некоторым более старым версиям ext3 это было ужасно, поэтому и возникли btrees. Reiser намного эффективнее работает с большим количеством таких файлов. Раньше у меня был каталог Novell NSS на сервере NetWare с 250 000 файлов размером 4 Кбайт в нем из-за ошибки GroupWise, и он работал нормально. Перечисление каталогов - отстой, но доступ к конкретному файлу в этом каталоге работал так быстро, как вы надеялись. Поскольку это было 8 лет назад, я должен предположить, что современные файловые системы Linux могут справиться с этим с апломбом.
Если вы выходите за рамки нескольких сотен изображений, определенно учитывайте две вещи:
Я бы рекомендовал использовать XFS или, в противном случае, ReiserFS с двух- или трехуровневой иерархией каталогов, разделенной на двухбайтовые пары. например
11/2f/112f667c786eac323e300632b5b2a78d.jpg
49/2f/49ef6eb6169cc57d95218c842d3dee5c.jpg
0a/26/0a26f9f363f1d05b94ceb14ff5f27284.jpg
Это даст вам 256 каталогов на первых нескольких уровнях, разделив изображения на 65535 отдельных каталогов (этого более чем достаточно для изображений 100-200 тыс. И более). Это сделает вещи намного быстрее и более масштабируемыми, а также упростит обслуживание в дальнейшем.
Большинство конфигураций ext3 по умолчанию имеют ограничение 32K подкаталогов на каталог (сейчас не могу вспомнить фактическое число, но мы столкнулись именно с этой проблемой пару недель назад. Система в то время была Debian / Etch).
Может также поразить вас в некоторых приложениях, которые используют много кэширования.
Рассматривать не используя ext3, конечно. http://kernelnewbies.org/Ext4#head-97cbed179e6bcc48e47e645e06b95205ea832a68 (показывает новые функции в ext4) может быть полезной отправной точкой.
Сказал бы, посмотрите, как squid также организует свой кеш (несколько уровней каталогов), так как много файлов в одном каталоге может оказаться трудным в обслуживании. Длинные списки (как правило) - отстой.
Файловые системы ext3 по умолчанию имеют htrees для больших каталогов в большинстве дистрибутивов. сделать tune2fs -l /dev/sda1 (или любое другое блочное устройство, которое вы используете) и проверьте строку «Возможности файловой системы:». если среди них есть "dir_index", вы золотой.
обратите внимание, однако, что даже лучшая структура каталогов может ускорить поиск только одного конкретного файла. делать ls в огромном каталоге будет ужасно, как и любое сопоставление с образцом, даже если вы знаете, что он соответствует одному файлу.
по этим причинам обычно лучше добавить один или два уровня каталогов. обычно используют некоторые биты идентификатора для именования каталогов.
Это будет в некоторой степени зависеть от того, какую файловую систему вы используете на своем сервере Linux.
Предполагая, что вы используете ext3 с dir_index, вы сможете довольно быстро выполнять поиск в больших каталогах, поэтому скорость не должна быть большой проблемой. Объявления (очевидно) займут больше времени.
Что касается максимального количества файлов, которые вы можете поместить в каталог, я почти уверен, что вы можете надежно работать с 32000 файлов. Я не уверен, что захочу превысить это (хотя вы, вероятно, можете).