Alexey Pechnikov wrote:
>
> А вот бэкап надо реорганизовывать или "размазывать" во времени. Например,
> rsync имеет опцию
> --bwlimit=KBPS limit I/O bandwidth; KBytes per second
> Может быть, это то, что вам нужно?
>
>
Да, сейчас бэкап идет с помощью backuppc, думаю что эта опция будет полезна.
с другой стороны - backuppc создает много файлов, что опять дает
нагрузку на ФС.
> Запросы, которые не могут быть обработаны, стоит сразу "отбивать" (это верно
> для системы любого типа), это верно как с точки зрения безопасности, так и с
> точки зрения производительности (именно в таком порядке).
>
надо будет проследить какое количество одновременных запросов сейчас
оптимально, хотя сейчас я думаю не о старой машине а о том как буду
организовывать новую.
>
> Выбираю ext3 за ее надежность; reiserfs имеет иные настройки по умолчанию,
> потому часто рекомендуется для соответствующих задач, но чтение манов по ext3
> позволит настроить как минимум не хуже. Для начала на ext3 отключите atime,
> diratime и включите индекс директорий. После этого сможете эффективно
> работать с десятками и сотнями тысяч файлов в директории (тестировал и с
> миллионом файлов, но это на практике пока не потребовалось). Есть и другие
> полезные опции, но мне хватает вышеназванных. Имхо, рейзер нестабильная ФС с
> непонятной поддержкой и на свой сервер я ее никогда не поставлю (да и зачем -
> ощутимых преимуществ не вижу). Еще для вашей задачи стоит попробовать опцию
> data=journal (в /etc/fstab использовать нельзя, надо указывать как параметр
> загрузки), для конкурентного ввода-вывода может оказаться очень полезной.
>
>
Значит наш взгляд на ext2/ext3 совпадает. про atime/diratime я знал,
а как включается индекс директорий ?
тоже опция монтирования ?
(нет, я конечно посмотрю в man :), просто интересно мнение и опыт)
небольшое уточнение про опцию data=journal в опциях ядру - это
справедливо только для корневой ФС, остальные легко меняются на ходу и в
fstab.
> P.S. Утилита rm отвратительно работают с большим числом файлов в директории.
> Я
> пишу свои скрипты на tcl, которые выполняют то же самое на несколько порядков
> быстрее. В то же время ls работает нормально, не знаю, в чем проблема. На
> примере миллиона файлов: rm /test_1000000/* думает часами и зверски насилует
> винт, в то время как на тикле foreach fn [glob /test_1000000/*] {file delete
> $fn} работает две-три минуты и почти не шелестит винтом. Посмотрите, может, и
> у вас где подобные грабли закопаны.
>
Кстати да, искал альтернативу rm/ls/mv, неужели лучше писать самому в
скриптах ?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
