From: Tony Hoyle <tony@hoyle.me.uk>
To: linux-ext4@vger.kernel.org
Subject: Re: [dm-devel] can't recover ext4 on lvm from ext4_mb_generate_buddy:739: group 1687, 32254 clusters in bitmap, 32258 in gd
Date: Mon, 19 Mar 2012 23:06:50 +0000 [thread overview]
Message-ID: <4F67BC0A.5000706@hoyle.me.uk> (raw)
I looked at the changelogs for 3.2.x and couldn't see anything that
obviously related to this issue - hence posting on this (slightly old)
thread, since I can't find any followup. I've downgraded to 2.6.32
(last debian kernel available, since they don't seem to keep historical
kernels around) for now, which is running solidly.
WIMPy <wimpy <at> yeti.dk> writes:
> written to (extended) while the rsync was running, which seems to be
> a situation, where rsync causes a lot of stress. It certainly takes a
> hell of a lot of time.
I get it when I'm writing large files over nfs - exactly the same
symptoms as mentioned elsewhere in the thread, followed by nfsd going
into D state and things generally going downhill from there.
Started when I upgraded to 3.1.0 and continued up to 3.2.0. fsck shows
no errors on the disk, but the logs fill up with
ext4_mb_generate_buddy:739 errors anyway.
> And a short repeat: I'm using an md, but no lvm.
>
Same setup here - md, but no lvm. Another non-raid drive doesn't show
the same symptoms, if it's any help.
Tony
nb: Some logs, FWIW. As mentioned above, fsck says there are no errors
on the drive:
Mar 19 20:50:52 goliath kernel: [ 1721.686880] EXT4-fs error (device
md0): ext4_mb_generate_buddy:739: group 21345, 32254 clusters in bitmap,
32258 in gd
Mar 19 20:50:52 goliath kernel: [ 1721.703397] JBD2: Spotted dirty
metadata buffer (dev = md0, blocknr = 0). There's a risk of filesystem
corruption in case of system crash.
Mar 19 20:51:38 goliath kernel: [ 1767.622399] EXT4-fs error (device
md0): ext4_mb_generate_buddy:739: group 21346, 32254 clusters in bitmap,
32258 in gd
Mar 19 20:52:18 goliath kernel: [ 1808.268856] EXT4-fs error (device
md0): ext4_mb_generate_buddy:739: group 21347, 32254 clusters in bitmap,
32258 in gd
Mar 19 20:53:29 goliath kernel: [ 1879.257332] EXT4-fs error (device
md0): ext4_mb_generate_buddy:739: group 21348, 32254 clusters in bitmap,
32258 in gd
Mar 19 20:54:45 goliath kernel: [ 1955.083019] EXT4-fs error (device
md0): ext4_mb_generate_buddy:739: group 21349, 32254 clusters in bitmap,
32258 in gd
..etc. They don't vary much. A few thousand of these in rapid succession.
next reply other threads:[~2012-03-19 23:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 23:06 Tony Hoyle [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-01-05 10:37 can't recover ext4 on lvm from ext4_mb_generate_buddy:739: group 1687, 32254 clusters in bitmap, 32258 in gd Sander Eikelenboom
2012-01-05 13:21 ` Sander Eikelenboom
2012-01-05 14:45 ` Theodore Tso
[not found] ` <4910694144.20120105171428@eikelenboom.it>
2012-01-05 18:15 ` Ted Ts'o
2012-01-06 16:40 ` [dm-devel] " Mikulas Patocka
2012-01-28 4:53 ` WIMPy
2012-01-28 8:14 ` WIMPy
2012-01-28 8:34 ` Andreas Dilger
2012-01-28 15:31 ` WIMPy
2012-01-28 21:04 ` WIMPy
2012-02-03 5:30 ` WIMPy
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=4F67BC0A.5000706@hoyle.me.uk \
--to=tony@hoyle.me.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).