linux-ext4 - Re: ext4 metadata corruption bug?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 20 Apr 2014 12:32:12 -0400
From:	Nathaniel W Filardo <nwf@...jhu.edu>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	Mike Rubin <mrubin@...gle.com>, Frank Mayhar <fmayhar@...gle.com>,
	admins@....jhu.edu, linux-ext4@...r.kernel.org
Subject: Re: ext4 metadata corruption bug?

We just got

> [817576.492013] EXT4-fs (vdd): pa ffff88000dea9b90: logic 0, phys.  1934464544, len 32
> [817576.492468] EXT4-fs error (device vdd): ext4_mb_release_inode_pa:3729: group 59035, free 14, pa_free 12
> [817576.492987] Aborting journal on device vdd-8.
> [817576.493919] EXT4-fs (vdd): Remounting filesystem read-only

Upon unmount, further

> [825457.072206] EXT4-fs error (device vdd): ext4_put_super:791: Couldn't clean up the journal

fscking generated

> fsck from util-linux 2.20.1
> e2fsck 1.42.9 (4-Feb-2014)
> /dev/vdd: recovering journal
> /dev/vdd contains a file system with errors, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> Block bitmap differences:  +(1934464544--1934464545)
> Fix<y>? yes
> Free blocks count wrong (1379876836, counted=1386563079).
> Fix<y>? yes
> Free inodes count wrong (331897442, counted=331912336).
> Fix<y>? yes
>
> /dev/vdd: ***** FILE SYSTEM WAS MODIFIED *****
> /dev/vdd: 3631984/335544320 files (1.6% non-contiguous), 1297791481/2684354560 blocks

The particular error reported by the kernel seems to be the first of the
three, but the other two look like leaks?  A huge number of inodes (14894)
and blocks (6686243, or 3.2Gi of storage!) were marked busy in a way that
fsck didn't believe, if I am reading that right?

/dev/vdd is virtio on Ceph RBD, using write-through caching.  We have had a
crash on one of the Ceph OSDs recently in a way that seems to have generated
inconsistent data in Ceph, but subsequent repair commands seem to have made
everything happy again, at least so far as Ceph tells us.

The guest `uname -a` sayeth

> Linux afsscratch-kvm 3.13-1-amd64 #1 SMP Debian 3.13.7-1 (2014-03-25) x86_64 GNU/Linux

And in case it's relevant, host QEMU emulator is version 1.7.0 (Debian
1.7.0+dfsg-3) [modified locally to include rbd]; guest ceph, librbd, etc.
are Debian package 0.72.2-1~bpo70+1 .

Cheers,
--nwf;

Content of type "application/pgp-signature" skipped