“error count” in ext4

Gestern verursachte ein defektes SATA-Kabel ein paar I/O-Errors auf einem ext4-Volume:

kernel: ata4: hard resetting link
kernel: ata4: hard resetting link
kernel: ata4: hard resetting link
kernel: ata4: limiting SATA link speed to 1.5 Gbps
kernel: ata4: hard resetting link
kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
kernel: ata4.00: failed to IDENTIFY (I/O error, err_mask=0x100)
kernel: sd 3:0:0:0: [sdc] Unhandled error code
kernel: sd 3:0:0:0: [sdc]  Result: hostbyte=0x04 driverbyte=0x00
kernel: sd 3:0:0:0: [sdc] CDB: cdb[0]=0x28: 28 00 6d 9e 5a 40 00 00 80 00
kernel: sd 3:0:0:0: [sdc] Unhandled error code
kernel: sd 3:0:0:0: [sdc]  Result: hostbyte=0x04 driverbyte=0x00
kernel: sd 3:0:0:0: [sdc] CDB: cdb[0]=0x28: 28 00 6d 9e 5a 40 00 00 08 00
kernel: sd 3:0:0:0: [sdc] READ CAPACITY(16) failed
kernel: sd 3:0:0:0: [sdc]  Result: hostbyte=0x04 driverbyte=0x00
kernel: sd 3:0:0:0: [sdc] Sense not available.
kernel: sd 3:0:0:0: [sdc] READ CAPACITY failed
kernel: sd 3:0:0:0: [sdc]  Result: hostbyte=0x04 driverbyte=0x00
kernel: sd 3:0:0:0: [sdc] Sense not available.
kernel: sdc: detected capacity change from 1000204886016 to 0

Nach dem Austausch und anschließendem fsck tauchte im Log immer noch periodisch folgende Meldung auf, was mich irritierte:

kernel: EXT4-fs (dm-13): error count: 2
kernel: EXT4-fs (dm-13): initial error at 1294001951: __ext4_get_inode_loc:4929: inode 78512129: block 314048544
kernel: EXT4-fs (dm-13): last error at 1294001953: ext4_find_entry:922: inode 61734943

Entwarnung fand ich auf der KML in einem Post von ext-Godfather Theodore Ts’o, der von einem im Superblock abgespeicherten Error-Log als neuen ext4-Feature berichtet. Selbiges wird erst ab Version 1.41.13 der e2fsprogs nach erfolgreichem Check wieder bereinigt – ein kurzer Blick mit Pacman zeigt mir 1.41.12-2 auf meinem System :)

Typisch Arch: ca. eine Minute später meldet sich mein Update-Cronjob mit e2fsprogs-1.41.14-1 ;)

19 Monate Arch – Was mich hält

Ein Blick auf mein pacman-log zeigt:

[2008-07-16 20:16] installed filesystem (2008.07-1)

Seit mehr als 19 Monaten residiert Arch also nun schon auf der Platte meines Notebooks. Und das, obwohl ich (entgegen meiner Einstellung zum Wechsel des Wohnortes) ein System aus reiner “Lust, mal wieder ein neues aufzusetzen” sonst nie länger als ein halbes Jahr am Stück behalten habe. Warum nun Arch? Das zeigt eine durch den regen Kontakt zu openSUSE-Maschinen und diverse Distributions-Eskapaden meiner Freundin ( ;) ) angestoßene Safari durch den mittlerweile recht dicht gewordenen Distro-Dschungel.

Am Wochenende nahm ich mir nämlich aktuelle Images sämtlicher vom Distro-Finder vorgeschlagener Distributionen (plus einiger Exoten, die mich schon länger mal interessierten) her und installierte sie testweise in einer virtuellen Maschine. Hier ein paar Eindrücke:

Debian: “Gutes, altes Debian” dachte ich mir, als ich die Seite betrat und feststellte, dass sich absolut nichts geändert hatte in den Jahren. “Oh, modernes, gutes, altes Debian” dann, als ich den nun grafischen Installer sah. “Grmpf, zu altes, gutes Debian” schließlich, als ich den fehlenden EXT4-Support realisierte. Das ist dann auch der entscheidende Nachteil: ich schätze die Stabilität des Systems auf Servern sehr, aber im privaten Bereich will ich ein Bisschen mehr bleeding-edge. EXT4 muss schon sein. Und da nicht mal das aktuelle Testing damit umgehen kann, fällt Debian leider flach für meine Zwecke.

Sidux: Viel mir ins Auge, als ich nach einem Debian-Derivat suchte, das den bei Debian vorherrschenden Staub kompensieren würde. Ubuntu kam von vornherein nicht in Frage – zu Mainstream, zu Canonical-verstickert.
Da ich kein KDE4 wollte, testete ich die XFCE-Variante. Im Grunde ein recht ordentliches System, allerdings mit recht unübersichtlichem init-output und ohne nennenswerte eigene Tools. Der Unterschied bei einem Umstieg wäre also minimal ausgefallen. Schwer zu beschreiben, was mir daran genau nicht gefiel – genauso schwer wie zu beschreiben, was mir denn gefiel. Vielleicht genau das… ;)

Fedora: Aktueller Hype bei einigen meiner ebenfalls vom Ubuntu-Hype genervten Kommilitonen. Ich hatte diverse Male das Vergnügen, die Distribution auf als Multimedia-PC gedachten Workstations zu installieren, und war vom Umgang mit proprietären Inhalten unter Fedora sehr genervt. Ich kann verstehen, dass man fragliche Codecs oder Closed-Source-Treiber nicht ohne Kommentar direkt ins System integrieren will. Aber muss es denn gleich kompliziert sein, als Endanwender bewusst an solche ranzukommen? Damals habe ich jedenfalls irgendwann den benötigten NVIDIA-Treiber manuell installiert, weshalb er jetzt auch bei jedem Kernelupgrade manuell neu gebacken werden muss. Ja, bestimmt hätte man es durch Hinzufügen irgendeines speziellen Repos irgendwie auch über die Paketverwaltung und damit “richtig” lösen können. Damals jedenfalls fand ich selbst im Wiki dazu nichts außer dem Hinweis auf die Lizenz und den Treiber von der Homepage.
Okay, mit dem neuen “nouveau”-Treiber könnte sich das erledigen und vielleicht war ich zu blind fürs Wiki, vielleicht teste ich Fedora doch mal. (Fedora gehört somit eigentlich nicht in die Liste, da nicht wirklich am Wochenende getestet.)

Zenwalk: Einer der Exoten, deren Beschreibung in der Wikipedia mir sehr viel versprechend vor kam. Schnell gefundener Haken: 32bit-only. Sorry Zenwalk, aber gemäß einem deiner eigenen Prinzipien, “optimized for specific architectures” wäre die Installation auf einem Core Duo Frevel.
Ich habe es trotzdem mal laufen lassen, um mir die Paketveraltung anzuschauen. Vielleicht finde ich noch eine passende Maschine.

Ender der Aufzählung, was bleibt? Ich schätze nach wie vor an Arch die

  • Aktualität der Pakete
  • KISS-Treue, die man überall spürt
  • Nähe zu den Sourcen, was das selbst-bauen einiger Pakete extrem vereinfacht

und das einzige, was mich derzeit wirklich stört ist das antike, nicht-nebenläufige (aber natürlich KISS-treue) Init-System, was auf meinem Notebook die Bootzeit leider in die Höhe treibt.
Tja Arch, auf die nächsten 20 Monate! :)