EXT4-fs error

UCS - Univention Corporate Server
#1

Hallo Forum,

seit mindestens Ende Juni (länger reicht das Kern.log nicht zurück) haben wir bei einer UCS4-Instanz, welche mittels KVM/libirt als Gast auf einem Debian Wheezy Host läuft, immer mal wieder EXT4 Fehler:

Zuerst waren wir auf UCS 4.0.1 wobei es nur die Daten-Partition (Mount auf /srv) betraf, einige Auszüge:

Jun 28 11:15:34 bigpapa kernel: [4394357.724033] EXT4-fs (dm-2): error count since last fsck: 1 Jun 28 11:15:34 bigpapa kernel: [4394357.724040] EXT4-fs (dm-2): initial error at time 1433147258: ext4_mb_generate_buddy:757 Jun 28 11:15:34 bigpapa kernel: [4394357.724043] EXT4-fs (dm-2): last error at time 1433147258: ext4_mb_generate_buddy:757 Jun 29 11:17:21 bigpapa kernel: [4480865.244033] EXT4-fs (dm-2): error count since last fsck: 1 Jun 29 11:17:21 bigpapa kernel: [4480865.244064] EXT4-fs (dm-2): initial error at time 1433147258: ext4_mb_generate_buddy:757 Jun 29 11:17:21 bigpapa kernel: [4480865.244067] EXT4-fs (dm-2): last error at time 1433147258: ext4_mb_generate_buddy:757 Jun 30 11:19:09 bigpapa kernel: [4567372.764124] EXT4-fs (dm-2): error count since last fsck: 1 Jun 30 11:19:09 bigpapa kernel: [4567372.764158] EXT4-fs (dm-2): initial error at time 1433147258: ext4_mb_generate_buddy:757 Jun 30 11:19:09 bigpapa kernel: [4567372.764161] EXT4-fs (dm-2): last error at time 1433147258: ext4_mb_generate_buddy:757

später kam dann auch die VAR-Part. (dm-1) dazu

Oct 2 09:20:06 bigpapa kernel: [7752946.652045] EXT4-fs (dm-1): error count since last fsck: 4 Oct 2 09:20:06 bigpapa kernel: [7752946.652079] EXT4-fs (dm-1): initial error at time 1441953680: ext4_mb_release_inode_pa:3773 Oct 2 09:20:06 bigpapa kernel: [7752946.652082] EXT4-fs (dm-1): last error at time 1443327929: ext4_mb_generate_buddy:757 Oct 2 17:42:32 bigpapa kernel: [7783093.212034] EXT4-fs (dm-2): error count since last fsck: 5 Oct 2 17:42:32 bigpapa kernel: [7783093.212042] EXT4-fs (dm-2): initial error at time 1438956079: ext4_mb_generate_buddy:757 Oct 2 17:42:32 bigpapa kernel: [7783093.212045] EXT4-fs (dm-2): last error at time 1442906245: ext4_mb_generate_buddy:757

Als wir am 2.10. auf 4.0.3 (In Stufen zuerst auf 4.0.2) aktualisiert haben, wurde auch rebootet, wobei auch schon Root-FS (vda1) erstmals anschlug mit:

Oct 2 21:05:02 bigpapa kernel: [ 8.053245] EXT4-fs (vda1): INFO: recovery required on readonly filesystem Oct 2 21:05:02 bigpapa kernel: [ 8.053252] EXT4-fs (vda1): write access will be enabled during recovery Oct 2 21:05:02 bigpapa kernel: [ 8.060703] EXT4-fs (vda1): recovery complete Oct 2 21:05:02 bigpapa kernel: [ 8.061544] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: (null) Oct 2 21:05:02 bigpapa kernel: [ 11.024710] EXT4-fs (vda1): re-mounted. Opts: (null) Oct 2 21:05:02 bigpapa kernel: [ 11.241866] EXT4-fs (vda1): re-mounted. Opts: errors=remount-ro,user_xattr

Nachdem EXT4 auf /dev/dm-2 sich ansch. nicht selbst recovered hat

root@bigpapa ~ # tune2fs -l /dev/dm-2 | grep state Filesystem state: clean with errors

haben wir in dem Zuge das FS der Daten-Partition (nach Stop relevanter Services wie Samba, mysql, Zarafa, …) ausgehängt und mit ‘fsck’ erfolgreich repariert.

Am 8.10. gab es dann einen Notfall, als nach einem weiteren EXT4 error das Root FS auf readonly ging und dann klarerweise bald gröbere Störungen hervor rief (U.a. Zarafa konnet nicht mehr auf /tmp schreiben und warf endlos Fehler):

Oct 8 11:23:15 bigpapa kernel: [472597.802665] EXT4-fs error (device vda1): __ext4_new_inode:1010: comm zsh: failed to insert inode 130358: doubly allocated? Oct 8 11:23:15 bigpapa kernel: [472597.812738] EXT4-fs (vda1): Remounting filesystem read-only Oct 8 11:23:15 bigpapa kernel: [472597.812768] EXT4-fs error (device vda1) in ext4_symlink:2952: IO failure Oct 8 12:51:29 bigpapa kernel: [ 8.177084] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: (null) Oct 8 12:51:29 bigpapa kernel: [ 11.987099] EXT4-fs (vda1): re-mounted. Opts: (null) Oct 8 12:51:29 bigpapa kernel: [ 12.324816] EXT4-fs (vda1): re-mounted. Opts: errors=remount-ro,user_xattr Oct 8 12:51:29 bigpapa kernel: [ 16.111844] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: user_xattr Oct 8 12:51:29 bigpapa kernel: [ 16.114472] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: user_xattr

Automatisches recovery beim Reboot der UCS VM war ansch. nicht möglich, wir haben dann die Root Part. manuell via Debian-Host-System eingebunden und mit ‘fsck’ erfolgreich repariert, wie oben beim Boot um 12:51 zu sehen, waren die FS dann wieder OK.

Nach etwas Recherche dachte ich, dass ev. diese EXT4-Kernel-Probleme im älteren UCS Kernel (Maschine wurde erst mit 4.0.1 im Frühjahr 2015 installiert) ursächlich seien, doch nun habe ich nach einigen Wochen Ruhe wieder Fehler auf der Daten-Partition:

root@bigpapa ~ # zless ~log/kern.log.1 | grep EXT Oct 20 16:15:52 bigpapa kernel: [1049090.658387] EXT4-fs error (device dm-2): ext4_mb_generate_buddy:757: group 1100, block bitmap and bg descriptor inconsistent: 4578 vs 4575 free clusters root@bigpapa ~ # zless ~log/kern.log | grep EXT Oct 21 16:18:27 bigpapa kernel: [1135645.660031] EXT4-fs (dm-2): error count since last fsck: 1 Oct 21 16:18:27 bigpapa kernel: [1135645.660075] EXT4-fs (dm-2): initial error at time 1445350552: ext4_mb_generate_buddy:757 Oct 21 16:18:27 bigpapa kernel: [1135645.660079] EXT4-fs (dm-2): last error at time 1445350552: ext4_mb_generate_buddy:757

Aktuell sind wir am letzten Patch-Level 4.0-3 errata342 und haben Kernel:

root@bigpapa ~ # uname -a Linux bigpapa 3.16.0-ucs135-amd64 #1 SMP Debian 3.16.7-ckt11-1~bpo70+1.135.201507161851 (2015-07-1 x86_64 GNU/Linux

Zum Host-System & Storage-Backend:

Alle Partitionen der UCS VM liegen dort auf drbd-Devices, wobei dm-1 & dm-2 innerhalb der UCS VM in einer LVM-Gruppe liegen:

root@bigpapa ~ # lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert bigpapa-data-SRV vg-bigpapa-data -wi-ao-- 381,36g bigpapa-data-SWAP vg-bigpapa-data -wi-ao-- 4,66g bigpapa-data-VAR vg-bigpapa-data -wi-ao-- 13,97g

KVM disk config:

[code] 28     <disk type='block' device='disk'>
 29       <driver name='qemu' type='raw'/>
 30       <source dev='/dev/drbd2'/>
 31       <target dev='vda' bus='virtio'/>
 32       <boot order='1'/>
 33       <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
 34     </disk>
 35     <disk type='block' device='disk'>
 36       <driver name='qemu' type='raw'/>
 37       <source dev='/dev/drbd3'/>
 38       <target dev='vdb' bus='virtio'/>
 39       <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
 40     </disk>

[/code]

Logs auf Hostnode sind sauber, keine Anzeichen eines Problems (drbd o.ä.) außerdem laufen auf dem DRBD-Cluster noch andere VMs seit langem ohne Probleme.

Danke für jeden Hinweis,
VG Robert

#2

Hallo,

Es sieht so aus, als sei dies ein sehr spezifisches Problem, das man schon mehrere Male behoben geglaubt hat. In einem ganz aktuellen Bug wird momentan noch geforscht, die Randbedingungen scheinen etwa die gleichen zu sein: KVM Host, Gast mit Linux Kernel 3.16.x, dm Geräte und darauf ext4, und relativ große Partitions.

In einem Beitrag glaubt man beobachtet zu haben, daß Maschinen mit wenig Speicher (1G) anfälliger seien – wenn die Maschine Samba und Zarafa trägt, hat sie wahrscheinlich schon wesentlich mehr?

Nach dem Lesen des obengenannten Bugs würde ich wahrscheinlich momentan in dieser Konstellation ext4 Dateisysteme ganz und gar vermeiden, und statt dessen XFS verwenden. Keine triviale Aufgabe, wenn es auch das Root-Filesystem betrifft und es sich außerdem um eine Produktivmaschine handelt. Wahrscheinlich würde ich mit der VAR Partition anfangen um zu sehen, ob es was bringt.

viele Grüße
Frank Greif.

#3

Vorerst Danke für Ihre Hinweise Herr Greif!

Scheint in die richtige oder ähnliche Richtung zu gehen. Nicht übereinstimmend ist, dass meine Root-Part. keinen device-manager verwendet, hier wird einfach “direkt” das drbd device vom Host als kvm/qemu raw device eingebunden und unter der drbd-Schicht liegt in dem Fall direkt das HW-RAID der Host-Maschine. Aber diese root-Part. ist bis jetzt auch nur einmal und mit anderem als im Bug erwähnten Fehler raus geflogen (’__ext4_new_inode:1010’ anstatt ‘ext4_mb_generate_buddy’). Bei den Fehlern auf meinen anderen dm Part. sind die FS auch nie read-only gegangen.

Ja, aktuell hat die VM 12GB RAM, und diese sind bei weitem nicht ausgelastet.

[quote=“greif”]
Nach dem Lesen des obengenannten Bugs würde ich wahrscheinlich momentan in dieser Konstellation ext4 Dateisysteme ganz und gar vermeiden, und statt dessen XFS verwenden. Keine triviale Aufgabe, wenn es auch das Root-Filesystem betrifft und es sich außerdem um eine Produktivmaschine handelt. Wahrscheinlich würde ich mit der VAR Partition anfangen um zu sehen, ob es was bringt.[/quote]

Naja, wie sie schon sagen ist so ein FS Wechsel 1) nicht so leicht gemacht 2) hat mMn auch XFS seine Nachteile bzw. keiner weiß, ob die Probleme dadurch weg sind bzw. nicht neue entstehen.
Aktuell tendiere ich mit dem jetzigen Infos und dem seltenen Auftreten dazu, den Fehler aus zu sitzen bzw. so bald als möglich auf neuere Kernel in UCS VM (v4.1 soll ja heuer noch kommen) bzw. am Host (Upgrade auf Debian Jessy ev. Backport Kernel) zu wechseln. Laut dem verlinkten Kernel-Bug ist es noch nicht klar, wie es sich dort mit neuen Kerneln verhält.
Interessant ist nur, dass das Problem ansch. selten auftritt, so ich glaube, dass mein Setup (drbd -> kvm/qemu -> (lvm) -> ext4) nicht so unüblich wäre.

Ich werde weiter berichten :wink:

VG
Robert

Mastodon