Leider greift revdep-rebuild in diesem Fall nicht, aber sobald man im dmesg dank aktueller btrfs-progs den Dateipfad sieht, kann man diese neu bauen. Leider gibt es noch keine Möglichkeit eine Liste von defekten Daten zu bekommen. Wäre ja zu einfach diese per sort und uniq in den Griff zu bekommen um die Pakete neu zu bauen…

Klar, als Frau ist es unüblich, über technische Dinge zu schreiben. Klar kann ich hier auch über z.B. den neuen, tollen Nagellack oder über die neuesten Trends und schwärmen, wie toll ich einen Filmstar finde.

Gut – in diesem Fall werde ich es heute ausnahmsweise tun und mal über den tollen Nagellack schreiben, den ich heute trage. Die Farbe nennt sich Perlmutt und schillert schön.

Es sollten zwei bis drei Schichten aufgetragen werden, damit der Nagellack ordentlich deckt.

Ich hoffe das reicht jetzt an Beauty Themen für dieses Jahr und wir können uns wieder den interessanten Themen zuwenden.

static const char *usblp_messages[] = { “ok”, “out of paper”, “off-line”, “on fire” };

Der Status ‘on fire’mag zwar aus Programmierer-Sicht Sinn machen, aber was mich dabei etwas beunruhigt ist, dass sich wahrscheinlich im Brandfall meines Druckers zu viel Rauch vor dem Monitor befinden würde, um diese Meldung überhaupt lesen zu können…

Was dabei gleich auffällt ist, dass die Mobiltelefone dem Navi zwar CPU-Technisch auf der ganzen Linie überlegen sind, jedoch nebenher auch noch ein paar andere Dinge zu erledigen haben, wie zum Beispiel die Kommunikation mit den sozialen Netzwerken, welche uns gleich schon zum ersten Kritikpunkt bringt:

Mobiltelefone neigen dazu, die Anzeige mit Statusmeldungen aufgrund von Hintergrund-Apps zuzupflastern. Das heißt, sobald jemand meiner Freunde auf Facebook seinen Status ändert, will beim iPhone eine Meldung bestätigt werden. Beim Android Telefon kamen andere Apps in die Quere, welche sich jedoch problemlos deaktivieren lassen, mit Ausnahme von Telefonanrufen.

Ein Vorteil der Mobiltelefone ist, dass bei den Navigationssystemen Daten aus dem Internet sehr leicht nachgeladen werden können, was ich jetzt mal als einen eindeutigen Pluspunkt für die Telefone werte, wenn da nicht Dinge wie Roamingkosten und ähnliche Stolperfallen im Ausland wären.

Rein äußerlich gesehen ist der Unterschied zwischen Navi und Mobiltelefon in der Halterung im Auto gar nicht so groß, da man beim Telefon durch den GPS Sensor sehr viel Strom verbraucht und daher auch am Ladekabel im Auto hängt.

Für mich sind die Navigierenden Mobiltelefone eher eine Notlösung bzw. als Spielzeug einzustufen, obwohl es an der Software nichts auszusetzen gab. Grund dafür ist die mangelnde Displaygröße und eben die weiteren Funktionen eines Handys, die den Navigationsbetrieb stören – Frei nach Murphy: gerade dann, wenn man das Navi braucht, kommt ein Anruf…

Laut dem Git-Pull Request von Chris Mason wurden einige schon länger geplante Änderungen und Fixes nun endlich eingepflegt, was sich durch eine Performance-Steigerung – nicht nur beim Scrubbing – bemerkbar macht.

Wie es scheint wurde auch am fsck gearbeitet, nachdem auch bei den btrfs-progs einige Commits passierten.

Irgendwie kann ich das Ganze nicht so ganz nachvollziehen, jetzt wo ich in jenem Bus sitze, den ich mir mir einer lauten Gruppe von Schülern teilen muss. Ich vermisse mein Auto.

Irgendwie kommen mir die Bilder, wenn sie nur am Computer gespeichert sind komisch vor, da das Gefühl fehlt, wenn man in einer Runde zusammen sitzt und ein Fotoalbum gemeinsam durchblättert.

Als Scrubbing bezeichnet man das Überprüfen aller Dateien auf dem Dateisystem, ob sie sozusagen noch das sind, was wir ursprünglich abgelegt haben. Klingt jetzt komisch, aber ist eigentlich ganz praktisch, da uns keine Datei mehr unbemerkt kaputt gehen kann. BTRFS schreibt ja pro Datei eine Prüfsumme mit, die eben beim Scrubbing überprüft wird.

Stimmt diese nicht mehr überein, ist etwas mit der Datei passiert und wir haben inkonsistente Daten, welchen man nicht mehr trauen kann.

Und so wird es gemacht:

# btrfs scrub start /mnt/btrfs
scrub started on /mnt/btrfs, fsid be328d82-a5fe-45ea-8e0b-be319912ea11 (pid=463)

Nachdem wir nun den Prozess angestoßen haben, läuft er im Hintergrund und man kann sich den Fortschritt anzeigen lassen:

# btrfs scrub status /mnt/btrfs
scrub status for be328d82-a5fe-45ea-8e0b-be319912ea11
        scrub started at Wed Nov 22 08:34:52 2011, running for 30 seconds
        total bytes scrubbed: 1.16GB with 0 errors

Ist das Ganze abgeschlossen, sieht die Ausgabe so aus:

# btrfs scrub status /mnt/btrfs
scrub status for be328d82-a5fe-45ea-8e0b-be319912ea11
        scrub started at Wed Nov 22 08:34:52 2011 and finished after 346 seconds
        total bytes scrubbed: 15.61GB with 0 errors

Sollten Fehler aufgezeigt werden, lohnt sich ein Blick in das Kernel-Log (dmesg) um die entsprechenden Dateien zu finden.

Nicht einmal der Licht-Wecker bringt mich da wirklich schön raus aus den Federn. Habt ihr Ideen wie man das Aufstehen leichter machen kann?