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

## 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:

```
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

```
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':

```

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:

```

nano /etc/portage/package.mem
```

```

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.

----------

## gutter

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

Aggiunto ai post utilissimi sezione Tips.

----------

## 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...  :Shocked:   lo proverò a breve!   :Wink: 

----------

## flocchini

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

```
>>> 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

```
none on /dev type ramfs (rw)

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

quindi se sono montati dovrei averli...

un emerge info

```
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'

```
PORTAGE_MEMSIZE=700M
```

ho 1 giga...

----------

## fedeliallalinea

Ottimo tip fonderia. Grande  :Very Happy: 

----------

## FonderiaDigitale

 *flocchini wrote:*   

> ho seguito le istruzioni giusto per un bell'aggiornamento ma ho un problema:
> 
> ```
> >>> emerge (1 of 53) sys-devel/gnuconfig-20050324 to /
> 
> ...

 

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

Specifica solo la dimensione  :Smile: 

----------

## xchris

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

sembra molto promettente  :Wink: 

denghiu  :Smile: 

----------

## 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  :Laughing: 

ora funziona regolarmente, vediamo quanto e' piu' veloce  :Wink: 

----------

## redview

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

grazie!

----------

## FonderiaDigitale

beh nano e' un pacchetto piccolo  :Smile:  prova con glibc e vedi  :Cool: 

----------

## X-Drum

impressive  :Shocked: 

veramente bello come hack

----------

## 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

----------

## FonderiaDigitale

ok, aggiunto il controllo  :Smile:  modificato il primo post

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

----------

## 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  :Smile: 

non so la butto li ne...  :Very Happy: 

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

```

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...  :Smile: 

----------

## 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)

----------

## Xet

ho provato, forse per abitudine, a dare:

```

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)

----------

## FonderiaDigitale

scarica l'ultima versione, c'e quel controllo

----------

## 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  :Smile:  ed era un'idea balenata così a caldo  :Smile: 

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

magari me la sogno  :Wink: 

----------

## Xet

```

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

 :Smile: 

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

```

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'è ""...

----------

## gionag

complimenti è riduttivo  :Very Happy:  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  :Very Happy: 

grazie

ciao

----------

## flocchini

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

grande fonderia  :Wink: 

----------

## 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.

 *Quote:*   

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

 

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.

----------

## xchris

```

 * 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?

----------

## randomaze

Spettacolare  :Very Happy: 

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:

```
 PORTAGE_MEMSIZE=512 emerge xorg-x11
```

ottenendo come risultato:

```
gzip: stdout: No space left on device
```

...adesso riprovo con 700.

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

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

----------

## FonderiaDigitale

 *xchris wrote:*   

> 
> 
> ```
> 
>  * if you've upgraded from libexif-0.5.8 you'll
> ...

 

hai qualche job sotppato o screen? prova 

```
lsof|grep mountpoint
```

----------

## FonderiaDigitale

 *randomaze wrote:*   

> 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:
> 
> ```
> ...

 

molto strano.. finita la ram dovrebbe passare alla swap. hai swap o swapfiles?

per la tabella si puo' fare anche un /etc/portage/package.mem e ficcare tutto li

----------

## gutter

 *randomaze wrote:*   

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

 

Ricordi benissimo  :Wink: 

----------

## randomaze

 *FonderiaDigitale wrote:*   

> molto strano.. finita la ram dovrebbe passare alla swap. hai swap o swapfiles?
> 
> per la tabella si puo' fare anche un /etc/portage/package.mem e ficcare tutto li

 

```
 $ free

             total       used       free     shared    buffers     cached

Mem:        774524     730744      43780          0         20     536092

-/+ buffers/cache:     194632     579892

Swap:      1502036          0    1502036

```

Sei sicuro che finita la dimensione del disco passa allo swap? Perché mi sa che la dimensione del disco é fissa, ovvero 700M, poi il passaggio allo swap avviene se necessario (ad esempio se creo 1G di tempfs sicuramente un tot viene gestita dallo swap, se invece lo creo di 400 viene swappata solo se le app corenti si prendono troppo).

(BTW adesso sta swappando)

```

 $ free

             total       used       free     shared    buffers     cached

Mem:        774524     771660       2864          0          0     453072

-/+ buffers/cache:     318588     455936

Swap:      1502036     227192    1274844

 $ df

Filesystem           1K-blocks      Used Available Use% Mounted on

/dev/hdc7             12849728   9905316   2944412  78% /

none                    387260         0    387260   0% /dev/shm

/dev/hdc2             22351536  15786960   6564576  71% /mnt/WinXP

tmpfs                   716800    626412     90388  88% /var/tmp/portage

```

EDIT: Anche 700 sono finiti e non é riuscito....

```

ranlib: /var/tmp/portage/xorg-x11-6.8.2-r1/image//usr/lib/libXau.a: No space left on device

...

$ df

...

tmpfs                   716800    716800         0 100% /var/tmp/portage

$ free

             total       used       free     shared    buffers     cached

Mem:        774524     760856      13668          0          0     459384

-/+ buffers/cache:     301472     473052

Swap:      1502036     316212    1185824

```

----------

## Cazzantonio

BELLISSIMO!  :Very Happy: 

Grande Fonderia!!!  :Very Happy: 

Un solo dubbio mi assale... quanto ramdisk dedicare alla compilazione?  :Confused: 

non ho mai fatto statistiche su quanto spazio venga occupato... 

inoltre, usare la use kdeenablefinal può essere problematico?  :Confused: 

----------

## xchris

```

root@lyra xchris # lsof|grep /var/tmp/portage

gconfd-2   7085    root   11u     unix 0xc2f48d80             6326053 /var/tmp/portage/mozilla-1.7.8/temp/orbit-root/linc-1bad-0-5b5fb322da9b4

gconfd-2   7085    root   12wW     REG       0,13      737    6326057 /var/tmp/portage/mozilla-1.7.8/temp/gconfd-root/lock/0t1116837445ut895646u0p7085r1428852984k3220905676 (deleted)

```

tieni conto che era un emere -Du world

ciao  :Smile: 

----------

## Cazzantonio

Un particolare...

io ho

PORTAGE_TMPDIR=/var/portage_tmp

devo decommentare questa riga in make.conf per usare il ramdisk?

----------

## FonderiaDigitale

 *randomaze wrote:*   

> 
> 
> Sei sicuro che finita la dimensione del disco passa allo swap? Perché mi sa che la dimensione del disco é fissa, ovvero 700M, poi il passaggio allo swap avviene se necessario (ad esempio se creo 1G di tempfs sicuramente un tot viene gestita dallo swap, se invece lo creo di 400 viene swappata solo se le app corenti si prendono troppo).
> 
> 

 

non mi sono spiegato: non c'e modo di montare, ad es., 400MB e forzare 200mb in ram e 200 in swap, solo se la memoria fisica si esaurisce (ovvero: memoria fisica disponibile < memoria mancante al disco tmpfs) il sistema passa allo swap.

L'unica maniera decente (o quasi..) di usare un fs piu grosso della ram e swappare il resto, preservando la priorita' di allocazione della ram per X etc, e' di montare il disco con un nice + alto degli altri processi.. anche se non e' un modo efficacissimo per farlo.

Ricordate che in ogni caso, e questo lo sottolineo 10 volte, tmpfs non togliera' mai memoria ai processi interattivi o allo scheduler di sistema[/b]. inoltre, la memoria se non viene occupata viene liberata per altri usi, ed e' anchequesto il motivo per cui smonto il disco alla fine del merge, ottenendo anche l'effetto secondario di ripulire in un colpo di spugna tutti i file temporanei rimanenti (tipo autoclean  :Razz: )

 *Quote:*   

> A temporary file system uses memory to simulate a traditional disk partition. Normal file system writes are scheduled to be written to disk along with access control information, but the files actually reside in memory only.
> 
> A good candidate for a tmpfs is a partition that will have many small files that will be accessed often, e.g. /tmp. This will considerably speed up their access time. Tmpfs files and directories are NOT saved when the system shuts down.
> 
> Tmpfs is recommended for systems that do a lot of compiling and loading of programs and have large amounts of memory (> 16 MB) and swap space.
> ...

 

----------

## FonderiaDigitale

 *Cazzantonio wrote:*   

> Un particolare...
> 
> io ho
> 
> PORTAGE_TMPDIR=/var/portage_tmp
> ...

 

no funziona con qualsiasi locazione, purche sia montabile.

----------

## FonderiaDigitale

[quote="FonderiaDigitale"] *randomaze wrote:*   

> 
> 
> Sei sicuro che finita la dimensione del disco passa allo swap? Perché mi sa che la dimensione del disco é fissa, ovvero 700M, poi il passaggio allo swap avviene se necessario (ad esempio se creo 1G di tempfs sicuramente un tot viene gestita dallo swap, se invece lo creo di 400 viene swappata solo se le app corenti si prendono troppo).
> 
> 

 

non mi sono spiegato: non c'e modo di montare, ad es., 400MB e forzare 200mb in ram e 200 in swap, solo se la memoria fisica si esaurisce (ovvero: memoria fisica disponibile < memoria mancante al disco tmpfs) il sistema passa allo swap.

L'unica maniera decente (o quasi..) di usare un fs piu grosso della ram e swappare il resto, preservando la priorita' di allocazione della ram per X etc, e' di montare il disco con un nice + alto degli altri processi.. anche se non e' un modo efficacissimo per farlo.

Ricordate che in ogni caso, e questo lo sottolineo 10 volte, tmpfs non togliera' mai memoria ai processi interattivi o allo scheduler di sistema. inoltre, la memoria se non viene occupata viene liberata per altri usi, ed e' anchequesto il motivo per cui smonto il disco alla fine del merge, ottenendo anche l'effetto secondario di ripulire in un colpo di spugna tutti i file temporanei rimanenti (tipo autoclean  :Razz: )

 *Quote:*   

> A temporary file system uses memory to simulate a traditional disk partition. Normal file system writes are scheduled to be written to disk along with access control information, but the files actually reside in memory only.
> 
> A good candidate for a tmpfs is a partition that will have many small files that will be accessed often, e.g. /tmp. This will considerably speed up their access time. Tmpfs files and directories are NOT saved when the system shuts down.
> 
> Tmpfs is recommended for systems that do a lot of compiling and loading of programs and have large amounts of memory (> 16 MB) and swap space.
> ...

 

----------

## randomaze

 *FonderiaDigitale wrote:*   

> non mi sono spiegato: non c'e modo di montare, ad es., 400MB e forzare 200mb in ram e 200 in swap, solo se la memoria fisica si esaurisce (ovvero: memoria fisica disponibile < memoria mancante al disco tmpfs) il sistema passa allo swap.
> 
> L'unica maniera decente (o quasi..) di usare un fs piu grosso della ram e swappare il resto, preservando la priorita' di allocazione della ram per X etc, e' di montare il disco con un nice + alto degli altri processi.. anche se non e' un modo efficacissimo per farlo.

 

Si, mi sa che mi sono espresso male io... 

Dato che, dal mio punto di vista con un disco allocato da 512M l'errore "no space left.." significava banalmente che dovevo creare un file più grosso la tua risposta:

```
molto strano.. finita la ram dovrebbe passare alla swap. hai swap o swapfiles? 
```

mi ha lasciato un'attimo perplesso perché pensavo intendessi "finiti i 512M dovrebbe andare sullo swap" e la cosa mi sembrava un poco strana.

----------

## FonderiaDigitale

ok  :Smile:  ora cmq e' piu' chiaro?

----------

## XstefanoX

Scusate una domanda, ma non sarebbe più semplice aggiungere ad fstab una linea del tipo:

```
none     /tmp     tmpfs     size=800m     0 0
```

così si eviterebbe di montare/smontare la partizione ad ogni emerge? Tanto, in questo modo, anche se non emergo niente, mi pare di aver capito che di ram non ne consumo, o sbaglio?

----------

## Xet

 *XstefanoX wrote:*   

> Scusate una domanda, ma non sarebbe più semplice aggiungere ad fstab una linea del tipo:
> 
> ```
> none     /tmp     tmpfs     size=800m     0 0
> ```
> ...

 

beh mi pare eccessivo...tieni conto che è un fs temporaneo...

e poi se monti 800m in ram per non farci nulla ti giochi quegli 800 mega di ram che restano inutilizzati...

se invece li monti per usarli allora ottieni dei risultati  :Smile: 

sempre che io abbia capito tutto perfettamente  :Wink: 

----------

## XstefanoX

Non credo che la ram venga allocata tutta quando monti il tmpfs. Questa è la situazione iniziale:

```
             total       used       free     shared    buffers     cached

Mem:        386652     251232     135420          0      37292     132168

-/+ buffers/cache:      81772     304880

Swap:       497972          0     497972

```

Poi monto un tmpfs così:

```
mount -t tmpfs none /var/tmp/portage -o size=1g
```

E la ram utilizzata praticamente non cambia:

```
             total       used       free     shared    buffers     cached

Mem:        386652     251848     134804          0      37528     132336

-/+ buffers/cache:      81984     304668

Swap:       497972          0     497972

```

Questo è l'output di df -h:

```
Filesystem         Dimens. Usati Disp. Uso% Montato su

none                  1,0G     0  1,0G   0% /var/tmp/portage
```

Quindi, perchè non montare sempre al boot il tmpfs?

----------

## federico

Com'e' che tutti sui pacchetti piccoli hanno guadagnato manciate di secondi e io su nano ci perdo ?

senza:

real	0m41.751s

user	0m29.496s

sys	0m8.500s

con:

real	0m42.553s

user	0m29.194s

sys	0m8.298s

----------

## jp10hp

beh per una volta voglio fare il criticone, ecco i mie risultati prima con e poi senza lo script per la compilazione in ram!

```
     Mon May 23 19:42:56 2005 >>> media-video/vlc-0.8.1-r1

       merge time: 2 minutes and 53 seconds.

     Mon May 23 19:47:11 2005 >>> media-video/vlc-0.8.1-r1

       merge time: 2 minutes and 51 seconds.

```

ovviamente nelle stesse condizioni...

devo però precisare che io uso questa features di portage che forse genera di suo il boost che dovrebbe essere associato alla compilazione in ram:

```
# PORTAGE_TMPFS is a location where portage may create temporary files.

#     If specified, portage will use this directory whenever possible

#     for all rapid operations such as lockfiles and transient data.

#     It is _highly_ recommended that this be a tmpfs or ramdisk. Do not

#     set this to anything that does not give a significant performance

#     enhancement and proper FS compliance for locks and read/write.

#     /dev/shm is a glibc mandated tmpfs, and should be a reasonable

#     setting for all linux kernel+glibc based systems.

PORTAGE_TMPFS="/dev/shm"

```

cmq non so, aspetto illuminazioni! :Very Happy: Last edited by jp10hp on Mon May 23, 2005 6:02 pm; edited 1 time in total

----------

## .:chrome:.

 *jp10hp wrote:*   

> 
> 
> ```
> # PORTAGE_TMPFS is a location where portage may create temporary files.
> 
> ...

 

infatti... ci pensavo proprio oggi.

sarebbe interessante usare /dev/shm, ma in tutta onestà io so che esiste, ma non so bene a cosa serve, quindi il dubbio era sulla sua reale utilizzabilità.

se non saltano fuori critiche, jp10hp mi ha dato indirettamente la risposta

----------

## Cazzantonio

 *k.gothmog wrote:*   

> sarebbe interessante usare /dev/shm, ma in tutta onestà io so che esiste, ma non so bene a cosa serve, quindi il dubbio era sulla sua reale utilizzabilità.

 

beh... in ogni caso è un ramdisk...

```
none                    /dev/shm        tmpfs           defaults                0 0
```

quindi che problemi potrebbero esserci? (se non finire la ram sul più bello della compilazione  :Very Happy:  )

Forse il fatto che non viene smontato (e quindi ripulito) dopo che la compilazione è finita?  :Rolling Eyes: 

----------

## FonderiaDigitale

 *XstefanoX wrote:*   

> Scusate una domanda, ma non sarebbe più semplice aggiungere ad fstab una linea del tipo:
> 
> ```
> none     /tmp     tmpfs     size=800m     0 0
> ```
> ...

 

il motivo primario per cui smonto e rimonto il fs a ogni emerge e' che in questo modo pulisco tutto il disco in un colpo solo, facendo lavorare anche meno il disco.

----------

## FonderiaDigitale

 *jp10hp wrote:*   

> beh per una volta voglio fare il criticone, ecco i mie risultati prima con e poi senza lo script per la compilazione in ram!
> 
> ```
>      Mon May 23 19:42:56 2005 >>> media-video/vlc-0.8.1-r1
> 
> ...

 

stai usando ccache?

 *Quote:*   

> 
> 
> ```
> # PORTAGE_TMPFS is a location where portage may create temporary files.
> 
> ...

 

non e' la stessa cosa. il mio approccio compila TUTTO in memoria, non solo i file temporanei. si tratta di due approcci diversi: a ognuno usare quello che preferisce.

un'altra cosa: se hai un urgente bisogno di memoria, col mio sistema puoi  disabilitare in toto, temporaneamnete, l'uso di memoria fisica (es. stai lavorando su un progetto java e quella memoria ti serve per lo scopo). l'altro appoccio e' una-tantum.

----------

## FonderiaDigitale

 *federico wrote:*   

> Com'e' che tutti sui pacchetti piccoli hanno guadagnato manciate di secondi e io su nano ci perdo ?
> 
> senza:
> 
> real	0m41.751s
> ...

 

avevi la ram occupata per altri processi quando hai fatto la prova?

----------

## _Hadakaar

Scusate l'ignoranza, ma da dove si inseriscono nel kernel il tmpfs? non l'ho trovato in File Systems.

----------

## federico

 *FonderiaDigitale wrote:*   

>  *federico wrote:*   Com'e' che tutti sui pacchetti piccoli hanno guadagnato manciate di secondi e io su nano ci perdo ?
> 
> senza:
> 
> real	0m41.751s
> ...

 

Stavo utilizzando il pc penso normalmente, controllo meglio domani con + precisione forse e' meglio fare una riprova.

----------

## gutter

 *_Hadakaar wrote:*   

> Scusate l'ignoranza, ma da dove si inseriscono nel kernel il tmpfs? non l'ho trovato in File Systems.

 

```

File systems

       Pseudo filesystems

          [V] Virtual memory file system support (former shm fs) (TMPFS)

```

----------

## _Hadakaar

fatto e funziona, grazie  :Wink: 

Purtroppo però è andato in errore un pacchetto (gstreamer-ffmpeg), e non mi smonta più il tmpfs.

```
umount2: Dispositivo o risorsa occupata

umount: tmpfs: non trovato

umount: /var/tmp/portage: Illegal seek

umount2: Dispositivo o risorsa occupata

umount: /var/tmp/portage: device occupato
```

ho anche provato 

```
 lsof | grep mount
```

 ma l'outpit è vuoto

tra l'altro Firefox non compila....errore moooooolto grave

```

i686-pc-linux-gnu-gcc -o Linux2.6_x86_glibc_PTH_OPT.OBJ/pcertdb.o -c -O2 -fPIC -DLINUX1_2 -Di386 -D_XOPEN_SOURCE -DLINUX2_1 -ansi  -pipe -DLINUX -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSOFTOKEN_LIB_NAME=\"libsoftokn3.so\" -UDEBUG -DNDEBUG -D_REENTRANT -I/var/tmp/portage/mozilla-firefox-1.0.4/work/mozilla/dist/include  -I../../../../dist/public/nss -I../../../../dist/private/nss -I../../../../dist/include -I/var/tmp/portage/mozilla-firefox-1.0.4/work/mozilla/dist/include/nspr -I/var/tmp/portage/mozilla-firefox-1.0.4/work/mozilla/dist/include/dbm -I../../../../dist/public/dbm  pcertdb.c

{standard input}: Assembler messages:

{standard input}:1808: Error: bad register name `%ea8'

gmake[4]: *** [Linux2.6_x86_glibc_PTH_OPT.OBJ/pcertdb.o] Error 1

gmake[4]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.4/work/mozilla/security/nss/lib/softoken'

gmake[3]: *** [libs] Error 2

gmake[3]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.4/work/mozilla/security/nss/lib'

gmake[2]: *** [libs] Error 2

gmake[2]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.4/work/mozilla/security/manager'

gmake[1]: *** [tier_40] Error 2

gmake[1]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.4/work/mozilla'

make: *** [default] Error 2
```

----------

## ErniBrown

Ho trovato un errore: se la compilazione si interrompe non viene smontato il filesystem in memoria!

Ho dato un emerge -uD world, con dimensione del tmpfs di soli 200Mb; ovviamente si è bellamente piantato quando è arrivato all'update di openoffice, no space left on device. Visto che fra swap e memoria fisica arrivo sì e no a 1 giga ho disabilitato lo script, ma continuava a darmi lo stesso errore: dopo un po' ho capito che in caso di errore di compilazione, o errore di estrazione lo script non smonta la memoria! Quindi mi manteneva occupati 200Mb, e in più mi bloccava l'emerge di openoffice!

----------

## _Hadakaar

quello che ho detto io  :Very Happy: 

----------

## ErniBrown

pala grazie, devo sotterrarmi!

----------

## FonderiaDigitale

postate l'output di emerge info e di ls -l ${PORTAGE_TMPDIR}/portage

----------

## !equilibrium

installato e configurato come da guida proprio nel bel mezzo di un "emerge -uD world" e ha iniziato ad usare il ramfs senza fare una piega, il guadagno di prestazione è molto evidente sul mio notebook (che non è il massimo in fatto di prestazioni);

l'unica cosa che ho notato è che se do un "df" ottengo:

```
Filesystem           1K-blocks      Used Available Use% Mounted on

udev                    241652       688    240964   1% /dev

tmpfs                   307200     32676    274524  11% /var/tmp/portage
```

e la / ? e gli altri mount point che avevo (samba, nfs, cifs) non ci sono +, o meglio nel filesystem ci sono, posso tranquillamente surfare tra le samba/NFS share, solo che il comando "df" non le vede +; non sono sicuro che dipenda dal tuo script, io comunque lo segnalo lo stesso non si sa mai, ma sono sicuro che prima di installare il tuo script tale comando riportava i valori esatti perchè l'avevo appena lanciato prima di "emerge -uD world".

a parte questo, ti sei guadagnato un giro gratis di birra   :Mr. Green: 

----------

## FonderiaDigitale

son contento che ti sia stato utile  :Smile: 

cmq, hai provato con df -a?

----------

## !equilibrium

 *FonderiaDigitale wrote:*   

> son contento che ti sia stato utile 

 

utilissimo, almeno l'hd del notebook non viene impegnato durante la compilazione e questo non è poco nel mio caso specifico; a parte l'aumento di prestazioni in fase di compilazione ho anche l'indubbio beneficio di non avere la CPU occupata da processi di lettura/scrittura della compilazione, a totale vantaggio della fluidità del DE (ovviamente non è che faccia miracoli, ma la differenza si nota)

 *Quote:*   

> cmq, hai provato con df -a?

 

si, ma riporta sempre gli stessi mount point:

```
Filesystem           1K-blocks      Used Available Use% Mounted on

proc                         0         0         0   -  /proc

sysfs                        0         0         0   -  /sys

udev                    241652       688    240964   1% /dev

devpts                       0         0         0   -  /dev/pts

usbfs                        0         0         0   -  /proc/bus/usb

tmpfs                   307200     63376    243824  21% /var/tmp/portage
```

----------

## FonderiaDigitale

molto strano.. che versione di coreutils hai? io ~5.2.1-r6

----------

## !equilibrium

 *FonderiaDigitale wrote:*   

> molto strano.. che versione di coreutils hai? io ~5.2.1-r6

 

idem  :Crying or Very sad: 

```
 emerge -av coreutils

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] sys-apps/coreutils-5.2.1-r6  -acl -build -debug -hardened +nls (-selinux) -static (-uclibc) 4,259 kB
```

----------

## FonderiaDigitale

non capisco. posta l'output di

```
mount

cat /proc/mtab

```

non vorrei fosse qualcosa a livello kernel. hai grsec o lids?

----------

## !equilibrium

 *FonderiaDigitale wrote:*   

> non capisco. posta l'output di
> 
> ```
> mount
> 
> ...

 

no assolutamente, normalissimo kernel 'gentoo-sources' esente da qualsiasi tipo di patch,

idem tutto l'ambiente è una normalissima gentoo ~x86, niente SELinux o cose simili;

comunque non è importante, non influisce sul funzionamento di tutto il resto.

----------

## Cazzantonio

Non smonta il tmpfs non solo se interrotto dall'esterno (ctrl+c) ma anche quando si blocca per un errore...

Inoltre anche la compilazione di wine falliva per "no space left on device"... e gli avevo dato ben 512 mega.... (su 1 giga)  :Rolling Eyes: 

Forse bisognerebbe ritirare fuori questo script l'anno prossimo quando avremo tutti 2 p 3 giga di ram sui nostri pc  :Wink: 

----------

## makoomba

veramente un bel tip.

ho iniziato la migrazione di tutti i servers a gentoo e lo sto utilizzando dal bootstrap.

solo un problema, "mount" non è presente nello stage1, ho risolto copiandolo da cd (con relative dipendenze).

è un pò grezzo, sono sicuro che dev'esserci una soluzione più elegante.

----------

## _Hadakaar

 *FonderiaDigitale wrote:*   

> postate l'output di emerge info e di ls -l ${PORTAGE_TMPDIR}/portage

 

per ora non posso fare nulla:(  :Sad:   :Sad:   :Sad: 

https://forums.gentoo.org/viewtopic-p-2443479.html#2443479

----------

## Raffo

stasera mi ci faccio un giro  :Wink: 

----------

## FonderiaDigitale

 *Cazzantonio wrote:*   

> Non smonta il tmpfs non solo se interrotto dall'esterno (ctrl+c) ma anche quando si blocca per un errore...
> 
> Inoltre anche la compilazione di wine falliva per "no space left on device"... e gli avevo dato ben 512 mega.... (su 1 giga) 
> 
> Forse bisognerebbe ritirare fuori questo script l'anno prossimo quando avremo tutti 2 p 3 giga di ram sui nostri pc 

 

le prove che ho fatto io sono proprio di interromperlo con SIGTERM, o CTRL+C. a me funziona.

Tieni conto cmq che non e' nato per essere ficcato nel make.conf e lasciato li con i settaggi di default per qualsiasi cosa: va da se che in ram non puoi compilare tutto openoffice.

----------

## FonderiaDigitale

 *makoomba wrote:*   

> veramente un bel tip.
> 
> ho iniziato la migrazione di tutti i servers a gentoo e lo sto utilizzando dal bootstrap.
> 
> solo un problema, "mount" non è presente nello stage1, ho risolto copiandolo da cd (con relative dipendenze).
> ...

 

basterebbe usare mtab.

il problema e' che per vedere i fs montati basta quello, ma per montarlo serve comunque mount (che sta fuori dal chroot)

----------

## makoomba

 *FonderiaDigitale wrote:*   

> il problema e' che per vedere i fs montati basta quello, ma per montarlo serve comunque mount (che sta fuori dal chroot)

 

infatti il problema è il "montaggio" e "smontaggio" del tmpfs

cmq, il bootstrap con gcc-3.4 è stato completato regolarmente compilando tutto in ram.

invece il successivo emerge -e system si è bloccato su openssl (mi pare?) dicendo che mancava perl ???

disabilitando la compilazione in ram è filato tutto liscio....

----------

## Cazzantonio

@FonderiaDigitale

Pensi sia possibile implementare un modo per escludere particolari pacchetti dalla compilazione in ram?

Tipo un check su una lista di file dove indicare i pacchetti da escludere...

----------

## Dece

Ottimo tip complimenti  :Very Happy:  anche se (ovviamente) con i pacchetti piccoli non ho notato nessuna riduzione dei tempi di compilazione: appena ho tempo provo con qualche cosa di più sostanzionso da compilare, magari sul portatile dove ho l'hd più lento e dovrei notare miglioramenti  :Smile:  cmq rimane il fatto che compilando in ram gli hard disk ne traggono un gran vantaggio.

Non ho capito qual è il problema del mount: ho provato a interrompere una compilazione con ctrl-c, e quando l'ho fatta ripartire mi ha correttamente smontato e rimontato /var/tmp/portage: alla peggio si può smontare a mano... se mi sono perso qualcosa bacchettatemi pure  :Wink: 

Ciao!

----------

## ErniBrown

il problema è che viene smontata quando riparte la compilazione, mentre dovrebbe essere smontata appena dopo l'interruzione di emerge, prima della fine dello script. Altrimenti una buona fetta della memoria rimane inutilizzabile (anche se probabilmente viene passata allo swap).

----------

## Dece

 *ErniBrown wrote:*   

> il problema è che viene smontata quando riparte la compilazione, mentre dovrebbe essere smontata appena dopo l'interruzione di emerge, prima della fine dello script. Altrimenti una buona fetta della memoria rimane inutilizzabile (anche se probabilmente viene passata allo swap).

 

Capito  :Smile: 

Quindi o si patcha emerge o si fa uno scriptino che controlla se ci sono processi di emerge attivi e in caso contrario smonta tmpfs o... non so  :Wink: 

----------

## FonderiaDigitale

ok: vedro' di fare trapping dei segnali, se riesco... ma non credo, visto che il bashrc viene invocato PRIMA di eseguire ogni singolo passo dell'ebuild, e non durante, quindi dovrei scrivere un qualcosa che esegua PRIMA di emerge stesso, soluzione che non mi piace affatto; la soluzione del rimontaggio all'emerge era proprio un workaround a questo.

.. e implementare la famosa lista dei pacchetti: a tal proposito, se avete una lista (a coppie, pacchetto - dimensione) da suggerire di modo tale che la implemento.

----------

## Ciccio Bueo

FonderiaDigitale alla homer j. s. MMM-ITICO!

ottimo, dopo un emerge -uDav world tutto ok e in pochissimo tempo (poche ore su p3 733)!  :Very Happy: 

----------

## CRV§ADER//KY

 *randomaze wrote:*   

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

 

2.5 Gb se non ricordo male.

Io ho semplicemente aggiunto a fstab

```
none                    /tmp                    tmpfs           defaults,size=1595M   0 0

none                    /var/tmp                tmpfs           defaults,size=1595M   0 0
```

e funziona benissimo. Al termine di un emerge, portage lascia in /var/tmp/portage una manciata di kb, quindi non vale proprio la pena IMHO ripulire tutto ogni volta; l'unico caso in cui lascia files temporanei è quando una compilazione fallisce o viene interrotta. Confermo che i tmpfs possono essere di qualsiasi dimensione fino a quella massima di RAM+swap e che, finché sono vuoti, non influiscono minimamente sul quantitativo di RAM/swap libero.

[EDIT]Nota per chi hostasse un server: poiché TUTTI gli utenti possono scrivere su /tmp e /var/tmp, vi sconsiglierei di settare la dimensione di tali fs temporanei a quella massima di swap+RAM, in quanto qualunque utente locale può farvi un bel DoS generalizzato tramite errori di out of memory, banalmente allocando tutto lo spazio su /tmp.

----------

## Benve

 *CRV§ADER//KY wrote:*   

> 
> 
> Io ho semplicemente aggiunto a fstab
> 
> ```
> ...

 

Sto eseguendo una installazione (da stage3) in questo modo e tutto sembra andare a meraviglia.

C'è un tool a linea di comando per monitorare l'uso del disco ?

----------

## CRV§ADER//KY

 *Benve wrote:*   

> C'è un tool a linea di comando per monitorare l'uso del disco ?

 

df -h

----------

## Benve

 *CRV§ADER//KY wrote:*   

>  *Benve wrote:*   C'è un tool a linea di comando per monitorare l'uso del disco ? 
> 
> df -h

 

 :Smile:  intendevo qulcosa tipo gkrellm che mostra i byte trasferiti...

----------

## cloc3

 *randomaze wrote:*   

> 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:
> 
> ```
>  PORTAGE_MEMSIZE=512 emerge xorg-x11
> ```
> ...

 

Infatti, io che non avevo ancora letto questo post, ho trovato:

```

gentoo-amd ~ #  du -sh /var/tmp/portage/xorg-x11-6.8.99.8/

580M    /var/tmp/portage/xorg-x11-6.8.99.8/

```

Immagino anche (direi ovviamente), che questa opzione sia incompatibile con le FEATURES="keepwork keeptemp".

----------

## Dece

 *cloc3 wrote:*   

> Immagino anche (direi ovviamente), che questa opzione sia incompatibile con le FEATURES="keepwork keeptemp".

 

Se sono settate nel make.conf funziona tutto lo stesso, ovviamente non hanno alcun effetto  :Smile: 

----------

## ballero

Tool molto interessante, ma prima di provarlo aspettero' una fase piu' approfondita di testing. 

Ad ogni modo complimenti a FonderiaDigitale.  :Smile: 

----------

## Cazzantonio

 *ballero wrote:*   

> Tool molto interessante, ma prima di provarlo aspettero' una fase piu' approfondita di testing. 

 

E' assolutamente sicuro da usare... l'unico problema può essere finire lo spazio sulla ram  :Smile: 

L'unica accortezza è quella di smontare il tmpfs nel caso esca per un errore di compilazione (dovuto alle dimensioni del ramdisk oppure perché un determinato pacchetto non compila... a volte succede anche senza ramdisk  :Wink:  )

----------

## thewally

 *Cazzantonio wrote:*   

> 
> 
> E' assolutamente sicuro da usare... l'unico problema può essere finire lo spazio sulla ram 
> 
> 

 

Successo, in compilazione di mozilla-thunderbird con 400MB (ho solo 512MB di ram  :Crying or Very sad:  )

 *Cazzantonio wrote:*   

> 
> 
> L'unica accortezza è quella di smontare il tmpfs nel caso esca per un errore di compilazione (dovuto alle dimensioni del ramdisk oppure perché un determinato pacchetto non compila... a volte succede anche senza ramdisk  )

 

Successo ache questo. Bisognerebbe includere un controllo prima del montaggio della partizione, cancellare il contenuto di /var/tmp/portage [1] e smontare tmpfs (se necessario). Parola all'autore....

The Wally

[1] Anche se credo che una cancellazione sconsiderata di quella dir potrebbe creare problemi con la compilazione di meta pkg (I sorgenti di kde hanno meno tar che ebuild). Ditemi voi, io sono niubbo si Gentoo.

----------

## CRV§ADER//KY

 *thewally wrote:*   

>  *Cazzantonio wrote:*   
> 
> E' assolutamente sicuro da usare... l'unico problema può essere finire lo spazio sulla ram 
> 
>  
> ...

 

Aumenta lo swap.

----------

## fctk

una domanda un po' stupida... secondo voi mi conviene provare a compilare nella ram nonostante abbia solo 256mb a disposizione? secondo me sono troppo pochi ma vorrei avere anche il vostro parere...

----------

## Cazzantonio

@fctl

256 mega di ram sono pochine... anche 512 secondo me sono troppo poche...

IMHO lo script è utile se hai almeno 1 giga di ram...

----------

## ErniBrown

io ho 512, e in effetti per le cose più grosse mi tocca disabilitare il tutto: a proposito: c'è un modo più pratico per disabilitare il tutto se non cancellare bashrc da /etc/portage?

----------

## Cazzantonio

 *ErniBrown wrote:*   

> io ho 512, e in effetti per le cose più grosse mi tocca disabilitare il tutto: a proposito: c'è un modo più pratico per disabilitare il tutto se non cancellare bashrc da /etc/portage?

 

non passare la variabile PORTAGE_MEMSIZE ?  :Rolling Eyes: 

Se l'hai messa nel make,conf basta commentare la voce, altrimenti basta non scriverla davanti al comando emerge  :Wink: 

----------

## ErniBrown

 *Cazzantonio wrote:*   

> ... basta non scriverla davanti al comando emerge 

 

Nell'arco di due minuti mi hai già dato due dritte utili! Grande!

----------

## CRV§ADER//KY

 *fctk wrote:*   

> una domanda un po' stupida... secondo voi mi conviene provare a compilare nella ram nonostante abbia solo 256mb a disposizione? secondo me sono troppo pochi ma vorrei avere anche il vostro parere...

 

Basta che tu abbia swap a sufficienza; potrai comunque usufruire della velocità della RAM per tutti i pacchetti piccoli (cioé la massima parte).

----------

## !equilibrium

 *ErniBrown wrote:*   

> io ho 512, e in effetti per le cose più grosse mi tocca disabilitare il tutto: a proposito: c'è un modo più pratico per disabilitare il tutto se non cancellare bashrc da /etc/portage?

 

si vero, però le cose "grosse" non le ricompili ogni 2 giorni  :Wink:  (almeno spero)

----------

## FonderiaDigitale

 *Cazzantonio wrote:*   

> @fctl
> 
> 256 mega di ram sono pochine... anche 512 secondo me sono troppo poche...
> 
> IMHO lo script è utile se hai almeno 1 giga di ram...

 

no. finiresti comunque a swappare, e se hai la swap criptata e' pure peggio. (parlando cmq di pacchetti di un certo peso, tipo vlc, oo, xorg..)

----------

## FonderiaDigitale

 *Cazzantonio wrote:*   

>  *ErniBrown wrote:*   io ho 512, e in effetti per le cose più grosse mi tocca disabilitare il tutto: a proposito: c'è un modo più pratico per disabilitare il tutto se non cancellare bashrc da /etc/portage? 
> 
> non passare la variabile PORTAGE_MEMSIZE ? 
> 
> Se l'hai messa nel make,conf basta commentare la voce, altrimenti basta non scriverla davanti al comando emerge 

 

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

gestione automatica dei casi sopra via /etc/portage/package.mem: Da implementare  :Very Happy: 

ps. personalmente ritengo piu utile lasciare la variabile nel make.conf con valore nullo, di modo tale da avere tutto sottomano una volta che se ne ha bisogno (non mi terrei mai tutte le variabili a mente  :Smile: )

----------

## FonderiaDigitale

 *thewally wrote:*   

> 
> 
>  *Cazzantonio wrote:*   
> 
> L'unica accortezza è quella di smontare il tmpfs nel caso esca per un errore di compilazione (dovuto alle dimensioni del ramdisk oppure perché un determinato pacchetto non compila... a volte succede anche senza ramdisk  ) 
> ...

 

non so che versione hai provato tu, comunque sia il controllo e' gia' stato inserito. quello che e' strano, e' che alcune persone riportano errori di questo genere, altre 0.

a me farebbe comodo avere un minimo di informazioni in piu dalle persone che riportano errori, in special modo:

```
emerge info

cat /proc/mounts

. /etc/make.conf && lsof|grep ${PORTAGE_TMPDIR}

```

o darmi accesso temporaneo alla macchina (se vi fidate  :Razz: ) quando sono connesso via IM.

----------

## fctk

 *FonderiaDigitale wrote:*   

>  *Cazzantonio wrote:*   @fctl
> 
> 256 mega di ram sono pochine... anche 512 secondo me sono troppo poche...
> 
> IMHO lo script è utile se hai almeno 1 giga di ram... 
> ...

 

forse non ho capito... ma se uno ha 1gb di ram non è ancora sufficiente?

----------

## gutter

 *fctk wrote:*   

> 
> 
> forse non ho capito... ma se uno ha 1gb di ram non è ancora sufficiente?

 

No, se devi compilare roba grossa tipo OO allora non ti basta.

----------

## FonderiaDigitale

per renderti conto della situazione:

fai,senza il tool, emerge openoffice. interrompi la compilazione a meta'. vai in /var/tmp/portage/openoffice* e scrivi: du -sh.

----------

## fctk

ok... credo di aver capito il concetto...

ho provato con wxGTK e non con ooo, e il risultato è comunque desolante:

```
thorium / # du -sh /var/tmp/portage/wxGTK-2.6.0-r1/

285M   /var/tmp/portage/wxGTK-2.6.0-r1/
```

vabbè... lascio perdere...

----------

## CRV§ADER//KY

 *fctk wrote:*   

> ok... credo di aver capito il concetto...
> 
> ho provato con wxGTK e non con ooo, e il risultato è comunque desolante:
> 
> ```
> ...

 

Scusa, ma quanto hai di swap? se hai almeno mezzo Gb (come dovresti) non c'è assolutamente nessun problema...

----------

## fctk

sì, ho mezzo giga ma non capisco perchè non avrei nessun problema... la swap è spazio sull'hard disk, quindi utilizzare la swap o utilizzare /var/tmp/portage è lo stesso... andrebbe lento uguale... ovviamente IMHO

----------

## CRV§ADER//KY

 *fctk wrote:*   

> sì, ho mezzo giga ma non capisco perchè non avrei nessun problema... la swap è spazio sull'hard disk, quindi utilizzare la swap o utilizzare /var/tmp/portage è lo stesso... andrebbe lento uguale... ovviamente IMHO

 

Sì e no. Non conosco le specifiche di tmpfs, ma se è fatto come penso (ovvero parte dal presupposto che non deve garantire la consistenza dei dati in caso di arresto del PC) sarà comunque molto più veloce di altri filesystem, pur avendo un quantitativo di RAM limitata, per il semplice motivo che (1) terrà molta più roba in cache di scrittura e (2) la dimensione della cache arriverà potenzialmente al totale della RAM, cosa che dubito sia vera per i file system tradizionali.

----------

## fctk

alla fine mi sono deciso di provare questo tip... ma dalle prove che ho fatto risulta che i tempi di compilazione sono praticamente gli stessi di prima (i pacchetti provati sono: nano, xchat, mplayer).

non vorrei che ciò dipendesse dal fatto che uso ccache...

----------

## CRV§ADER//KY

 *fctk wrote:*   

> alla fine mi sono deciso di provare questo tip... ma dalle prove che ho fatto risulta che i tempi di compilazione sono praticamente gli stessi di prima (i pacchetti provati sono: nano, xchat, mplayer).
> 
> non vorrei che ciò dipendesse dal fatto che uso ccache...

 

Ma quanta RAM libera hai? non è che, durante la compilazione, tieni aperti KDE, Firefox, Apache o altri programmi affini?

----------

## fctk

no no, i test li ho fatti con fluxbox chiuso...

non so esattamente quanta ram libera avessi, ma credo almeno 200mb su 256mb (dato che quando chiudo X circa 50mb risultano occupati)

----------

## skakz

posso proporre un suggerimento?

introdurrei un controllo per vedere se il pacchetto che si sta cercando di emergere è un binario o meno,dato che questa procedura risulta inutile per i pacchetti precompilati oppure in alternativa introdurrei l'uso di un file (del tipo /etc/portage/package.tmpfs) dove includere tutti i pacchetti che non si vogliono emergere con questa procedura...

o implementare entrambe le features  :Razz:  non so.. a voi la parola..

----------

## CRV§ADER//KY

 *darkdude wrote:*   

> introdurrei un controllo per vedere se il pacchetto che si sta cercando di emergere è un binario o meno

 

Non è vero, i pacchetti binari vengono prima scompattati nella sandbox e poi copiati.

emerge -k non dovrebbe toccare la sandbox in nessun caso.

----------

## skakz

 *CRV§ADER//KY wrote:*   

> 
> 
> Non è vero, i pacchetti binari vengono prima scompattati nella sandbox e poi copiati.
> 
> emerge -k non dovrebbe toccare la sandbox in nessun caso.

 

che c'entra? i pacchetti scompattati prima o poi dovranno essere  copiati sull'hd, farli passare per una sandbox montata in ram mi sembra una procedura inutile...

----------

## Cazzantonio

 *darkdude wrote:*   

> in alternativa introdurrei l'uso di un file (del tipo /etc/portage/package.tmpfs) dove includere tutti i pacchetti che non si vogliono emergere con questa procedura...

 

Penso che fonderia stia lavorando su una cosa di questo tipo... o almeno questo ho capito in uno dei suoi post precedenti...

----------

## CRV§ADER//KY

 *darkdude wrote:*   

>  *CRV§ADER//KY wrote:*   
> 
> Non è vero, i pacchetti binari vengono prima scompattati nella sandbox e poi copiati.
> 
> emerge -k non dovrebbe toccare la sandbox in nessun caso. 
> ...

 

No, i pacchetti binari (openoffice-bin, nvidia-glx, opera, etc.) passano prima dalla sandbox; in questo modo si è sicuri che non vanno a fare porcherie in giro per il file system. Quindi se hai tmpfs hai 1 scrittura su disco, se non ce l'hai hai 1 scrittura, 1 lettura e infine 1 scrittura.

----------

## khris81

a me rallenta paurosamente il sistema con questa cosa, nn ho notato il minimo miglioramento!  :Sad: 

----------

## Cazzantonio

nemmeno io penso ci sia stato un boost di prestazioni... però mi piace l'idea che la compilazione non avvenga su hd  :Wink: 

Lui lavora meno, si spacca meno e io sono più contento  :Smile:  (anche il mio portafogli...)

----------

## pistodj

Scusate per la richiesta ma tempo fa avevo letto un howto per fare la compilazione in ram...

Sono 2 giorni che lo cerco sia in google che nel forum... nn è che uno di voi mi posta il link?

Grazie e Scusate ancora!!

----------

## johnnystuff

https://forums.gentoo.org/search.php

 :Cool: 

----------

## .:chrome:.

puoi anche impostare /dev/shm come PORTAGE TEMPDIR

----------

## knefas

https://forums.gentoo.org/viewtopic-t-340329-highlight-compilazione+ram.html

(ti ho lasciato le parole evidenziate cosi' vedi come l'ho trovato io). 

Ricorda che il search del forum di default non cerca nei forum nazionali, per cui lo devi selezionare esplicitamente. Buon lavoro  :Smile: 

----------

## Kernel78

Trovo questo tips stupendo (a prescindere dall'aumento di prestazioni diminuire le scritture su disco non può che rendermi felice).

Ho però qualche dubbio io ho 756M di ram e altrettanti di swap (e al 99% del tempo la swap è completamente vuota) avevo impostato ccache ma aquesto punto mi chiedo se mantenga la sua utilità ...

Voi cosa dite mi conviene tenerlo o è meglio toglierlo ?

----------

## gutter

Fatto il merge del thread di pistodj con questo.

----------

## bld

 *k.gothmog wrote:*   

> puoi anche impostare /dev/shm come PORTAGE TEMPDIR

 

cosa ottieni in piu se fai questo? Spazio, velocita' e minore stress del disco rigido?

----------

## Kernel78

Secondo voi mi bastano 500 mb riservati per la compilazione di kde 3.4.1 versione split ? essendo programma per programma dovrebbe bastare ma non vorrei trovarmi sorprese ...

----------

## bender86

Che fine ha fatto il bashrc? L'indirizzo specificato è irraggiungibile.

----------

## gutter

 *bender86 wrote:*   

> Che fine ha fatto il bashrc? L'indirizzo specificato è irraggiungibile.

 

Hai provato a contattare con un PM l'autore dello script?

----------

## FonderiaDigitale

ho aggiornato il file. le modifiche sono nel primo post.

----------

## Kernel78

Domanda: se voglio che un pacchetto non venga compilato in ram posso mettere nel file package.mem un valore 0 ?

Complimenti, hai salvato la vita del mio hd con questo tip   :Wink: 

----------

## ultimodruido

Ciao, sono in fase aggiornamento sistema e ho deciso di provare le prestazioni della tua soluzione.

solo una cosa: ho scaricato il file bashrc oggi sabato 28 gen, e usandolo emerge lamenta un syntax error alla linea 25 dove ci sta una }

spero di esser utile ciao

Nic

----------

## Kernel78

Ho provato adesso a emergere qualcosa e anche commentando la parentesi della riga 25 da un bell'errore 

```
/etc/portage/bashrc: line 168: ismounted: command not found
```

----------

## FonderiaDigitale

pardon. c'era un refuso.

ho aggiornato il link. provate adesso

----------

## Kernel78

C'è ancora un problema (ho provato a emergere joe) ma ...

```
>>> md5 src_uri ;-) joe-3.2.tar.gz

/etc/portage/bashrc: line 180: ismounted: command not found

```

/EDIT: ho anche notato che mentre prima quando montava tmpfs dava una dimensione tipo 1000M mentre adesso scrive un (IMHO molto più brutto) * Mounting 1000000000 bytes (as tmpfs) to /var/tmp/portage ...

Non si potrebbe riportare la dicitura come prima ?

----------

## FonderiaDigitale

si, e' innocuo, puoi commentare la riga, o lo puoi riscaricare.

sembra che io sia piu' rincoglionito del solito  :Smile: 

----------

## Kernel78

Adesso va bene, devo testare approfonditamente anche la funzionalità del file package.mem (grazie per questa innovazione, la aspettavo da tempo).

Non è che potresti anche guardare il problema estetico che chiedevo nel post precedente ?

----------

## Kernel78

Altro problema ...

```
>>> app-editors/joe-3.2 merged.

 * Unmounting  ...

Usage: umount [-hV]

       umount -a [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]

       umount [-f] [-r] [-n] [-v] special | node...

Cannot umount, erasing contents.

 * Using defined in shell global tmpfs size: [ 1000000000 ]

 * Mounting 1000000000 bytes (as tmpfs) to /var/tmp/portage ...

>>> clean: No packages selected for removal.

```

e un df -h mi mostra 

```
none                  954M     0  954M   0% /var/tmp

```

----------

## FonderiaDigitale

ok, prova questo.

ho fatto l'ebuild:

pagina degli ebuilds

----------

## FonderiaDigitale

 *xchris wrote:*   

> 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.
> ...

 

cito christian per un'osservazione:

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:

```

nano /etc/portage/package.mem
```

```

app-office/openoffice-ximian    2G

kde-base/kdelibs                    800M

sys-devel/gcc                         500

```

e cosi' via.

Usandolo globale e per-pacchetto comunque secondo me ci guadagna in emivita ( :Very Happy: ) il disco fisso.

----------

## Kernel78

Altro problemino ... (dopo aver installato la versione 0.4)

All'inizio mi informa che sta montanto 1000M (la dimensione che ho specificato io)

```
 * Using /etc/make.conf global tmpfs size: [ 1000 mbytes ]

 * Mounting /var/tmp/portage ...

```

Il problema è che mount mi segnala montata /var/tmp (non /var/tmp/portage) e inoltr df mi riporta

```
Filesystem        blocchi di   1K   Usati Disponib. Uso% Montato su

/dev/hda3              7646672   5237688   2408984  69% /

udev                    387296       240    387056   1% /dev

/dev/hda4              2835364   1675920   1159444  60% /home

/dev/hda1              2043296   1301656    741640  64% /mnt/windows

none                    387296         0    387296   0% /dev/shm

```

 :Shocked:  non mi segnala ne /var/tmp ne /var/tmp/portage  :Crying or Very sad: 

Io mi basavo su df per valutare la quantità di memoria da far allocare ... potrei usare du ma non riesco a capire il perchè di queste anomalie   :Confused: 

----------

## ultimodruido

ciao ho installato tutto dall'ebuild da poco, ora stavo testando.

Confermo anche io l'ultimo commento di Kernel78, viene montata /var/tmp/

Credo che l'errore sia alla riga 141 di bashrc

```
/bin/mount -o size=${memsize},mode=770 -t tmpfs none ${PORTAGE_TMPDIR}
```

Infatti alla riga 133 si dice

```
ebegin "Mounting ${PORTAGE_TMPDIR}/portage"
```

 e siccome l'output è 

```
 * Mounting /var/tmp/portage ... 
```

 si deduce che 

```
${PORTAGE_TMPDIR} = /var/tmp
```

spero di aver beccato il punto giusto... 

ciaoaoao, grazie Nic

----------

## FonderiaDigitale

 *Kernel78 wrote:*   

> Altro problemino ... (dopo aver installato la versione 0.4)
> 
> All'inizio mi informa che sta montanto 1000M (la dimensione che ho specificato io)
> 
> ```
> ...

 

e' voluto, perche' portage in realta' non usa $PORTAGE_TMPDIR ma $PORTAGE_TMPDIR/portage

 *Kernel78 wrote:*   

> e inoltr df mi riporta
> 
> ```
> Filesystem        blocchi di   1K   Usati Disponib. Uso% Montato su
> 
> ...

 

quando l'emerge termina viene smontata. 

hai fatto df dopo aver terminato l'emerge o hai stoppato durante e fatto df?

----------

## Ferdinando

 *FonderiaDigitale wrote:*   

> e' voluto, perche' portage in realta' non usa $PORTAGE_TMPDIR ma $PORTAGE_TMPDIR/portage

 

Credo ci fosse un refuso, io ho fatto questa modifica:

```
141c141

<       /bin/mount -o size=${memsize},mode=770 -t tmpfs none ${PORTAGE_TMPDIR}

---

>       /bin/mount -o size=${memsize},mode=770 -t tmpfs none ${PORTAGE_TMPDIR}/portage
```

Questo risolve anche il problema del df.

Comunque mi dà:

```
rm: impossibile rimuovere la directory `/var/tmp/portage': Dispositivo o risorsa occupata

mkdir: impossibile creare la directory `/var/tmp/portage': Il file esiste
```

Per il resto tutto bene.

Ciao

----------

## Kernel78

 *FonderiaDigitale wrote:*   

>  *Kernel78 wrote:*   e inoltr df mi riporta
> 
> ```
> Filesystem        blocchi di   1K   Usati Disponib. Uso% Montato su
> 
> ...

 

ne l'uno ne l'altro, ho fatto df da un altro terminale durante l'emersione e la cosa mi stupiva perchè alternando df e mount continuavo a non vederla con df e a vederla con mount  :Confused: 

----------

## Ferdinando

 *Kernel78 wrote:*   

> ne l'uno ne l'altro, ho fatto df da un altro terminale durante l'emersione e la cosa mi stupiva perchè alternando df e mount continuavo a non vederla con df e a vederla con mount 

 

Idem per me. Comunque la patch che ho postato prima ha risolto.

La cosa per me era grave perché montando /var/tmp/ mi cancellava sia la ccache sia i miei distfiles (che tengo in /var/tmp/distfiles), e quindi riscaricava tutto...

Ciao

EDIT: Mi correggo, a quanto pare df non me la vede più   :Confused: 

Eppure, facendolo a mano:

```
root@Aurora portage # /bin/mount -o size=900M,mode=770 -t tmpfs none /var/tmp/portage

root@Aurora portage # mount

[...]

none on /var/tmp/portage type tmpfs (rw,size=900M,mode=770)

root@Aurora portage # df

Filesystem        blocchi di   1K   Usati Disponib. Uso% Montato su

[...]

none                    921600         0    921600   0% /var/tmp/portage
```

Boh

----------

## Ferdinando

Risolto il problema del df:

```
107c107

<               m=${PORTAGE_TMPDIR}

---

>               m=${PORTAGE_TMPDIR}/portage

141c141

<       /bin/mount -o size=${memsize},mode=770 -t tmpfs none ${PORTAGE_TMPDIR}

---

>       /bin/mount -o size=${memsize}M,mode=770 -t tmpfs none ${PORTAGE_TMPDIR}/portage
```

Ciao

----------

## Cazzantonio

 *Kernel78 wrote:*   

> Domanda: se voglio che un pacchetto non venga compilato in ram posso mettere nel file package.mem un valore 0

 

Sarei curioso anche io di saperlo...   :Rolling Eyes: 

P.S. hai provato a mandarlo ai dev di gentoo per una eventuale valutazione? (magari potrebbe essere una feature carina da introdurre in un portage futuro....)   :Wink: 

P.P.S. nel primo post c'è indicato /ec/portage/package.mem invece di /etc/portage/package.mem... ok che è un errore da nulla ma te lo segnalo comunque   :Wink: 

----------

## FonderiaDigitale

ok grazie.

la fix di ferninando in realta' l'avevo gia aggiunta alla 0.5

ho aggiornato l'ebuild

ho aggiunto un altro paio di controlli per ccache

ps. penso che mettero' un server rsync prima o poi.

----------

## Ferdinando

 *FonderiaDigitale wrote:*   

> ps. penso che mettero' un server rsync prima o poi.

 

Magari!!!   :Very Happy: 

Ciao

----------

## FonderiaDigitale

 *Cazzantonio wrote:*   

> 
> 
> P.S. hai provato a mandarlo ai dev di gentoo per una eventuale valutazione? (magari potrebbe essere una feature carina da introdurre in un portage futuro....)  
> 
> 

 

no per questi motivi:

- mi darebbero la stessa risposta che dettero a christian riguardo a unclepine tempo fa, ovvero 'is a ugly hack'

- non e' sufficientemente testato per essere distribuito

- prima o poi lo implementeranno direttamente in python, credo.

----------

## Ic3M4n

```
no per questi motivi: 

- mi darebbero la stessa risposta che dettero a christian riguardo a unclepine tempo fa, ovvero 'is a ugly hack' 
```

beh... mal che vada te lo dicono. e se non te lo dicessero?

```

- non e' sufficientemente testato per essere distribuito 
```

credo che la comunità italiana di gentoo o comunque una buona parte lo utilizzi. si può fare un sondaggio/sondaggino?

```

- prima o poi lo implementeranno direttamente in python, credo.
```

è autoesplicativa...

----------

## Ferdinando

Con il portage-bashrc-0.5 però continua a montarmi tmpfs con size=900 invece di size=900M, e così df non mostra la partizione:

```
root@Aurora ~ # DEBUG=on emerge k3b

Calculating dependencies  ...done!

>>> emerge (1 of 1) app-cdr/k3b-0.12.10 to /

:: evaluating memory size of: 900M

:: evaluating new size:900

:: evaluating memunit:M

:: new size of memory disk is:900

:> make.conf mem:900M

900

 * Using shell global tmpfs size: [ 900 mbytes ]

 * Mounting /var/tmp/portage.

 * Please remember that ccache data dir is outside the newly mounted

 * portage temporary directory, to preserve the spool between merges.
```

Ciao

----------

## FonderiaDigitale

sei sicuro di avere l'ultima versione?

----------

## Ferdinando

 *FonderiaDigitale wrote:*   

> sei sicuro di avere l'ultima versione?

 

In effetti ho fatto un diff con l'ebuild sul sito e vedo che l'url è cambiata; sto riscaricando.

P.S. C'è un modo per evitare che provi a scaricarlo da tutti i mirrors internazionali?

Ciao

----------

## fabius

Ci sarebbero due questioni da risolvere:

 se il valore della memoria è 0, non ha senso montare la directory temporanea;

 se la variabile ambiente PORTAGE_MEMSIZE è settata in make.conf ed uso portage.mem per sovrascriverla, la mia impostazione viene ignorata

----------

## FonderiaDigitale

 *fabius wrote:*   

> Ci sarebbero due questioni da risolvere:
> 
>  se il valore della memoria è 0, non ha senso montare la directory temporanea;

 

questo era un controllo che era presente nella prima versione.

l'ho tolto in quanto ritenevo fosse piu sensato non impostare la variabile globalmente piuttosto che azzerarla.

Provvedero'

 *Quote:*   

> 
> 
>  se la variabile ambiente PORTAGE_MEMSIZE è settata in make.conf ed uso portage.mem per sovrascriverla, la mia impostazione viene ignorata
> 
> 

 

/etc/portage/package.mem

----------

## fabius

 *FonderiaDigitale wrote:*   

> /etc/portage/package.mem

 

Si, ho sbagliato a scrivere ma il problema esiste. Tu fai 3 controlli in sequenza dell'esistenza di

PORTAGE_MEMSIZE in /etc/make.conf

 settaggio in package.mem

 variabile ambiente PORTAGE_MEMSIZE

Il problema è che emerge inserisce nell'ambiente di esecuzione di bashrc la variabile PORTAGE_MEMSIZE prelevata da make.conf

----------

## FonderiaDigitale

che version e di portate hai?

anzi meglio:

```
emerge info
```

----------

## fabius

Ho il sistema x86, quindi stabile. Ti faccio un esempio del malfunzionamento: ho PORTAGE_MEMSIZE=1024 in /etc/make.conf, ho

```
x11-libs/wxGTK             10
```

in /etc/portage/package.mem ed ottengo

```
~ # DEBUG=1 emerge wxGTK

Calculating dependencies ...done!

>>> emerge (1 of 1) x11-libs/wxGTK-2.6.1-r1 to /

:: evaluating memory size of: "1024"

:: new size of memory disk is:

:> make.conf mem:"1024"

:: evaluating memory size of: 10

::  evaluating new size(no unit):10

:: new size of memory disk is:10

::- package.mem match -> mem:10

::-                      pkg: x11-libs/wxGTK

:: evaluating memory size of: 1024

:: evaluating new size(no unit):1024

:: new size of memory disk is:1024

1024

 * Using manually ovverridden shell global tmpfs size: [ 1024 mbytes ]

 * Mounting /var/tmp/portage.

Exiting due to signal
```

Ovviamente la variabile ambiente PORTAGE_MEMSIZE non è settata quando lancio emerge. Per completezza

```
pcfabio ~ # emerge info

Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.13-gentoo-r5 i686)

=================================================================

System uname: 2.6.13-gentoo-r5 i686 AMD Athlon(tm) Processor

Gentoo Base System version 1.6.14

dev-lang/python:     2.3.5-r2, 2.4.2

sys-apps/sandbox:    1.2.12

sys-devel/autoconf:  2.13, 2.59-r6

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1

sys-devel/binutils:  2.16.1

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -pipe"

CHOST="i686-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/lib/openoffice/share/dict/ooo /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"

CXXFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -pipe"

DISTDIR="/mnt/lfs/distfiles/"

FEATURES="autoconfig distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/ http://ftp.students.cs.unibo.it/gentoo/"

LANG="it_IT.UTF-8"

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="x86 3dnow 3dnowext X aac acl alsa apache2 arts asf audiofile avi bash-completion berkdb bitmap-fonts blas boehm-gc bonobo browserplugin bzip2 cairo cddb cdparanoia cdr chroot cmucl crypt cups curl directfb dv dvb eds emboss encode ethereal examples exif expat fam fame fbcon ffmpeg fftw firefox flac foomaticdb fortran fpx gcj gd gdbm gif gimpprint glut gmp gnutls gphoto2 gpm graphviz gtk gtk2 gtkhtml guile idn imagemagick imlib innodb java jbig jpeg jpeg2k kde kdeenablefinal lcms libg++ libwww live lm_sensors logitech-mouse lzo mad mhash mikmod mime mjpeg mmx mmxext mng motif mozdevelop mozsvg mozxmlterm mp3 mpeg mysql ncurses network nls nntp nptl odbc ogg oggvorbis opengl oss pam pcre pdflib perl php plotutils png postgres ppds python qt quicktime readline real recode samba sdk sdl skey smime speex spell sql ssl stats subversion svg tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1 type1-fonts udev unicode usb utf8 vim-with-x vorbis wifi win32codecs wmf wxgtk1 wxwindows xanim xine xml xml2 xmms xv xvid yv12 zlib video_cards_radeon userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS
```

Come ti ho scritto in precedenza il problema è nel check sequenziale della variabile PORTAGE_MEMSIZE (funzione evaluate_mem_size()).

Con questo esempio si capisce l'utilità di interpretare il valore 0 in /etc/portage/package.mem (ovvero per disabilitare la funzionalità di compilazione in tmpfs)  :Wink: 

----------

## FonderiaDigitale

ok.

il problema e' essenzialmente che portage, nei confronti della shell, e' stateless: ovvero nei singoli passi 

ricarica completamente l'ambiente (clean,unpack,merge ecc) e non tiene traccia dei passi precedenti.

Appena ho due minuti fixo.

----------

## ^Stefano^

ieri ho provato anche io ad usare questo tool ed effettivamente su kdelibs è stato formidabile. però quando ho finito di usarlo, riavviando il pc, ho scoperto che /var/tmp aveva tutti i permessi cannati che ho dovuto reimpostare con chmod 1777 /var/tmp /tmp e anche l'utente:gruppo era sbagliato. al posto di root:root mi sono trovato portage:portage.

è possibile che questo casino sia stato fatto da questo tool? lo chiedo perchè quando ho dato l'emerge mi sono allontanato dal pc e quando sono tornato ho soltanto riavviato. non effettuato altre operazioni.

ho già controllato /var/log/emerge.log ma non mi dice nulla.

voi cosa ne pensate?

----------

## FonderiaDigitale

si e' possibile.  :Smile: 

mio errore ingenuo.

domani pubblico la fix (adesso ho mezzo neurone attivo)

----------

## maurs

Hai poi provveduto al fix? 

Inoltre, il tuo script ha interazioni con ccache e/o genlop? Sembra che questi due programmi non funzionino correttamente (ma potrebbe essere un mio problema indipendente dallo script).

Non ho avuto modo ancora di analizzare il problema a fondo. 

Porgo l'occasione per farti i miei complimenti per il lavoro fin qui svolto  :Wink: 

----------

## FonderiaDigitale

guarda chi si vede  :Smile: 

genlop non legge dalla tmpdir di portage, mentre ccache non dovrebbe aver problemi.

e' stata una settimana molto pesante, solo ora posso aggiornare il pacchetto con le fix di cui sopra.

----------

## Ferdinando

Fonderia, sembra che portage-bashrc abbia seri problemi con portage-2.1_pre6: guarda qui.

Se non vuoi supportare il portage instabile ti capisco, per ora disinstallo portage-bashrc.

EDIT: come non detto, hanno modificato portage invece  :Very Happy: 

EDIT: mi correggo di nuovo, un problemino c'è ancora: alla fine del bashrc c'è un exit che provoca un'uscita imprevista quando, dopo la fase di merge e appena prima del qmerge, il bashrc viene importato da /usr/lib/portage/bin/misc-functions.sh. Per ovviare al problema basta toglierlo:

```
--- /etc/portage/bashrc.old     2006-03-26 12:01:42.456103000 +0200

+++ /etc/portage/bashrc 2006-03-26 12:03:16.443880750 +0200

@@ -203,6 +203,4 @@

                postinst) echo 1 > $RANDLOCK;;

                clean) startup;;

        esac

-else

-       exit

 fi
```

Ciao

----------

## syntaxerrormmm

Io vorrei ringraziare Ferdinando, grazie al quale abbiamo fixato il bug del portage e disponiamo (finalmente...) di una versione compatibile di portage-bashrc con portage-2.1-pre6*

Ovviamente ringrazio anche FonderiaDigitale: utilizzo questo {tool,hack} da un'infinità di tempo e questo era il primo problema 'serio' che ho incontrato.

Ciao a tutti e ancora grazie.

----------

## Ciccio Bueo

 *Ferdinando wrote:*   

> [cut]......../usr/lib/portage/bin/misc-functions.sh. Per ovviare al problema basta toglierlo:
> 
> ```
> --- /etc/portage/bashrc.old     2006-03-26 12:01:42.456103000 +0200
> 
> ...

 

scusami... non ho capito bene quale file / come /  correggere il problema....  (...niubba ingenuità)   :Wink: 

grazie!

----------

## Ferdinando

 *Ciccio Bueo wrote:*   

> non ho capito bene quale file / come /  correggere il problema....

 

Sì, scusami: devi aprire in un editor /etc/portage/bashrc e cancellare/commentare il ramo else dell'if in fondo al file (praticamente le due righe sopra il fi). Oppure potresti mettere quell'output di diff sopra in un file e chiamarlo con "patch -p0 < ${nomepatch}".

Ciao

----------

## Ciccio Bueo

 *Ferdinando wrote:*   

>  *Ciccio Bueo wrote:*   non ho capito bene quale file / come /  correggere il problema.... 
> 
> Sì, scusami: devi aprire in un editor /etc/portage/bashrc e cancellare/commentare il ramo else dell'if in fondo al file (praticamente le due righe sopra il fi). Oppure potresti mettere quell'output di diff sopra in un file e chiamarlo con "patch -p0 ${nomepatch}".
> 
> Ciao

 

perfetto, grazie!   :Wink: 

----------

## matrix

Salve,

ci sono due buone FEATURES da utilizzare usando lo script di fonderia, ovvero "keeptemp"  "keepwork".

Se si riesce ad implementarle in modo corretto riuscirete a velocizzare di un pò emerge!

Non è utile fare il clean della workdir del pacchetto se tutto ciò sta in ram e ad ogni cambio pacchetto viene smontata e rimontata  :Smile: 

A voi i test...

 :Wink: 

----------

## makami

Se in package.mem scivo una riga simile a questa:

```
app-office/openoffice    0
```

che succede se emergo openoffice ? viene compilato normalmente nel disco ?

in pratica.. volendo lasciare attivo il montaggio in ram in make.conf, per compilare un pacchetto su disco, come ad esempio openoffice, devo scrivere una riga del genere in package.mem o devo per forza fare una cosa tipo 

```
PORTAGE_MEMSIZE="" emerge openoffice
```

  ??

----------

## Deus Ex

Grazie Ferdinando!

in effetti, quando mi diceva 

```

!!! install_qa_check failed; exiting. 
```

non sapevo che pesci prendere!

Ora va tutto ok!

----------

## Ferdinando

Ciao a tutti.

Per un po' di tempo sono passato ad un /var/tmp/portage staticamente montato in tmpfs ma, a causa del nuovo gcc (4.1) e dello spazio che richiede per compilare, sono tornato al bashrc per ottenere la flessibilità necessaria; tuttavia, per lo stesso motivo per cui lo avevo abbandonato, non ero soddisfatto, così stamattina gli ho apportato delle sostanziali modifiche.

Questa versione modificata, che per ora chiamerò portage-bashrc-ng, ha un suo thread qui.

Grazie per l'attenzione  :Smile: 

Ciao

----------

## fbcyborg

Salve!

Già da tempo utilizzo questo sistema per compilare in TMPFS in tutti i processi di emerge.

Utilizzo questo tip-howto da prima dell'aggiornamento del primo post ad una sue delle ultime versioni definitive.

Premesso che tutto sembra funzionare a regola d'arte, e così sono portato a credere vorrei far presente un quesito.

Quando emergo qualcosa, vedo sempre 

"mounting ... 1400 MB in tmpfs" o qualcosa del genere, e quando finisco "unmounting /var/tmp/portage".

Inoltre facendo un df -h mentre emergo qualcosa vedo che è montato tmpfs.

Suppongo che tutto sia regolare.

Tempo fa mi sembra di aver cancellato il contenuto di /usr/local/portage, contenente, credo, gli ebuild di portage-bashrc.

Se però oggi do un emerge -s portage-bashrc, anche dopo aver riscaricato gli ebuild in quella locazione, 

ottengo che lo stato del pacchetto è "not installed". 

Visto che in teoria senza portage-bashrc la compilazione in ram non dovrebbe funzionare, come faccio a sapere se questo

pacchetto è realmente installato e funzionante? Fino ad ora non mi sono preoccupato visti anche i messaggi che leggo quando

emergo qualcosa e che ho anche riportato nel post.

Tra l'altro ho usato questo howto anche di recente su un pc in cui ho installato gentoo da poco ed ho visto che i messaggi di 

mounting 1400 mb ram e unmounting /var/tmp/portage, sono leggermente diversi da quelli che leggo sulla mia gentoo.

Forse mi sto preoccupando più del dovuto.. ma, non si sa mai!  :Very Happy:  voglio essere sicuro di avere le cose a posto.

grazie!   :Wink: 

----------

## Ferdinando

 *fbcyborg wrote:*   

> Se però oggi do un emerge -s portage-bashrc, anche dopo aver riscaricato gli ebuild in quella locazione, 
> 
> ottengo che lo stato del pacchetto è "not installed". 

 

Le informazioni di installazione sono in /var/db/pkg/, quindi oltre a rimuovere l'ebuild probabilmente lo avevi anche disinstallato; in realtà il portage-bashrc di Fonderia si può disinstallare solo manualmente, perché emerge --unmerge non elimina in files il /etc. Perciò, anche con l'ebuild disinstallato è ancora lì in /etc/portage/bashrc: è quello che devi vedere per sapere se è presente.

Ciao

----------

## fbcyborg

OK! grazie!

allora è tutto a posto il file è presente... dici che dovrei aggiornarlo?

se si, è sufficiente aggiornare quel file o devo riscaricare l'ebuild e fare tutta la procedura?

----------

## fejfbo

Ma è successo qualcosa? Non riesco più ad installarlo...

```
>>> Downloading 'http://www.fonderiadigitale.it/gentoo/repo/portage-bashrc/porta                                                                                                   ge-bashrc-0.5.tar.bz2'

--14:16:03--  http://www.fonderiadigitale.it/gentoo/repo/portage-bashrc/portage-                                                                                                   bashrc-0.5.tar.bz2

           => `/usr/portage/distfiles/portage-bashrc-0.5.tar.bz2'

Resolving www.fonderiadigitale.it... 213.92.118.13

Connecting to www.fonderiadigitale.it|213.92.118.13|:80... connected.

HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable

    The file is already fully retrieved; nothing to do.

!!! Couldn't download 'portage-bashrc-0.5.tar.bz2'. Aborting.

```

----------

## fbcyborg

prova a scaricarlo a mano e a mettere nel tuo PORTDIR_OVERLAY tutte le directory e i files nel giusto ordine.

PS: ti consiglio di utilizzare tmpfs manuale dando questo comando quando emergi:

```
mount -t tmpfs tmpfs -o size=1400M,mode=770 /var/temp/portage
```

poi lo smonti a mano. 1400M è la dimensione della ram da usare.. vedi tu qual'è il valore più adatto a seconda di quanta ram hai..

Sembra che portage-bashrc, essendo ancora sperimentale, non funzioni benissimo, a volte mi rimane montata tmpfs o addirittura viene smontata durante gli emerge.

Anche io attendo che questo processo automatizzato si perfezioni, che è una grande idea. Lo usavo con le vecchie versioni di portage.

----------

## fejfbo

Ho solo un dubbio, il file portage-bashrc-0.5.tar.bz2 dove lo metto?

----------

## fbcyborg

Scarica la directory app-portage e tutto il suo contenuto rispettando la struttura della dir che è nel sito nella tua dir /usr/local/portage/ . 

Successivamente controlla che nel tuo make.conf ci sia 

```
PORTDIR_OVERLAY="/usr/local/portage"
```

dopo di che dai un 

```
emerge portage-bashrc
```

In ogni caso segui questa guida come indicato nel primo post.

----------

## fejfbo

questo l'ho fatto ma tenta sempre di scaricare il file "portage-bashrc-0.5.tar.bz2", fallendo purtroppo

----------

## fbcyborg

 *fejfbo wrote:*   

> questo l'ho fatto ma tenta sempre di scaricare il file "portage-bashrc-0.5.tar.bz2", fallendo purtroppo

 

quindi questo succede anche se tu quel file già ce l'hai in quella cartella app-portage???

prova a dare un emerge --sync dopo che hai scaricato la dir app-portage e tutto il suo contenuto e a ridare l'emerge.. altrimenti prova con l'applicativo ebuild

----------

## fejfbo

Sì, continua a tentare inutilmente di scaricarlo.

Cosa vuol dire "prova con l'applicativo ebuild"?

La cosa stranissima è che se provo a scaricare la versione 0.4, funziona senza problemi    :Confused: 

Con la 0.5 penso che l'errore sia dovuto a questo "416 Requested Range Not Satisfiable" ma non saprei il perchè

----------

## fbcyborg

prova a fare:

```
# ebuild /usr/local/portage/app-portage/portage-bashrc/portage-bashrc-0.5.ebuild digest

# ebuild /usr/local/portage/app-portage/portage-bashrc/portage-bashrc-0.5.ebuild unpack    

# ebuild /usr/local/portage/app-portage/portage-bashrc/portage-bashrc-0.5.ebuild compile    

# ebuild /usr/local/portage/app-portage/portage-bashrc/portage-bashrc-0.5.ebuild install

# ebuild /usr/local/portage/app-portage/portage-bashrc/portage-bashrc-0.5.ebuild qmerge

# ebuild /usr/local/portage/app-portage/portage-bashrc/portage-bashrc-0.5.ebuild clean
```

----------

## fejfbo

Scusami, ma avevo già provato.

Al primo comando tenta di scaricare con il solito errore   :Crying or Very sad: 

----------

## fbcyborg

posizionati in /usr/portage/distfiles e dai un

```
wget http://www.fonderiadigitale.it/gentoo/portage-bashrc-0.5.tar.bz2
```

poi ridai un 

```
emerge portage-bashrc
```

----------

## fejfbo

Niente da fare, stesso errore   :Crying or Very sad: 

----------

## Luca89

@fejfbo

Ti consiglio di passare a portage-bashrc-ng perchÃ© Ã¨ piÃ¹ mantenuto, questo di fonderia credo che sia stato abbandonato. Per installare la versione ng basta che usi l'overlay dei gechi. Qua c'Ã¨ scritto come inserire l'overlay (usa quello gechi-testing), poi basta che fai "emerge portage-bashrc-ng".

----------

## fbcyborg

Guarda, non saprei quale possa essere questa stregoneria che non te lo fa funzionare.... comunque, con calma riseguiti l'howto passo passo e se non ci riesci intanto emergi con il montaggio manuale di /var/tmp/portage in tmpfs.. tra l'altro te lo consiglio, almeno fino a che portage-bashrc non sarà testato e stabile.

EDIT: Ah! è vero!!!! scusa ma ero convinto di trovarmi in questo thread e che tu avessi il problema con l'ultimo portage-bashrc, che invece è l'ng. Quello di fonderia non funziona con i portage 2.1.x.

----------

## fejfbo

 *Luca89 wrote:*   

> @fejfbo
> 
> Ti consiglio di passare a portage-bashrc-ng perchÃ© Ã¨ piÃ¹ mantenuto, questo di fonderia credo che sia stato abbandonato. Per installare la versione ng basta che usi l'overlay dei gechi. Qua c'Ã¨ scritto come inserire l'overlay (usa quello gechi-testing), poi basta che fai "emerge portage-bashrc-ng".

 

grazie mille, proverò questo.

Solo una cosa: avevo provato ad emergere il pacchetto di Fonderia (versione 0.4) ma come la tolgo ora? Con emerge -C non mi funziona   :Embarassed: 

----------

## fbcyborg

prova a fare 

```
ebuild /usr/local/portage/app-portage/portage-bashrc/portage-bashrc-0.4.ebuild unmerge
```

----------

## Ferdinando

 *fbcyborg wrote:*   

> prova a fare 
> 
> ```
> ebuild /usr/local/portage/app-portage/portage-bashrc/portage-bashrc-0.4.ebuild unmerge
> ```
> ...

 Purtroppo il bashrc è config-protected, e un semplice unmerge non basta: l'unico modo è

```
rm /etc/portage/bashrc
```

Oppure, se hai intenzione di passare all'ng, basta fare etc-update dopo averlo emerso e accettare le modifiche a quel file.

Ciao

----------

