From: Sander Smeenk <ssmeenk@freshdot.net>
To: linux-ext4@vger.kernel.org
Subject: Re: ext4 metadata corruption bug?
Date: Wed, 23 Apr 2014 09:23:11 +0200 [thread overview]
Message-ID: <20140423072311.GD10163@dot.freshdot.net> (raw)
In-Reply-To: <20140420163211.GT10985@gradx.cs.jhu.edu>
On Sun, Apr 20, 2014 at 12:32:12PM -0400, Nathaniel W Filardo wrote:
> 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
I'm jumping in on this thread as a co-worker pointed me to it after i
reported somewhere else about a similar ext4 metadata corruption issue
i'm running into.
Quite similar situation to the OP in this thread:
Linux QEMU 2.0.0~rc1+dfsg-0ubuntu3 running on 3.13.0, guest and host
both run Linux 3.13.0, guest has one 'big' volume (10T, 5.5T in use) as
/dev/vdb which in it's entirety is used as an ext4 filesystem. No
partitioning.
The trouble starts with:
| EXT4-fs (vdb): pa ffff880078754c30: logic 274378, phys. 1617823779, len 54
| EXT4-fs error (device vdb): ext4_mb_release_inode_pa:3729: group 49372, free 52, pa_free 50
| Aborting journal on device vdb-8.
After which the system remounts the disk read-only and logs some more
ext4 trouble which i've pasted here: https://8n1.org/9763/4928
The system doesn't crash as this isn't the "OS disk". Running fsck on
the disk reports bitmap corruption and some incorrect free block/inode
counts after which the FS seems to work again.
It only happens to the guest with the large disk. All the other guests
on the same hypervisor and the same backend storage have no issues at
all. No IO errors are logged other than the ext4 errors from the guest.
The workload on this guest is not at all spectacular. A bit of random IO
on a set of files, the rest is mostly archive and rarely touched.
HTH,
-Sander.
--
| You dig around for a while but you fail to find any treasure.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2
next prev parent reply other threads:[~2014-04-23 7:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140409223820.GU10985@gradx.cs.jhu.edu>
[not found] ` <CAGagf4eEzY4+3cfNWSEENTo1PKe40nq1Ne6ZzOLGm-O78W7RcA@mail.gmail.com>
2014-04-10 5:04 ` ext4 metadata corruption bug? Nathaniel W Filardo
2014-04-10 14:03 ` Theodore Ts'o
2014-04-10 16:33 ` Nathaniel W Filardo
2014-04-10 22:17 ` Theodore Ts'o
2014-04-20 16:32 ` Nathaniel W Filardo
2014-04-20 17:57 ` Theodore Ts'o
2014-04-23 7:23 ` Sander Smeenk [this message]
2014-04-23 14:36 ` Theodore Ts'o
2014-04-23 15:30 ` Nathaniel W Filardo
2014-04-23 18:05 ` Sander Smeenk
2014-04-29 15:22 ` Nathaniel W Filardo
2014-05-01 16:25 ` Nathaniel W Filardo
2014-05-06 15:42 ` Theodore Ts'o
2014-05-06 15:51 ` Nathaniel W Filardo
2014-07-31 2:37 ` Theodore Ts'o
2014-08-06 8:53 ` Sander Smeenk
2014-05-01 17:02 ` Sander Smeenk
2014-05-06 14:22 ` Sander Smeenk
2014-05-26 14:59 ` Sander Smeenk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140423072311.GD10163@dot.freshdot.net \
--to=ssmeenk@freshdot.net \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.