> > Запросы, которые не могут быть обработаны, стоит сразу "отбивать" (это
> > верно для системы любого типа), это верно как с точки зрения
> > безопасности, так и с точки зрения производительности (именно в таком
> > порядке).
>
> надо будет проследить какое количество одновременных запросов сейчас
> оптимально, хотя сейчас я думаю не о старой машине а о том как буду
> организовывать новую.
Зато у вас есть возможность потестировать на уже работающей системе, это
полезно.
> > Выбираю ext3 за ее надежность; reiserfs имеет иные настройки по
> > умолчанию, потому часто рекомендуется для соответствующих задач, но
> > чтение манов по ext3 позволит настроить как минимум не хуже. Для начала
> > на ext3 отключите atime, diratime и включите индекс директорий. После
> > этого сможете эффективно работать с десятками и сотнями тысяч файлов в
> > директории (тестировал и с миллионом файлов, но это на практике пока не
> > потребовалось). Есть и другие полезные опции, но мне хватает
> > вышеназванных. Имхо, рейзер нестабильная ФС с непонятной поддержкой и на
> > свой сервер я ее никогда не поставлю (да и зачем - ощутимых преимуществ
> > не вижу). Еще для вашей задачи стоит попробовать опцию data=journal (в
> > /etc/fstab использовать нельзя, надо указывать как параметр загрузки),
> > для конкурентного ввода-вывода может оказаться очень полезной.
>
> Значит наш взгляд на ext2/ext3 совпадает. про atime/diratime я знал,
> а как включается индекс директорий ?
> тоже опция монтирования ?
С помощью tune2fs включаем dir_index. Получим вот такую информацию о разделе:
# /sbin/tune2fs -l /dev/sda1|grep index
Filesystem features: has_journal resize_inode dir_index filetype
needs_recovery sparse_super large_file
> (нет, я конечно посмотрю в man :), просто интересно мнение и опыт)
> небольшое уточнение про опцию data=journal в опциях ядру - это
> справедливо только для корневой ФС, остальные легко меняются на ходу и в
> fstab.
Да, спасибо за уточнение. Сам я пробовал как раз на корневой ФС, для моих
задач счел эту опцию ненужной.
> > P.S. Утилита rm отвратительно работают с большим числом файлов в
> > директории. Я пишу свои скрипты на tcl, которые выполняют то же самое на
> > несколько порядков быстрее. В то же время ls работает нормально, не знаю,
> > в чем проблема. На примере миллиона файлов: rm /test_1000000/* думает
> > часами и зверски насилует винт, в то время как на тикле foreach fn [glob
> > /test_1000000/*] {file delete $fn} работает две-три минуты и почти не
> > шелестит винтом. Посмотрите, может, и у вас где подобные грабли закопаны.
>
> Кстати да, искал альтернативу rm/ls/mv, неужели лучше писать самому в
> скриптах ?
У меня доступ к файлам производится из сервера приложений (aol web server),
так что все равно пишу на тикле и проблем, подобных вышеозначенной, не
возникает. При тестировании работы с большим количеством файлов в директории
вылезла проблема с rm, а поскольку тестовый скрипт также на тикле, написать
foreach fn [glob /test_1000000/*] {file delete $fn}
вместо
rm /test_1000000/*
сложностей не составило. Если вы системные скрипты пишете на bash, то я вам
просто сочувствую. На bash я делаю только скрипты для /etc/init.d/ Временами
в рассылке пробегают темы о различных извращениях для ценителей bash, но это,
видно, не для меня, читаю (интересно же) с ужасом :-)
