# Experiment: emerge --sync  beschleunigen mit unionfs

## slick

Das ist ein Entwurf um das emerge --sync / Updaten des Portage-Cache zu beschleunigen, bei mir war es spürbar schneller, das Konzept ist aber noch fertig ausgereift, aber ich wollte es euch nicht vorenthalten, vielleicht möchte das ja jemand mit weiterentwickeln bzw. genauer austesten.  :Wink:  Es richtet an Leute die wissen was sie tun, daher auch erstmal ohne weitere Kommentare:

```
mv /usr/portage /usr/portage_org

mkdir /usr/portage

mv /var/cache/edb/dep /var/cache/edb/dep_org

mkdir /var/cache/edb/dep

mkdir /cache

mount -t tmpfs tmpfs -o size=800M,nr_inodes=1M /cache

mkdir /cache/portage

mkdir /cache/dep

mount -t unionfs -o dirs=/cache/portage:/usr/portage_org unionfs /usr/portage

unionctl /usr/portage --mode /usr/portage_org ro

mount -t unionfs -o dirs=/cache/dep:/var/cache/edb/dep_org unionfs /var/cache/edb/dep

unionctl /var/cache/edb/dep --mode /var/cache/edb/dep_org ro

emerge --sync
```

Wäre dann noch zu klären wie man die Änderungen zu einem späteren Zeitpunkt (z.B. beim Runterfahren) auf die Platte "zurückschreibt" und ggf. /usr/portage/distfiles nochmal "drüber" mountet, damit die distfiles nicht im RAM landen.

----------

## tost

https://forums.gentoo.org/viewtopic-t-465367-highlight-portage+squash.html

Dies und die "original-Methode" beschleunigen das --sync auch enorm, allerdings braucht das erstellen eine Weile und daher nutze ich es auch nicht mehr...

Kann man ja noch evtl. noch hierzu ergänzen und irgendwann in die deutsche Doku / Wiki schieben !

tost

----------

## slick

 *tost wrote:*   

> https://forums.gentoo.org/viewtopic-t-465367-highlight-portage+squash.html
> 
> Dies und die "original-Methode" ...

 

Da war ja wieder einer schneller   :Mad:   :Wink: 

----------

## think4urs11

 *slick wrote:*   

>  *tost wrote:*   https://forums.gentoo.org/viewtopic-t-465367-highlight-portage+squash.html
> 
> Dies und die "original-Methode" ... 
> 
> Da war ja wieder einer schneller   

 

*grübel* ist das dann jetzt ein [DUP]?   :Rolling Eyes: 

----------

## slick

 *Think4UrS11 wrote:*   

> *grübel* ist das dann jetzt ein [DUP]?  

 

Nö, weil dazu müßte|sollte der andere in Deutsch sein.  :Razz:  (allerdings siehe auch Forenregel Nr. 12) 

Gut, ich räume einen Verstoß meinerseits gegen Forenregel Nr. 4 ein. Allerdings, war Dein Post nicht ein Verstoß gegen Forenregel Nr. 7 bzw. Nr. 10?  :Twisted Evil: 

----------

## c_m

 *slick wrote:*   

> Wäre dann noch zu klären wie man die Änderungen zu einem späteren Zeitpunkt (z.B. beim Runterfahren) auf die Platte "zurückschreibt" und ggf. /usr/portage/distfiles nochmal "drüber" mountet, damit die distfiles nicht im RAM landen.

 

... und was passiert wenns nen Stromausfall gibt.

AFAIS muss das aktuallisierte /usr/portage dann erstmal in nen tmp Ordner geschoben werden um nach dem Abbau des UnionFS nach /usr/portage kopiert werden zu können.

Was mir grad in den Sinn kam:

das unionfs in einen Temporären ordner bauen und emerge umlenken a la

PORTDIR="/tmp/portage" emerge --sync && cp /tmp/portage -r /usr/portage

----------

## slick

 *c_m wrote:*   

> ... und was passiert wenns nen Stromausfall gibt.

 

Naja, 1) hat man dieses Problem immer, von daher wäre wahrscheinlich keine Lösung zufriedenstellend, also aufgrund der Wahrscheinlichkeit ignorieren (und wenn dann hat man vermutlich andere Probelme als ein defektes /usr/portage) und 2) hat man immernoch den Stand vom vorherigen sync (wenn dieses schon zurückgeschrieben wurde)

 *c_m wrote:*   

> AFAIS muss das aktuallisierte /usr/portage dann erstmal in nen tmp Ordner geschoben werden um nach dem Abbau des UnionFS nach /usr/portage kopiert werden zu können.
> 
> Was mir grad in den Sinn kam:
> 
> das unionfs in einen Temporären ordner bauen und emerge umlenken a la
> ...

 

Wenn ich so darüber nachdenke ists doch relativ kompliziert, denn mit einem einfachen cp aus dem unionfs auf /das orginale usr/portage ists ja nicht getan. Das würde ja nur neue Dateien hinzufügen, aber keine alten löschen, d.h. man müßte im Prinzip einen rsync von unionfs > /usr/portage machen. D.h. man hat zwar das emerge sync schnell fertig, braucht aber einen cronjob der das z.B. die Nacht wieder lokal syncronisiert. Wäre aber durchaus eine denkbare Alternative.

Eine Idee die ich noch hatte war das "cache-verzeichnis" einfach in ein tar zu schreiben und beim nächsten boot wieder (ins unionfs) zu laden, das würde aber bedeuten auf lange Sicht hab ich damit das komplette port-dir im RAM liegen. d.h. auch hier müßte eine Aufräumroutine her. Aber mit einer entsprechend großen swap würde das ggf. sogar Sinn machen, weil ja die Speicherverwaltung die Dateien eh in die Swap auslagert wenn der RAM knapp wird. Ist nur die Frage obs dann noch viel Geschwindigkeitvorteile bringt.

Also ich denke aufgrund der "Aufräumaktionen" um die man nicht rumzukommen scheint wäre es nur eine Alternative für Rechner die überwiegend durchlaufen und wo z.B. die Nacht ein cron laufen kann.

----------

## c_m

Also zum stromausfall: Es war igendlich nur so gemeint, dass das Schreiben auf die Platte möglichst Zeitnahe zum Sync sein sollte. Wenn Teile des Syncs im Ram liegen wären die nach nem Stromausfall weg. Aber egal, darum gehts ja nun nicht primär.

Ich hatte UnionFS bis jetzt so verstanden, dass mir das UnionFS eine kombination  aus beiden Ordnern präsentiert, auch wenn es nur änderungen speichert.

Bsp:

UnionFS in /union wo eine CD mit eingebunden ist. lösche ich nun was und/oder füge etwas hinzu wird dies bei z.B. ls -l entsprechend angezeigt. Ein cp (so dachte ich) würde dementsprechend alles zusammenführen (gelöschte dateien weglassen, neue hinzufügen) und so ans Ziel kopieren.

Klärt mich mal auf  :Smile: 

----------

## slick

 *c_m wrote:*   

> Klärt mich mal auf 

 

Also ich versuchs mal... bei unionfs kannst Du mehrere Verzeichnisse zu einem Verzeichnis zusammenfügen. d.h.

```
mkdir -p /teil1/foo

mkdir -p /teil2/bar

mkdir /gesamt

mount -t unionfs -o dirs=/teil1:/teil2 unionfs /gesamt
```

In /gesamt wird bei einem ls alles das angezeigt was sich in /teil1 und /teil2 gefindet. d.h. es existiert dann /gesamt/foo und /gesamt/bar

So, nun stell Dir vor /teil2 ist readonly ins unionfs gemountet. Das heißt beim schreiben auf /gesamt/bar kannst Du eigentlich nichts schreiben. Hier setzt dann unionfs an und schreibt das ganze in den beschreibbaren /teil1. Wenn Du etwas aus /gesamt/bar löscht wird in /teil1 eine "Löschdatei" angelegt, die unionfs sagt das diese Datei gelöscht wurde, folglich siehst Du die nicht mehr wenn Du in /gesamt/bar ein ls machst, siehst sie aber noch wenn du in /teil2 schaust (weil das ist ja unverändert)

Der Gedanke von oben dazu ist nun folgender: Du bindest /usr/portage readonly ein und eine beschriebbare Ramdisk. D.h. alle Schreibaktionen finden dann nicht in /usr/portage statt sondern auf der schnellen Ramdisk. Die Änderungen existieren dann aber nur "innerhalb" von unionfs, d.h. willst Du das reale /usr/portage updaten mußt Du das über unionfs gemountete /usr/portage "zurückspielen". Kopierst Du nur, werden zwar neuen Dateien überspielt, aber das kopieren kann nicht in unionfs gelöschte Dateien im realen /usr/portage löschen. d.h. Du müßtest dazu rsync nehmen. (Es sei denn Du löscht dein reales /usr/portage vorher, aber dann ists ja auch in unionfs weg, weil ja dort rein gemountet ist) 

Ok, klingt ziemlich kompliziert... aber einfacher ists mir nicht eingefallen.

EDIT: wenn ichs mir so überlege brauchst Du 2x den Portage-Tree, einmal der der readonly ins unionfs gemountet ist und einmal der welcher dann aus dem unionfs "exportiert" wird. Den ersten mußt man dann nach dem umounten von unionsfs durch das zweite ersetzen.

----------

## c_m

Also hab ichs doch nicht falsch verstanden  :Smile:  (btw: vielen Dank nochmal für die Erklärung, Slick)

Ich versuche mal dein Script so abzuändern wie ich mir das ganze dachte, vllt. wirds dann eindeutiger.

```
mv /usr/portage /usr/portage_org

mkdir /usr/portage

mv /var/cache/edb/dep /var/cache/edb/dep_org

mkdir /var/cache/edb/dep

mkdir /cache

mount -t tmpfs tmpfs -o size=800M,nr_inodes=1M /cache

mkdir /cache/portage

mkdir /cache/dep

mkdir /tmp/portage

mkdir /tmp/dep

mount -t unionfs -o dirs=/cache/portage:/usr/portage_org unionfs /tmp/portage

unionctl /tmp/portage --mode /usr/portage_org ro

mount -t unionfs -o dirs=/cache/dep:/var/cache/edb/dep_org unionfs /var/cache/edb/dep        # Hier hab ich noch nicht wirklich 

unionctl /var/cache/edb/dep --mode /var/cache/edb/dep_org ro                    # einen Ansatz wie man es nach /tmp/dep umleiten könnte

PORTDIR="/tmp/portage" emerge --sync

cp -r /tmp/portage /usr/portage

cp -r /tmp/dep /var/cache/edb/dep
```

Ich hab keine Ahnung ob sich das in die Richtung realisieren lässt (noch nicht genug ahnung von der Materie^^).

Die Idee ist jedenfalls das Syncen in nem anderen Ordner als dem original Portage dir stattfinden zu lassen. Da durch deinen weg der original ordner quasi geleert wurde, würde nachher ein einfaches rüberkopieren genügen.

Jetzt bleibt die Frage, ob sich /var/cache/edb/dep auch irgendwie umleiten lässt.

----------

## slick

Was mich daran stört ist das man die Variable beim emerge --sync setzen muss, bzw. nicht vergessen darf. Mir kam zu dem Kontrukt gerade eine andere Idee. Ich habs mal aufgemalt, muss ich allerdings erläutern sonst wirds nicht klar:

http://img46.imageshack.us/img46/875/portageunionfslv3.jpg

linke Bildhälfte: 

Ich mounte mit unionfs /usr/portage_org (ro) und die ramdisk /ramdisk/portage (rw) zum /ramdisk/portage_level2

nun mounte ich wiederum /ramdisk/portage_level (rw) (als einzige Verzeichnis) über unionfs nach /usr/portage

d.h. bei einem emerge --sync wandern die Daten zwar zweimal durch unionfs aber landen letztlich auf der Ramdisk.

Nun kann die Nacht ein Aufräum-cronjob laufen der folgendes macht, jetzt rechte Bildhälfte

er tauscht im unionfs-mount /usr/portage das /ramdisk/portage_level2 mit unionctl gegen /usr/portage_org aus.

dann wird mittels rsync der inhalt von /ramdisk/portage_level2 nach /usr/portage_org kopiert

danach wird /ramdisk/portage_level2 aufgelöst, die ramdisk geleert, anschliessend /ramdisk/portage_level2 neu aufgebaut und wieder statt /usr/portage_org eingehangen

analog das ganze in /var/...

Hat den Vorteil der emerge --sync läuft über die Ramdisk, und die Nacht wird aufgeräumt... 

Nachteil: Während der Zeit des Umkopierens von von /ramdisk/portage_level2 nach /usr/portage_org ist kurzzeitig der alte Portagetree drin. Und wer den Rechner eh die Nacht laufen läßt kann auch gleich den sync per cron machen und sich das alles sparen.

Ist aber vielleicht ein Gedankenansatz den man ausbauen könnte... und es wäre zu ermitteln ob 2x unionfs noch Geschwindigkeitsvorteile bringt.

EDIT: ok, grober Unfug, man braucht keine 2x unionfs hintereinander, einmal mounten von /ramdisk/portage_level2  nach /usr/portage und einmal mounten mit -o bind von /usr/portage_org nach /usr/portage reicht auch. Hauptsache man tauscht die zum "Aufräumen" aus.

----------

## Finswimmer

Bevor du dir den Stress machst, teste doch mal, wieviel schneller das ist...

Wenns 10 Sekunden ist, juckt es doch keinen...

Tobi

----------

## py-ro

Hmm wie verhält sich ein raid aus ramdisk und bspw. einer Image Datei mit dem Portage?

Py

----------

## c_m

Also bei mir lief der Serversync nachts per cron ^^#

Interessant wäre es für mein NB.

Klingt aber mitlerweile ein wenig wie kanonenkugeln auf spatzen :-/

----------

## stahlsau

hi,

wie ich schon im normalen Forum geschrieben habe (siehe hier):

Wozu soll das gut sein? Wer sitzt denn schon blöd vor dem Monitor und wartet drauf dass das syncen fertig wird? Ich meine, linux ist ja bekanntlich multitasking-fähig, warum sitzt dann der user da und wartet auf einen prozess?  :Wink: 

Man soll ja eh nur einmal am Tag syncen, maximal...

Erleuchtet mich  :Wink: 

----------

## Freiburg

Das Hauptproblem ist doch das du irgendwann den/die Layer(n) die unionfs angelegt hat zusammenführen willst so das der Portage wieder auf einem aktuellen Stand ist. Die Frage ist doch lohnt es sich sagen wir 2 Sync's in einen oder zwei neue Layer zu schreiben und diese(n) dann mit dem Portageverzeichniss zusammen zu führen. Das ganze würde sich wenn nur auf Server lohnen die mehr als einen Tag laufen (ich nehme einfach mal an das alle ihren Rechner abends ausmachen). Was nicht schlecht wäre ein dm modul das komprimiert (oder gibt es das schon und ich war bislang zu blind??) dann könnte man komplett in eine Ramdisk schreiben mit einem komprimierten Dateisystem und nach beendigung des emerge die ganze Ramdisk auf die Festplatte schreiben.

----------

## slick

Leute... deswegen steht ja im Titel Experiment... bevor ich allein daheim sitze und mir was allein ausgrübel dachte ich ich post es einfach, vielleicht findet ja jemand die Idee interessant. Außerdem sehen 4 Augen mehr als zwei  :Wink: 

Warum? Tja, weils geht!  :Wink:  Nein, mal ernsthaft, mir gehts immer so, ich habe zwar eine lokalen sync-mirror, aber nicht alle Rechner synchen gleichmäßig, da auch mal die Nacht aus usw. Da sitze ich an Rechner A und denke "AHA, neues Paket... das wäre auch was für Rechner B". Ich logge mich auf Rechner B ein und wills updaten, und siehe da Portage noch nicht up-to-date. Also emerge sync (zum lokalen Mirror) absetzen. Da die meisten Rechner nicht so frisch sind dauerts doch was länger... klar ich kann derweil auf A irgendwas machen, oder Kaffeetrinken oder aufs Klo gehen, aber wäre halt schön wenns scheller ginge. Und wenn man halt daheim nicht viel zu tun hat kommt man halt auf solche Ideen  :Wink: 

By the way, das mit dem Raid... witzige Idee... so witzig das ich das unbedingt mal ausprobieren muß...  :Wink: 

EDIT: @Freiburg, es geht halt darum die Wartezeit auf das Fertigwerden von emerge --sync "nach hinten" zu verschieben. Was der Rechner dann den halben oder ganzen Tag (nach dem emerge --sync) macht wenn ich ihn nicht brauche ist erstmal zweitrangig. Wichtig ist mir das es genau dann schnell geht wenn ichs brauche.

----------

## Freiburg

@slick sollte auch keine kritik sein, ich wollte nur dalegen wo meiner Meinung nach die Probleme liegen, das es mir als einen Ansatz gibt für mehr als ein Problem  mit mehr als eine Lösung ist klar.

----------

## slick

Habe ich auch nicht als Kritik verstanden... auf dem Nachhauseweg ist mir noch was wichtiges eingefallen was ich unbedingt im Zusammenhang, zur Motivation meinerseits über sowas nachzudenken, sagen wollte. Ob es letztendlich sehr viel bringt oder nur sehr wenig, der Lerneffekt bei sowas ist nicht zu unterschätzen. Vor ~3 Tagen kannte ich unionfs nur vom Namen, inzwischen habe ich einiges dazugelernt. Deswegen denke ich manchmal nicht unbedingt über den tieferen Sinn nach, sondern freue mich darauf wieder was Neues "erforschen" zu können.

----------

## slick

 *Finswimmer wrote:*   

> Bevor du dir den Stress machst, teste doch mal, wieviel schneller das ist... 

 

```
# Messung mit unionfs

mkdir /cache

mount -t tmpfs tmpfs -o size=800M,nr_inodes=1M /cache

mkdir /cache/dep

cd /var/cache/edb

cp -a dep dep_half # kopiere dep zu testzwecken

rm -rf dep_half/usr/portage/{app-*,dev-*} # zu testzwecken einige aus dem Cache löschen

mount -t unionfs -o dirs=/cache/dep:/var/cache/edb/dep_half unionfs /var/cache/edb/dep

unionctl /var/cache/edb/dep --mode /var/cache/edb/dep_half ro

time emerge --metadata

   real    5m7.617s

   user    0m21.289s

   sys     0m7.843s

umount /var/cache/edb/dep

rm -rf /var/cache/edb/dep_half

umount /cache

rmdir /cache

# Messung jetzt ohne unionfs

cd /var/cache/edb

rm -rf dep/usr/portage/{app-*,dev-*} # zu testzwecken einige aus dem Cache löschen

time emerge --metadata

   real    3m51.762s

   user    0m27.689s

   sys     0m8.942s
```

Ok, ist zwar nicht ganz 100% genau gemessen (da nur /var/... über unionfs), aber es scheint eindeutig das es eher bremst statt beschleunigt. Schade, wo es doch beim ersten Test spürbar schneller ging... naja, menschliche Zeiteinschätzungen. Kann das Ergebnis jemand bestätigen? 

Schade...   :Mad: 

----------

## stahlsau

mmh..das tut mir jetzt leid   :Crying or Very sad: 

Im Ernst, wenn's ein Testprojekt ist, ists ja gut. Ich hab halt am praktischen Sinn der Aktion gezweifelt (dachte es wäre ein weiterer Artikel im Sinne von "gentoo ricers"  :Wink: ).

----------

