Привет всем программистам.Написал небольшой патч для ядра FreeBSD, подсистемы VFS.
Исправляет панику при синхронизации с потеряным устройством, тобишь не отмонтировали флешку, вытащили и словили дамп)))
В общем проблемы была в функции bufobj_invalbuf, исравил правкой флагов (наибольший эффект наименьшими средствами), попутно поправил реализацию msdosfs, не было проверки на нулевой указатель и ядро падало в панику с page fault. Так же изменению подверглась функция dounmount поскольку не уничтожала точку монтирования при отрицательном резельтате синхронизации.Вопрос к вам товарисчи, куда мне все это деть, это вообще нужно кому нибудь???)))
Какой Русский коммитер может это заценить, английский знаю плохо))) поэтому в списки рассылки не суюсь)))
>Привет всем программистам.
>
>Написал небольшой патч для ядра FreeBSD, подсистемы VFS.
>Исправляет панику при синхронизации с потеряным устройством, тобишь не отмонтировали флешку, вытащили
>и словили дамп)))
>В общем проблемы была в функции bufobj_invalbuf, исравил правкой флагов (наибольший эффект
>наименьшими средствами), попутно поправил реализацию msdosfs, не было проверки на нулевой
>указатель и ядро падало в панику с page fault. Так же
>изменению подверглась функция dounmount поскольку не уничтожала точку монтирования при отрицательном
>резельтате синхронизации.
>
>Вопрос к вам товарисчи, куда мне все это деть, это вообще нужно
>кому нибудь???)))
>Какой Русский коммитер может это заценить, английский знаю плохо))) поэтому в списки
>рассылки не суюсь)))man send-pr
send-pr
Если это правда, то вопрос риторический, конечно нужно. Я хочу такой патч. Тысячи людей хотят по всему миру. Только это больше похоже (прости конечно) на стёб. Один анонимус написал на опеннете. Если это выложить хотя бы на бесплатник, поставить счётчик, и дать здесь и на bsdportal.ru ссылку желающих можно будет оценить уже через месяц. Тысячи полторы я думаю будет по-любому.
>Если это правда, то вопрос риторический, конечно нужно. Я хочу такой патч.
>Тысячи людей хотят по всему миру. Только это больше похоже (прости
>конечно) на стёб. Один анонимус написал на опеннете. Если это выложить
>хотя бы на бесплатник, поставить счётчик, и дать здесь и на
>bsdportal.ru ссылку желающих можно будет оценить уже через месяц. Тысячи полторы
>я думаю будет по-любому.+1
Я разбирался с флэшка-бедам, там весьма не простая задачка. Она, между прочим, широко обсуждается в узких кругах и затрагивает базовые подсистемы ядра.Но откомитить надо :-) а вдруг и правда чудо произошло :-)
>Если это правда, то вопрос риторический, конечно нужно. Я хочу такой патч.
>Тысячи людей хотят по всему миру. Только это больше похоже (прости
>конечно) на стёб. Один анонимус написал на опеннете. Если это выложить
>хотя бы на бесплатник, поставить счётчик, и дать здесь и на
>bsdportal.ru ссылку желающих можно будет оценить уже через месяц. Тысячи полторы
>я думаю будет по-любому.Ну вы даете господа, я могу сюда выложить конкретно текст исправлений и куда их писать, какой смысл здесь пистеть (простите за выражение):))))
Просто забыл подписаться)))
Я поэтому и спросил совета куда мне это девать, потому что делал эти исправления от того что меня задолбал этот баг, который ещё с 6-ой версии действителен.
Кароче завтра diff-ом делаю файл патча, пишите куда выложить, на этом надеюсь сомнения в моей честности исчезнут...
>Кароче завтра diff-ом делаю файл патча, пишите куда выложить, на этом надеюсь
>сомнения в моей честности исчезнут...Да сомнений в честности нет. Просто, на сколько я понимаю проблема в следующем:
1) монтирует флэшку,
2) выдёргиваем её,
3) пытаемся размонтировать -- Device not configured.
4) пытаемся размонтировать с ключом -f -- паника и ребутДело в том, что паника связана с тем, что системный вызов umount пытается освободить ресурсы ядра, которые уже были освобождены другими механизмами. Таким образом вы могли сделать:
1) исправить внутренние системы, освобождающие ресурсы при вытаскивании флэшки, но для этого надо неплохо (даже отлично!) разбираться в GЕOM и прочих подсистемах.
2) вы "поправили" umount, теперь он не освобождает ресурсы, но это плохое решение (мне такое не нужно :-)).
3) вы что-то изменили в atausb/umass... но на сколько я понимаю этот случай паники не зависит от этих подсистем и так проблему не решить.
4) вы могли написать userspace работу с файловыми системами (продублировав функции ядра вне ядра), это не простая задача (много дублировать), но вполне решаемая, для этого есть всякие FUSE, но ведь речь не об этом? вы говорите, что правили ядро.Мне очень интересно, что именно вы сделали. Не поясните?
Я сам писал пачи (правда не в ядро) и прекрасно представляю, что во вполне уважаемом софте могут быть совершенно тупые ошибки. Я верю, что проблему можно решить и, возможно, вы её решили. Мне просто очень интересно как именно потому, что я тоже этим занимался :-)
Все досконально объяснять не буду слишком много печатать, поверхностно поясняю)))
Проблема была в синхронизации грязных буферов vnode, с устройством. Ну разумеется суперблок тоже не мог записаться.
Исправлению подверглась функция bufobj_invalbuf, причем минимально. Паника возникала от того что при попытке отмонтировать флеш карту вызывалась функция vflush, и от того что демон синхронизации пытался записать на это устройство. Функция делала попытку завершить все опереции ввода выводы с буферами внодов, но число этих буферов не уменьшалось, хобя поток geom g_up ошибку сразу не возвращал, просто число не завершенных операций было бльше нуля, но это не повод для паники в принципе, просто необходимо было очистить списки буфуров bufobj внода без флага V_SAFE, вот патч--- /home/arch_kern_files_2/vfs_subr.c Mon Dec 4 17:47:53 2006
+++ /sys/kern/vfs_subr.c Thu May 17 11:46:32 2007
@@ -1029,8 +1029,10 @@
* enabled under INVARIANTS
*/
BO_LOCK(bo);
- if (bo->bo_numoutput > 0 || bo->bo_dirty.bv_cnt > 0)
- panic("vinvalbuf: dirty bufs");
+ if (bo->bo_numoutput > 0 || bo->bo_dirty.bv_cnt > 0) {
+ printf("bufobj_invalbuf: warning panic not run, error=%d\n", error);
+ flags = 0;
+ }
}
}
/*
следующая проблема в процедурах unmount файловых систем, причем все они реализованы по разному и ведут себя совершенно не предсказуемо с точки зрения возвращения ошибок, если ufs возвращало код глобальной ошибки после попытки синхронизации с процедуры dounmount, то msdosfs этого не делало, в общем ufs не трогал а msdosfs поправил немножко
патчи--- /home/arch_kern_files_2/msdosfs_vfsops.c Wed Dec 20 12:05:30 2006
+++ /sys/fs/msdosfs/msdosfs_vfsops.c Wed May 16 21:24:03 2007
@@ -766,8 +766,10 @@
/* If the volume was mounted read/write, mark it clean now. */
if ((pmp->pm_flags & MSDOSFSMNT_RONLY) == 0) {
error = markvoldirty(pmp, 0);
- if (error && (flags & FORCECLOSE) == 0)
+ if (error && (flags & FORCECLOSE) == 0 && (error & ENXIO) == 0)
return (error);
+ if (error & ENXIO)
+ error = 0;
}
#ifdef MSDOSFS_DEBUG
{
также в msdos была ошибка при выводе информации о не записанных секторах патч--- /home/arch_kern_files_2/msdosfs_vnops.c Mon Mar 13 12:05:13 2006
+++ /sys/fs/msdosfs/msdosfs_vnops.c Thu May 17 11:44:23 2007
@@ -1834,7 +1834,9 @@
printf("\tstartcluster %lu, dircluster %lu, diroffset %lu, ",
dep->de_StartCluster, dep->de_dirclust, dep->de_diroffset);
- printf("on dev %s\n", devtoname(dep->de_dev));
+ if (dep->de_dev != NULL) {
+ printf("on dev %s\n", devtoname(dep->de_dev));
+ }
return (0);
}НУ и процедура dounmount тоже немного поменялась, ПРИЧЕМ ПОДЧЕРКИВАЮ ЭТО НЕ ТУПАЯ ПОПЫТКА ИЗБЕЖАТЬ ПАНИКИ это все делалось с тонким расчетом и желанием как можно меньше менять в ядре
патч--- /home/arch_kern_files_2/vfs_mount.c Wed Oct 25 01:02:39 2006
+++ /sys/kern/vfs_mount.c Thu May 17 11:48:49 2007
@@ -1194,6 +1194,10 @@
(flags & MNT_FORCE)) {
error = VFS_UNMOUNT(mp, flags, td);
}
+ if (error & ENXIO) {
+ printf("dounmount: error=%d\n", error);
+ error = VFS_UNMOUNT(mp, 0, td);
+ }
vn_finished_write(mp);
if (error) {
/* Undo cdir/rdir and rootvnode changes made above. */Ориентировался я по номерам глобальных ошибок которые возвращались после операции io
Заценивайте...
>Заценивайте...даа... снимаю шляпу :-)
не уверен на 100%, что от этого нигде ничего не потечёт, но это надо отправить разработчикам однозначно.думаю вам сюда: http://www.freebsd.org/projects/ideas/
там есть контактные mailы людей, занимающихся разыми вопросам.
вам наверно нужен Luigi Rizzo <luigi[at]FreeBSD.org> "Improving the USB stack in FreeBSD"
и Robert Watson <rwatson[at]FreeBSD.org> "FAT (msdosfs) infrastructure work"
посмотрите там ещё сами, может кого более подходящего присмотрите.
кроме того, посмотрите в сорцах, которые правили. я никогда не замечал, но может просто внимания не обращал, может там есть какие-то контакты.А так.. Успехав! :-)
Держите по возможности в курсе :-)PS. Люди! я сам во фрёвое ядро никогда ничего не комитил, если кто-то это делал, подскажите человеку, он вроде дело говорит.
>>Заценивайте...
>
>даа... снимаю шляпу :-)
>не уверен на 100%, что от этого нигде ничего не потечёт, но
>это надо отправить разработчикам однозначно.
>
>думаю вам сюда: http://www.freebsd.org/projects/ideas/
>там есть контактные mailы людей, занимающихся разыми вопросам.
>вам наверно нужен Luigi Rizzo <luigi[at]FreeBSD.org> "Improving the USB stack in FreeBSD"
>и Robert Watson <rwatson[at]FreeBSD.org> "FAT (msdosfs) infrastructure work"
>посмотрите там ещё сами, может кого более подходящего присмотрите.
>кроме того, посмотрите в сорцах, которые правили. я никогда не замечал, но
>может просто внимания не обращал, может там есть какие-то контакты.
>
>А так.. Успехав! :-)
>Держите по возможности в курсе :-)
>
>PS. Люди! я сам во фрёвое ядро никогда ничего не комитил, если
>кто-то это делал, подскажите человеку, он вроде дело говорит.Спасибо на добром слове)))
Распространите пожалуйста этот патч везде где только можно среди пользователей)))
А с английским у меня худо, только маны да сорцы читать)))
Я продолжу копать конечно, может где есть утечки...Пишите если че))) "Zver Z." <feliks_dzerginsk@mail.ru>
>>Заценивайте...
>
>даа... снимаю шляпу :-)
>не уверен на 100%, что от этого нигде ничего не потечёт, но
>это надо отправить разработчикам однозначно.
>
>думаю вам сюда: http://www.freebsd.org/projects/ideas/
>там есть контактные mailы людей, занимающихся разыми вопросам.
>вам наверно нужен Luigi Rizzo <luigi[at]FreeBSD.org> "Improving the USB stack in FreeBSD"
>и Robert Watson <rwatson[at]FreeBSD.org> "FAT (msdosfs) infrastructure work"
>посмотрите там ещё сами, может кого более подходящего присмотрите.
>кроме того, посмотрите в сорцах, которые правили. я никогда не замечал, но
>может просто внимания не обращал, может там есть какие-то контакты.
>
>А так.. Успехав! :-)
>Держите по возможности в курсе :-)
>
>PS. Люди! я сам во фрёвое ядро никогда ничего не комитил, если
>кто-то это делал, подскажите человеку, он вроде дело говорит.Если проблемы с английским, то всё же рекомендую для начала подписаться хотя бы на русский список рассылки, freebsd@opennet.ru (# Russian -- maillist@opennet.ru)
И учите английский, всегда пригодится. :)Удачи!
=
>
>--- /home/arch_kern_files_2/vfs_subr.c Mon Dec 4 17:47:53 2006
>+++ /sys/kern/vfs_subr.c Thu May 17 11:46:32 2007
>@@ -1029,8 +1029,10 @@
> * enabled under INVARIANTS
> */
> BO_LOCK(bo);
>- if (bo->bo_numoutput > 0 || bo->bo_dirty.bv_cnt > 0)
>- panic("vinvalbuf: dirty bufs");
>+ if (bo->bo_numoutput > 0 || bo->bo_dirty.bv_cnt > 0) {
>+ printf("bufobj_invalbuf: warning panic not run, error=%d\n", error);
>+ flags = 0;
>+ }
> }
> }
> /*
>
>
больше напоминает хак чем настоящиее решение. Более правильное решение научить BO_FSYNC коректно игнорировать ошибки записи.Решение в лоб простое - при выдергивании девайса - выставляем флаг READONLY и в функции записи при обнаружении этого флага тупа возвращаем OK.
>больше напоминает хак чем настоящиее решение. Более правильное решение научить BO_FSYNC коректно
>игнорировать ошибки записи.
>
>Решение в лоб простое - при выдергивании девайса - выставляем флаг READONLY
>и в функции записи при обнаружении этого флага тупа возвращаем OK.
>Не согласен, придется модифицировать usb стек(umass) или geom, я писал коммитерам что на самом деле проблема в не коректно возвращаемой ошибке вышестоящей функции bufsync в этом цикле, поскольку g_up её возвращает. На счет перевода состояния файловой системы в readonly это хорошая идея, тогда отпадает необходимость в модификации функций размонтирования. Вижу решение в том чтобы модифицировать функции синхронизации в VFS, поскольку поток синхронизации каждые 30 секунд делает попытки записи, чтобы файловая система перешла в ro.
НО это я сделаю недели через три, может раньше, поскольку у меня сессия, и я впухаю не падецки)))
На самом деле если это действительно надо, мне будет нетрудно сделать нормальные патчи, просто я не увидел особого интереса со стороны публики, только желание подвергнуть сомнениям возможность решения этих проблем.
Советы и технические обоснованные рекомендации с удовольствием приму к сведению.
Удачи.
>>больше напоминает хак чем настоящиее решение. Более правильное решение научить BO_FSYNC коректно
>>игнорировать ошибки записи.
>>
>>Решение в лоб простое - при выдергивании девайса - выставляем флаг READONLY
>>и в функции записи при обнаружении этого флага тупа возвращаем OK.
>>
>
>Не согласен, придется модифицировать usb стек(umass) или geom,
зачем? все делается на vfs уровне, макс - на geom, сползания в umass точно не надо.
>Вижу решение в том чтобы модифицировать функции
>синхронизации в VFS, поскольку поток синхронизации каждые 30 секунд делает попытки
>записи, чтобы файловая система перешла в ro.
зачем трогать BO_SYNC когда это только одна часть проблемы?
запис по любому пойдет через BO_WRITE где и проще проверить флаги устройства и проще имитировать нормально завершившиюся запись.
>зачем? все делается на vfs уровне, макс - на geom, сползания в
>umass точно не надо.
>зачем трогать BO_SYNC когда это только одна часть проблемы?
>запис по любому пойдет через BO_WRITE где и проще проверить флаги устройства
>и проще имитировать нормально завершившиюся запись.
>
GEOM трогать однозначно не надо, зачем ему костыль от VFS. Если следовать вашей логике,
то добавить проверку на вид ошибки в bufstrategy, однако появляется проблема как отследить
точку монтирования которая должна быть переведена в RO. Можно через buf->b_vp.v_mount, это не трудно, можно глобальным поиском в mountlist))) Это для извращенцев и руткито писателей:mtx_lock(&mountlist_mtx);
TAILQ_FOREACH_REVERSE(mp, &mountlist, mntlist, mnt_list) {
if (strcmp(mp->mnt_stat.f_mntfromname, DEV) == 0) {
printf("name = %s\n", mp->mnt_stat.f_mntfromname);
break;
}
}
mtx_unlock(&mountlist_mtx);Почему bufstrategy??? Ошибки чтения тоже имеют тот же код ENXIO, устройство не сконфигурировано, поскольку провайдер geom сдох, все операции будут идти через эту функцию.
Я думаю что это хороший способ и я его реализую, если конечно не возникнет гемороя с отдельными файловыми системами, И если все ресурсы будут освобождаться правильно в VFS, еще не известно как поведут себя вноды с грязными буферами, точно можно будет сказать только при непосредственном эксперементе, ядро фряхи это потемки)))
да! не сказал куда выложить :-)
Ну если вам совсем некуда, то заведите сайт на каком-нибудь народе и положите туда, я бы с превеликим интересом посмотрел бы на эти патчи.
Или уж на худой конец, киньте их мне, я их выложу где-нибудь и ссылку здесь дам.
alvm [собака] rol.ru
>Ну вы даете господа, я могу сюда выложить конкретно текст исправлений и
>куда их писать, какой смысл здесь пистеть (простите за выражение):))))
>
>Просто забыл подписаться)))Ёптить, ЗВЕРь, ааааа..
>Я поэтому и спросил совета куда мне это девать, потому что делал
>эти исправления от того что меня задолбал этот баг, который ещё
>с 6-ой версии действителен.А меня как он задолбал. Послать советают на Ruslan Ermilov <ru@FreeBSD.org>
Ну да теперь оно раскопипастится по рунету и шамо дойдёт.>Кароче завтра diff-ом делаю файл патча, пишите куда выложить, на этом надеюсь
>сомнения в моей честности исчезнут...Написал бы что ЗВЕРь никто бы и не сомневался. Я бы точно по крайней мере.. =)
Можно проголосовать по этому вопросу здесь:
http://www.bsdportal.ru/viewtopic.php?t=14058
Дублирую сообщение с bsdportal:
При синхронизации стабильного дерева исходных кодов с тестовым, выяснилось что не все исправления выложил, для msdosfs решение проблемы правильное, а для ufs и других файловых систем(rw in FreeBSD), к сожалению, чтобы они правильно освобождали ресурсы, тоже приходится вносить изменения, вечером выложу патч.
>Дублирую сообщение с bsdportal:
>При синхронизации стабильного дерева исходных кодов с тестовым, выяснилось что не все
>исправления выложил, для msdosfs решение проблемы правильное, а для ufs и
>других файловых систем(rw in FreeBSD), к сожалению, чтобы они правильно освобождали
>ресурсы, тоже приходится вносить изменения, вечером выложу патч.
PAtch:
--- /sys/ufs/ffs/ffs_vfsops.c Mon May 21 22:06:40 2007
+++ ffs_vfsops.c Mon May 21 22:07:35 2007
@@ -979,10 +979,12 @@
if (fs->fs_ronly == 0) {
fs->fs_clean = fs->fs_flags & (FS_UNCLEAN|FS_NEEDSFSCK) ? 0 : 1;
error = ffs_sbupdate(ump, MNT_WAIT, 0);
- if (error) {
+ if (error && (error & ENXIO) == 0) {
fs->fs_clean = 0;
return (error);
}
+ if (error & ENXIO)
+ error = 0;
}
DROP_GIANT();
g_topology_lock();Хоть кто нибудь попробуйте)))
>Хоть кто нибудь попробуйте)))
Попробовал. Всё прекрасно работает. Автору СПАСИБО.
Единственное пожелание - может стоит эти патчи выложить в виде
файлов, а то пришлось всё вбивать руками (copy-paste не прокатил).
>
>
>>Хоть кто нибудь попробуйте)))
>
>Попробовал. Всё прекрасно работает. Автору СПАСИБО.
>
>Единственное пожелание - может стоит эти патчи выложить в виде
>файлов, а то пришлось всё вбивать руками (copy-paste не прокатил).Дык некуда)))
Я в списки рассылки отправил, там можно файлы взять, или у меня попросить)))
Спасибо что попробовал)
>>
>>
>>>Хоть кто нибудь попробуйте)))
>>
>>Попробовал. Всё прекрасно работает. Автору СПАСИБО.
>>
>>Единственное пожелание - может стоит эти патчи выложить в виде
>>файлов, а то пришлось всё вбивать руками (copy-paste не прокатил).
>
>Дык некуда)))
Прям некуда?
Стукните в аську, могу положить на сервер, для всеобщего доступа.
icq 81340020.
>>>
>>>
>>>>Хоть кто нибудь попробуйте)))
>>>
>>>Попробовал. Всё прекрасно работает. Автору СПАСИБО.
>>>
>>>Единственное пожелание - может стоит эти патчи выложить в виде
>>>файлов, а то пришлось всё вбивать руками (copy-paste не прокатил).
>>
>>Дык некуда)))
>Прям некуда?
>Стукните в аську, могу положить на сервер, для всеобщего доступа.
>icq 81340020.Ну возможно это смешно, но аськи у меня нету, я деревенский))) Если серьёзно то попозже зарегистрирую, а пока пишите на мыло.
>Какой Русский коммитер может это заценить, английский знаю плохо))) поэтому в списки
>рассылки не суюсь)))Напишите Константину Белоусову (kib@freebsd.org), из наших коммитеров, мне кажется, его зона интересов ближе всего.
>>Какой Русский коммитер может это заценить, английский знаю плохо))) поэтому в списки
>>рассылки не суюсь)))
>
>Напишите Константину Белоусову (kib@freebsd.org), из наших коммитеров, мне кажется, его зона интересов
>ближе всего.Написал, пока тихо, мне его рекомендовал Руслан Ермилов.
Кстати эти патчи работают не только на 6.2-RELEASE, но и на 6.2-STABLE (на 28.05.2007).
А можно ли сделать такой же набор для CDROM, с ними тоже иногда
бывают проблемы ( например если смонтирован cdrom с дистрибом и запустить sysinstall)?
>Кстати эти патчи работают не только на 6.2-RELEASE, но и на 6.2-STABLE
>(на 28.05.2007).
>А можно ли сделать такой же набор для CDROM, с ними тоже
>иногда
>бывают проблемы ( например если смонтирован cdrom с дистрибом и запустить sysinstall)?
>Сделать можно все))) Главное, это воспроизвести эту проблему у себя. К сожалению(может к счастью) я с такой проблемой не сталкивался. Более подробно действия опиши, которые приводят к краху.
>Сделать можно все))) Главное, это воспроизвести эту проблему у себя. К
>сожалению(может к счастью) я с такой проблемой не сталкивался. Более подробно
>действия опиши, которые приводят к краху.1. Когда смонтирован дистрибутив Freebsd ( mount /cdrom )
и при этом запустить sysinstall - panic, kernel dump и т д , но это бывает редко.2. При чтении с повреждённого диска команда umount /cdrom часто приводит к panic, kernel dump
точно-точно! я на это налетал тоже +1
>1. Когда смонтирован дистрибутив Freebsd ( mount /cdrom )
>и при этом запустить sysinstall - panic, kernel dump и т д
>, но это бывает редко.
>
>2. При чтении с повреждённого диска команда umount /cdrom часто приводит к
>panic, kernel dump
Найду хреновый диск, попробую, но сам не сталкивался.
>Найду хреновый диск, попробую, но сам не сталкивался.
Печально, но у меня краха нет. Ищите другие баги.
К сожалению ни один коммитер мне не ответил по существу, поэтому эти патчи так и останутся попыткой, что то исправить не только для себя. Очень жаль.
>>Найду хреновый диск, попробую, но сам не сталкивался.
>Печально, но у меня краха нет. Ищите другие баги.
>К сожалению ни один коммитер мне не ответил по существу, поэтому эти
>патчи так и останутся попыткой, что то исправить не только для
>себя. Очень жаль.Всё не так уж плохо :-). У меня они уже стоят на диске 6.2-RELEASE-p5.
Может быть уже начали переписывать usb-стек, как и обещали, поэтому такая вялая реакция?
>Всё не так уж плохо :-). У меня они уже стоят на
>диске 6.2-RELEASE-p5.
>
>Может быть уже начали переписывать usb-стек, как и обещали, поэтому такая вялая
>реакция?Ну дело не совсем в usb стеке, скорее в VFS, а че за исправления добавили??? Можно поподробней)))
Большой респект автору патча!
Я тоже планировал поработать над этим,только руки еще не дошли. счас расковыриваю jail, надо сделать:
1. лимит юзания проца, но не жесткий,скажем 40% итп,а приоритетливый,те юзать свободное процессорное время,вернее хавать времени чуть-чуть(выставляется),а остальное,если есть свободное.
2. лимит рамы. тут уже жестко. 2мб,значит 2 :)
это все должно действовать на весь jail целиком,без разбору,в сумме. и плюс в нутри каждого jail-а могут работать свои login.conf лимиты.
ну и виртуального рута,отмапленого на хостовой системе,скажем на nobody или выборочно на какой-то uid для каждого jail отдельно.
И еще жесткие лимиты распространить на root-а на хостовой системе,чтобы при определенной sysctl, равной 1(и ее нельзя декрейсить,подобно kern.securelevel,по умолчанию 0,но можно инкрейсить) нельзя было увиличить себе rlimit,только уменьшить.
Есть какай-то реализация в perforce, jail2 называется,но я ее не копал
>Есть какай-то реализация в perforce, jail2 называется,но я ее не копал
это моя поделка :)
щас в связи с сменой работы времени стало совсем мизер, но если надо могу подсказать куда копать что бы сделать это.
>Большой респект автору патча!
>Я тоже планировал поработать над этим,только руки еще не дошли. счас расковыриваю
>jail, надо сделать:
>1. лимит юзания проца, но не жесткий,скажем 40% итп,а приоритетливый,те юзать свободное
>процессорное время,вернее хавать времени чуть-чуть(выставляется),а остальное,если есть свободное.
тут вариантов по сути не много, самый простой и добавлящий неплохо оверхеад - это счетчик который накапливает использование CPU за HZ - и потом скипает треды в точке выбора.
просто - но когда у тебя много процессов в очереди на выполнение - не экономно.
более интересный вариант или лоторейный или fair share шедулеры - они заменяют собой 44BSD или ULE (и его доработку от Давида Ксю) на свой - тут можно добиться практически O(1). для примера можно глянуть как это сделано в OpenVZ или поискать наработки для 4.x/5.x по лоторейному шедулеру.>2. лимит рамы. тут уже жестко. 2мб,значит 2 :)
а вот тут определись какой рамы:
1) address space
2) resident size
3) resident + swap
4) реально аллоцированные странички памяти - с учетом того что память может шариться между задачами?
>это все должно действовать на весь jail целиком,без разбору,в сумме. и плюс
>в нутри каждого jail-а могут работать свои login.conf лимиты.
>ну и виртуального рута,отмапленого на хостовой системе,скажем на nobody или выборочно на
>какой-то uid для каждого jail отдельно.
аха. в jail2 это уже давно есть. называется разделение uid hash.
>И еще жесткие лимиты распространить на root-а на хостовой системе,чтобы при определенной
>sysctl, равной 1(и ее нельзя декрейсить,подобно kern.securelevel,по умолчанию 0,но можно инкрейсить)
>нельзя было увиличить себе rlimit,только уменьшить.
есть в jail2. rlimit ты можешь выставлять что угодно - а то что выставлено для контекста будет проверяться раньше.>Есть какай-то реализация в perforce, jail2 называется,но я ее не копал
;)
>>Всё не так уж плохо :-). У меня они уже стоят на
>>диске 6.2-RELEASE-p5.
>>
>>Может быть уже начали переписывать usb-стек, как и обещали, поэтому такая вялая
>>реакция?
>
>Ну дело не совсем в usb стеке, скорее в VFS, а че
>за исправления добавили??? Можно поподробней)))Вот ссылка:
http://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi?az=sh...