Arch Linux

Ureadahead

agaida

Eigntlich nicht. Aber der aktuelle Zen ist doch im AUR???

Ying

Hmm. Ich habe aber Probleme mit dem zusammenspiel der Arch Patches. Aber ich versuchs später nochmal. Zurzeit viel zu tun. 😉

Edit: Im zen Kernel ist die variable arch_patch (so was ähnliches) auf false gesetzt. Setze ich diese auf true, dann geht der Build aus dem Aur auch nicht. 😉

Edit2:

zen patch includes 99.9% patches from arch patches, only logo is missed 🙂

Naja 99.9% stimmt nicht ganz vllt 85-90%
Das ganze PKGBUILD von dem Betreuer ist nicht gerade schön. Habe mehrere Fehler entdeckt. Ich weiß nicht ob ich den zen patch nehmen soll, wenn die Arch nicht gehen. Ich hole mir nur noch den ck patch. Der Rest im Zen Kernel ist für mich unwichtig.

agaida

Hi. Ich will Dir ja nicht zu nahe treten, ABER!
-Kernel gpatcht, kompiliert, installiert - ok.
-libnih-yi geholt und installiert
-ureadahead geholt und installiert
-neu gestartet und nichts passiert

Es ist ja schön, dass ein /etc/init/ gibt, nur das macht noch nichts. Ich kann ja bei Ubuntu spickern und sehen, dass der sich an den mountall ranhängt. Den gibt es aber in der Syntax unter Arch so nicht, oder? Wie geht Otto Normal jetzt weiter vor?

Ach so, manuelles Starten als root brachte eines: Das Tracing funkt.

Ying

Sry. Die initscripts-ureadahead habe ich ich noch nicht ins Aur gestellt. Sry aber ich habe sehr viel zu tun gehabt. Ich stelle die gleich rein, wenn ich alles fertig getestet habe. Ich schreibe dann noch ein Wiki, damit man sich die Scripts nicht selber anschauen muss.

Tut mir Leid, dass ich das noch nicht fertig gemacht habe.

Edit: Natürlich funktioniert ureadahead nur mit root Rechten.

MFG

agaida

Ist überhaupt nicht tragisch. Ich hab mal Hand aufgelegt. Klappt nach Startschwierigkeiten vom allerfeinsten. Eins ist natürlich wie immer klar. Auf meiner Konfiguration funktioniert das natürlich nicht ohne manuellen Eingriff. Du hast wahrscheinlich nur eine Partition. Ich hab das jetzt so gelöst. In der rc.sysinit nach den Mounts:

run_hook sysinit_premount
# now mount all the local filesystems
/bin/mount -a -t $NETFS -O no_netdev
stat_done

status "Activating Swap" /sbin/swapon -a

#Alf ureadahead - Versuch
#/sbin/ureadahead --daemon --force-trace
/sbin/ureadahead /var/lib/ureadahead/pack
/sbin/ureadahead /var/lib/ureadahead/usr.pack
/sbin/ureadahead /var/lib/ureadahead/home.pack

Irgendwie so, da die Reads ja im Vordergrund laufen sollen. Eine mögliche Änderung wäre jetzt noch, den Read auf die /home nach die gdm in den Hintergrund zu packen, das ist aber, glaube ich, rein akademisch. Insgesamt eine feine Sache. Ein Hinweis auf das manuelle Killen mit ps ax|grep read sudo kill id wäre auch nicht schlecht.

EDIT: Damit wären wir schon fast wieder beim Ansatz des Threads angelangt. Xorg im Ram. Wenn man das jetzt umformuliert in Xorg schneller in Ram, dann passt es. Ein paar Sachen, die mir gestern noch eingefallen sind und die ich erfolgreich ausprobiert habe:
1. Partitionen sind auch auf einer Platte sinnvoll.
2. 1. Partition '/', 2. Partition '/usr/' 3. Partition '/home'. Die jeweiligen Daten in die jeweilien Partitionen einspielen. Dann die '/' auslagern, putzen und definiert wieder einlagen. Und wie durch Geisterhand liegen alle benötigten Files richtig eng beieinander. '/' sollte jetzt nur noch 2-3G haben.
3. Das System nochmal profilieren. Ureadahed optimiert die Zugriffe auf die zu lesenden Files nach deren physikalischer Anordnung und liest dann optimiert ein.

Das sollte es gewesen sein. Mein Arch startet nur noch vernachlässigbar langsamer als Ubuntu. Und alles ohne Upstart und dash.

Ying

🙂

Aber du brauchst nur

/sbin/ureadahead --daemon

in rc.sysinit einfügen, da deamon alles selber macht:

Falls Pack Datei/en verfügbar -> dann Bootprozess pausieren und alles in den Ram schreiben.
Falls nicht, dann Bootprozess weiterlaufen lassen und ureadahead in den Hintergrund alles protokollieren lassen.

Edit: initscripts-ureadahead ist jetzt im Aur verfügbar. Konnte die Release jedoch noch nicht testen. Mache ich morgen.

agaida

Dem ist nicht ganz so. Wenn kein pack vorhanden, dann legt er die Packs an. Beim nächsten Start findet er eine Pack und lädt auch nur diese. Der Auszug aus der Man-Page ist bitter ernst gemeint.

       When started without any arguments, it checks for the existance and age of the default pack file /var/lib/ureadahead/pack, and if  not  present or  older  than a month, will discard it and retrace the boot sequence. The pack will then contain information about the  files  opened  during boot, and the blocks that were in memory at the completion of the boot.

--daemon
Places ureadahead into the background once  the  pack  file  has been read, or once tracing has been enabled. This  is  ignored  when reading on rotational hard drives, since it's important for performance reasons not to content with other processes for I/O.

OTHER MOUNT POINTS
PACK  need not be the filename of a pack, instead it may be the name of a mount point (or indeed any non-file within the filesystem), in  which case  the pack for that device is read instead.  This allows ureadahead to be called in the style ureadahead /usr for filesystems split  across multiple devices.

Diese Worte sind so gemeint, wie geschrieben. Übersetzt bedeutet das eigentlich nur: Hast Du Deine Daten auf verschiedene Laufwerke verteilt, bist Du am Arsch und kannst die ganze Arbeit manuell erledigen. Siehe mein erstes Posting. Das Tracen über mehrere Mountpoints kriegt der daemon noch alleine hin. Das Laden der Packfiles ohne Argumente funktioniert genau einmal. den Rest kannst Du allein erledigen. Da ich genau diese Konfiguration fahre, bin ich also wieder einmal am Arsch. Fährst Du eine Partition, erledigt der daemon den Rest, auch die monatlichen Updates. Eine interssante Option aus dem Fedora-Readahead hat Remnand nicht zurückportiert. Die Steuerung über Semaphoren-Datei. Ich werde das mal testweise morgen einbauen. Das muss nur ins Scripting. Hintergrund sind Änderungen der Systemkonfiguration. Fahre ich Updates, stelle ich mit touch /.readahead eine Datei ins Root. Beim nächsten Start wird die abgefragt und falls vorhanden abgearbeitet. Uralt und wirkungsvoll. Aus diesem Grund habe ich meine Sachen auch nicht als daemon eingestellt.

Die Idee, dass mehrere kleine Paritionen auch auf einer Platte sinnvoll sein können, kam mir gestern beim Aufräumen. Ich hab endlich mal meine Linuxe in Ordnung gebracht und sortiert. Brachte auch mächtig was an Speed. (Auslagerung und Wiedereinlagerung = Defragmentierung) Ausserdem ist jetzt alles vernünftig benamst und nachvollziehbar. Das sieht dann ungefähr so aus:

Arch:

[agaida@archramme ~]$ blkid | grep arch_
/dev/sda5: LABEL="arch_root" UUID="779ce544-5c2d-46a3-9851-72797d0d0e96" TYPE="ext4" EXT_JOURNAL="01cb20c3-c508-47ac-b518-504b7d9d4b00" 
/dev/sdb5: LABEL="arch_root_jrnl" UUID="01cb20c3-c508-47ac-b518-504b7d9d4b00" TYPE="jbd" 
/dev/sdb6: LABEL="arch_usr_jrnl" UUID="bcfe0e8a-dcf9-4e2e-9119-1dbd934c9e3a" TYPE="jbd" 
/dev/sdb7: LABEL="arch_home_jrnl" UUID="b26e9e74-5c59-4be0-a0c3-93c90bef389d" TYPE="jbd" 
/dev/sdd5: LABEL="arch_usr" UUID="b2c1260f-f530-44e4-8a08-3be0bcb289f1" EXT_JOURNAL="bcfe0e8a-dcf9-4e2e-9119-1dbd934c9e3a" TYPE="ext4" 
/dev/sde7: LABEL="arch_home" UUID="c3cd9ca2-199b-4b14-b72d-1e83506cf1d0" TYPE="ext4" EXT_JOURNAL="b26e9e74-5c59-4be0-a0c3-93c90bef389d"

Ubuntu64

[agaida@archramme ~]$ blkid | grep ub64_
/dev/sdb11: LABEL="ub64_root_jrnl" UUID="97228b13-12d3-4585-86be-3e1009184ec7" TYPE="jbd" 
/dev/sda9: LABEL="ub64_root" UUID="49aa0b87-9a75-450f-af0e-a8e9d7427892" TYPE="ext4" EXT_JOURNAL="97228b13-12d3-4585-86be-3e1009184ec7" 
/dev/sdb13: UUID="d9019c04-838b-42b3-a756-9f9655c509f2" TYPE="jbd" LABEL="ub64_home_jnrl" 
/dev/sdb12: UUID="827aa49c-da1a-4c0f-8ab0-dea305acbe12" TYPE="jbd" LABEL="ub64_usr_jrnl" 
/dev/sdd9: LABEL="ub64_usr" UUID="e96eb250-5269-43db-86bf-37634e1f69f7" TYPE="ext4" EXT_JOURNAL="827aa49c-da1a-4c0f-8ab0-dea305acbe12" 
/dev/sde8: LABEL="ub64_home" UUID="2de3fa05-6aa2-400c-b6a2-33742b43a621" EXT_JOURNAL="d9019c04-838b-42b3-a756-9f9655c509f2" TYPE="ext4"

Wie Du siehst, fehlen /dev/sdc.. Das ist der Tatsache geschuldet, das man mit der Ubuntu-Varinte bisher kein separates '/var' ansprechen konnte. Das probiere ich morgen aber noch mal aus.

Ying

Hmm. Ich habe bezüglich des Problems vllt eine Lösung. Ich schreibe gerade die initscript-ureadahead um. Mal schaun ob es klappt.

Edit: Die neuen Scripts sind jetzt im Aur verfügbar. Wiki: https://wiki.archlinux.de/title/Ureadahead

agaida

Sauber. Das mit /var hat Remnand hart und nicht änderbar verdrahtet, aber das ist ja die Version aus der Entwicklung?

Ying

Hmm. Nein das glaube ich nicht. Ich habe nur den letzten Source von der Seite https://launchpad.net/ureadahead genommen.
Was sagst du zu meinen Scripts: /usr/bin/ureadahead-start und /usr/bin/ureadahead-stop? Sind das akzeptierbare Möglichkeiten, dass so zu lösen?

agaida

Schon ganz ok, nur die Bedingungen gefallen mir nicht wirklich. Ich brauch noch ein wenig, ich prügel mich grade mit Mav.

Edit: Interessant und auf der Such nach neuen Sourcen zum "partizipieren"...

Zu Deinem Script:
Nette Idee, aber ein wenig am Thema vorbei. Das ist kein Unix, das ist kein Arch, dass ist ncht Kiss. Begründung: Wenn irgendwo ein Fehler ein auftritt, soll er sich auch melden dürfen, wenn man ihm das erlaubt. Die gesamte Behandlung, die Du abfängst, ist schon eingebaut und funktionerend. Warum da noch was dran schrauben?
1. If - wenn das Verzeichnis nicht da ist, schmeisst er einen Fehler - mehr nicht. (gelöst)
2. find - name pack ist eingebaut, Standardverhalten, braucht nicht eingebaut werden.
3. else - dito, stehet alles in den man-pages.
4. eine Protokollierung hat unter /etc/nichts zu suchen, dafür gibts /var/log, meiner Meinung nach auch unnötige verbosity

Das Verzeichniss für /var/lib/ureadahead gehört ins postinstall. Wann und wo wird ureadahead-stop getriggert?
(Sorry, wenn das jetzt zu hart klingt, ist nicht persöhnlich gemeint, so würde ich es machen)

Auf einem Ein-Partitionen-System würde ich im ersten Schritt nur einen
/sbin/ureadahead --daemon
setzen und im Wiki auf die Möglichkeit hinweisen, weitere Packs dazuzuladen.

Ein weiterer Schritt wäre meiner Meinung nach ein Konstrukt a la

if [ -f /.ureadahead]; then
  rm /.ureadahead
  ureadahead --daemon --force..
else
  ureadahead  --daemon
fi

um einen Neuaufbauzu forcieren.

/edit: Aufruf von ureadahead-stop aus einer .desktop fänd ich irgendwie klasse, da wir keine events haben

agaida

Solche notwendigen Änderungen an Scripts könnte man noch per echo aus dem postinstall raushauen. Wers nicht liest, Pech gehabt. Eine andere Möglichkeit ist, glaube ich pkginfo oder so.

Ying

Hmm. K danke für das Feedback. Ich setzte mich Morgen gleich dran. Jedoch habe ich noch ein paar Fragen.

2. find - name pack ist eingebaut, Standardverhalten, braucht nicht eingebaut werden.

? Wieso? Du musst diese doch manuell nachladen?! Ich dachte, wie ich das oben verstanden habe, dass ureadahead nur die pack Datei ausliest?!

/edit: Aufruf von ureadahead-stop aus einer .desktop fänd ich irgendwie klasse, da wir keine events haben

Wie wärs mit einer kleinen Gui, die immer zum Vorschein kommt, wenn neu getraced wird, damit man ganz einfach per Mausklick ureadahea-stop aufrufen kann -> genügend Zeit alles zu starten, was man in den Ram geladen haben will?

4. eine Protokollierung hat unter /etc/nichts zu suchen, dafür gibts /var/log, meiner Meinung nach auch unnötige verbosity

? Das ist nur ein File zum neu tracen lassen. Kann ich aber ändern. Passt jedoch nicht zu log?!

Edit: Wenn du Lust hast, kannst du gerne den Wiki Eintrag mitverbessern;)

MFG

agaida

zu 2. When started without any arguments, it checks for the existance and age of the default pack file /var/lib/ureadahead/pack, and if not present or older than a month, will discard it and retrace the boot sequence. The pack will then contain information about the files opened during boot, and the blocks that were in memory at the completion of the boot.

agaida

Wie wärs mit einer kleinen Gui, die immer zum Vorschein kommt, wenn neu getraced wird, damit man ganz einfach per Mausklick ureadahea-stop aufrufen kann -> genügend Zeit alles zu starten, was man in den Ram geladen haben will?

Nö. Entweder Default=irgendwas oder kill Prozess. Wobei mir die Idee mit dem .desktop File immer besser gefällt, da das die Event-Steuerung von upstart ziemlich genau nachbildet.
GUI nicht gut, was ist bei gui-losem Einsatz?

Ying

When started without any arguments, it checks for the existance and age of the default pack file /var/lib/ureadahead/pack, and if not present or older than a month, will discard it and retrace the boot sequence. The pack will then contain information about the files opened during boot, and the blocks that were in memory at the completion of the boot.

of the default pack fil. Also nicht home.pack usr.pack .... Mit dem find code werden alle pack files gestartet.

.desktop File immer besser gefällt

Ist .desktop nicht einfach eine Starterdatei, wie die in /usr/share/applications/ ?

MFG

agaida

echo "##If this file exists, then ureadahead is loading the pack files in '/var/lib/ureadahead/' in ram." > /etc/ureadahead
echo "##If not, then ureadahead is going to force a new tracing." >> /etc/ureadahead
fi

Was ist das sonst? Zeile 1 prügelt was in ein File, echo2 hängt Text an. Wenn ich das richtig lese, nennt man das in Fachkreisen Protokoll. Wenn ich mich verlesen habe, funktioniert das trotzdem nicht, weil das File kein execute-Flag hat und auch nie aufgerufen wird.

agaida

Ying schriebof the default pack fil. Also nicht home.pack usr.pack .... Mit dem find code werden alle pack files gestartet.

Wer partitioniert, kann auch 2 Zeilen dazu schreiben. Der muss nur drauf hingewiesen werden. KISS. Wie ich gestern schon schrieb, ich weiss zum Beispiel nicht, ob mir das Lesen der home.pack an der Stelle gefällt oder ich die überhaupt laden will.

.desktop Missbraüchlich ja, Du kannst im File Optionen mitgeben.

Ying

Stimmt. Es wird nie aufgerufen. Ureadahead ist frisch installiert und prüft beim hochfahren, ob die Datei "/etc/ureadahead" vorhanden ist. Da diese Datei noch nicht existiert, traced ureadahead neu und erstellt diese Datei. Ich hätte diese auch mit touch erstellen können. Jedoch wundert sich dann jeder, wieso sie leer ist. Ich hätte es vllt besser erklären sollen. Beim nächsten Start prüft ureadahead erneut. Da sie existiert, werden alles *.pack files und das defaut pack file ausgelesen und verarbeitet. Will man ureadahead neu tracen lassen, dann löscht man einfach die Datei /etc/ureadahead.

Ich habe das so bewusst gemacht, da ich nicht jeden Monat ureadahead neu tracen lassen will. Wenn dann mach ich das manuell. Vllt habe ich dich jetzt falsch verstanden und ich erzähle dir etwas, dass du schon verstanden hast.

Kannst du mir deinen Vorschlag mit der .desktop Datei näher erklären. Wäre leichter für mich, deinen Vorschlag zu verstehen. Ich weiß, dass meine Skripts nicht richtig oder verbesserungswürdig sein könnten aber dazu ist doch eine Community da?!

Edit: Du warst jetzt schneller;) Da du Kiss erwähnt hast. Ja du hast Recht. Ich lösche einfach die initscripts-ureadahead. Jeder kann sich das manuell einstellen. Dann braucht man aber auch nicht die .desktop file. Wenn jemand den benötigt, dann kann man sich den selbst erstellen, da z.b. ich keine .desktop files nutze. Alles geht über den Rechtklickt oder Tastatur.

Edit2: Wie kann man Pakete aus dem Aur löschen?

agaida

zu 1. Ureadahead frisch installiert: ureadahead --daemon findet nichts und erstellt alles neu. Standard. Mit einem touch bremst Du ureadahead eigentlich nur aus, da er dann eine leee Datei verarbeitet. pack ist das File von '/'. Der eventuelle Rest sind die Packs der Mountpoints. da würd ich nicht reingreiffen, da ist Verstand bei. Sprich Otto Normal hat nur ein packfile.

Wenn Du neu Tracen willst, lösch das pack-File. Standard.

zu 2. Du kannst Dich auf den Kopf stellen, der macht einen neue Trace nach einem Monat. Standard. Einzige Möglichkeit ist, die Datei mit einem Touch zu erneuern, hab ich aber noch nicht probiert.

Mein Vorschlag ist, den Trace anzuschubsen mit "touch /.ureadahead", weniger Tipperei, als etwas zu löschen.

zu 3. Wenn Du Dir die Calls von upstart in den Scripts anschaust, findes Du eine Eventsteuerung z.B "On Ereignis do irgendwas...". Das Ereignis ist in unserem Fall das Erreichen des Desktops, da wir das Beenden eines Scripts nicht direkt feststellen können. Als erstes rappelt er durch die Autostart. Da steht dann unsere Datei mit dem kill. Das meinte ich mit Nachbildung der Eventsteuerung. Von der zeitlichen Steuerung ist die Genauigkeit unrelevant, da nicht zeitkritisch. Hauptsache das Ding terminiert so ungefähr im angegebenen Zeitrahmen. Ein Zehntel mehr oder weniger machen da den Kohl nicht fett.

« Vorherige Seite Nächste Seite »