Gentoo Forums • [PORTAGE][TOOL] Emerge in ram/tmpfs: aggiornato a gennaio 06

Page 1 of 8

[PORTAGE][TOOL] Emerge in ram/tmpfs: aggiornato a gennaio 06

Posted: Sun May 22, 2005 5:42 pm

by FonderiaDigitale

UPDATE: Ebuild disponibile. vedi sotto.
UPDATE: A distanza di mesi, sotto sollecito di alcune persone, torno ad aggiornare lo script.
- Ho fatto un paio di modifiche documentate sotto.
- Ho risolto un paio di bug riguardo lo smontaggio del fs.
- L'ho riscritto. non sono sicuro che sia apposto, provatelo, ho fatto dei test ma non posso garantire che sia perfetto.

-----------------------------------------------------------------------------------------
Questo tratta di come modificare emerge per automontare la dir temporanea di portage in ram, o nel caso specifico in tmpfs (quindi ram fino alla capacita' massima fisica disponibile, il resto in swap, per essere sicuri di non rimanere a secco).
Compilare in ram, specie per pacchetti molto esosi come gcc o glibc, diminuisce molto ma molto ma molto il tempo necessario.
Senza contare il fatto, molto importante per me, che aumenta anche la vita al vostro disco fisso (credo che la compilazione per un utente gentoo medio, sia uno degli aspetti di piu grosso stress per gli HD).

Il tutto viene fatto e disfatto automaticamente per ogni emerge, da emerge stesso.
L'unica cosa da configurare e' la dimensione, ovvero una variabile da inserire in /etc/make.conf:

Code: Select all

PORTAGE_MEMSIZE=xxx

dove xxx e' la quantita' (in MegaBytes) del disco da creare.
Sono supportate le seguenti sintassi per la misura:

- 60 - 60 megabytes (se non c'e' unita' il default e' megabytes)
- 60M o 60Mb
- 2G o 2Gb

Ovviamente, come ogni altra variabile in make.conf, potete sovrascriverla a runtime ogni volta che emergerete un pacchetto magari molto dispendioso in termini di spazio in compilazione, ad esempio

Code: Select all

PORTAGE_MEMSIZE=800M emerge openoffice

per specificare dimensioni eccezionali per casi eccezionali.
-------------
UPDATE:
Ho inserito il supporto per un file, /etc/portage/package.mem, dove si puo' sovrascrivere le impostazioni globali per pacchetto, esattamente come avviene per package.use.

La sintassi corretta per il file e':

Code: Select all

categoria/pacchetto           dimensione_tmpfs

NOTA BENE: non sono supportati i numeri di versione al momento.

L'ordine di priorita' e' questo, in ordine ascendente da sinistra a destra:
make.conf --> package.mem --> variabile d'ambiente shell
-------------

Se la variabile non e' specificata ne da linea di comando ne nel make.conf, emerge funzionera' come al solito, senza montare il fs.

esempi:

a. disabilitato per default, attivo su richiesta esplicita per singoli pacchetti
- make.conf: PORTAGE_MEMSIZE="" (o nulla direttamente)
- emerge world
oppure
- PORTAGE_MEMSIZE=50 emerge nano

b. attivo per default, inattivo su richiesta esplicita per singoli pacchetti
- make.conf: PORTAGE_MEMSIZE="500" (dimensione a scelta)
- emerge world
oppure
- PORTAGE_MEMSIZE="" emerge nano

c. attivo per default, dimensione per singoli pacchetti diversa da default
- make.conf: PORTAGE_MEMSIZE="500"
- emerge world
oppure
- PORTAGE_MEMSIZE=50 emerge nano

Giustamente qualcuno ha detto che e' poco utile per pacchetti piccoli, specie su macchine non proprio eccellenti.
vero.

A questo proposito puo' essere utile settare PORTAGE_MEMSIZE=0 in /etc/make.conf, e usarlo selettivamente per pacchetti grandi, tipo:

Code: Select all

nano /etc/portage/package.mem

Code: Select all

app-office/openoffice-ximian    2G
kde-base/kdelibs               800M
sys-devel/gcc                 500

e cosi' via.

NOTA BENE: DOVETE avere il supporto per ramfs/tmpfs nel vostro kernel.

Download: Ebuild disponibile a questo indirizzo.

Per installarlo, dovete inserirlo nel vostro overlay di ebuilds.
--

NOTA BENE: Al momento non e' prevista la gestione di piu processi di emerge concorrenti. La spiegazione e' ovvia: far partire piu emerge contemporaneamente e' gia rischioso di per se, puo' seriamente corrompere portage e il sistema stesso.

il "coso" non ha pretese di essere perfetto, se avete migliorie son ben accette.

Posted: Sun May 22, 2005 5:58 pm

by gutter

I miei complimenti, analisi e soluzione del problema sono davvero degni di nota.

Aggiunto ai post utilissimi sezione Tips.

Re: [PORTAGE][TOOL] modifica per portage: autocompilare in R

Posted: Sun May 22, 2005 5:59 pm

by neryo

FonderiaDigitale wrote: Compilare in ram, specie per pacchetti molto esosi come gcc o glibc, diminuisce molto ma molto ma molto il tempo necessario.

Ottimo tip...

lo proverò a breve!

Posted: Sun May 22, 2005 7:09 pm

by flocchini

ho seguito le istruzioni giusto per un bell'aggiornamento ma ho un problema:

Code: Select all

>>> emerge (1 of 53) sys-devel/gnuconfig-20050324 to /
 * Mounting 700MMb (tmpfs) to /var/tmp/portage...
mount: wrong fs type, bad option, bad superblock on tmpfs,
       or too many mounted file systems

*credo* di avere entrambe le features da te indicate gia' compilate nel kernel. Dico credo perche' non sn riusscito ad individuare nello specifico le voci ma un "mount" mi restituisce

Code: Select all

none on /dev type ramfs (rw)
none on /dev/shm type tmpfs (rw)

quindi se sono montati dovrei averli...

un emerge info

Code: Select all

Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.11-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 22 2005, 18:23:45)]
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.4-r1
sys-apps/sandbox:    [Not Present]
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=athlon64 -pipe -fweb -frename-registers -ftracer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon64 -pipe -fweb -frename-registers -ftracer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/"
LDFLAGS="-Wl,-O1"
LINGUAS="it"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X aalib acpi alsa amd64 arts avi berkdb bitmap-fonts crypt cups curl dga dvd dvdr encode fam flac font-server fortran gif gphoto2 gpm gtk imagemagick imlib ipv6 ithreads java jp2 jpeg kde kdeenablefinal lzw lzw-tiff motif mp3 mpeg ncurses nls nptl ogg oggvorbis opengl oss pam pda pdflib perl png python qt quicktime readline samba sdl ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xml2 xmms xpm xrandr xv xvid zlib linguas_it userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL

e in make.conf c'e'

Code: Select all

PORTAGE_MEMSIZE=700M

ho 1 giga...

Posted: Sun May 22, 2005 7:22 pm

by fedeliallalinea

Ottimo tip fonderia. Grande

Posted: Sun May 22, 2005 7:28 pm

by FonderiaDigitale

flocchini wrote:ho seguito le istruzioni giusto per un bell'aggiornamento ma ho un problema:
Code: Select all
>>> emerge (1 of 53) sys-devel/gnuconfig-20050324 to /
 * Mounting 700MMb (tmpfs) to /var/tmp/portage...
mount: wrong fs type, bad option, bad superblock on tmpfs,
       or too many mounted file systems
*credo* di avere entrambe le features da te indicate gia' compilate nel kernel

colpa mia. avevo detto di aggiungere M ma poi lo ho fatto nello script. ho corretto il primo post
Specifica solo la dimensione

Posted: Sun May 22, 2005 7:59 pm

by xchris

appena poso le mani sulla mia gentoo box faro' un po' di prove...

sembra molto promettente

denghiu

Posted: Sun May 22, 2005 8:01 pm

by flocchini

hahaha mi sento come quando ero a scuola... quando pensi di avere la risposta giusta ma non la dici per paura di fare brutta figura, dando un 'occhiata allo script ci avevo pensato ma avevo paura di fare peggio... Dovro' dare piu' retta al mio sitinto

ora funziona regolarmente, vediamo quanto e' piu' veloce

Posted: Sun May 22, 2005 8:05 pm

by redview

storia malata..nano compilato con 20s di anticipo..
grazie!

Posted: Sun May 22, 2005 8:07 pm

by FonderiaDigitale

beh nano e' un pacchetto piccolo

prova con glibc e vedi

Posted: Sun May 22, 2005 8:13 pm

by X-Drum

impressive

veramente bello come hack

Posted: Sun May 22, 2005 8:56 pm

by xchris

provato con successo su pacchetti piccoli per ora...

57 secs contro i 71 normali.
Ovviamente non ha molto senso sui pacchetti piccoli... provero' quanto prima su qc di + corposo.

Un suggerimento...
Se non e' settato PORTAGE_MEMSIZE sarebbe meglio non montare nulla.
In questo modo e' completamente trasparente...

(avevo dimenticato di settare la var e mi ha creato un RAMDISK di 0k ... che bloccava qualunque emerge)
(e poi non lo ha neanche smontato... non so perche'... a dire il vero)

Provato in modo corretto ha funzionato alla grande (mount/umount)

ciao

Posted: Sun May 22, 2005 9:00 pm

by FonderiaDigitale

ok, aggiunto il controllo

modificato il primo post

EDIT: aggiunto controllo sullo smontaggio del fs, e spostato sul mio server.

Posted: Sun May 22, 2005 9:31 pm

by Xet

che bello O_o veramente utile!!!
GJ

ps: aspetto con ansia la parte di script che determina quanta memoria fisica hai ancora libera e monta un fs adeguato

non so la butto li ne...

sarebbe una bella feature secondo voi?
se mi date una mano si può fare...mi serve solo sapere il comando per ottenere info sulla memoria...
azzarderei un

Code: Select all

more /proc/meminfo

con poi un grep e un passaggio in una variabile...

secondo voi è sensato montare TUTTA la mem rimanente o no?
voglio dire...quella cache montata in ram può essere usata da gcc per compilare o è usata da emerge per gestire le compilazioni?
ok ok ok reddo il fuckin manual...

Posted: Sun May 22, 2005 9:34 pm

by FonderiaDigitale

assegnare la quantita' di memoria per emerge non dipende dalla quantita' fisica disponibile ma dallo spazio necessario in compilazione, e non e' una cosa automatizzabile, anche xche la ram che togli al sistema e' ram che potrebbe servire all'uso del pc (in ambito desktop).
Secondo me e' meglio lasciarla settare all'utente in base alle sue esigenze (se vuole o meno rallentare il suo uso quotidiano del sistema o no)

Posted: Sun May 22, 2005 9:45 pm

by Xet

ho provato, forse per abitudine, a dare:

Code: Select all

PORTAGE_MEMSIZE="" emerge rdate

e mi ha giustamente insultato, facendomi sbattere su un "no space left on device"
inoltre bisogna considerare un minimo spazio per far funzionare?
e sicuramente non può essere 0 (questo l'ho detto ma non ho fatto in tempo a vedere se l'avevi gia previsto)

Posted: Sun May 22, 2005 9:55 pm

by FonderiaDigitale

scarica l'ultima versione, c'e quel controllo

Posted: Sun May 22, 2005 9:55 pm

by Xet

FonderiaDigitale wrote:assegnare la quantita' di memoria per emerge non dipende dalla quantita' fisica disponibile ma dallo spazio necessario in compilazione, e non e' una cosa automatizzabile, anche xche la ram che togli al sistema e' ram che potrebbe servire all'uso del pc (in ambito desktop).

beh io pensavo ad un utonto

ed era un'idea balenata così a caldo

ok....stanotte il letto mi aspetterà...devo trovare una formula atta allo scopo

magari me la sogno

Posted: Sun May 22, 2005 10:14 pm

by Xet

Code: Select all

Ulisse xet # time emerge rdate
Calculating dependencies ...done!
>>> emerge (1 of 1) net-misc/rdate-1.4-r1 to /
[cut]


 * GNU info directory index is up-to-date.


real    0m8.624s
user    0m7.094s
sys     0m0.939s
Ulisse xet # time emerge rdate
Calculating dependencies ...done!
>>> emerge (1 of 1) net-misc/rdate-1.4-r1 to /
 * Mounting 200Mb (tmpfs) to /var/tmp/portage ...

[cut]

 * Unmounting /var/tmp ...

>>> clean: No packages selected for removal.

>>> Auto-cleaning packages ...

>>> No outdated packages were found on your system.


 * GNU info directory index is up-to-date.


real    0m12.683s
user    0m10.812s
sys     0m1.284s

lol i tempi di mount\umount invalidano il tip per pacchetti di piccolissime dimensioni

cmq io ho scaricato la versione ultima (ATM), ma lanciando con

Code: Select all

PORTAGE_MEMSIZE=0 emerge rdate

non ignora il mount e cerca di emergere con un tmp di 0 mega...
stessa cosa se al posto di 0 c'è ""...

Posted: Sun May 22, 2005 10:22 pm

by gionag

complimenti è riduttivo

ottimo lavoro...

ho solo alcuni dubbi: ho 512mb di memoria fisica, se io specifico nella variabile 700M dopo che ha esaurito la ram va autamaticamente nello swap ? e poi, siccome io ho utilizzato fino ad ora una partizione dedicata e montata su /var/tmp/portage, grazie a questo script è resa praticamente inutile, giusto ?

due piccoli bug: uno l'override del mount in caso di MEMSIZE="0" non funziona e in secondo luogo fa confusione con emerge multipli

grazie
ciao

Posted: Sun May 22, 2005 10:29 pm

by flocchini

10 minuti buoni sulle qt, da 51 a 40 su amd64@3200

grande fonderia

Posted: Sun May 22, 2005 11:00 pm

by FonderiaDigitale

Xet wrote: lol i tempi di mount\umount invalidano il tip per pacchetti di piccolissime dimensioni

questo era PALESE. di certo i 3 secondi di nano non ti cambiano la vita, mentre i minuti per kde si.

cmq io ho scaricato la versione ultima (ATM), ma lanciando con
Code: Select all
PORTAGE_MEMSIZE=0 emerge rdate
non ignora il mount e cerca di emergere con un tmp di 0 mega...
stessa cosa se al posto di 0 c'è ""...

mah: specificare dimensione=0 non e' che abbia molto senso e va contro la modalita' standard di azzerrare le var in bash, ha molto piu senso ="", in ogni caso ho aggiunto anche questo controllo.

Posted: Mon May 23, 2005 9:02 am

by xchris

Code: Select all

 * if you've upgraded from libexif-0.5.8 you'll
 * have to run revdep-rebuild from gentoolkit
 *
>>> Regenerating /etc/ld.so.cache...
 * Caching service dependencies...
>>> media-libs/libexif-0.5.12-r3 merged.
 * Unmounting /var/tmp...
umount2: Device or resource busy
umount: /var/tmp/portage: device is busy
umount2: Device or resource busy
umount: /var/tmp/portage: device is busy

uhm... come mai non lo smonta? (non ho ancora aggiornato alla versione finale.. ma non credo cambi molto)

Che tipo di test potrei fare?

Posted: Mon May 23, 2005 9:15 am

by randomaze

Spettacolare

Noto che tuttavia le dimensioni da specificare in PORTAGE_MEMSIZE sono infide... infatti a quanto pare un 512 non é sufficiente per xorg-x11 infatti dopo i primi tentativi andati bene mi sono esaltato é ho lanciato un:

Code: Select all

 PORTAGE_MEMSIZE=512 emerge xorg-x11

ottenendo come risultato:

Code: Select all

gzip: stdout: No space left on device

...adesso riprovo con 700.

Potremmo fare una tabellina con le dimensioni consigliate per i vari pacchetti

Ricordo male oppure openoffice per compilare richiede circa 4/5Gb di spazio?

Posted: Mon May 23, 2005 9:33 am

by FonderiaDigitale

xchris wrote:

Code: Select all

 * if you've upgraded from libexif-0.5.8 you'll
 * have to run revdep-rebuild from gentoolkit
 *
>>> Regenerating /etc/ld.so.cache...
 * Caching service dependencies...
>>> media-libs/libexif-0.5.12-r3 merged.
 * Unmounting /var/tmp...
umount2: Device or resource busy
umount: /var/tmp/portage: device is busy
umount2: Device or resource busy
umount: /var/tmp/portage: device is busy

uhm... come mai non lo smonta? (non ho ancora aggiornato alla versione finale.. ma non credo cambi molto)

Che tipo di test potrei fare?

hai qualche job sotppato o screen? prova

Code: Select all

lsof|grep mountpoint