Univention Bugzilla – Bug 26192
ext4-Korruption bei Verwendung von sparse-Files, AIO
Last modified: 2012-11-14 12:53:57 CET
Created attachment 4192 [details] vollständiger Screenshot der Session in der Gast-VM Auf xen14 wurde UCS-3.0-0 + UCS-3.0-1 auf amd64 installiert. Anschließend wurde per UVMM eine UCS-3.0-i386-PV-Instanz angelegt und installiert. Nach dem Upgrade der Gast-VM auf UCS-3.0-1 konnte die nicht gestartet werden, weil das InitRamFS defekt war. UVMM bzw. Xen bzw. gzip meldete folgenden Fehler: invalid compressed data--format violated Das konnte Manuell nachvollzogen werden: pygrub ucs24-32-0.raw gzip -dc </var/run/xend/boot/boot_ramdisk.GVOTzO >/dev/null Der Fehler trat wiederholt und immer auf. Ein Wechsel des Host-Kernels von ucs59 auf ucs52 brachte keine Verbesserung. Der Fehler ließ sich auch innerhalb der Gast-VM nachvollzieren: ucr set repository/online/server=apt.knut.univention.de univention-upgrade net ls -l /boot/initrd.img-2.6.32-ucs59-686-bigmem # ? 16804312 md5sum /boot/initrd.img-2.6.32-ucs59-686-bigmem # ? 5cbd5394558fc040e738932... gzip -dc </boot/initrd.img-2.6.32-ucs59-686-bigmem | md5sum - # ? 6424 grep /boot /proc/mounts # ? /dev/xvdb1 umount /boot mount /boot grep /boot /proc/mounts # ? /dev/xvdb1 ls -l /boot/initrd.img-2.6.32-ucs59-686-bigmem # ? 16804312 md5sum /boot/initrd.img-2.6.32-ucs59-686-bigmem # ? 27d4b45b49f8f05febae3da... gzip -dc </boot/initrd.img-2.6.32-ucs59-686-bigmem | md5sum - # ? invalid Erst nach einem cp --sparse=never ucs24-32-1.raw ucs24-32-0.raw & trat der Fehler nicht mehr auf.
Bei mir ist das gerade bei der QA für einen anderen Bug auf xen14 auch aufgetreten. Ich teste das mal auf einem anderen System mit einem ähnlichen Setup.
(In reply to comment #1) > Bei mir ist das gerade bei der QA für einen anderen Bug auf xen14 auch > aufgetreten. Ich teste das mal auf einem anderen System mit einem ähnlichen > Setup. Als ich dasselbe Setup auf xen11 installiert habe (anderes Hardware-Modell) trat der Fehler nicht auf.
Kommando zurück, der Fehler tritt doch auf nach einem Reboot: Folgende Ausgabe erscheint in UVMM, wenn man dann versucht die VM zu starten: Error managing domain '16535ca8-0bf4-7d29-6a68-13f6819b19f4': POST operation failed: xend_post: error from xen daemon: (xend.err 'Boot loader didn't return any data!')
Der Fehler tritt auch mit dem 2.6.32-ucs52 als Host-Kernel auf. Es genügt ein "echo 1 >/proc/sys/vm/drop_caches", um den Fehler zu reproduzieren. Das Spricht dafür, das die Daten nicht auf der Platte landen sondern nur im RAM zwischengespeichert sind. Zum Test wurde das Image vor und nach dem drop_caches aus der VM herauskopiert. Ein "cmp -l -b" hat gezeigt, das ab File-Offset 5024257 bis zum Ende der Datei (16804176) nur noch Nullen statt dem erwarteten Inhalt in der Datei stehen.
Da meine Installation ext4 verwendet: Corruption bei ext4 und Sparse-Files <http://osdir.com/ml/xen-development/2011-07/msg00471.html> <http://patchwork.ozlabs.org/patch/79880/> Nachdem ich das ganze auf ein ext3-Dateisystem rüber kopiert hatte, hat dort alles ohne Probleme funktioniert. (In reply to comment #3 from JMM) > Kommando zurück, der Fehler tritt doch auf nach einem Reboot: > > Folgende Ausgabe erscheint in UVMM, wenn man dann versucht die VM zu starten: > > Error managing domain '16535ca8-0bf4-7d29-6a68-13f6819b19f4': POST operation > failed: xend_post: error from xen daemon: (xend.err 'Boot loader didn't return > any data!') Das ist eine Folge von Bug #25981 und ist unabhängig von dieser ext4-Problematik.
Created attachment 4212 [details] WIP Backport e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d: ext4: serialize unaligned asynchronous DIO In REHL5 wurde der Bug im Mai 2011 korrigiert: <http://rpmfind.net/linux/RPM/centos/updates/5.7/i386/RPMS/kernel-devel-2.6.18-274.12.1.el5.i686.html> <https://bugzilla.redhat.com/show_bug.cgi?id=689830> In 2.6.32 wurde er offiziell bisher nicht korrigiert, aber ich gehe mal stark davon aus, daß das in RHEL6 auch korrigiert wurde; der ist aber nicht einsehbar. Die Xen-Leute haben auch schon um einen Backport gebeten: <http://osdir.com/ml/xen-development/2011-07/msg00474.html> Außerdem könnte noch ein weiteres Patch-Set notwendig werden: <http://thread.gmane.org/gmane.comp.file-systems.ext4/19659> Der Test-Kernel baut noch. Der Patch sollte nach einigen Tests auch an tytso und die ext4-, LK-, Xen-ML gehen, mit dem Ziel, daß der nach Möglichkeit noch in einem 2.6.32-stable-Patch oder wenigstens in Debian aufgenommen wird.
Created attachment 4217 [details] Backport e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d: ext4: serialize unaligned asynchronous DIO Dieser Patch ist ein Backport von e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d aus 2.6.38-rc5 nach 2.6.32-ucs59. <http://news.gmane.org/find-root.php?group=gmane.comp.file-systems.ext4&article=23176> Das beobachtete Problem der Korruption trat damit bei einem einmaligen Test nicht mehr auf. Der Patch wurde an den ursprünglichen Autor Eric Sandeen, Debian-Maintainer Ted Ts'o und linux-ext4 versendet, mit der Bitte um ein Review.
1. Feedback von der ML <http://marc.info/?l=linux-ext4&m=133000393207726&w=2> <https://bugzilla.redhat.com/show_bug.cgi?id=615309> ist der RHEL6 Bug. In XFS gibt es einen ähnlichen Bug: <https://bugzilla.redhat.com/show_bug.cgi?id=669272> Eric hat noch f46c483357c2d87606bbefb511321e3efd4baae0 und f2d28a2ebcb525a6ec7e2152106ddb385ef52b73 zurückportiert. Empfehlung: xfstest ausführen Kernel baut noch auch dimma, Test-Build auf xen14 war erfolgreich.
Folgende xfstests <git://oss.sgi.com/xfs/cmds/xfstests.git> schlagen fehl: 062 Exercises the getfattr/setfattr tools Unkritisch, Ursache sind Änderungen in der Sortier-Reihenfolge der Ausgabe 083 Exercise filesystem full behaviour Unfixed → anderer Bug 225 Run the fiemap (file extent mapping) tester Unkritisch, weil das von ext4 in 2.6.32 noch nicht unterstützt wird. 243 Test to ensure that the EOFBLOCK_FL gets set/unset correctly. Unfixed → anderer Bug Das war mit dem alten ungepatchen Kernel aber auch schon kaputt. Wichtig ist das 240 jetzt nicht mehr anschlägt.
XFS wird erst zu 3.0-2 angegangen → Bug #26255 Ansonsten wurde der Patch eingespielt und der Kernel und die Meta-Pakete für ucs60 neu gebaut. svn10170, linux-2.6.32_2.6.32-41~ucs1.60.201202231541 svn31118, univention-kernel-image-2.6.32_5.0.1-1.56.201202271212 ChangeLog: \item An ext4 file system corruption has been fixed when using asynchronous IO on sparse files (\ucsBug{26192}).
Verified: * Fehler trat nach update auf ucs3.0-1 nicht mehr auf * Changelog OK
UCS 3.0-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"
*** Bug 25102 has been marked as a duplicate of this bug. ***