Модуль aufs тоже неплохо бы добавить ;)
Уф. Сразу-то сложно было? :) Если несрочно, то погоди, я постараюсь добраться до проверки для начала 2.6.27-tmc-tc-alt6 на предмет регрессов. Если срочно -- скажи.
(В ответ на комментарий №1) > Уф. Сразу-то сложно было? :) Дык не сообразил сходу, чего мне не хватает для полного счастья :) Я, кстати, даже спрашивал как-то: отчего в ALTSP для решения проблемы r/o root используется tmpfs вместо aufs - но никто не ответил :( > Если несрочно, то погоди, я постараюсь добраться до проверки для начала > 2.6.27-tmc-tc-alt6 на предмет регрессов. Если срочно -- скажи. Потерплю
Так, alt6 у меня работает вроде бы не хуже alt5 (и с autoload тоже теперь порядок). 2 led: у тебя случайно нет готового aufs для 2.6.27? :)
(В ответ на комментарий №3) > Так, alt6 у меня работает вроде бы не хуже alt5 (и с autoload тоже теперь > порядок). > > 2 led: у тебя случайно нет готового aufs для 2.6.27? :) Есть конечно. И aufs, и unionfs. И работают они они и по очереди, и одновременно.
Ожидается ли к понедельнику прогресс?
ping 2 led: а что значит есть? Я совсем не умею собирать альтовские ядра, но git-clone/gear-hsh я выполнить в состоянии. Есть ли, собственно, что выполнять или как сделать, чтоб было?
(В ответ на комментарий №6) > ping > > 2 led: а что значит есть? Я отвечал на вопрос: "...у тебя случайно нет...?" Мой ответ: "у меня есть". > Я совсем не умею собирать альтовские ядра, но > git-clone/gear-hsh я выполнить в состоянии. Есть ли, собственно, что выполнять > или как сделать, чтоб было? Я так думаю, что обратится к мейнтейнеру, обосновав необходимость aufs именно в tc-ядре (я, напрмер, не знаю зачем оно вам там)
(In reply to comment #6) > ping pong > 2 led: а что значит есть? Я совсем не умею собирать альтовские ядра Вот мои рабочие заметки, по которым всё и собиралось: http://www.altlinux.org/Kernelnotes/mike Модули: http://www.altlinux.org/Сборка_модулей_ядра (In reply to comment #5) > Ожидается ли к понедельнику прогресс? Смотря какого года... PS: тебе точно aufs и никак иначе? Только отошёл от проведения конференции (это ещё очень быстро) и разгрёб чуточку хвостов по работе.
(В ответ на комментарий №8) > (In reply to comment #6) > > ping > pong > > > 2 led: а что значит есть? Я совсем не умею собирать альтовские ядра > Вот мои рабочие заметки, по которым всё и собиралось: > http://www.altlinux.org/Kernelnotes/mike > > Модули: http://www.altlinux.org/Сборка_модулей_ядра Спасибо, как припрет - попробую > (In reply to comment #5) > > Ожидается ли к понедельнику прогресс? > Смотря какого года... > > PS: тебе точно aufs и никак иначе? Только отошёл от проведения конференции > (это ещё очень быстро) и разгрёб чуточку хвостов по работе. Угу, у меня довольно специфические чруты получаются, которые мне удобнее собирать отдельно средствами mkimage. Большая часть кода ALTSP при этом не используется (но я поглядываю туда временами), проблема r/o root решается с помощью aufs, ядро std-def, как ни странно, на имеющемся железе ведет себя в целом приемлемо. Хочется все же съехать на tmc-tc - да вот незадача ... ;)
(В ответ на комментарий №9) > ядро std-def, как ни странно, на имеющемся железе ведет себя в > целом приемлемо. Хочется все же съехать на tmc-tc - да вот незадача ... ;) Зачем "съезжать" на tmc-tc? Это не универсальное ядро.
(В ответ на комментарий №10) > (В ответ на комментарий №9) > > > ядро std-def, как ни странно, на имеющемся железе ведет себя в > > целом приемлемо. Хочется все же съехать на tmc-tc - да вот незадача ... ;) > > Зачем "съезжать" на tmc-tc? Это не универсальное ядро. Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно отдельно собранный аналогичным образом (mkimage) чрут.
(В ответ на комментарий №11) > Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно > отдельно собранный аналогичным образом (mkimage) чрут. Так при чём тут ядро? Почему специализированное (причём специализированное явно не для ваших задач) tmc-tc, а не std-def?
(В ответ на комментарий №12) > (В ответ на комментарий №11) > > Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно > > отдельно собранный аналогичным образом (mkimage) чрут. > > Так при чём тут ядро? Почему специализированное (причём специализированное явно > не для ваших задач) tmc-tc, а не std-def?
(В ответ на комментарий №12) > (В ответ на комментарий №11) > > Съезжать в тех случаях, где ALTSP применим, но субъективно удобнее именно > > отдельно собранный аналогичным образом (mkimage) чрут. > > Так при чём тут ядро? Почему специализированное (причём специализированное явно > не для ваших задач) tmc-tc, а не std-def? Ну почему же специализированное не для моих задач? Я бы так не сказал судя по http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog. Повторюсь: задачи аналогичны задачам, решаемым с помощью ALTSP, но клиентский чрут формируется другим (более удобным мне) способом. Этот способ некоторым даже снился - http://lists.altlinux.org/pipermail/ltsp-server/2008-May/001492.html - но потом, видимо, отпустило :) Меня же пока еще нет (тем более что пропагатор - не причина) ;)
(В ответ на комментарий №14) > Ну почему же специализированное не для моих задач? Тогда возвращаемся к нашим (или вашим?) баранам: ядро tmc - для тонких бездисковых клиентов. Зачем вам aufs на тонких бездисковых клиентах? Это просто вопрос, чтобы уточнить потребности - не более того. > Я бы так не сказал судя по > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog. А что по этому можно судить?
(В ответ на комментарий №15) > (В ответ на комментарий №14) > > Ну почему же специализированное не для моих задач? > > Тогда возвращаемся к нашим (или вашим?) баранам: ядро tmc - для тонких > бездисковых клиентов. Зачем вам aufs на тонких бездисковых клиентах? Это просто > вопрос, чтобы уточнить потребности - не более того. aufs мне для перемонтирования корня из r/o в r/w. Я в курсе, что в ALTSP обошлись без aufs, используя, как я понял, дополнительное монтирование нужных каталогов, размещенных на tmpfs - верно? Я уже спрашивал (в т.ч. чуть выше) о причинах этого решения - оно экономит какие-то ресурсы? Для быстрого решения проблемы и для последующей отладки aufs мне оказалось удобнее, тем более, что в live и rescue из m-p-d этот способ уже используется. > > Я бы так не сказал судя по > > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog. > > А что по этому можно судить? Пожалуй, ничего - это так, напомнить мечтавшему :)
> > > Я бы так не сказал судя по > > > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog. > > > > А что по этому можно судить? > > Пожалуй, ничего - это так, напомнить мечтавшему :) Э ... попутал ссылку :)
> > Я бы так не сказал судя по > > http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-tmc-tc/changelog. > > А что по этому можно судить? Ну как что - отключенные и включенные фичи по сравнению std-def
(В ответ на комментарий №16) > (В ответ на комментарий №15) > aufs мне для перемонтирования корня из r/o в r/w. Я в курсе, что в ALTSP > обошлись без aufs, используя, как я понял, дополнительное монтирование нужных > каталогов, размещенных на tmpfs - верно? Не совсем. > Я уже спрашивал (в т.ч. чуть выше) о > причинах этого решения - оно экономит какие-то ресурсы? Да. > Для быстрого решения > проблемы Какой проблемы? Почему вы не указываете, в чём именно проблема? > и для последующей отладки aufs мне оказалось удобнее, тем более, что в > live и rescue из m-p-d этот способ уже используется. Это не аргумент. Ещё раз повторяю: tmc-tc - это СПЕЦИАЛИЗИРОВАННОЕ ядро для ТОНКИХ БЕЗДИСКОВЫХ клиентов. Для других случаев стОит использовать ДРУГИЕ специализированное ядро или, за неимением такового, универсальное ядро. Цели tmc-tc: 1) Минимальный размер (даже в ущерб 5% падения производительности) 2) Образание всего, что не нужно для поставленной задачи (для достижения п.1) 3) Избежание дэдлоков при сетевом свопе Ядро tmc используется для запуска ТОЛЬКО X-сервера и минимального набора сервисов. Т.о. если у вас запускается что-то кроме вышеперечисленного, то ядро tmc-tc не только безсполезно, но и вредно
Ох, у нас с вами хроническое непонимание друг друга ... Устраивают меня цели tmc-tc и use case у меня в данном случае аналогичный. Не хватает всего лишь aufs. Проблема (о которой я "не говорю" :) ) - это перемонтирование корня из r/o в r/w, и проблема она потому, что способ, используемый в ALTSP, может и эффективнее с точки зрения экономии ресурсов, но мне неудобен.
(In reply to comment #9) > Угу, у меня довольно специфические чруты получаются, которые мне удобнее > собирать отдельно средствами mkimage. Вообще есть желание втащить сборку чрута под mkimage, поскольку иначе не сделать livecd'шку, да и каждый раз при установке делать одно и то же (инвариантное относительно пакетной базы) смысла большого нет -- кроме разве реюза RPMS.main и экономии сотни или двух мегабайт в образе. Что уже CD не спасёт, если openoffice оттуда не грохнуть, а на DVD запас пока есть. Так что если что это получится обобщить -- буду рад, а раз тебе по сути не особо-то и надо именно tmc-tc -- может, ну его? :) (In reply to comment #19) [да] > Т.о. если у вас запускается что-то кроме вышеперечисленного, > то ядро tmc-tc не только безсполезно, но и вредно А вот с последним словом как $PACKAGER не могу согласиться. Работает -- и ладно, специального вреда туда не закладывалось -- только отсутствие потенциальной пользы. И кстати, ты ещё pulseaudio как минимум забыл упомянуть. :)
(В ответ на комментарий №21) > (In reply to comment #9) > > Угу, у меня довольно специфические чруты получаются, которые мне удобнее > > собирать отдельно средствами mkimage. > > Т.о. если у вас запускается что-то кроме вышеперечисленного, > > то ядро tmc-tc не только безсполезно, но и вредно > А вот с последним словом как $PACKAGER не могу согласиться. Это твоё право - не соглашаться. Но использовать tmc-tc в качестве универсального - вредно. В том числе и из-за того, что пользователи начинают требовать от него универсальности и развешывать баги об отсутствующей в нём функциональности. > Работает -- и > ладно, специального вреда туда не закладывалось -- только отсутствие > потенциальной пользы. И кстати, ты ещё pulseaudio как минимум забыл упомянуть. > :) Не забыл. Читай внимательнее - "...и минимального набора сервисов"
Насколько понимаю, Женя косится в сторону client/initramfs/hooks/ltsp_nbd и client/initramfs/scripts/ltsp_nbd. Другое дело, что я сейчас NBD как штатный корень всё равно не использую... PS: despam CC:
(В ответ на комментарий №23) > Насколько понимаю, Женя косится в сторону client/initramfs/hooks/ltsp_nbd и > client/initramfs/scripts/ltsp_nbd. Другое дело, что я сейчас NBD как штатный > корень всё равно не использую... nbd вместо nfs для корня - абсолютно ортогонально к aufs
(В ответ на комментарий №21) > (In reply to comment #9) > > Угу, у меня довольно специфические чруты получаются, которые мне удобнее > > собирать отдельно средствами mkimage. > Вообще есть желание втащить сборку чрута под mkimage, поскольку иначе не > сделать livecd'шку, да и каждый раз при установке делать одно и то же > (инвариантное относительно пакетной базы) смысла большого нет -- кроме разве > реюза RPMS.main и экономии сотни или двух мегабайт в образе. Что уже CD не > спасёт, если openoffice оттуда не грохнуть, а на DVD запас пока есть. > > Так что если что это получится обобщить -- буду рад, а раз тебе по сути не > особо-то и надо именно tmc-tc -- может, ну его? :) Ну как это ну его? ;) Я понимаю и не тороплю, собственно и сам может когда сделаю и проверю ощущения, если ты не доберешься. Просто сейчас на std-def есть проблемы с несколькими экземплярами Х и потреблением памяти nxclient'ом - просто пока вроде придумали, как обойтись без того и другого. А насчет обобщить - до того надо, как уже led@ упоминал, разрезать ltsp-server на собственно ltsp-server и ltsp-chroot-build c выделением некоего ltsp-common. И какие, кстати, технические причины делать livecd средствами mkimage? Делается ведь почти это сейчас без mkimage? Или цель - унификация инструментов и кода? > (In reply to comment #19) > [да] > > > Т.о. если у вас запускается что-то кроме вышеперечисленного, > > то ядро tmc-tc не только безсполезно, но и вредно > А вот с последним словом как $PACKAGER не могу согласиться. Работает -- и > ладно, специального вреда туда не закладывалось -- только отсутствие > потенциальной пользы. И кстати, ты ещё pulseaudio как минимум забыл упомянуть. > :) да - мне оно пока не надо, но может позже и пригодится
(В ответ на комментарий №24) > (В ответ на комментарий №23) > > Насколько понимаю, Женя косится в сторону client/initramfs/hooks/ltsp_nbd и > > client/initramfs/scripts/ltsp_nbd. Другое дело, что я сейчас NBD как штатный > > корень всё равно не использую... > > nbd вместо nfs для корня - абсолютно ортогонально к aufs Именно - в моем случае aufs необходим и для загрузки с nfs
(В ответ на комментарий №22) > (В ответ на комментарий №21) > > (In reply to comment #9) > > > Угу, у меня довольно специфические чруты получаются, которые мне удобнее > > > собирать отдельно средствами mkimage. > > > Т.о. если у вас запускается что-то кроме вышеперечисленного, > > > то ядро tmc-tc не только безсполезно, но и вредно > > А вот с последним словом как $PACKAGER не могу согласиться. > > Это твоё право - не соглашаться. Но использовать tmc-tc в качестве > универсального - вредно. В том числе и из-за того, что пользователи начинают > требовать от него универсальности и развешывать баги об отсутствующей в нём > функциональности. Я понимаю эти опасения, но полагаю, что иметь aufs в tmc-tc не слишком дорого и противоестественно ;)
(В ответ на комментарий №26) > Именно - в моем случае aufs необходим и для загрузки с nfs Использование nbd или nfs в качестве RO-корня в этом плане ничем не отличается. Более того, я тестировал и nfs и nbd RO-корня - никаких отличий, которые могли бы потребовать aufs
(В ответ на комментарий №27) > Я понимаю эти опасения, но полагаю, что иметь aufs в tmc-tc не слишком дорого и противоестественно ;) Использовать aufs на тонком бездисковом клиенте - дорого. И нецелесообразно. Вы так и не указали, для чего не хватает mount, mount --bind
(В ответ на комментарий №29) > (В ответ на комментарий №27) > > Я понимаю эти опасения, но полагаю, что иметь aufs в tmc-tc не слишком дорого и противоестественно ;) > > Использовать aufs на тонком бездисковом клиенте - дорого. И нецелесообразно. Вы > так и не указали, для чего не хватает mount, mount --bind В принципе хватает, только слишком много mount, mount --bind нужно. Все они локализованы где-то в одном месте или размазаны по shell-коду ALTSP? Покажите место локализации (я сходу не нашел, но возможно плохо искал) - и я подумаю, насколько трудоемко мне будет использовать аналогичный механизм (правда не только для бездисковых клиентов - aufs-то я выбрал именно как универсальный способ превращения r/o в r/w).
(В ответ на комментарий №30) > > так и не указали, для чего не хватает mount, mount --bind > > В принципе хватает, только слишком много mount, mount --bind нужно. Зачем "много mount"? Достаточно одного. А mount --bind - столько, сколько нужно. > Все они > локализованы где-то в одном месте или размазаны по shell-коду ALTSP? Покажите > место локализации (я сходу не нашел, но возможно плохо искал) /etc/rc.d/scripts/ltsp-client-bind-mounts - собственно, сам монтировщик /etc/default/ltsp-client-setup - конфиг к нему - и я подумаю, > насколько трудоемко мне будет использовать аналогичный механизм (правда не > только для бездисковых клиентов - aufs-то я выбрал именно как универсальный > способ превращения r/o в r/w). "универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий бездисковый клиент"
(In reply to comment #25) > И какие, кстати, технические причины делать livecd средствами mkimage? Да сам livecd-то я сделать могу. А вот ltsp-build-client как раз и сняли с использования hasher, поскольку выглядела установка пару лет назад "под капотом" как: создаём левого юзера, hasher-useradd, потом им собираем чрут, потом (кажется) растариваем с нужными правами. То есть у нас на руках всё равно рут, а мы бегаем огородами через псевдопользователя. Ну и во времена собирания образа при помощи spt пытаться это туда интегрировать хорошей идеей не показалось. > Делается ведь почти это сейчас без mkimage? Сейчас инсталятор (не livecd с LTSP) собирается mkimage, а вот чрут собирается после установки пакетной базы (каждый раз). > Или цель - унификация инструментов и кода? И это тоже. (In reply to comment #29) > Использовать aufs на тонком бездисковом клиенте - дорого. А там не просто модуль, а ещё и статиком что-то зацепится? (для общего образования) > И нецелесообразно. Скажем так -- лично я бы всё равно предпочёл обождать, пока aufs в ядро примут (и для такого ядра будет доступен vm_deadlock patch или каким-то чудом его тоже интегрируют), поскольку сейчас есть и работает tmpfs.
(В ответ на комментарий №32) > > Использовать aufs на тонком бездисковом клиенте - дорого. > А там не просто модуль, а ещё и статиком что-то зацепится? (для общего > образования) Ну, вообще-то изначально только статиком, но я начил его собираться и работать модулем. Дорого - в runtime. Зачем лишний оверхэд, когда можно обойтись обычным тривиальным стандартным bind'ом? > > И нецелесообразно. > Скажем так -- лично я бы всё равно предпочёл обождать, пока aufs в ядро примут > (и для такого ядра будет доступен vm_deadlock patch или каким-то чудом его тоже > интегрируют), поскольку сейчас есть и работает tmpfs. Ты путаешь: tmpfs в любом случае придётся использовать - иначе куда ты будешь биндить тем же aufs'ом? Вот поэтому я и спрашиваю: почему не биндить с помощью стандартного mount --bind/--rbind, а заюзывать для этого ещё одну лишнюю сущность? чего не хватает в mount --bind?
(В ответ на комментарий №25) > А насчет обобщить - до того надо, как уже led@ упоминал, разрезать ltsp-server > на собственно ltsp-server и ltsp-chroot-build c выделением некоего ltsp-common. хочешь попилить? ;> http://git.altlinux.org/people/prividen/packages/ltsp.git
> Зачем "много mount"? Достаточно одного. > А mount --bind - столько, сколько нужно. > > > Все они > > локализованы где-то в одном месте или размазаны по shell-коду ALTSP? Покажите > > место локализации (я сходу не нашел, но возможно плохо искал) > > /etc/rc.d/scripts/ltsp-client-bind-mounts - собственно, сам монтировщик > /etc/default/ltsp-client-setup - конфиг к нему спасибо > - и я подумаю, > > насколько трудоемко мне будет использовать аналогичный механизм (правда не > > только для бездисковых клиентов - aufs-то я выбрал именно как универсальный > > способ превращения r/o в r/w). > > "универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий > бездисковый клиент" Пожалуй. Но сейчас полезнее иметь _универсальный_ способ превращения r/o в r/w, который в т.ч. можно (пусть и с некоторыми накладными расходами) использовать и для бездискового тонкого клиента. Поэтому я попробую прикрутить aufs и с вопросами пойду в devel-newbies@
> > "универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий > > бездисковый клиент" > > Пожалуй. Но сейчас полезнее ... Уточню, что мне полезнее :)
(В ответ на комментарий №35) > > "универсальный способ превращения r/o в r/w" - не есть задача в рамках "тонкий > > бездисковый клиент" > > Пожалуй. Но сейчас полезнее иметь _универсальный_ способ превращения r/o в r/w, Тогда вам нужно универсальное ядро. > который в т.ч. можно (пусть и с некоторыми накладными расходами) использовать и > для бездискового тонкого клиента. Уриверсальное ядро добавляет "некоторые накладные расходы" при использовании на бездисковых тонких коиентах. "серебряной пули" нет :(
Насколько я понимаю, тащить fix-vm_deadlock и отключение ненужных фич в универсальное ядро будет труднее. Впрочем, утащить ваш feat-fs-aufs в tmc-tc у меня тоже сходу не вышло. Я втянул его из people/led/packages/kernel-image-2.6.27-tmc.git, добавил генерацию и использование соответствующего патча в .gear/rules в спеке, обновил kernel-source (из вашего же upstream) и бранчи патчей (fix-vm_deadlock и feat-fs-squashfs), перегенерил тэги, и в результате сборки получил: fs/aufs/vfsub.c: In function 'vfsub_splice_to': fs/aufs/vfsub.c:404: error: implicit declaration of function 'vfs_splice_to' fs/aufs/vfsub.c: In function 'vfsub_splice_from': fs/aufs/vfsub.c:417: error: implicit declaration of function 'vfs_splice_from' Боюсь, что в devel-newbies@ мне предложат тянуть aufs из апстрима, а я уж было позарился на возможность сборки модулем, а не статиком. Может вы подскажете, чего ему может не хватать и собирается ли оно вообще так просто с 2.6.27.37?
(В ответ на комментарий №38) > Насколько я понимаю, тащить fix-vm_deadlock и отключение ненужных фич в > универсальное ядро будет труднее. > > Впрочем, утащить ваш feat-fs-aufs в tmc-tc у меня тоже сходу не вышло. Потому что нужны ещё fix-fs-splice и fix-security. Без них не соберётся.
(В ответ на комментарий №38) > Насколько я понимаю, тащить fix-vm_deadlock и отключение ненужных фич в > универсальное ядро будет труднее. А зачем его тащить? fix-vm_deadlock нужен только для клиентов с сетевым свопом. Вы всё-таки пытаетесь на^Wобмануть судьбу и отлить "серерянную пулю" (сделать одно ядро и для экспериментов, и для надёжной работы тонких бездисковых клиентов)?:) Удачи! Но я здесь вам не помошник.
Собрал в http://git.altlinux.org/people/enp/packages/kernel-image.git, однако обмануть судьбу и вправду пока не выходит - все глюки, что я списывал было на дедлоки при сетевом свопе, на месте :( Собственно, сами глюки: * Невозможно переключиться из Х обратно на любую из виртуальных консолей * Зависание при выключении с руганью вида "/sbin/halt: Input/output error" - наблюдается исключительно в случаях загрузки с nbd Причем и то, и другое зависит непонятно от чего - то воспроизводится, то нет.
В общем, фичреквест понятен, но смыслу его реализовывать не обнаружено. Спасибо вам обоим за терпение и понимание.
