The power of Linux

Heute mal etwas völlig anderes: man kennt das ja, da hat man eine externe Festplatte, die man unbedingt frei haben muss, um sie mit neuem Zeug zu füllen und muss sie mindestens für ein, zwei Tage auf dem eigenen Rechner speichern können. Auf der externen Festplatte sind vielleicht 300 GB an Daten und auf dem eigenen Rechner sind noch 350 GB an Plattenplatz frei. Dumm nur, dass sich diese 350 GB auf drei Festplatten verteilen und auf der ersten 200 GB frei sind, auf der zweiten 100 und der dritten ebenfalls.

Was also tun? Man könnte versuchen, den Inhalt von einer Platte auf die andere interne zu kopieren, um so zumindest auf einer genügend freien Platz zu schaffen – aber das dauert und besonders einfach ist das auch nicht immer. Nein.

Praktischer ist es dabei, sich ein billiges Raid-0 (Striping) über Loop-Devices zu basteln, deren Imagedateien auf den drei Festplatten liegen, das man dann mit einem beliebigen, geeigneten Dateisystem formatiert und die externe Festplatte wird darauf gesichert. Das geht standardmässig mit jedem einigermaßen, aktuellen Linux recht einfach.

Zuerst einmal fängt der Spaß damit an, dass man die Imagefiles auf den jeweiligen Festplatten als sog. Sparse File anlegt. Dies macht man praktischerweise mit dem netten Befehl dd:

dd if=/dev/zero of=file1.img bs=1k seek=128M

Das legt ein Sparsefile an, welches maximal 128 GB an Inhalt fasst. Man lege also so drei Sparse-Files auf den verschiedenen Festplatten an, nenne sie meinetwegen file1.img, file2.img und file3.img und passe natürlich auch die Größe an, meinetwegen 150 GB, 100 GB und 50 GB.

Als nächstes muss man dann Linux sagen, dass es diese Image-Files als Loopback-Device zur Verfügung stellt. Wer ein Loopback-Device nicht kennen sollte: damit tut der Kernel so, als sei das Image-File ein weiteres, physikalisches Gerät. Man kann diese Devices also z.B. nutzen, um ISO-Images direkt von der Festplatte zu mounten und auszulesen, eine praktische Sache.

Der Befehl, den wir dazu brauchen, ist losetup, und so sieht das dann auf:

losetup /dev/loop0 /file1.img
losetup /dev/loop1 /mnt/bla/file2.img
losetup /dev/loop2 /mnt/bla2/file3.img

Damit wird dem Device /dev/loop0 die Datei file1.img zugewiesen usw.

Als nächstes müssen wir dann aus den drei Devices ein Raid-0 basteln, was nichts anderes bedeutet als dass der Kernel aus dem Speicherplatz der drei Dateien einen einzigen, zusammenhängenden Bereich generiert, und das geht so:

md-adm --create /dev/md0 --level=0 --raid-devices=3 /dev/loop0 /dev/loop1 /dev/loop2

Damit wird der Kernel angewiesen, mit der Datei /dev/md0 ein Raid-0 zur Verfügung zu stellen, welches sich genau über die drei Loop-Devices erstreckt.

Als letztes formatiere man dann das Raid-Device md0 noch mit einem Dateisystem (hier: Ext4) seiner Wahl, beispielsweise so:

mkfs.ext4 /dev/md0

Und mounte es:

mount /dev/md0 /mnt/backup

Wenn man dann später das Backup nicht mehr braucht, kann man die Imagedateien einfach löschen und der Platz ist wieder frei, und fertig ist die Laube. Schön, nicht wahr?

Ach ja, und wenn man später mal die Dateien doch noch mal zusammen bauen will zum Raid-0, um nach einem Neustart wieder darauf zuzugreifen, muss man nur den Schritt mit losetup ausführen und danach das hier eintippen:

md-adm --assemble /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2

Das ist alles.

PS: Für wen Linux und dessen Kommandozeile ein böhmisches Dorf ist, der sollte besser die Finger davon lassen, bevor er sich noch wichtige Daten zerschießt und ohnehin ist es sinnvoll, immer mindestens ein aktuelles Backup zur Hand zu haben! Ihr seid gewarnt!

Wie man Fragen richtig und erfolgreich stellt

Es gibt im englischen Sprachraum vom Opensourceevangelisten Eric S. Raymond ein klassisches Howto mit dem schönen Namen „How to ask questions the smart way“, also eine Anleitung wie man Fragen in Foren und Chats intelligent stellt. Intelligent bedeutet in dem Sinn, dass die Chance auf Beantwortung der Frage wächst, indem man die wichtigen Informationen rüberbringt, zeigt das man selber ein wenig recherchiert hat und den Leuten etwas zum Arbeiten gibt. Diese Anlitung lässt sich großteils auch problemlos auf Second Life Gruppenchats anwenden, da die Mechanismen überall dieselben sind, und wurde auch ins Deutsche übersetzt. Auf Deutsch heißt es einfach „Wie man Fragen richtig stellt“.

Eine typisch konfuse Fragesituation

Zuerst mal als Beispiel eine typische Fragesituation, die man besser in SL so vermeiden sollte. Chat ist dabei in Kursiv gesetzt.

Frager: Hallo, jemand da?
A: Ja.
B: Bestanden!
C: X
D: Hallo!
E: Hallihallohallöle!
F: Ja, guten Tag auch!

So kann man natürlich eine Frage anfangen und tun es viele, das Problem ist dabei aber dass das so eine Menge an Rauschen erzeugt und schon einige Mitleser, die vielleicht die Antwort wissen könnten, entnervt den Chat schließen, da man nicht direkt mit dem Anliegen rüberkommt und es so Manche für den Beginn einer der typischen, langen Laberrunden halten.

Oft geht es dann so weiter:

Frager: Ich habe eine Frage zu $BLAFASEL, ist jemand da der sich damit auskennt?
A: Nein.
B: Zu was?
C: Fleisch ist heute aus!
D: Stell die Frage doch einfach!
E: Uh, huhu $SOMEGUY, lange nicht mehr gelesen, winke winke!
$SOMEGUY: Holla die Waldfee, du lebst ja auch noch!
F: $SOMEGIRL kennt sich damit aus, ist aber gerade nicht online.

Auch das zerrt dann erneut stark an den Nerven der Mitleser, da sie nun zwar wissen da will jemand eine Frage loswerden, aber kommt noch immer nicht damit heraus, was es denn nun ist – das Rauschen wächst weiter und so machen erneut viele den Chat dicht. Außerdem ist diese Frage, ob jemand da ist der sich damit auskennt einfach schlecht, denn wenn einer da ist wird er sich schon melden, wenn er mag, wenn nicht kriegt man es auch mit und stellt die Frage vielleicht später einfach noch einmal. Natürlich sollte die Gruppe thematisch zu der Frage einigermaßen passen.

Frager: Ach, ich stelle die Frage nun einfach: wie kann ich den $NIPPEL durch die $LASCHE ziehen, weiß das jemand?

Erst damit ist dann die eigentliche Frage gestellt und im Raum, so dass die restlichen Mitleser damit arbeiten können, aber viele werden den Chat bereits entnervt verlassen haben wegen des Rauschens. Das wiederum vermindert die Wahrscheinlichkeit, dass man eine passende Antwort auf die erwünschte Frage bekommt.

Wie man es besser macht

Wie aber kann man es nun besser machen und damit dafür sorgen, dass die Wahrscheinlichkeit einer passenden Antwort wächst? Indem man sofort mit der Frage rausrückt, denn die erste Textzeile ist das einzige, was wirklich dann alle Teilnehmer von einem lesen und es intelligent formuliert. Das kann dann zum Beispiel so aussehen:

Frager: Hallo! Ich habe schon $HIER, $DORT und $SOWIESO gesucht, aber nichts gefunden und frage mich: wie kann ich den $NIPPEL durch die $LASCHE ziehen? Antworten bitte direkt an mich per IM, Danke!

Die Wahrscheinlichkeit, dass eine solch formulierte Frage beantwortet wird, ist recht groß. Erstens zeigt man, dass man sich schon mit dem Thema auseinandergesetzt hat, zweitens stellt man die Frage direkt und fragt nicht zuerst, ob jemand da ist der sich damit auskennt oder nicht. Das erhöht die Wahrscheinlichkeit der Antwort enorm, und wenn man denn sagt die Leute sollen sich per IM melden, entlastet es den Chat noch. Natürlich kann man danach sich noch im Kanal für die Antworten bedanken und die Lösung, die einem weiter half, kurz nennen. So einfach könnte mit ein bisschen Nachdenken ein gut funktionierender Chat sein.

Denn merke: was man als Antwort aus einem Chat ziehen kann hängt stark davon ab, wie gut die Frage gestaltet worden ist!

Anleitung: wie man den Phoenix Viewer mit dem Squid-Cache betreibt

Das Problem

Wir alle kennen das doch in Second Life: man hat inzwischen Speicherplatz ohne Ende, aber aus verschiedenen Gründen kann man nach wie vor den Cache (also Zwischenspeicher) des Viewers maximal auf 1 GB einstellen und danach ist Feierabend. Dieser Speicher ist dabei auch schneller voll, als einem lieb ist und da viele von uns häufig den Cache auch bei diversen Problemen löschen, wird sein ohnehin schon geringer Nutzen nur noch mehr geschmälert, ohnehin funktioniert er auch sonst nicht besonders gut. Gerade bei den heutigen Speichermonstern sollte es ohne Problem möglich sein, z.B. 10-20 GB an Speicherplatz für Texturen einzustellen, bisher geben das alle Viewer aber nicht her.

Die Idee

Im Internet sind Proxy-Caches ein alter Hut, eine ausgereifte Technik und kostenlos verfügbar. Ein Proxy-Cache – wir benutzen hier dabei die Software Squid 2.7 – ist nichts anderes als ein zwischen dem eigenen Rechner und Internet dazwischen geschaltetes Programm, das anstelle des Viewers die Texturen herunterlädt und lokale Kopien in einer geeigneten Struktur auf der Festplatte anlegt. Ist erst einmal eine Textur lokal auf der Festplatte gespeichert, dann wird sie direkt von der Festplatte gelesen und nicht mehr erst mühselig aus dem Internet geladen.

Früher war dies übrigens schlecht möglich, seitdem aber Linden Lab als Standardtransportprotokoll für Texturen das altbekannte HTTP, mit dem auch jede Webseite arbeitet, eingeführt hat ist dies recht einfach machbar.

Die Lösung

Die aktuellen Phoenix-Viewer erlauben die direkte Angabe eines Proxy-Caches. Wer also Phoenix ohnehin nutzt, der kann dies recht einfach aktivieren, hier in dem Beispiel beschreibe ich die Installation unter Windows ab XP.

Ein Problem bei der Sache ist, dass Linden Lab für den Aufruf derselben Textur in der URL auch den Simnamen vorkommen hat. Man muss also den Squid dazu bringen, dass er für jede Textur intern dieselbe URL (Adresse) speichert, damit es auch wirklich gut funktioniert. Dafür bedarf es eines Features namens storeurl_rewrite, das nur in Squid bis Version 2.7 verfügbar ist. In aktuelleren Versionen mit einer 3 davor ist es nicht vorhanden und daher sind diese für diesen Zweck unbrauchbar. Mehr erfahren