On Wed, 2008-03-26 at 16:41 -0500, Eric Sandeen wrote:
> This report just came in on the fedora list...
>
> EXT4-fs error (device dm-0): ext4_mb_generate_buddy: EXT4-fs: group 717:
> 23410 blocks in bitmap, 23411 in gd
>
> EXT4-fs error (device dm-0): ext4_mb_generate_buddy: EXT4-fs: group 721:
> 19309 blocks in bitmap, 19333 in gd
>
> has anyone else seen this problem in testing? I guess it means
> freespace accounting got out of sync...?
>
No, I haven't seen this before. The related code is
ext4_mb_generate_buddy(..)
{
....
if (free != grp->bb_free) {
ext4_error(sb, __func__,
"EXT4-fs: group %lu: %u blocks in bitmap, %u in gd\n",
group, free, grp->bb_free);
/*
* If we intent to continue, we consider group descritor
* corrupt and update bb_free using bitmap value
*/
grp->bb_free = free;
}
}
I guess the free blocks counter in in-memory group descriptor is not
sync with the on-disk bitmap. Looks like mballoc introduced in-core
block group descriptor(struct ext4_group_info) and keep track of free
blocks counter in the in-core block group
descriptor(ext4_group_info.bb_free), while the non-mballoc allocation
accounting is done via the on-disk block group descriptor, which is
likely, the metadata block(s) (e.g index extent block, xattr block) are
all allocated in the old way (ext4_new_blocks_old()).
I guess this out-of-sync happens already without notice, only when the
buddy info for this block group is re-generated after being pushed out
of memory under pressure this check is being hit.
> Thanks,
> -Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
