16706 2008-08-15 23:18:20 +0400 [FR] Сборка на tmpfs 2010-12-28 00:04:26 +0300 1 1 4 Development Sisyphus hasher unstable all Linux NEW P2 enhancement --- 1 dottedmag ldv at erthad evg glebfm kas ldv legion mike placeholder vvk qa-sisyphus oldest_to_newest 75549 0 dottedmag 2008-08-15 23:18:20 +0400 Хочется увидеть в самом hasher возможность сборки пакетов на tmpfs, дабы не приходилось пользоваться кустарными методами, типа описанного в http://www.altlinux.org/TmpFS 75552 1 2787 dottedmag 2008-08-16 01:22:15 +0400 Created attachment 2787 Первая реализация Реализация сборки на tmpfs в виде враппера вокруг hsh. Вместо workdir принимает repodir (как непосредственно видимую пользователю). 75573 2 legion 2008-08-17 13:46:19 +0400 Я не понял назначение этого скрипта. Мне не понятно почему сложно выполнить команду из exec руками. Например так, если у вас /tmp на tmpfs: hsh --repo=~/tmp $TMPDIR <SRPM> Этот скрипт безусловно не реализация сборки на tmpfs т.к. в скрипте tmpfs не упоминается вообще. Скрипт только генерирует WORKDIR самостоятельно в /tmp/.private, а он не обязательно должен быть на tmpfs. Зачем используется gear-sh-functions ? Это пользовательский скрипт и он должен замаскировать работу с WORKDIR, но вы не проверяете можно ли собирать /tmp/.private. Так и задумано? После выполнения скрипта в /tmp/.private/$USER/ будут копиться WORKDIR от разных репозитриев. Если предположить что /tmp/.private на tmpfs, то такой подход будет просто замусоривать память. Пользователю будет не очевидно, что потом ему нужно идти в /tmp/.private/$USER/, искать созданный каталог и чистить его т.к. никаких сообщений о том как называется WORKDIR не выводится. Пока писал, подумал вот о чём: А зачем выделаете разные WORKDIR для разных репозиториев? hasher всё равно кэширует только базовую часть репозитория. Мне думается, что с учётом того что вы вынесли REPO из WORKDIR, в создании разных WORKDIR нет смысла. 75574 3 dottedmag 2008-08-17 14:09:04 +0400 (In reply to comment #2) > Я не понял назначение этого скрипта. Мне не понятно почему сложно выполнить > команду из exec руками. Несложно. Только на двадцатый-тридцатый-пятидесятый-сотый раз начинает надоедать подпихивать аргументы ручками в два-три разных хэшерницы и тогда садишься писать ровно такой же скрипт. Зачем каждому человеку писать аналогичный скрипт, когда можно положить готовую реализацию, которая покроет 80% (с потолка) потребностей? > Этот скрипт безусловно не реализация сборки на tmpfs т.к. в скрипте tmpfs не > упоминается вообще. Скрипт только генерирует WORKDIR самостоятельно в > /tmp/.private, а он не обязательно должен быть на tmpfs. Да, это проблема. См. ниже. > Зачем используется gear-sh-functions ? По ошибке. > Это пользовательский скрипт и он должен замаскировать работу с WORKDIR, но вы > не проверяете можно ли собирать /tmp/.private. Так и задумано? Ошибка. > После выполнения скрипта в /tmp/.private/$USER/ будут копиться WORKDIR от > разных репозитриев. Если предположить что /tmp/.private на tmpfs, то такой > подход будет просто замусоривать память. Пользователю будет не очевидно, что > потом ему нужно идти в /tmp/.private/$USER/, искать созданный каталог и > чистить его т.к. никаких сообщений о том как называется WORKDIR не выводится. Это вопрос, который стоит обсудить. Тут я вижу два выхода: 1) Сборка на создаваемом/очищаемом tmpfs - тогда проблемы с мусором не будет, но не будет и возможности воспользовать --lazy-cleanup. Кроме того, в этом случае придётся дополнительно хранить cache рядом или внутри репозитория. 2) Сборка как сейчас (с дополнительной проверкой на то, что workdir располагается на tmpfs) и дополнительная утилита hsh-tmpfs-cleanup. В этом случае весь функционал hasher сохраняется, но появляется дополнительная "ручка", которую нужно периодически дёргать. > Пока писал, подумал вот о чём: А зачем выделаете разные WORKDIR для разных > репозиториев? hasher всё равно кэширует только базовую часть репозитория. Мне > думается, что с учётом того что вы вынесли REPO из WORKDIR, в создании разных > WORKDIR нет смысла. А если репозитории разные? 75576 4 legion 2008-08-17 14:22:01 +0400 (In reply to comment #3) > Это вопрос, который стоит обсудить. > > Тут я вижу два выхода: Есть выход использовать только один WORKDIR. Тогда копиться ничего не будет и cache будет на месте. Минусы подхода: 1) Нужна дополнительная работа по прописыванию REPO в sources.list в случае, если репозитории разные. Это не сложно. 2) Пользователь должен знать о WORKDIR, чтобы иметь возможность её удалить. И таким образом совсем спрятать WORKDIR не получится... хотя такой задачи и не ставится. > А если репозитории разные? см. выше пункт #1. 75577 5 dottedmag 2008-08-17 14:29:32 +0400 (In reply to comment #4) > Есть выход использовать только один WORKDIR. Тогда копиться ничего не будет и > cache будет на месте. А как осуществлять переключение "я хочу собрать этот пакет в среде branch/4.0"? --apt-conf при каждом запуске? Но при использовании hsh очень удобно при создании workdir указать настройки и в дальнейшем просто показывать на нужную директорию. Хочется и с hsh-tmpfs добиться того же результата. > 2) Пользователь должен знать о WORKDIR, чтобы иметь возможность её удалить. И > таким образом совсем спрятать WORKDIR не получится... хотя такой задачи и не > ставится. С этим согласен - удалять её (или их, если их много) всё равно кому-нибудь придётся. 75578 6 legion 2008-08-17 14:56:57 +0400 (In reply to comment #5) > Хочется и с hsh-tmpfs добиться того же результата. Но hsh в этом плане проще. Пользователь сам говорит, что он хочет и явно указывает WORKDIR. В случае hsh-tmpfs это сделать намного сложнее. Чтобы добиться такого же эффекта и не идти по экстенсивному пути с множественными WORKDIR, придётся городить своё вспомогательное хранилище, где сохранять sources.list и cache-dir для каждого REPO. А при переключении с одного REPO на другой выполнять --clean на WORKDIR. 75579 7 dottedmag 2008-08-17 15:02:44 +0400 А чем плох экстенсивный путь? Между workdir и repodir сохраняется соответствие 1-1. Если дополнительно утащить cache на диск, внурь repodir, то размер workdir будет совсем небольшим. 75580 8 kas 2008-08-17 15:04:55 +0400 Я поступил проще. У меня в fstab есть строчка: tmpfs /home/kas/hasher tmpfs size=4G 0 0 Мне хватает. 75581 9 dottedmag 2008-08-17 15:19:42 +0400 Для одной машины и для одного хашера я и сам руками в fstab чего-нибудь напишу. Вопрос совершенно не в этом. 75586 10 legion 2008-08-17 18:29:57 +0400 (In reply to comment #7) > А чем плох экстенсивный путь? Между workdir и repodir сохраняется > соответствие 1-1. Тем что он экстенсивный :) Я понимаю, вы хотите держать по одному REPO на каждый бранч. Но ведь есть люди, которые делают отдельный REPO на пакет (или зависимую группу пакетов). Это не противоречит идее hasher. И в этом случае WORKDIR'ов у пользователя будет больше. > Если дополнительно утащить cache на диск, внурь repodir Как раз cache стабилен по размеру и меняется не часто и не сильно. Ведь это базовая часть *любого* чрута для сборки. Если из WORKDIR убрать cache, repo и aptbox (как я фактически предлагаю), то в WORKDIR останется лишь одна директория, которая пересоздаётся для каждой сборки: chroot. Именно (aptbox + cache) соотносится с repo 1-1. > то размер workdir будет совсем небольшим. "Небольшой WORKDIR" понятие относительное. WORKDIR после ash действительно мал относительно WORKDIR после openoffice.org (или mozilla.org). Просто вам везло с проектами (вот мне не везёт), но это не значит что нет больших проектов и то что их мантейнеры не захотят пользоваться вашей утилитой. 75589 11 dottedmag 2008-08-17 18:57:16 +0400 Понял идею. Тогда и правда наиболее удобным будет хранить всё, кроме chroot, в районе repo (точнее, сделать свой "workdir", в котором хранится всё, кроме chroot), и использовать один workdir, в котором только chroot, для всех сборок. Правда, вылезет бяка с --number, но и её можно обойти. Попробую сделать так. 76581 12 ldv 2008-08-29 20:29:56 +0400 Есть идея монтировать chroot на отдельный tmpfs во время сборки. Именно этот каталог используется наиболее интенсивно, он самый большой по размеру и числу файлов. По сравнению с обычной сборкой на tmpfs, cleanup после сборки таких пакетов как subversion существенно ускорится. Есть только одна проблема с этим подходом: как такое реализовать относительно безопасным для системы образом. 76584 13 legion 2008-08-29 20:50:27 +0400 (In reply to comment #12) > подходом: как такое реализовать относительно безопасным для системы > образом. А в чём проблема? У нас есть превилегированный хэлпер. Добавить в него ещё одну команду монтирования/размонтирования tmpfs. 76585 14 ldv 2008-08-29 20:53:52 +0400 (In reply to comment #13) > (In reply to comment #12) > > подходом: как такое реализовать относительно безопасным для системы > > образом. > > А в чём проблема? > > У нас есть превилегированный хэлпер. Добавить в него ещё одну команду > монтирования/размонтирования tmpfs. Непонятно, как это сделать безопасным для хост-системы. Чтобы обычный пользователь по ошибке не разбудил OOM killer. 76586 15 dottedmag 2008-08-29 20:56:16 +0400 Ввести лимит на максимальный суммарный размер tmpfs'ов, таким образом доступных пользователю? 76588 16 legion 2008-08-29 21:02:24 +0400 (In reply to comment #14) > Чтобы обычный пользователь по ошибке не разбудил OOM killer. Мне кажется, что от этого мы не сможем застраховаться т.к. мы заранее не знаем какой будет размер чрута. Кстати, вот ещё одна проблема: как узнать параметры tmpfs чтобы его хватило на чрут? Мы заранее не знаем сколько файлов будет создано и их размер. 76589 17 dottedmag 2008-08-29 21:05:05 +0400 (In reply to comment #16) > > Чтобы обычный пользователь по ошибке не разбудил OOM killer. > Мне кажется, что от этого мы не сможем застраховаться т.к. мы заранее не > знаем какой будет размер чрута. tmpfs нужного размера всегда можно выделить. Тогда не хост упадёт, а сборка сломается. > Кстати, вот ещё одна проблема: как узнать параметры tmpfs чтобы его хватило на > чрут? Мы заранее не знаем сколько файлов будет создано и их размер. Выставить ручку для регулирования в hsh. Если запрошено больше лимита - отлуплять, если нет ручки - выдать столько, сколько в лимите написано. 76591 18 legion 2008-08-29 21:16:17 +0400 (In reply to comment #17) > tmpfs нужного размера всегда можно выделить. Тогда не хост упадёт, а сборка > сломается. Если я правильно понял Диму, то речь шла о автоматическом создании tmpfs и расположении там chroot. В этом случае размер tmpfs и количество inodes предётся считать автоматически иначе в этом нет мысла. > Выставить ручку для регулирования в hsh. Если запрошено больше лимита - > отлуплять, если нет ручки - выдать столько, сколько в лимите написано. Чем это будет удобнее чем есть сейчас? Сейчас у нас есть /tmp на tmpfs определённого размера (это и есть лимит для обычных пользовтаелей), если пакет хочет больше места, то процесс сборки обламывается пока админ не увеличит лимит. 76619 19 ldv 2008-08-30 02:38:13 +0400 (In reply to comment #18) > (In reply to comment #17) > > tmpfs нужного размера всегда можно выделить. Тогда не хост упадёт, а сборка > > сломается. > > Если я правильно понял Диму, то речь шла о автоматическом создании tmpfs и > расположении там chroot. Конечно, об автоматическом создании и удалении. Причём основной выигрыш, помимо простоты использования, будет именно в существнном упрощении (в т.ч. с точки зрения защиты от атак со стороны пакетов) удаления чрута. > В этом случае размер tmpfs и количество inodes предётся > считать автоматически иначе в этом нет мысла. Автоматически по объёму доступной виртуальной памяти. Проблема в том, что избежать overcommit непросто (много пользователей, и каждый может завести много таких чрутов), а если не избежать, то можно устроить DoS на хост-систему. Пойдём в devel? 76625 20 legion 2008-08-30 03:18:29 +0400 (In reply to comment #19) > Конечно, об автоматическом создании и удалении. > Причём основной выигрыш, помимо простоты использования, будет именно в > существнном упрощении (в т.ч. с точки зрения защиты от атак со стороны > пакетов) удаления чрута. Значит я тебя правильно понял :) > Автоматически по объёму доступной виртуальной памяти. > Проблема в том, что избежать overcommit непросто (много пользователей, > и каждый может завести много таких чрутов), Если у каждого пользователя будет возможность создавать свои tmpfs, то overcommit не избежать. Если сделать единое место учёта пользовательских tmpfs, то overcommit ты избежишь, но пользователи смогут DoS'ить друг друга... хотя и сейчас при желании пользователи могут это делать. Но тут встают новые проблемы: Как делить память (tmpfs) на пользователей? Что делать, когда заводится новый пользователь, а лимит на память для пользователей исчерпан другими пользователями? Конечно, эти проблемы можно решить, если примерно знать сколько пользователей ожидается на данном сервере, но динамичность всего решения "каждый chroot в tmpfs" сильно уменьшается и ложится на плечи админа. Получается нечто подобное квотам... хотя почему подобное? Это именно квоты как есть, но по prefix'у каждого пользователя. > а если не избежать, то можно устроить DoS на хост-систему. Сейчас есть общий лимит tmpfs на /tmp и админ хост-системы может управлять общим количеством памяти, используемым под сборку. > Пойдём в devel? Пойдём. 86351 21 mike 2009-02-23 18:09:02 +0300 (In reply to comment #19) > а если не избежать, то можно устроить DoS на хост-систему. Дяденьки, а дяденьки -- форкбомба уже не работает? local DoS -- не то, чего стоит пытаться избежать любыми средствами, потому как слишком уж много вариантов на системе, которая хоть чем-то полезна. Так что я бы исходил из того, что автомат рассчитывает на одного сборщика и умеет куда-то смотреть -- а локальный админ уже может там сказать "поделить поровну на число состоящих в группе hashman", или задать циферку, на которую делить, или просто абсолютное значение лимита. > Пойдём в devel? BTW у меня от него сейчас отпуск. :) 2787 2008-08-16 01:22:15 +0400 2008-08-16 01:22:15 +0400 Первая реализация hsh-tmpfs text/plain 2472 dottedmag IyEvYmluL3NoCiMKIyBDb3B5cmlnaHQgKEMpIDIwMDggIE1pa2hhaWwgR3VzYXJvdiA8ZG90dGVk bWFnQGFsdGxpbnV4Lm9yZz4KIwojIGhzaCB3cmFwcGVyIGZvciBidWlsZGluZyBwYWNrYWdlcyBv biB0bXBmcwojCiMgVGhpcyBmaWxlIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli dXRlIGl0IGFuZC9vciBtb2RpZnkKIyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l cmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQojIHRoZSBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yCiMgKGF0IHlvdXIg b3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KIwojIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRl ZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAojIGJ1dCBXSVRIT1VUIEFOWSBX QVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiMgTUVSQ0hBTlRB QklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiBTZWUgdGhlCiMgR05V IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KIwojIFlvdSBzaG91bGQg aGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCiMg YWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdh cmUKIyBGb3VuZGF0aW9uLCBJbmMuLCA1MSBGcmFua2xpbiBTdCwgRmlmdGggRmxvb3IsIEJvc3Rv biwgTUEgMDIxMTAtMTMwMSwgVVNBLgojCgouIGdlYXItc2gtZnVuY3Rpb25zCi4gc2hlbGwtZ2V0 b3B0CgpwcmludF92ZXJzaW9uKCkKewogICAgICAgIGNhdCA8PEVPRgokUFJPRyB2ZXJzaW9uICRQ Uk9HX1ZFUlNJT04KV3JpdHRlbiBieSBNaWtoYWlsIEd1c2Fyb3YgPGRvdHRlZG1hZ0BhbHRsaW51 eC5vcmc+CgpDb3B5cmlnaHQgKEMpIDIwMDggIE1pa2hhaWwgR3VzYXJvdiA8ZG90dGVkbWFnQGFs dGxpbnV4Lm9yZz4KVGhpcyBpcyBmcmVlIHNvZnR3YXJlOyBzZWUgdGhlIHNvdXJjZSBmb3IgY29w eWluZyBjb25kaXRpb25zLiAgVGhlcmUgaXMgTk8Kd2FycmFudHk7IG5vdCBldmVuIGZvciBNRVJD SEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCkVPRgogICAg ICAgIGV4aXQKfQoKaGFzaF9yZXBvX2RpcigpIHsKICAgIGVjaG8gIiQxIiB8IHNlZCAtZSAncywv LF8sZycKfQoKR0VUT1BUX0FMTE9XX1VOS05PV049MQpURU1QPWBnZXRvcHQgLW4gJFBST0cgLW8g J2gsVicgLWwgJ3JlcG86LHJlcG8tYmluOixyZXBvLXNyYzosaGVscCx2ZXJzaW9uJyAtLSAiJEAi YCB8fCBzaG93X3VzYWdlCmV2YWwgc2V0IC0tICIkVEVNUCIKCndoaWxlIDo7IGRvCiAgICBjYXNl ICIkMSIgaW4KICAgICAgICAtLXJlcG98LS1yZXBvLWJpbnwtLXJlcG8tc3JjKQogICAgICAgICAg ICBvcHRpb249JDEKICAgICAgICAgICAgc2hvd191c2FnZSAiaHNoKDEpIG9wdGlvbiAkMSBpcyBu b3Qgc3VwcG9ydGVkIGluICRQUk9HIgogICAgICAgICAgICBleGl0CiAgICAgICAgICAgIDs7CiAg ICAgICAgLWh8LS1oZWxwKQogICAgICAgICAgICBoc2ggLWggfCBhd2sgJ0JFR0lOIHsgc2hvdz0x IH0KL15oc2gvIHsgJDE9ImhzaC10bXBmcyI7ICQ0PSJwYWNrYWdlIGluIHRtcGZzIiB9Ci9eVXNh Z2U6LyB7ICQwPSJVc2FnZTogaHNoLXRtcGZzIFtvcHRpb25zXSBbPHBhdGgtdG8tcmVwb2Rpcj5d IDxwYWNrYWdlPi4uLiIgfQovXjxwYXRoLXRvLXdvcmtkaXI+LyB7ICQxPSI8cGF0aC10by1yZXBv ZGlyPiIgfQovLS1yZXBvLyB7IHNob3c9MCB9Ci8tLXNhdmUtZmFrZXJvb3QvIHsgc2hvdz0xIH0K eyBpZihzaG93KSBwcmludCB9JwogICAgICAgICAgICBleGl0CiAgICAgICAgICAgIDs7CiAgICAg ICAgLVZ8LS12ZXJzaW9uKQogICAgICAgICAgICBwcmludF92ZXJzaW9uCiAgICAgICAgICAgIDs7 CiAgICAgICAgLS0pCiAgICAgICAgICAgIHNoaWZ0CiAgICAgICAgICAgIGJyZWFrCiAgICAgICAg ICAgIDs7CiAgICBlc2FjCiAgICBzaGlmdApkb25lCgppZiBbICQjIC1lcSAwIF07IHRoZW4KICAg IHNob3dfdXNhZ2UgIkF0IGxlYXN0IG9uZSBhcmd1bWVudCBpcyByZXF1aXJlZCIKZmkKClJFUE9E SVI9JDEKc2hpZnQKCm1rZGlyIC1wICIkUkVQT0RJUiIgfHwgc2hvd191c2FnZSAiVW5hYmxlIHRv IGNyZWF0ZSByZXBvc2l0b3J5IGluICRSRVBPRElSIgpSRVBPRElSPWByZWFscGF0aCAkUkVQT0RJ UmAKCldPUktESVI9L3RtcC8ucHJpdmF0ZS8kVVNFUi9gaGFzaF9yZXBvX2RpciAiJFJFUE9ESVIi YApta2RpciAtcCAiJFdPUktESVIiIHx8IHNob3dfdXNhZ2UgIlVuYWJsZSB0byBjcmVhdGUgaGFz aGVyIHdvcmtlciBkaXJlY3RvcnkgaW4gJFdPUktESVIiCgpleGVjIGhzaCAtLXJlcG89IiRSRVBP RElSIiAiJFdPUktESVIiICIkQCIK