Da ich in der nächsten Zeit nicht allzu viel zu tun habe, habe ich beschlossen, den Blog zweisprachig werden zu lassen. Wichtige und große Artikel und Seiten sollen relativ schnell übersetzt werden, kleinere kommen dann irgendwann.

Das Ziel ist, dass der Blog nicht nur deutschsprachigen Menschen weiterhilft, sondern auch den ganzen Rest da draußen erreichen kann. Wir sind ja nicht nur zum Amusement hier

Ich stell mich mal kurz vor… ich bin ein Kumpel vom Adrian, der in etwa ähnliche technische Interessen hat. Auf der einen Seite hab ich so gut wie keine Zeit dafür, aber auf der anderen programmiere ich dann doch ab- und zu etwas oder mache etwas anderes technisches. Da ich ein Opensource Fan bin, würde ich meine Ergebnisse der Welt gerne zur Verfügung stellen und werde es hier in unregelmäßigen Abständen – eben sobald es etwas nützliches gibt – auch umsetzen

Angenommen, wir haben eine ClientRequest-Nachricht, welche bestimmte Anfragen an den Server schicken kann. Beispielsweise die Anfrage, den Spieler im Spiel zu registrieren. Dies sieht in der .proto-Datei (gekürzt) folgendermaßen aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

message ClientRequest {
	enum Operation {
		REGISTER_PLAYER = 1;
		[...]
	}
	optional RegisterPlayerParameters register_player_parameters = 3;
	[...]
}
 
message RegisterPlayerParameters {
	required PlayerInfo player_info = 1;
	[...]
}
 
message PlayerInfo {
	required string name = 1;
	[...]
}

Dann sieht das C++-Snippet zum Versenden ungefähr so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

using namespace boost::asio;
boost::asio::io_service io_service;
tcp::resolver resolver(io_service);
tcp::resolver::query query(tcp::v4(), “127.0.0.1?, 12345); // host und port
tcp::resolver::iterator iterator = resolver.resolve(query);
 
sock = new tcp::socket(io_service);
sock->connect(*iterator);
 
// Hier die protobuf-messages
ClientRequest req; // diese wird wirklich angelegt
RegisterPlayerParameters* rpp; // pointer, da von req bereitgestellt!
PlayerInfo* info; // pointer, da von rpp bereitgestellt!
 
req.set_operation(ClientRequest::REGISTER_PLAYER); // Parameter für req setzen
 
// wir holen uns einen Pointer auf die RegisterPlayerParameter-Message !innerhalb! des ClientRequest-Objekts
rpp = req.mutable_register_player_parameters();
 
// wir holen uns einen Pointer auf die PlayerInfo-Message !innerhalb! des RegisterPlayerParameters-Objekts
info = rpp->mutable_player_info(); // mutable, damit wir es ändern können
 
// Mit diesem Pointer können wir die Attribute setzen
info->set_name(name);
 
boost::asio::streambuf b;
std::ostream os(&b); // Protobuf serialisiert in einen Stream (der im Endeffekt alles in einen Puffer schiebt)
 
// Das ClientRequest-Objekt “versandfertig” verpacken
req.SerializeToOstream(&os);
 
// Der ostream packt alles in den streampuffer b, den wir per asio versenden können
boost::asio::write(*sock, b);

Mein System lief auf einem 1GB USB-Stick und lief eigentlich ziemlich super. Lief. Ja. Das ist der Knackpunkt: Mein USB-Stick ist ziemlich tot.

Das äußert sich darin, dass plötzlich irgendwelche Befehle nicht mehr tun, ich kryptische Errors um den Kopf geworfen bekomme und das System nicht mehr bootet, weil das ext2-fs so stark beschädigt ist, dass es nicht durch den routinemäßigen Check beim boot repariert werden kann, sondern manuell per e2fsck gefixt werden muss (von einem anderen pc aus).

Die Ursache dafür liegt darin, dass die in USB-Sticks und SD-Karten verbauten Flash-Chips zwar praktisch unendlich viele Lesevorgänge, aber nur ca. 10.000 – 100.000 Schreibzyklen pro Sektor verkraften. Das ist normalerweise absolut kein Problem, wenn man einfach nur “Daten” auf diesen Sticks zwischenspeichert. Außerdem versuchen die Hersteller meist, die Schreibvorgänge auf mehrere Sektoren zu verteilen, um ein Überschreiben von immergleichen Sektoren zu vermeiden. Letzteres kann aber natürlich nicht funktionieren, wenn der Stick quasi voll ist.

Wenn man aber ein Betriebssystem auf dem Stick betreibt, können diese Zyklen relativ schnell erreicht sein, vor allem durch Logfiles, Lockfiles und temporäre Daten. Auf diese Weise hat sich wie eingangs schon erwähnt mein (zugegeben ziemlich billiger und schon länger gebrauchter) USB-Stick verabschiedet.

Da viele Teile dermaßen beschädigt waren, dass das Reparieren verdammt aufwändig geworden wäre, habe ich das System von Neuem hochgezogen. Dabei habe ich mir die Frage gestellt: Wie kann ich vermeiden, dass das System wieder meinen Stick screwed? Als erstes kam mir die Idee, einfach das rootfs read-only zu mounten. Das hat aber zur Folge, sämtliche Schreiboperationen im RAM zu cachen. Da die Dockstar nur 128MB RAM hat, schied diese Möglichkeit aus. Als zweites kam mir die Idee, die ich jetzt auch umgesetzt habe:

Flüchtige Daten in einer Ramdisk halten

Das heißt, ich mounte mir einen Teil des spärlich vorhandenen RAMs als Datenträger und mappe ihn als Ersatz für die Verzeichnisse

• /var/log (Logfiles)
• /var/lock (Sperr-Files)
• /var/run (Daemon-PIDs)
• /var/tmp (Temporäre Dateien)
• /tmp (Temporäre Dateien).

Dadurch fange ich fast alle Schreibzugriffe ab, welche im Dauerbetrieb eben anfallen. Änderungen an Configfiles etc. werden aber immernoch sofort auf den Stick geschrieben. Falls das System sich aufhängt, abstürzt oder ähnliche Scherze passieren, ist der “zusätzliche” Datenverlust also gering (nur die neueren Logfiles). Trotzdem: Hier werden einige Dateien nur im RAM vorgehalten. Wenn das System crasht oder die Daten vorm Ausschalten nicht von der Ramdisk auf den Stick gesichert werden, sind sie weg!

Bevor ich mit der Anleitung beginne, sei hier die Seite cat brain.stuff > wordpress als Quelle genannt, da fast alle Informationen von dort stammen. Ich habe es lediglich zu Arch Linux / Plugbox Linux “geportet” und an meine Bedürfnisse angepasst.

Anlegen der Verzeichnisse

mkdir /var/log-bak

mkdir /var/lock-bak

mkdir /var/run-bak

mkdir /var/tmp-bak

mkdir /tmp-bak

mkdir /run-bak

mkdir /mnt/ramdisk

Den Daemon anlegen

Die Datei /etc/rc.d/ramdisk erstellen und folgendes hineinpasten:

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

case “$1″ in
start)
stat_busy “Copying files to ramdisk”

rm -Rf {/var/log-bak,/var/lock-bak,/var/run-bak,/var/tmp-bak,/tmp-bak,/run-bak}

mount –move /var/log /var/log-bak
mount –move /var/lock /var/lock-bak
mount –move /var/run /var/run-bak
mount –move /var/tmp /var/tmp-bak
mount –move /tmp /tmp-bak
mount –move /run /run-bak

mkdir /mnt/ramdisk/var
mkdir /mnt/ramdisk/var/log
mkdir /mnt/ramdisk/var/lock
mkdir /mnt/ramdisk/var/run
mkdir /mnt/ramdisk/var/tmp
mkdir /mnt/ramdisk/tmp
mkdir /mnt/ramdisk/run
mkdir /mnt/ramdisk/run/lock
chmod 1777 /mnt/ramdisk/tmp
chmod 1777 /mnt/ramdisk/var/lock
chmod 1777 /mnt/ramdisk/var/tmp
chmod 1777 /mnt/ramdisk/run

mount –bind /mnt/ramdisk/var/log /var/log
mount –bind /mnt/ramdisk/var/lock /var/lock
mount –bind /mnt/ramdisk/var/run /var/run
mount –bind /mnt/ramdisk/var/tmp /var/tmp
mount –bind /mnt/ramdisk/tmp /tmp
mount –bind /mnt/ramdisk/run /run

cp -a -v /var/log-bak/* /var/log/ >> /var/log/ramdisk_sync.log
cp -a -v /var/lock-bak/* /var/lock/ >> /var/log/ramdisk_sync.log
cp -a -v /var/run-bak/* /var/run/ >> /var/log/ramdisk_sync.log
cp -a -v /var/tmp-bak/* /var/tmp/ >> /var/log/ramdisk_sync.log
cp -a -v /tmp-bak/* /tmp/ >> /var/log/ramdisk_sync.log
cp -a -v /run-bak/* /run/ >> /var/log/ramdisk_sync.log

echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk synced from HD >> /var/log/ramdisk_sync.log
if [ $? -gt 0 ]; then
stat_fail
else
add_daemon ramdisk
stat_done
fi
;;
stop)
stat_busy “Switching off ramdisk, direct hdd write”
rsync -av –delete /var/log/ /var/log-bak/
rsync -av –delete /var/lock/ /var/lock-bak/
rsync -av –delete /var/run/ /var/run-bak/
rsync -av –delete /var/tmp/ /var/tmp-bak/
rsync -av –delete /tmp/ /tmp-bak/
rsync -av –delete /run/ /run-bak/

# Unmount ramdisk bind
umount /mnt/ramdisk/var/log
umount /mnt/ramdisk/var/lock
umount /mnt/ramdisk/var/run
umount /mnt/ramdisk/var/tmp
umount /mnt/ramdisk/tmp
umount /mnt/ramdisk/run

# Unmount move
umount /var/log-bak
umount /var/lock-bak
umount /var/run-bak
umount /var/tmp-bak
umount /tmp-bak
umount /run-bak

# Deleting directories
rm -Rf /mnt/ramdisk/*

echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk synced to HD >> /var/log/ramdisk_sync.log
if [ $? -gt 0 ]; then
stat_fail
else
rm_daemon ramdisk
stat_done
fi
;;
sync)
echo “Syncing log and lock files to harddisk”
rsync -av –delete /var/log/ /var/log-bak/
rsync -av –delete /var/lock/ /var/lock-bak/
rsync -av –delete /var/run/ /var/run-bak/
rsync -av –delete /var/tmp/ /var/tmp-bak/
rsync -av –delete /tmp/ /tmp-bak/
rsync -av –delete /run/ /run-bak/

echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk synced to HD >> /var/log/ramdisk_sync.log
;;

restart)
$0 stop
$0 start
;;

*)
echo “usage: $0 {start|stop|sync}”
esac
exit 0

Die /etc/fstab anpassen

Dort eine Zeile hinzufügen à la

tmpfs                   /mnt/ramdisk    tmpfs   size=64m        0       0

Ich benutze hier bewusst tmpfs und nicht ramfs, da tmpfs bei akutem Ram-Mangel auf swap ausweicht, ramfs dies aber nicht tut. Weiterhin limitiere ich die Größe für die Ramdisk auf 64MB. Die Ramdisk wächst aber dynamisch, belegt also nur Platz, welchen sie auch braucht. Die 64MB sind nur ein grob geschätzter Maximalwert.

/etc/rc.conf anpassen

Hier sollte der Daemon als erster gestartet werden, damit so wenige Applikationen wie möglich den (sehr) kurzen Ausfall der oben genannten Verzeichnisse verkraften müssen. Euer DAEMONS-Array könnte also so aussehen:

DAEMONS=(ramdisk syslog-ng network openntpd netfs crond sshd)

Logrotate anpassen

Ein Punkt, der sich erst nach einiger Benutzung als wichtig herausgestellt hat: Die Logfiles können sehr groß werden und damit den RAM füllen. Um das zu verhindern, sollten die Logs in kurzen Zeitabständen rotiert werden.

Dazu passen wir die /etc/logrotate.conf an. Meine sieht so aus:

daily

rotate 3

size 16M

create

compress

tabooext + .pacorig .pacnew .pacsave

include /etc/logrotate.d

/var/log/wtmp {

weekly

create 0664 root root

rotate 1

}

Abschließende Worte

Soweit, so gut. Beim nächsten Neustart sollte euer System also nun den größten Teil der Schreiboperationen im RAM vorhalten. Ganz eilige können auch einfach den Daemon starten, es sollte auch so funktionieren. Was passiert, wenn ein Prozess genau dann der Meinung ist, ein Logfile schreiben zu müssen, wenn der Daemon gerade Verzeichnisse herumschiebt, kann ich absolut nicht vorhersagen.

Wenn ihr Verbesserungsvorschläge, Tipps, Kritik oder sonstigen Senf zum Zugeben habt, immer her damit.

Hätte ich einmal C++ RICHTIG gelernt und nicht alles zusammenklamüsert, wüsste ich sowas wahrscheinlich. Aber da der Grundkurs, den ich besucht habe, etwas arg verpeilt war und außer dem Klassenmodell und iostream kein C++ verwendete, sondern z.B. Speicher grundsätzlich mit “malloc” reservierte, war so etwas eben nicht drin.

Übrigens empfehlen die im “offiziellen” C++ Forum genau das, was ich auch im Hinterkopf hatte: geschachtelte Vektoren. Das wollte ich anfangs auch machen, dachte mir aber, dass es da doch was gescheites für geben müsste… mhja.

Das hier ist also mehr so für google, damit das andere auch finden ;D

http://www.cplusplus.com/forum/articles/7459/

Ich arbeite in der GeneCore-Abteilung und vergleiche verschiedene (kommerzielle und open-source / freie) Programme zur Analyse von riesigen Mengen (we’re talking ~1 TB per run) von RNA-Seq-Daten mit dem Ziel, am Ende eine “beste Lösung” für jedes Anwendungsgebiet zu haben.

Dabei habe ich gemerkt, wie verdammt wichtig eine gute Dokumentation ist. Das Forschungsfeld um RNA-Seq ist noch sehr jung und daher steckt auch die Software noch in den Kinderschuhen. Es ist aber teilweise wirklich unglaublich, wie schlecht Teile der Software dokumentiert sind und wie viel Zeit nur dafür draufgeht, Parameter und mögliche Interferenzen zu “erraten”…

Für mich als Schüler ist die Schnellebigkeit dieses Forschungsfeldes einfach der pure Wahnsinn. Papers zu neuen Erkenntnissen schießen wie Pilze aus dem Boden und referenzieren andere Schriften, die teilweise erst vor unter einem Monat veröffentlicht wurden. Zum Vergleich: In der Schule haben wir in manchen Fächern über 20 Jahre alte Bücher…

Best served in 720p

Ja, wer bei YouTube geschaut hat, hat vielleicht gemerkt, dass das Video nicht August, sondern Mai entstanden ist. Ich wollte das eigentlich schon länger hier auf dem Blog posten, habs aber irgendwie verpennt…

“cowsay” nimmt einen Text und zeigt ihn in einer Sprechblase mit einer Kuh (oder eben mit Tux) in ASCII-Art-Manier an.

Kombiniert und ans Ende der ~/.bashrc (oder ~/.zshrc oder was ihr eben für eine Shell benutzt) geschrieben gibt es beim Öffnen einer Shell instant Awesomeness!

# Make tux say something
fortune -e sprueche linuxcookie chucknorris archlinux | cowsay -f tux