Компиль всё в раме, а потом запускай rsync з exclude по *.o.

есть ли готовый способ собирания ядра в раме

А что, если указать при сборке KBUILD_OUTPUT в раме, это не решит вашу проблему?

есть предложение заюзать для этого ZRam

но ты же игноришь анонимусов, так что этого предложения не увидишь :D

нет, не решит

# 2) Set KBUILD_OUTPUT
# Set the environment variable KBUILD_OUTPUT to point to the directory
# where the output files shall be placed.
# export KBUILD_OUTPUT=dir/to/store/output/files/
# make

это уже надо пилить, оха!?
я спрашиваю про готовый вариант

матчасть осил, потом говори
сходи хотя бы ко мне в профиль и пойми, что ты обделался

where the output files shall be placed

Я так понимаю, имеются в виду именно директория куда складываются файлы, в процессе сборки. В том числе и *.o и прочий шлак. Нет?

аха, только меня не улыбает таки пилить решения вопроса вот этого чувака, например.
ты хоть понимаешь что есть выходные файлы и есть временные?

ты хоть понимаешь что есть выходные файлы и есть временные?

Ты хоть понимаешь, что временные файлы, для компилятора - выходные. Сейчас попробовал export KBUILD_OUTPUT=/dev/shm; make menuconfig; make

Все собирается в /dev/shm

а инклуды и модули куда падают?
падающих на винт файлов достаточно для сборки рабочих сторонних модулей под это ядро?

Ты же гентушник, справишься.

При сборке тудаже, ну а make install на что? Указываем INSTALL_PATH, INSTALL_MOD_PATH и вперед.

При сборке тудаже

первый фэйл

ну а make install на что? Указываем INSTALL_PATH, INSTALL_MOD_PATH и вперед.

второй фэйл
итого: 2:0 в пользу ядра

дык лень же...я очень ленивый

А ты скриптик напиши, а он дальше сам всё сделает.

И в чем фэйл? Нужные файлы после сборки выцепляются автоматически и складываются куда попросишь. За пивом не бегает - ну извини.

я этим занимаюсь уже хз сколько

ты так и не понял
ничего
вот когда столкнёшься, тогда поймёшь

ssd

я правильно понимаю, что ты пытаешься выгадать лишний годок жизни ssd, чтобы его хватило не на 10 лет, а на 11 ? :)

ssd на 10 лет?
фантазёр
а вообще это попытка и выгрести мусор - у меня при сборке ядра генерится 6202 треш-файлов

Кстате у тебя же reiserfs? Как скорость без трима не проседает?

я никак не дойду до магаза за ssd
потому пока ничего сказать не могу

я никак не дойду до магаза за ssd

какие нелепые отмазки, так бы сразу и сказал, что нищеброд :)

у меня ssd 2 года, износ 3%. ЧЯДНТ?

молодец, чо
только скорости проседание измерь, оха?

Ты так говоришь, как будто проседание зависит от времени использования, а не использования при почти полностью заполненном устройстве, которое потом все равно лечится TRIM'ом.

Нет никакого проседания у меня.

продолжай в это верить

Зачем верить, если можно измерить? Измерения говорят о том, что скорость не изменилась.

у тебя есть измерения 2 года назад и сейчас?
не вижу

Извини, я не задокументировал их, чтобы спорить с тобой, но память мне не изменяет, и я могу сравнить параметры обычных операций.

hdparm и dd как показывали 330/110 MB/s r/w, так и показывают, система как грузилась на 2.9 секунды, так и грузится, мерж глибц после компиляции по логам emerge.log как был 5 секунд, так и остался.

будут цифры - поговорим
а пока не вижу данных для обсуждения

есть ли готовый способ собирания ядра в раме, чтобы на винт падали только готовые ядра/модули/заголовки, а всякий треш типа этих самых *.o, *.cmd и иже с ними тонули в Лете(для не эрудитов - /dev/null)?

а что, не тонут? ну сделай скрипткик, и запускай после каждого вызова ld. В чём проблема?

Окей, оставайся в своей вере в затормаживание ссд, а я с живой системой, которую так и не получилось замедлить. Удачи.

готово

А ты скриптик напиши, а он дальше сам всё сделает.

написал :3

#!/bin/bash

RAM_DIR="${PWD%/*}/RAM"
mkdir "${RAM_DIR}"
SOURCE_DIR="${PWD}"
mount -t tmpfs tmpfs ${RAM_DIR}

#####################################################
##### copy sources over symlinks into RAM_DIR #######
for i in $(ls -A);do
	cp -Rs ${SOURCE_DIR}/${i} ${RAM_DIR}/${i}
done
cd "${RAM_DIR}"

#####################################################
##### config ########################################
[[ ! -f .config ]] && zcat /proc/config.gz > .config
if [[ -z "${1}" ]];then
	make oldconfig
else
	make ${1}
fi

#####################################################
##### compiling #####################################
threads="$(( $(awk '/^cpu cores/ {print $4}' /proc/cpuinfo | uniq) + 1 ))"
make -j${threads}

#####################################################
##### copy generated files back into SOURCE_DIR #####
rsync --checksum --recursive --links --safe-links \
	--exclude='*.o' \
	--exclude='*.cmd' \
	--exclude='*.builtin' \
	--exclude='*.order' \
	--exclude='*.mod' \
${RAM_DIR}/ ${SOURCE_DIR}/

cd "${SOURCE_DIR}"
umount "${RAM_DIR}"
rm -rf "${RAM_DIR}"

• «сорсы» в раме оказываются мгновенно, в отличии от реального копирования
• занимаемое место стремится к нулю, а это очень даже гуд

при сборке все временные файлы в раме
при «установке» на винт падают только реально нужные файлы и линки
в моём случае временных файлов 6000+ на 150+ метров
и приятный бонус - сборка происходит быстрей, хоть и в пределах погрешности
P.S. впринципе это дело можно прикрутить к любой сборке
/me доволен :3

нет, не тонут
сборка на винте - смотрим кол-во треша

find /usr/src/linux-3.7.5-pf/ -type f \( -name "*.o" -or -name "*.cmd" -or -name "*.mod" -or -name "*.builtin" -or -name "*.order" \) | wc -l
6149

find /usr/src/linux-3.7.5-pf/ -type f \( -name "*.o" -or -name "*.cmd" -or -name "*.mod" -or -name "*.builtin" -or -name "*.order" \)  | wc -l
0

ну сделай скрипткик, и запускай после каждого вызова ld. В чём проблема?

да, ты так и не понял поставленную задачу, да и зачем-то приплёл ld...

да, ты так и не понял поставленную задачу, да и зачем-то приплёл ld...

ну я не понял, что ты именно про ядро(хотя ты в первом посте писал), я думал про другие приложения. Для ядра - да, наделать кучу симлинков - хорошая мысль.

ЗЫЖ ИМХО можно просто в /tmp всё делать, у тебя ведь /tmp в tmpfs? Тогда скрипт будет попроще. В слаке, кстати, в /tmp все пакеты и собираются, вместе со всякими obj. Правда, про ядро я не помню - давно уже не собирал.

так у меня и так в tmpfs всё собирается
единственное отличие от «классического» варианта сборки в раме это отсутствие сорсов в раме как таковых, ибо копировать это очень долго - у меня получалось чот в районе 2-х минут.
а вот про слаку не понял - ты не про промежуточные файлы, которые можно просто по конвейеру пустить ключиком -pipe?

единственное отличие от «классического» варианта сборки в раме это отсутствие сорсов в раме как таковых, ибо копировать это очень долго - у меня получалось чот в районе 2-х минут. а вот про слаку не понял

фишка в том, что сырцы в слаке никогда на диск и не попадают - тарбол распаковывается в раму(/tmp/), и там собирается. Но для ядра, как я погляжу, исключение, оно в /usr/src/ собирается. Потому - спасибо за скрипт, и за проверку его работы (никогда так не пробовал собирать, на симлинках).

И да, обратное копирование (rsync) в слаке не нужно, там это всё можно прямо в раме опакетить, и сохранить только готовый пакет, который можно будет ставить.

а, так я таким макаром и в генте собираю, только сборка в другом месте происходит и нет необходимости держать /tmp в раме
а так то же самое

В арчике йогурт по дефолту собирает всё в /tmp/, в т.ч. и вёдра.
Емерж нельзя обучить подобному поведению?

Ну понятно, что /tmp в раме.

ты не поверишь!
можно
только ты явно не вкурил смысл

только ты явно не вкурил смысл

возможно. Про копирование позже немного прочитал. В случае арча все просто - он ничего не копирует, т.к. тянет тарболы из инета сразу в /tmp, и там же их разворачивает. Потом собирает, пакетирует и из рамы же предлагает поставить готовый пакет.

можно и так сделать, но это очень глупо, особенно при сборке больших пакетов по несколько штук сразу

Ну понятно, что /tmp в раме.

/tmp в раме это далеко не всегда хорошо - юзкейся и кол-во рамы у всех разные, оха!?

обсуждалось не единожды - потому гугли/смотри_техветки

кстати, а каким макаром арч собирает сторонние модули, если на винт не падают сорсы ядра? ;)

А он их и не собирает в пакет вместе с ядром.
Они отдельно пакетируются по тому же алгоритму, что и ведро. При этом, понятно, со стораджа заголовки ядерные читаются, но по-прежнему ничего не пишется, кроме уже готового пакета в процессе его установки.

а, так я таким макаром и в генте собираю, только сборка в другом месте происходит и нет необходимости держать /tmp в раме

а почему надо /tmp не в раме держать?

а как происходит сборка кастомного ядра и модулей к нему?
и что падает в «заголовки»?
одних хидеров малова-то для сборки модулей

В случае арча все просто - он ничего не копирует, т.к. тянет тарболы из инета сразу в /tmp

в случае ядра это не очень удобно - сырцы и заголовки ядра нужны не только для сборки загрузочного образа этого ядра. Т.ч. способ мегабакса годный.

Сборка кастомного ядра происходит просто: в /tmp утягивается пкгбилд и сопуствующее, туда же - исходники. Потом исходники разворачиваются, патчатся и собираются. После сборки мусор тримается (или не тримается, смотря насколько ленив автор пкгбилда), собранное пакетируется и предлагается к установке.

Модули можно собирать либо через отдельные пакеты (в раме, по той же схеме), либо dkms'ом, тогда это будет на сторадже. Возможно, dkms можно заставить собирать в раме, я просто туда не копал даже.

В любом случае с нестандартными модулями получается полуручной труд.