LINUX.ORG.RU

Нехватка места в TMPDIR при коньпиляции

 , ,


0

1

Привет!

Я не обновлял систему и не пользовался машиной где-то год. Дорвался, решил всё пересобрать, чтобы было красиво и хорошо. Почти закончил, но начала проявляться ошибка при компиляции пакетов, логи говорят, что не хватает места в tmpdir, которую я вынес в tmpfs.

Первую ошибку make выдал на пакете x11-libs/wxGTK. Я решил, что это просто жирный атом, занёс строку в package.env, после этого скомпилировалось. Но такая же ошибка возникла на следующем пакете, dev-lang/erlang. Начал разбираться, размер tmpfs - 3G, что более чем достаточно для таких пакетов по идее. Посмотрел папку из консоли, она практически пустая. Единственное, чего не сделал - не посмотрел размер tmpdir именно во время компиляции. Я занёс второй пакет в package.env и это снова решило проблему (скорее не решило, а подставило костыль).

Короче, чем дальше идет дело, тем больше пакетов мне приходится исключать, причём я эти пакеты не впервые в жизни ставлю, они были на машине раньше, и раньше в tmpfs спокойно они собирались. Горькая участь постигла dev-lang/ocaml, а потом и media-libs/raptor. Тогда-то я и бомбанул, что это такое, мне может вообще tmpdir из оперативы тогда вынести, раз такие зихера творятся?

Подскажите пожалуйста, в чем может быть проблема? Логи у всех пакетов одинаковые, одна и та же ошибка «No space left on device».

Для жирных пакетов можно отдельные правила сделать, чтобы они на диске собирались.

RazrFalcon ★★★★★ ()

emerge --info покажи для начала. Может ты всё с отладкой собираешь, вот бинарники и раздувает. Но вообще тот же wxGTK и erlang - это не маленькие пакеты, да...

Pinkbyte ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Доставишь маны покурить? Ты имеешь в виду, чтобы компилятор исходно определял размер пакета и слишком жирные выселял в notmpfs? Или ты имеешь в виду, что можно вручную каждый жирный пакет в package.env вносить с notmpfs.conf - если ты об этом, то я так и делал, но это ж блин не решение, количество не влезающих в tmpfs пакетов удивительным образом возросло, вот что меня напрягает.

Flagitio ()
Ответ на: комментарий от Flagitio

можно вручную каждый жирный пакет в package.env вносить с notmpfs.conf

This.

r3lgar ★★★★★ ()
Ответ на: комментарий от Flagitio

Да. Я про это.

Ну тогда нужно увеличить tmpfs. У меня 6ГиБ и только хром с лисой не влазят. Ну и dev-qt/qtwebengine.

RazrFalcon ★★★★★ ()

размер tmpfs - 3G, что более чем достаточно для таких пакетов по идее

Фиг там.

Вот по памяти часть того, что не влезает в 3G: firefox, chromium, wxGTK, clang, llvm, mesa.

r3lgar ★★★★★ ()
Ответ на: комментарий от r3lgar

То есть это не какой-то злой загадочный косяк, а просто я раньше реально не сталкивался с этими толстыми пакетами? Мне кажется, уж ocaml у меня стоял точно, но в package.env его не было, я только сейчас занёс. Если б я либру собирал, гцц, ещё что-то такое, то да. А так у меня всегда всё влезало, а тут вот влезать перестало, понимаешь какая беда.

Flagitio ()
Ответ на: комментарий от RazrFalcon

А я бич, у меня всего машина с 6 Гб ОЗУ. Кстати, мне казалось, что было 8 Гб, наверное одну планку мыши сгрызли за год.

Flagitio ()
Ответ на: комментарий от r3lgar

mesa, llvm, clang влезает. firefox вроде тоже влезал, 52.7.3esr по крайней мере. Рустовый ещё не трогал.

paran0id ★★★★★ ()
Ответ на: комментарий от Flagitio

То есть это не какой-то злой загадочный косяк, а просто я раньше реально не сталкивался с этими толстыми пакетами?

А так у меня всегда всё влезало, а тут вот влезать перестало, понимаешь какая беда.

А ещё ты не учитываешь, что объёмы кода со временем только растут.

r3lgar ★★★★★ ()
Ответ на: комментарий от Flagitio

Кстати, мне казалось, что было 8 Гб, наверное одну планку мыши сгрызли за год.

Планка могла пылью покрыться и при включении её могло статикой убить.

r3lgar ★★★★★ ()
Ответ на: комментарий от paran0id

mesa, llvm, clang влезает.

У меня не влезало. Но сейчас у меня рамы хватает, чтобы расширить zram при необходимости. 6G пока хватает для всего, что я компиляю.

r3lgar ★★★★★ ()
Ответ на: комментарий от r3lgar

Звучит очень необычно, наверное efi дал бы знать как-то об изменении в конфигурации. Вообще я с корабля на бал, даже не открывал корпус, термопаста рассохлась наверное давно, в простое под 60 градусов епта.

Flagitio ()
Ответ на: комментарий от Flagitio

наверное efi дал бы знать как-то об изменении в конфигурации

Он даст знать только в случае отказа критического для загрузки оборудования. Сейчас компы грузятся и без клавиатуры вообще, не говоря уже о наличии PS/2 на борту.

Вообще я с корабля на бал, даже не открывал корпус, термопаста рассохлась наверное давно, в простое под 60 градусов епта.

Мне периодически притаскивают говно мамонта, пылившееся много лет на балконе. Я всегда стараюсь заглянуть под капот перед запуском, мало ли, может там все кулера заклинило к чертям и паутина завелась…

r3lgar ★★★★★ ()
Ответ на: комментарий от Flagitio

>Есть, конечно же. И всегда было.

Наркоман чтоли? Если в tmpfs собирается, то -pipe не нужно.

paran0id ★★★★★ ()

32-битная система:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
...
/dev/sda6        11G  1.5G  8.6G  15% /var
tmpfs           2.5G     0  2.5G   0% /var/ramdisk
...

$ cat /etc/portage/package.env
# Needs more than 2.5G of tmp space for compilation
dev-qt/qtwebengine no-tmpfs.conf
dev-lang/rust no-tmpfs.conf
app-emulation/qemu-kvm no-tmpfs.conf
dev-db/mongodb no-tmpfs.conf
dev-lang/scala no-tmpfs.conf
dev-python/pypy no-tmpfs.conf
dev-python/pypy3 no-tmpfs.conf
dev-python/graph-tool no-tmpfs.conf
dev-util/eclipse-sdk no-tmpfs.conf
mail-client/thunderbird no-tmpfs.conf
media-gfx/blender no-tmpfs.conf
sci-libs/ipp no-tmpfs.conf
sci-libs/opencascade no-tmpfs.conf
net-libs/webkit-gtk no-tmpfs.conf
x11-misc/colord no-tmpfs.conf
www-client/firefox no-tmpfs.conf
www-client/chromium no-tmpfs.conf
sys-devel/llvm no-tmpfs.conf

# Needs more than 8.5G of tmp space for compilation
sys-devel/gcc tmp-on-data.conf
dev-java/icedtea tmp-on-data.conf
app-office/calligra tmp-on-data.conf
app-office/libreoffice tmp-on-data.conf

...

$ for F in $(find /usr/portage -name "*.ebuild") ; do REQ=$(grep "CHECKREQS" "$F") ; if [[ -n "$REQ" ]]; then echo -e "\n$F\n$REQ" ; fi; done
# Сам запусти у себя...

Kroz ★★★★★ ()
Ответ на: комментарий от Flagitio

а просто я раньше реально не сталкивался с этими толстыми пакетами?

Или пакеты разжирнели. Наблюдается такое.
Еще вариант - когда билд фейлится, и ты после этого билдишь другой пакет (ну, например, опция emerge --keep-going), то в tmp остается мусор. Возможно какой-то большой пакет тебе отсавил большой рудимент в tmp, а следующим уже места не хватило.

Kroz ★★★★★ ()
Ответ на: комментарий от Flagitio

наверное одну планку мыши сгрызли за год.

Попробуй вытяни планку, пройдись по контактам ластиком, как будто карандаш стираешь. Возможно три исхода: либо повредишь контакты и планку можно будет смело в мусорник выбрасывать, либо ничего не поменяется, либо планка заработает. Я за свою жизнь делал так раз 15, ни разу не убил, два раза реанимировал.

Kroz ★★★★★ ()
Ответ на: комментарий от paran0id

-pipe случайно нету в CFLAGS?

Есть, конечно же. И всегда было.

Наркоман чтоли? Если в tmpfs собирается, то -pipe не нужно.

Это с какой радости?
С -pipe наоборот дискового пространства должно юзаться меньше.
Почитай матчасть для начала:
https://wiki.gentoo.org/wiki/GCC_optimization#-pipe

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 1)

Я не обновлял систему и не пользовался машиной где-то год

сидел или в армии был? :P

по теме, без минимум 7гигов свободных помещать в tmpfs смысла нет

да и всё равно компиляция в процессор упиратется в основном

Harald ★★★★★ ()
Ответ на: комментарий от Flagitio

у меня всего машина с 6 Гб ОЗУ

а почему тогда tmpfs 3 гига? ставь 6 смело, схватишь своппинг в крайнем случае

eternal_sorrow ★★★★★ ()
Ответ на: комментарий от Kroz

>Если в tmpfs собирается, то -pipe не нужно.

Чукча не читатель?

paran0id ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Ну написал же русским языком, вы что слепые такие? Или ещё всё печальнее? :|

Смысл трубы, цитата с ссылки которую уже кинули, «It tells the compiler to use pipes instead of temporary files during the different stages of compilation, which uses more memory»

У него УЖЕ в tmpfs всё собирается. В ОЗУ.

paran0id ★★★★★ ()
Ответ на: комментарий от paran0id

В принципе какая разница.

Pipe насколько я помню просто не создаёт временных файлов, т.е. меньше нагрузка на I/O, меньше VFS, меньше переключений контекста и больше пользы.

anonymous ()
Ответ на: комментарий от paran0id

Уже. По скопировать-то из памяти в tmpfs придётся, причём с десяток раз скорее всего.

anonymous ()
Ответ на: комментарий от Kroz

Да это-то понятно, можно, и нужно так сделать. И пыль убрать, и пасту поменять. Да всё недосуг. Завтра, может быть.

Меж тем, я со всем справился, теперь система моя новая, кленовая, решетчатая. Решил ворлд сет почистить, чтобы совсем уже прямо лоску навести.

Flagitio ()
Ответ на: комментарий от Harald

Тмпфс просто красиво звучало, когда я только генту накатывал первый раз, вот и присобачил. Интересно же. Сидел, только не в тюрьме :D Но сидел.

Flagitio ()
Ответ на: комментарий от Flagitio

GCC 7.3 пересобери, иначе это всё пустое. Потом доложишь о результатах. Хотя без рюшек типа лто и графита проблем быть не должно.

anonymous ()

3G, что более чем достаточно

монтируй 10+ гигов в /var/tmp/portage иначе куча пакетов будет отваливаться, особенно при одновременной сборке нескольких пакетов. Скажем, браузеры и дрянь на шаблонах и бусте.

anonymous ()
Ответ на: комментарий от anonymous

Только вчера накатил 7.3, была вообще 5.х Зачем мне эту канитель снова два часа перебирать?

Flagitio ()
Ответ на: комментарий от Flagitio

gcc-config и дальше по списку, потом emerge -e @world --keep-going

не забудь про mount -B /home/user/tmp/portage /var/tmp/portage иначе всё много что поломается, файлы то не удаляются при ошибке сборки

ну и поинтересуйся что нового в мире, например https://spectreattack.com/

да и вообще банально у компиляторов большой прогресс

anonymous ()
Ответ на: комментарий от anonymous

Я хз о чем ты, у меня последняя стабильная версия, 7.30, свежесобранная, чего ради мне что-то делать? Ты так пишешь, что нихрена не ясно. Я лучше ядро обновлю.

Flagitio ()
Ответ на: комментарий от Flagitio

Новый конпелятор тебе ничего не даст если ты не пересоберёшь им весь мир. А то и два раза (хотя с нынешним eapi это вроде лишнее, но я @system пересобираю 1 раз сначала - помогает избежать проблем)

стабильная версия

7.30

с каких пор? Ещё пару дней назад он был замаскирован.

anonymous ()
Ответ на: комментарий от anonymous

В лучше случае ничего не даст, скорее всё начнёт постепенно разваливаться по мере обновления пакетов. Так что лучше не затягивать.

anonymous ()
Ответ на: комментарий от paran0id

Если в tmpfs собирается, то -pipe не нужно.

Чукча не читатель?

Ты так и не ответил на вопрос:

Это с какой радости?

То, что с -pipe теперь меньше создается временных файликов не отменяет того факта, что tmp все равно используется активно: туда гигабайты порой кладутся.

Kroz ★★★★★ ()
Ответ на: комментарий от paran0id

Если в tmpfs собирается, то -pipe не нужно.

Чукча не читатель?

Чукча не читатель, признаю. Хреново ночью писать комментарии, голова плохо варит.

Как по мне -pipe нужен даже если tmpfs, ибо
1) есть пакеты, которые собираются не в tmpfs
2) если multithreading настроен плохо, то -pipe позволит лучше заполнить процессорное время. Хотя, конечно, профита будет немного.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

Если условный $BUILDDIR запилен корректно в tmpfs, то всё там в озу и будет нормально собираться.

Я к тому, что -pipe в добавок к сборке в tmpfs не даёт ничего кроме незаметного для человеческого восприятия оверхеда на I/O и дополнительно бесполезного расхода ОЗУ, ну и как следствие проблемы «No space left on device», которую пытается решить ОП.
Ибо всёравно в КПУ упрётся в итоге.

Ну и ОПу: не собирай тяжёлое в tmpfs да ещё и с трубой, если места не хватает.

Я вот, например, для сборки chromium отмонитрую 6G tmpfs и просто с -pipe собираю.

paran0id ★★★★★ ()
Ответ на: комментарий от anonymous

Новый конпелятор тебе ничего не даст если ты не пересоберёшь им весь мир. А то и два раза (хотя с нынешним eapi это вроде лишнее, но я @system пересобираю 1 раз сначала - помогает избежать проблем)

Извини, брат, я в эту шизу не верю. Это имхо долбоебизм - при каждом обновлении такое устраивать, даже если там есть полумифический выигрыш в 0,хуйдесятых % производительности.

Flagitio ()
Ответ на: комментарий от paran0id

Советуешь пайп отключить, в общем? Хорошо, я щас маны воскурю еще немного и подумаю, мб ты прав. Видимо за год отсутствия программы стали еще тяжелее. Если раньше мне надо было выносить только хромиум, либру, гэцэцэ, тому подобные вещи, то теперь список исключений пополняется байдой, на которую раньше я бы и не подумал.

Flagitio ()
Ответ на: комментарий от Kroz

1) есть пакеты, которые собираются не в tmpfs

Согласен, и меня этот момент смутил. Таки да. Кроме того, этот флаг по умолчанию рекомендуется вместе с -О, одна из двух вообще умолчальных оптимизаций. Наверное уж он, блин, что-то даёт, что его не советуют отключать.

Flagitio ()
Ответ на: комментарий от anonymous

Заморочки генты. В апстриме это стабильная версия и во всех нормальных дистрибутивах он давно уже был.

anonymous ()
Ответ на: комментарий от Flagitio

Это вообще не оптимизация, можно просто посмотреть в документации gcc.

anonymous ()
Ответ на: комментарий от Flagitio

C 5 на 7? Ну оке. Бтв, ты не понял, по производительности проигрыш будет.) И нет, не при каждом, а только при значительных (типа смены мажорной версии).

anonymous ()
Ответ на: комментарий от Flagitio

jumbo-build включи хромиуму, ему больше не надо собираться 6 часов. Какие ещё исключения? Не страдай хернёй, хромиум и вебкиты единственные приложения которые долго собираются. Или накати Оперу, ещё лучше.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.