I get the following soon after booting, each time I boot:
[ 245.033381] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
EXT4-fs: group 923: 18046 blocks in bitmap, 32768 in gd
[ 245.033411]
[ 245.036258] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
EXT4-fs: group 924: 18113 blocks in bitmap, 32768 in gd
[ 245.036275]
[ 245.038909] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
EXT4-fs: group 925: 18000 blocks in bitmap, 32768 in gd
[ 245.038926]
[ 245.041258] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
EXT4-fs: group 926: 18142 blocks in bitmap, 32768 in gd
[ 245.041274]
[ 245.043624] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
EXT4-fs: group 927: 18026 blocks in bitmap, 32768 in gd
Kernel is 2.6.27.5 with the oneliner for the recent mmap problem. Same
problem was there with .4 with the oneliner too. Never noticed it
before using the oneliner.
Linux kaguya 2.6.27.5 #1 SMP Sat Nov 8 03:43:33 UTC 2008 x86_64
Intel(R) Atom(TM) CPU 330 @ 1.60GHz GenuineIntel GNU/Linux
fsck.ext4 (shutdown -Fr now) finds/fixes nothing.
kaguya ~ # dumpe2fs -h /dev/sda3
dumpe2fs 1.41.3 (12-Oct-2008)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 07520665-bfed-4d37-a38e-0a7cb04cff59
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index
filetype needs_recovery extent flex_bg sparse_super large_file
huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash test_filesystem
Default mount options: (none)
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 91430912
Block count: 365693619
Reserved block count: 0
Free blocks: 242506667
Free inodes: 90878491
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 936
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Fri Oct 31 13:43:31 2008
Last mount time: Sat Nov 8 03:50:45 2008
Last write time: Sat Nov 8 03:51:30 2008
Mount count: 1
Maximum mount count: 31
Last checked: Sat Nov 8 03:47:31 2008
Check interval: 15552000 (6 months)
Next check after: Thu May 7 03:47:31 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 17705890
Default directory hash: half_md4
Directory Hash Seed: ba0cc33f-c339-4fd9-aa04-bfdad45ecf92
Journal backup: inode blocks
Journal size: 128M
On Sat, Nov 08, 2008 at 02:37:03PM +0000, Roc Valles wrote:
> I get the following soon after booting, each time I boot:
> [ 245.033381] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
> EXT4-fs: group 923: 18046 blocks in bitmap, 32768 in gd
> [ 245.033411]
> [ 245.036258] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
> EXT4-fs: group 924: 18113 blocks in bitmap, 32768 in gd
> [ 245.036275]
> [ 245.038909] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
> EXT4-fs: group 925: 18000 blocks in bitmap, 32768 in gd
> [ 245.038926]
> [ 245.041258] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
> EXT4-fs: group 926: 18142 blocks in bitmap, 32768 in gd
> [ 245.041274]
> [ 245.043624] EXT4-fs error (device sda3): ext4_mb_generate_buddy:
> EXT4-fs: group 927: 18026 blocks in bitmap, 32768 in gd
If there were subsequent boots, it's *very* interesting that that the
group numbers are sequentially increasing. It's also interesting that
the number in the group descriptor is 32768 each time. Andit's always
only one such error for each boot, right?
In addition to the data collection exercises we discussed over IRC,
could you try putting something which runs:
logsave /var/cache/dumpe2fs.pre-boot dumpe2fs /dev/sda3
*before* the filesystem is mounted read-write. (Logsave will save the
output of dumpe2fs and wait until /var/cache is writable, and then
dump the results out to the file).
Hmm... is there any chance that a rtorrent was in the middle of
downloading a file at the time when you shutdown the system? If so,
try killing all processes which might be writing to the filesystem
(especially any rtorrent processes) before shutting down the
filesystem.
Another question is whether mounting -o nodelalloc (on the previous
boot session) makes the problem go away. These last two tries are
based on the assumption that the filesystem is somehow really getting
corrupted on shutdown, and since you have errors=continue, it's
getting silently fixed up in mballoc.c, and so it doesn't show up when
you unmount the filesystem and run e2fsck. If this assumption is
true, that bogus free blocks in the superblock should show up in the
dumpe2fs, and it should also show up when you reboot via a rescue disk
and run "e2fsck -nfv /dev/sda3".
- Ted
> Hmm... is there any chance that a rtorrent was in the middle of
> downloading a file at the time when you shutdown the system? If so,
> try killing all processes which might be writing to the filesystem
> (especially any rtorrent processes) before shutting down the
> filesystem.
Zero. I carefully quit rtorrent everytime I reboot, including this
one. If I ever forget to, I'll notice right away the moment I start
it, because it'd rehash everything.
I forgot to menction something that might be key, which is that a few
reboots ago, I couldn't reboot (reboot wouldn't finish) until I forced
it with with -f and another parameter which makes reboot not sync
before rebooting. Doing a sync in another terminal never finished, so
the FS got stuck somehow. The error might have started appearing
immediatly after that.
> Another question is whether mounting -o nodelalloc (on the previous
> boot session) makes the problem go away. These last two tries are
> based on the assumption that the filesystem is somehow really getting
> corrupted on shutdown, and since you have errors=continue, it's
> getting silently fixed up in mballoc.c, and so it doesn't show up when
> you unmount the filesystem and run e2fsck. If this assumption is
> true, that bogus free blocks in the superblock should show up in the
> dumpe2fs, and it should also show up when you reboot via a rescue disk
> and run "e2fsck -nfv /dev/sda3".
I'll do the later at next opportunity, also the other thing we discussed on irc.
> - Ted
>