linux - модный рамдиск

а разве оно не должно и так оставаться в файловом кэше?

> засунуть portage tree в файловую систему, находящуюся в оперативной памяти

И emerge --sync при каждой загрузке?

> И emerge --sync при каждой загрузке?

а зачем выключать комп?

> а разве оно не должно и так оставаться в файловом кэше?

ну, оно остаётся. Если сделать, например, emerge -pDNu world а потом emerge -pDNu system, то второе выполнится в разы быстрее, чем если его сделать не делая первое. Я наивно предполагал, что если поместить все файлы на *ramdisk* то оно будет работать быстрее даже без кэша.

Экспериментирую с tmpfs, кажется, скорости не прибавилось. Похоже, даже наоборот...

Получи!

О, спасибо!

name_no особо не за что. Там прикол в том что если со squashfs никаких проблем нет то с unionfs/aufs вечно не лады. В свежих ядрах unionfs/aufs как правило нет. Патчи на unionfs/aufs есть но не в gentoo-sources... Да и иногда при перезагрузках та схема сбоит и portage вообще не монтируется (для этого там есть банальный бекап...)

что бы память не простаивала лучше в неё /var/tmp/portage монтируй :)
толку больше :)
при 4Gb я так подозреваю, что даже OO в памяти сможешь позволить себе собрать :)

Скажите, как сейчас можно решать такую задачу?

Можно и вот так.

> что бы память не простаивала лучше в неё /var/tmp/portage монтируй :)
Поддерживаю
> при 4Gb я так подозреваю, что даже OO в памяти сможешь позволить себе собрать :)
А вот это уже не получится, там емнип больше 5 гигов надо.

13 G

> с unionfs/aufs вечно не лады

да, я уже наткнулся )) посмотрим, что можно сделать

>> что бы память не простаивала лучше в неё /var/tmp/portage монтируй :)

> Поддерживаю

>> при 4Gb я так подозреваю, что даже OO в памяти сможешь позволить себе собрать :)

> А вот это уже не получится, там емнип больше 5 гигов надо.

вот поэтому и не монтирую его в память. потому что из-за таких пакетов как OOo придётся постоянно размонтировать и вообще следить за этим... На маленьких пакетах скорость компиляции меня устраивает, а на больших всё равно придётся по-старинке. Хотя мысль здравая, надо посмотреть.

да, я уже наткнулся )) посмотрим, что можно сделать

name_no с тем методом вообще проблем бы не было если бы или unionfs или aufs или их замену воткнули бы наконец в ядро чтоб не надо было каждый раз патчами страдать. А то что иногда тот вариант сбоит не особо страшно. Ну я пару раз за пол года видел когда portage переставал монтироваться. Там проблемы как правило если параллельный запуск демонов стоит. Там тогда при выключении 40 секунд вроде и один фиг выключается питание не глядя на то окончилась ли создание сквашфс образа. Опять же проблем ноль взял с бекапа сделал emerge --sync и перезапустил демона.

> потому что из-за таких пакетов как OOo придётся постоянно размонтировать

Бггг, скажи, сколько ещё таких пакетов, и сколько раз в день ты ООо собираешь?

> сколько ещё таких пакетов, и сколько раз в день

определяющее слово здесь: придётся за этим следить. У меня слишком хреновая память (в голове), чтобы занимать её такой ерундой, как отмонтирование виртуальных файловых систем при компилянии OOo. Я про это забуду и оно грохнется. Мне больше по душе вариант "настроил и забыл"

Настроил и забыл? Зачем тогда компилировать ООо?

> Зачем тогда компилировать ООо?

Не вижу смысла развивать эту линию дискуссии

> Получи!

Ещё раз огромное спасибо за эту ссылку. Сделал как там предлагают, только вместо unionfs использовал aufs2 (оно есть в портежах). Проблем не возникло, ускорение в 3-4 раза.