Привет! On Sat, 8 Jul 2006, Paul Arakelyan wrote:
Эт всё хорошо, но "без спросу" отрывать диск с открытыми файлами - это как-то неправильно. Короче, "потрясающий менеджмент ресурсов".
Менеджмент системных, критичных ресурсов (своп - один из них) всегда был заботой системного администратора. И у него всегда было для этого средство в виде process resource limits, login.conf(5). Если в Вашей системе этот механизм не предотвратил исчерпания свопа (за счет ограничения maxproc, datasize, stacksize, ...), это говорит о том, что Вы его просто не настроили адекватно.
Стоп - я "отожрал" заданный кусок памяти - и "дальше - хоть потоп", диск же не наращивается в объёме - зачем тогда "неистощаемость ресурсов"?
Я знал, я знал ;) Мне кажется, Вы неверно представляете себе динамику "отжирания" свопа. Он выделяется не в момент запуска mdmfs, а по мере заполнения полученного диска. Попробуйте (если на машине достаточно свопа) издать, например mdmfs -s 512m md /mnt dd if=/dev/zero of=/mnt/aaa bs=1m и понаблюдайте с другой консоли за тем, как swapinfo показывает реальное использование свопа Вашим диском. Так что "отжор" здесь производится динамически, при работе с диском. Своп, к сожалению, более критичный ресурс, чем свободное место на файловых системах. Если в Вашей системе он и так склонен к истощению (по причине несоответствия process resource limits), зачем же его дополнительно истощать данными md-диска? Не понимаю логику, какой-то self foot shooting получается.
-F file Create a vnode-backed (MD_VNODE) memory disk backed by file.
дык мне надо чтоб а) быстро-быстро и б) всё к (нужное подставить) исчезло после ребута.
Странно, я по Вашему первому письму подумал, что данные на диске как раз критичны...
Ну и кто сказал, что при -F file опять ядро не прибъёт mount_mfs? (вероятность сего поменьше будет - но наверняка больше 0 ).
вобщем - явно нужно чтоб была возможность делать процессы "неубиваемыми" - иначе жить смогут только связки "процесс1 смотрит, чтоб не убили процесс2, который смотрит, .... чтоб не убили процесс N, который смотрит, чтоб не убили процесс 1.
А тут спорить в Вами не буду, логика убиения по out-of-swap во фришке (как и во многих *NIX-подобных системах) - проста, неуправляема и несовершенна. Время от времени появляются попытки решения этой проблемы, но в дерево пока никто еще ничего толкового на эту тему не закоммитил (наверное, потому, что универсального решения еще не придумали). Так что выход пока один - корректное распределение системных ресурсов. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message