I am having some pretty good success on some different machines with ext4.
However, I am getting this message: 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
What do I need to do to help debug this, if anything, and how do I find out which files or directories are affected?
Thank you, Trever Adams -- "Yesterday is gone. Tomorrow is too far for me. Today is what I have, and what I fight for." -- Unknown
Trever L. Adams wrote:
I am having some pretty good success on some different machines with ext4.
However, I am getting this message: 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
What do I need to do to help debug this, if anything, and how do I find out which files or directories are affected?
Hm, congratulations on finding the first mballoc bug in fedora :)
It looks like freespace accounting got out of sync somehow... and I assume this is right after a mount, right?
If the fs is still mounted, can you gather up the files in /proc/fs/ext4/dm-0 and make them available somewhere?
Any idea what sort of load led to this? Does it persist across mounts?
If you like, you could bring this to the linux-ext4 list, as well.
Thanks, -Eric
On Wed, Mar 26, 2008 at 1:07 PM, Eric Sandeen sandeen@redhat.com wrote:
Hm, congratulations on finding the first mballoc bug in fedora :)
Is this a free t-shirt moment?
-jef
On 26/03/2008, Jeff Spaleta jspaleta@gmail.com wrote:
On Wed, Mar 26, 2008 at 1:07 PM, Eric Sandeen sandeen@redhat.com wrote:
Hm, congratulations on finding the first mballoc bug in fedora :)
Is this a free t-shirt moment?
I found a bug in GNOME whereby new windows open all over the place instead of in browser windows.
Plus vi is the default editor.
I await my dual t-shirt goodness - mailing address is in FAS. :p
On Wed, Mar 26, 2008 at 2:30 PM, Christopher Brown snecklifter@gmail.com wrote:
I found a bug in GNOME whereby new windows open all over the place instead of in browser windows.
Plus vi is the default editor.
I await my dual t-shirt goodness - mailing address is in FAS. :p
I'm more than certain that you are not the 'first' person to find those...bugs.
-jef
If it is a free t-shirt moment, I would love to have one, provided you have 2XL or XL/2XL-tall.
Trever
On Wed, 2008-03-26 at 13:10 -0800, Jeff Spaleta wrote:
On Wed, Mar 26, 2008 at 1:07 PM, Eric Sandeen sandeen@redhat.com wrote:
Hm, congratulations on finding the first mballoc bug in fedora :)Is this a free t-shirt moment?
-jef
fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- "Selfishness is really self-destruction in slow motion." -— Elder Neal A. Maxwell - Ensign, May 1999, 23
On Wed, 2008-03-26 at 16:07 -0500, Eric Sandeen wrote:
Trever L. Adams wrote:
I am having some pretty good success on some different machines with ext4.
However, I am getting this message: 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
What do I need to do to help debug this, if anything, and how do I find out which files or directories are affected?
Hm, congratulations on finding the first mballoc bug in fedora :)
It looks like freespace accounting got out of sync somehow... and I assume this is right after a mount, right?
If the fs is still mounted, can you gather up the files in /proc/fs/ext4/dm-0 and make them available somewhere?
Any idea what sort of load led to this? Does it persist across mounts?
If you like, you could bring this to the linux-ext4 list, as well.
Thanks, -Eric
Eric, thank you for your help. I will bring it to that list if you do not wish to. I am not a file system guy. Heck, I am not much of a kernel guy and what debugging I have done involved Alan Cox about a decade ago.
This is an upgrade from ext3. I followed the instructions and did it before the actual upgrade to rawhide (from f8). I then booted into rescue mode from the disk to do some moving of home to another disk then back to get the files "extented," so to speak, and then did yum upgrade. I believe it unmounted cleanly on alt-ctrl-del. It showed up on the next mount. It has done it over 2 or three mounts now.
The data can be accessed at http://vichu.innernet.org/ext4debug.tar.bz2
So, how do I fix it up?
Thank you again, Trever -- "He that composes himself is wiser than he that composes a book." -- Ben Franklin
Trever L. Adams wrote:
This is an upgrade from ext3. I followed the instructions and did it before the actual upgrade to rawhide (from f8). I then booted into rescue mode from the disk to do some moving of home to another disk then back to get the files "extented," so to speak, and then did yum upgrade. I believe it unmounted cleanly on alt-ctrl-del. It showed up on the next mount. It has done it over 2 or three mounts now.
Ah, reproducible is good. Exact same message each time? And is it right after you mount it?
The data can be accessed at http://vichu.innernet.org/ext4debug.tar.bz2
Thanks...
So, how do I fix it up?
working on that... :)
-Eric
On Wed, 2008-03-26 at 19:32 -0500, Eric Sandeen wrote:
Trever L. Adams wrote:
This is an upgrade from ext3. I followed the instructions and did it before the actual upgrade to rawhide (from f8). I then booted into rescue mode from the disk to do some moving of home to another disk then back to get the files "extented," so to speak, and then did yum upgrade. I believe it unmounted cleanly on alt-ctrl-del. It showed up on the next mount. It has done it over 2 or three mounts now.
Ah, reproducible is good. Exact same message each time? And is it right after you mount it?
I believe it is. It is always two. I believe it is the same two. I had to erase my logs so I cannot tell you that for certain. I will reboot later tonight and let you know.
The data can be accessed at http://vichu.innernet.org/ext4debug.tar.bz2
Thanks...
You are welcome.
So, how do I fix it up?
working on that... :)
-Eric
Thank you. Trever -- "Black holes are where God divided by zero." -- Unknown
Eric Sandeen wrote:
Trever L. Adams wrote:
I am having some pretty good success on some different machines with ext4.
However, I am getting this message: 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
What do I need to do to help debug this, if anything, and how do I find out which files or directories are affected?
Hm, congratulations on finding the first mballoc bug in fedora :)
It looks like freespace accounting got out of sync somehow... and I assume this is right after a mount, right?
So, in the course of other things, I found a way to reproduce this error. And, just for mailing-list-posterity, it seems to be fixed, upstream, with:
commit 0bf7e8379ce7e0159a2a6bd3d937f2f6ada79799 Author: Jose R. Santos jrs@us.ibm.com Date: Tue Jun 3 14:07:29 2008 -0400
ext4: Fix uninit block group initialization with FLEX_BG
With FLEX_BG block bitmaps, inode bitmaps and inode tables _MAY_ be allocated outside the group. So, when initializing an uninitialized block bitmap, we need to check the location of this blocks before setting the corresponding bits in the block bitmap of the newly initialized group. Also return the right number of free blocks when counting the available free blocks in uninit group.
Tested-by: Aneesh Kumar K.V aneesh.kumar@inux.vnet.ibm.com Signed-off-by: Jose R. Santos jrs@us.ibm.com Signed-off-by: Mingming Cao cmm@us.ibm.com Signed-off-by: "Theodore Ts'o" tytso@mit.edu
which made it to the 2.6.26 kernels.
the description sounds innocuous but in my case it was actually corrupting memory ...
-Eric
Eric Sandeen wrote:
So, in the course of other things, I found a way to reproduce this error. And, just for mailing-list-posterity, it seems to be fixed, upstream, with:
commit 0bf7e8379ce7e0159a2a6bd3d937f2f6ada79799 Author: Jose R. Santos jrs@us.ibm.com Date: Tue Jun 3 14:07:29 2008 -0400
ext4: Fix uninit block group initialization with FLEX_BG With FLEX_BG block bitmaps, inode bitmaps and inode tables _MAY_ be allocated outside the group. So, when initializing an uninitialized block bitmap, we need to check the location of this blocks before setting the corresponding bits in the block bitmap of the newly initialized group. Also return the right number of free blocks when counting the available free blocks in uninit group. Tested-by: Aneesh Kumar K.V <aneesh.kumar@inux.vnet.ibm.com> Signed-off-by: Jose R. Santos <jrs@us.ibm.com> Signed-off-by: Mingming Cao <cmm@us.ibm.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>which made it to the 2.6.26 kernels.
the description sounds innocuous but in my case it was actually corrupting memory ...
-Eric
Is this going to be seen fixed in F9? And yes, this can be deadly to your data. I have seen it trash a file system. I am going to have to back up /home and /etc and re-ext4 the drive.
Trever
Trever L. Adams wrote:
Is this going to be seen fixed in F9? And yes, this can be deadly to your data. I have seen it trash a file system. I am going to have to back up /home and /etc and re-ext4 the drive.
Yep, the 2.6.26 kernel update in F9 testing should have it fixed. Sorry it took so long to resolve, btw.
-Eric
Eric Sandeen wrote:
Trever L. Adams wrote:
Is this going to be seen fixed in F9? And yes, this can be deadly to your data. I have seen it trash a file system. I am going to have to back up /home and /etc and re-ext4 the drive.
Yep, the 2.6.26 kernel update in F9 testing should have it fixed. Sorry it took so long to resolve, btw.
-Eric
Oh and pairing that with e2fsprogs-1.41.0 from F9 testing should work pretty well.
-Eric
-
Christopher Brown -
Eric Sandeen -
Jef Spaleta -
Trever L. Adams