zurück zum Artikel

Kernel-Log: Beutelteufel vorübergehend Linux-Maskottchen, Ext4-Problem erhitzt die Gemüter

| Thorsten Leemhuis

Tuz, ein Tasmanischer Teufel, übernimmt vorübergehend die Rolle von Tux; weitere Details zum Ext4-Problem; neuer Radeon-Grafiktreiber nutzt etwa Hardware-Beschleunigung und bietet rudimentäre DisplayPort-Unterstützung.

Mit einem gestern Abend vorgenommenen Commit [1] im Hauptentwicklungszweig [2] hat Linus Torvalds das Linux-Maskottchen [3] ins dreimonatige Sabbatical entlassen [4]. Bei der Linux-Version 2.6.29 wird Linux statt dessen von Tuz repräsentiert, der Darstellung des gemeinhin als Tasmanischer Teufel bekannten Beutelteufels [5], der eine aufgesetzte gelbe Nase trägt, die an die Nase des Linux-Pinguins erinnert.

Tuz hatte bereits der dieses Jahr in Hobart auf Tasmanien abgehaltenen Linux-Konferenz linux.conf.au [6] (LCA) als Maskottchen gedient. Der vorübergehende Austausch des Linux-Maskottchens soll Aufmerksamkeit auf den ausschließlich auf Tasmanien lebenden Beutelteufel lenken, dessen Fortbestand durch die noch recht junge "Devil Facial Tumour Disease [7]" (kurz DFTD; deutsch etwa Beutelteufeltypische Gesichtskrebserkrankung) bedrohten ist. Torvalds verweist dazu auf die Webseite tassiedevil.com.au [8], die weitere Hintergründe zu der im Rahmen einer Spendenauktion entstanden Aktion auf ihrer Webseite [9] erläutert. (thl [10]/heise open)

Am gestrigen Dienstag hat Greg Kroah-Hartman die Stable-Kernel 2.6.27.20 [11] und 2.6.28.8 [12] freigegeben. Beide enthalten jeweils um die hundert kleine Korrekturen und Erweiterungen. In der Freigabe-Mail zur neuen 2.6.28-Variante rät Kroah-Hartman allen Anwendern von selbstkompilierten Kerneln nachdrücklich zum Update auf die neue Version; wie so häufig geht aus der Freigabe-Mail aber nicht hervor, ob Sicherheitslücken oder andere schwerwiegende Fehler beseitigt wurden.

Die 2.6.29-Entwicklung ist derweil beim rc8 angelangt. Torvalds deutete bei dessen Freigabe [13] am vergangenen Freitag an, dass dies der letzte RC von 2.6.29 sein könnte, da sich der Hauptentwicklungszweig [14] des Kernels stabilisiere; ganz ausschließen will er weitere Vorabversionen aber nicht ("[...]it seems to be stabilizing to the point where I'm hoping that we're approaching a final 2.6.29, and this might be the last -rc. We'll have to see."). Angesichts der Zahl und des Umfangs der in den vergangenen Tagen aufgenommenen Änderungen scheint eine weitere Vorabversion wahrscheinlicher zu werden. Unter den Änderungen in letzter Minute befinden sich neben Tuz auch noch zwei neue Netzwerktreiber: be2net [15] steuert die 10-GB-LAN-Chips BladeEngine 2 von ServerEngines an, dnet [16] den auf dem Dave/DENX QongEVB-LITE FPGA integrierten Dave DNET Ethernet Controller.

Kurz nachdem das Kernel-Log im Rahmen der "Was 2.6.29 bringt"-Mini-Serie die teilweise umfangreichen Änderungen [17] am alten IDE-Subsystem ansprach, hat dessen Verwalter seine Beweggründe und seine weiteren Planungen für die Zukunft in einer Mail an die LKML [18] näher erläutert. Weitere radikale Änderungen an sind demnach nicht zu erwarten; er plant das IDE-Subsystem jedoch weiter aktiv zu pflegen, bis es eine bessere Lösung ersetzen kann ("The subsystem is in good shape now so I think that no more radical changes like the ones that happened recently will be needed. We will just concentrate on keeping things working till better solutions take over.". (thl [19]/heise open)

Datenverlust unter Ext4, Grafik, Kernel-Log-Staccato

Kernel-Log-Logo

Datenverlust unter Ext4

Vergangene Woche sorgte eine Meldung über mögliche Datenverluste mit Ext4 [20] für Aufregung und hitzige Diskussionen: Ein Anwender verlor bei einem Systemcrash [21] unmittelbar nach dem Start von KDE 4 auf einer Alpha-Version von Ubuntu 9.04 mit Ext4 eine Menge Daten – nach dem Reboot hatten fast alle Dateien, die während des letzten Starts geschrieben worden waren, eine Größe von 0 Byte und waren leer. Mit Ext3 sei ihm so etwas nie passiert, beklagte er.

Was war passiert? Wenn Anwendungen eine bestehende Datei mit neuen oder geänderten Daten überschreiben wollen (etwa eine Konfigurationsdatei, nachdem der User eine Einstellung geändert hat), legen sie für die neuen Daten häufig zunächst eine temporäre Datei an und benennen die anschließend mit dem Systemcall rename() um. Die Logik dahinter: Wenn beim Schreiben etwas schief geht, etwa der Rechner abstürzt oder der Strom ausfällt, bleibt zumindest die alte Version der Datei erhalten.

Dabei passieren zwei Dinge. Zum einen ändern sich Metadaten im Dateisystem: Für die neue Datei wird ein Inode angelegt, der die Daten referenziert, und ein neuer Verzeichniseintrag erzeugt, der auf den neuen Inode zeigt; beim rename() wird der Verzeichniseintrag der alten Datei dann so geändert, dass er auf den neuen Inode zeigt. Zum andern werden die Daten selbst geschrieben: Dazu muss das Dateisystem zunächst ausreichend viele Datenblöcke auf der Platte allozieren und dann die Daten in diese Blöcke schreiben.

Ext3 wie Ext4 schreiben alle Änderungen an den Metadaten zunächst in ihr Journal; auch nach dem rename() hat sich daher im Dateisystem selbst zunächst nichts geändert. Wenn jetzt der Strom ausfällt, existiert die neue Datei im Dateisystem noch nicht: Der Verzeichniseintrag der alten Datei zeigt auf den alten Inode und damit auf die alten Daten, die geänderten Metadaten im Journal sind noch nicht gültig. Dazu ist nämlich noch ein "Commit" der Änderungen im Journal nötig – erst dann überträgt das Dateisystem nach einiger Zeit (oder beim nächsten Reboot nach einem Crash) die geänderten Metadaten ins Dateisystem.

Dabei gibt es jedoch einen entscheidenden Unterschied zwischen Ext3 und Ext4. Ext3 (mit der Standard-Mount-Option "data=ordered") führt mit den Commit der Metadaten im Journal erst aus, wenn die Daten der neuen Datei tatsächlich auf die Platte geschrieben sind (was bis zu fünf Sekunden dauern kann, während denen die Daten noch im Cache zwischengespeichert sind). Das soll verhindern, dass nach einem Systemcrash in einer neu angelegten Datei alte Daten auftauchen, wenn die allozierten Datenblöcke zuvor von einer inzwischen gelöschten Datei belegt waren und noch nicht mit den neuen Daten beschrieben sind. Die Datei enthält nach einem Systemabsturz also entweder die alten oder die neuen Daten – je nachdem, ob der Crash vor oder nach dem Commit erfolgt.

Ext4 hingegen führt einen weiteren Mechanismus ein: delayed block allocation. Es kann nach dem Schließen einer Datei bis zu einer Minute dauern, bis tatsächlich Datenblöcke auf der Platte alloziert werden. Die delayed block allocation erlaubt dem Dateisystem eine bessere Optimierung von Schreibprozessen – allerdings um den Preis, dass die Metadaten einer neu angelegten Datei bis zu der verzögerten Allozierung eine Größe von 0 Byte und keine belegten Datenblöcke ausweisen. Wenn das System in dieser Zeitspanne abstürzt, kann die rename()-Operation im Journal bereits committed sein, obwohl die neue Datei noch keine Daten enthält. Ergebnis: Nach einem Crash ist die Datei leer, alte und neue Daten sind verloren.

Ext4-Entwickler Ted Ts'o betont in seiner Antwort auf den Bug-Report [22], dass sich Ext4 genau so verhält, wie es der POSIX-Standard für Dateioperationen fordert. Zudem zeigen andere Dateisysteme wie XFS das gleiche Verhalten; das "sicherere" Verhalten von Ext3 ist lediglich ein unbeabsichtigter Nebeneffekt. Das Problem sind für Ts'o die Anwendungsentwickler, die das gutmütige Verhalten von Ext3 als Standard nehmen. Sein Rat: Wenn eine Anwendung sicher sein will, dass Daten tatsächlich auf Platte geschrieben werden, muss sie vor dem Schließen der Datei die Funktion fsync() [23] aufrufen.

Trotzdem hat er als Workaround sehr schnell Patches für Ext4 geschrieben, die die rename()-Situation (und eine zweite Vorgehensweise, bei der mit ftruncate() gearbeitet wird) erkennen und dort für ein Verhalten wie bei Ext3 sorgen. Mittlerweile hat Ted Ts'o aber auch für eine "richtige" Lösung gesorgt: Die neue Ext4-Mount-Option "alloc_on_commit" [24] führt für Ext4 ein Analog zu "data=ordered" ein – Metadaten im Journal werden erst committed, nachdem die Blöcke alloziert und die Daten geschrieben sind. Die Änderung dürfte allerdings frühestens mit dem Kernel 2.6.30 kommen. (odi [25]/heise open)

AMD-Mitarbeiter Alex Deucher hat die Version 6.12.0 der kurz meist "ati" genannten Treiberpakets xf86-video-ati freigegeben [26]. Der dort enthaltene Treiber "radeon [27]" soll zusammen mit einem aktuellem DRM (Direct Rendering Manager) nun die Beschleunigungstechniken EXA und Xv (Xvideo) bei den R6xx- und R7xx-GPUs unterstützen, die auf Radeon-Grafikhardware der Serien 2000, 3000 und 4000 arbeiten. Laut der Freigabe-Mail soll der Treiber nun zudem das Drehen des Bildes auf eben diesen GPUs beherrschen sowie die Ausgabe über Display-Port ermöglichen; laut den Informationen im X.org-Wiki [28] geht das allerdings nur mit neueren Radeon-GPUs und nicht mit allen DP-Wiedergabegeräten.

Die Entwickler des Intel-Grafiktreibers arbeiten derweil auf den nächsten größeren Meilenstein hin und haben die ersten beiden Vorabversion der Treiber-Serie 2.7 veröffentlicht (1 [29], 2 [30]). Fedora-Entwickler Will Woods erläutert derweil in seinem Blog [31], warum glxgears seiner Meinung nach kein guter Benchmark ist –Tester von Fedora-11-Vorabversionen hatte zuvor größere Einbrüche bei den Bildraten durch KMS und DRI2 ausgemacht. (thl [32]/heise open)

Kernel-Log-Staccato

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich auch in den vorangegangen Ausgaben des Kernel-Logs [37] auf heise open:

Ältere Kernel-Logs [47] finden sich über das Archiv [48] oder die Suchfunktion [49] von heise open [50]. (thl [51]/heise open) (thl [52])

URL dieses Artikels:
https://www.heise.de/-221762

Links in diesem Artikel:
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8032b526d1a3bd91ad633dd3a3b5fdbc47ad54f1
[2] http://www.heise.de/glossar/entry/Hauptentwicklungslinie-397933.html
[3] http://de.wikipedia.org/wiki/Tux_(Maskottchen)
[4] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/logo.txt;h=a2e62445e28ee523c02f5f93f80c06a431e369e3
[5] http://de.wikipedia.org/wiki/Beutelteufel
[6] http://linux.conf.au/
[7] http://de.wikipedia.org/wiki/Beutelteufel#Die_Bedrohung_durch_DFTD
[8] http://tassiedevil.com.au
[9] http://tassiedevil.com.au/supporters.html
[10] mailto:thl@heiseopen.de
[11] http://thread.gmane.org/gmane.linux.kernel/808157
[12] http://thread.gmane.org/gmane.linux.kernel/808156
[13] http://thread.gmane.org/gmane.linux.kernel/806262
[14] http://www.heise.de/glossar/entry/Hauptentwicklungslinie-397933.html
[15] http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6b7c5b947c671a96e39f9526a5fd70c178b8dfd1
[16] http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4796417417a62e2ae83d92cb92e1ecf9ec67b5f5
[17] https://www.heise.de/hintergrund/Kernel-Log-Was-2-6-29-bringt-4-Dateisysteme-Storage-Btrfs-SquashFS-Ext4-ohne-Journal-und-neue-Storage-Treiber-221743.html
[18] http://thread.gmane.org/gmane.linux.ide/39009
[19] mailto:thl@heiseopen.de
[20] https://www.heise.de/news/Moeglicher-Datenverlust-bei-Ext4-205664.html
[21] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781
[22] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45
[23] http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
[24] http://thread.gmane.org/gmane.comp.file-systems.ext4/12179
[25] mailto:odi@heiseopen.de
[26] http://thread.gmane.org/gmane.comp.freedesktop.xorg.announce/583
[27] http://wiki.x.org/wiki/radeon
[28] http://www.x.org/wiki/DisplayPort
[29] http://thread.gmane.org/gmane.comp.freedesktop.xorg.announce/581
[30] http://thread.gmane.org/gmane.comp.freedesktop.xorg.announce/582
[31] http://qa-rockstar.livejournal.com/7869.html
[32] mailto:thl@heiseopen.de
[33] http://linuxdevices.com/articles/AT9599126972.html
[34] http://thread.gmane.org/gmane.linux.kernel/805382/
[35] http://www.heise.de/glossar/entry/Hauptentwicklungslinie-397933.html
[36] http://thread.gmane.org/gmane.linux.kernel/805382/focus=767
[37] http://www.heise.de/glossar/entry/Kernel-Log-397909.html
[38] https://www.heise.de/hintergrund/Kernel-Log-Was-2-6-29-bringt-6-Schneller-starten-und-andere-aenderungen-unter-der-Haube-221752.html
[39] https://www.heise.de/hintergrund/Kernel-Log-Was-2-6-29-bringt-5-Audio-FireWire-USB-Video-Audio-via-HDMI-FireWire-TV-und-neue-Staging-Treiber-221748.html
[40] https://www.heise.de/hintergrund/Kernel-Log-Was-2-6-29-bringt-4-Dateisysteme-Storage-Btrfs-SquashFS-Ext4-ohne-Journal-und-neue-Storage-Treiber-221743.html
[41] https://www.heise.de/hintergrund/Kernel-Log-Morton-stellt-Aufnahme-des-Xen-Dom0-Codes-in-Frage-Dateisysteme-fuer-SSDs-221740.html
[42] https://www.heise.de/hintergrund/Kernel-Log-Entwicklungstempo-der-Stable-Series-steigt-X-Server-1-6-in-Kuerze-221717.html
[43] https://www.heise.de/hintergrund/Kernel-Log-Was-2-6-29-bringt-3-ACPI-PCI-PM-und-Co-Verbesserungen-fuer-Notebooks-und-Stromspartechniken-221691.html
[44] https://www.heise.de/hintergrund/Kernel-Log-Neue-Stable-Kernel-AMD-3D-Dokumentation-und-Mesa-7-3-freigegeben-221684.html
[45] https://www.heise.de/hintergrund/Kernel-Log-Was-2-6-29-bringt-2-Grafik-Kernel-verwaltet-Bildschirmaufloesung-221672.html
[46] https://www.heise.de/hintergrund/Kernel-Log-Heisse-Entwicklungsphase-von-2-6-29-beendet-neue-X-org-Treiber-221664.html
[47] http://www.heise.de/glossar/entry/Kernel-Log-397909.html
[48] http://www.heise.de/open/news/archiv/
[49] http://www.heise.de/open/suche?sort=d;rm=search;q=Kernel-Log;channel=open
[50] http://www.heise.de/open/
[51] mailto:thl@heiseopen.de
[52] mailto:thl@ct.de

Copyright © 2009 Heise Medien