Kleiner Vorschlag zur build-Beschleunigung

[rhabarber1848]

Nach dem Kompilieren eines Paketes wird das Löschen des Paket-Verzeichnisses im Hintergrund erledigt:

Code: Alles auswählen

--- cdk/acinclude.m4	2011-06-19 13:46:27.000000000 +0200
+++ cdk/acinclude.m4	2011-10-02 23:01:16.000000000 +0200
@@ -2,7 +2,7 @@
 AC_MSG_CHECKING([$1 rules])
 eval `${srcdir}/rules.pl make ${srcdir}/rules-make $1 cdkoutput`
 INSTALL_$1=`${srcdir}/rules.pl install ${srcdir}/rules-install $1`
-CLEANUP_$1="rm -rf $DIR_$1"
+CLEANUP_$1="rm -rf $DIR_$1 &"
 CLEANUP="$CLEANUP $DIR_$1"
 DEPSCLEANUP="$DEPSCLEANUP .deps/$1"
 AC_SUBST(DEPENDS_$1)dnl
@@ -21,7 +21,7 @@
 CONFIGURE_$1="../$DIR_$1/configure"
 PREPARE_$1="$PREPARE_$1 && ( rm -rf build_$1 || /bin/true ) && mkdir build_$1"
 INSTALL_$1=`${srcdir}/rules.pl install ${srcdir}/rules-install $1`
-CLEANUP_$1="rm -rf $DIR_$1 build_$1"
+CLEANUP_$1="rm -rf $DIR_$1 build_$1 &"
 CLEANUP="$CLEANUP $DIR_$1"
 DIR_$1="build_$1"
 AC_SUBST(CLEANUP_$1)dnl

[amiga23]

Funktioniert für mich. Habe 3 Images erfolgreich gebaut. Aber ich habe den Zeitunterschied nicht gemessen.

[rhabarber1848]

Aber ich habe den Zeitunterschied nicht gemessen.

Ich habe es mittlerweile geschafft, Zeitmessungen durchzuführen, bei yadd-neutrino kein Unterschied meßbar
Daher werde ich das Thema nicht mehr weiterverfolgen.

[seife]

Und die potenziellen Probleme (falls mal 2 Pakete hintereinander gebaut werden sollten, die dieselben Verzeichnisnamen im Tarball haben, kann es unschöne und schwer zu debuggende Effekte geben).

Des weiteren macht deine Storage einfach nicht mehr IOPS, egal ob du nun im Hintergrund löschst oder im Vordergrund ;-)
Oder anders ausgedrückt: das Auspacken des nächsten Tarballs geht zwar evtl. früher los, aber dauert halt entsprechend länger, wenn gleichzeitig noch gelöscht wird... genau das, was deine Zeitmessungen auch zeigen.

Die Lösung ist: einfach im tmpfs bauen. Benötigt halt "ein wenig" mehr RAM

[rhabarber1848]

Und die potenziellen Probleme (falls mal 2 Pakete hintereinander gebaut werden sollten, die dieselben Verzeichnisnamen im Tarball haben, kann es unschöne und schwer zu debuggende Effekte geben).

Das Entpacken eines Paketes wird immer mit

( rm -rf linux-2.4.37.11 || /bin/true ) && ( rm -rf linux || /bin/true ) && bunzip2 -cd [...]

eingeleitet, es sollte also keine Probleme geben.

[Barf]

Das "Launchen" von Prozessen innerhalb make wird besser von make (und seine -j option) gehandhabt. "Hinter dem Rücken" von make zu gehen wird irgendwann beissen. Besser wäre, möglichst viele Maketargets parallelisierbar (in Sinn von make -j) zu machen.

Und die potenziellen Probleme (falls mal 2 Pakete hintereinander gebaut werden sollten, die dieselben Verzeichnisnamen im Tarball haben, kann es unschöne und schwer zu debuggende Effekte geben).

Schliesse mich an. Nach zwei Jahren kommt jemanden auf die (eventuell bescheuerte) Idee, zwei Packages in "utilities" zu entpacken...

Die Lösung ist: einfach im tmpfs bauen. Benötigt halt "ein wenig" mehr RAM

Oder ein journalling file system; ist wahnsinnig schell beim Löschen von Verzeichnissbäumen.

[seife]

OT: ein journaling filesystem muss nicht schnell beim Löschen sein. Im Gegenteil, es muss noch mehr tun um sicherzustellen dass wirklich gelöscht ist als ein FS ohne Journal.

Beispiel: XFS. Extrem langsam. Und ext3 ist auch nicht wirklich schnell beim Löschen.

[Barf]

Das "Launchen" von Prozessen innerhalb make wird besser von make (und seine -j option) gehandhabt. "Hinter dem Rücken" von make zu gehen wird irgendwann beissen. Besser wäre, möglichst viele Maketargets parallelisierbar (in Sinn von make -j) zu machen.

Habe ein Bisschen nachgedacht. Das Starten von Hintergrundprozessen in Make ist wirklich nicht eine gute Idee. Seifes Argument ist gültig, aber zweitrangig. Wichtiger ist, dass Make ist der "Arbeitsleiter", der wann ein Aufgabe (Task/Target) gestartet wird steuert, und der Bescheid bekommt wann etwas fertig ist. Hintergrundprozessen ist in diesem Sinn das Make anzulügen, und fehler zu provozieren. Was passiert wenn ein Hintergrundprozess fehlschlägt, oder sich aufhängt?

Natürlich kann man behaupten, dass dies nicht in hinreichen einfachen Fällen Gültigheit hat.... ...

(Um Missverständnisse zu vermeiden: Sinn und Zweck mit diese Zeilen ist nicht rhabarber zu kritisieren, sondern meine Gedanken aufzuschreiben. Eines Tages schreibe ich vielleicht ein Buch über Make....)

OT: ein journaling filesystem muss nicht schnell beim Löschen sein. Im Gegenteil, es muss noch mehr tun um sicherzustellen dass wirklich gelöscht ist als ein FS ohne Journal.

In Mitte der 90-er Jahren habe ich Solaris 2.4 mit dem Solaris Disksuite installiert, und ich erinnere mich das dadrin enthaltene journalling filesystem es als (subjektiv) superschell beim Löschen. (Keine Messungen.) Dass die genannten Filesysteme schlecht/langsam sind ist durchaus möglich.

[seife]

Ganz OT:
Das hat mit schlecht nichts zu tun. reiserfs3 ist auch extrem schnell was das Löschen vieler Datenmengen angeht.

Dafür braucht man kein undelete: ein "reiserfsck --rebuild-tree" (IIRC) erweckt sachen zum Leben, die schon längst nicht mehr da sein sollten.

Es ist eine correctness-issue: Jedes Filesystem muss irgendwann sein "housekeeping" machen. XFS macht das, IIRC, beim Löschen der Dateien. => verringerung der Fragmentierung etc.
Ext3 nullt beim Löschen von dateien bestimmte Datenblöcke, damit sichergestellt ist, dass die bei einem journal replay nicht wieder als ungelöscht erscheinen. => beim löschen grosser / vieler Dateien müssen blöcke verteilt über die Platte geschrieben werden.

Reiser3 hat das alles nicht gemacht mit der Konsequenz, dass nach einem Crash das Dateisystem zwar *konsistent* war, aber der Inhalt unter umständen nicht das, was der User erwartet hätte.

Das sind alles keine schlechten Dateisysteme, sie haben nur unterschiedliche Designziele / Prioritäten. Insbesondere XFS würde ich - trotz dem relativ langsamen Löschvorgang - immer noch bevorzugt meine Daten anvertrauen, auch weil ich die Entwickler kenne und weiss was sie für eine Einstellung haben.

Disclaimer: Ich bin kein FS-Experte, das oben ist eine vereinfachte Darstellung von meinem Verständnis der Sachverhalte