Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 7 Mar 2001 15:35:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 7 Mar 2001 15:35:45 -0500 Received: from h24-65-192-120.cg.shawcable.net ([24.65.192.120]:5618 "EHLO webber.adilger.net") by vger.kernel.org with ESMTP id ; Wed, 7 Mar 2001 15:35:36 -0500 From: Andreas Dilger Message-Id: <200103072035.f27KZ5V20201@webber.adilger.net> Subject: Re: [linux-lvm] EXT2-fs panic (device lvm(58,0)): To: Linux kernel development list , Linux FS development list Date: Wed, 7 Mar 2001 13:35:05 -0700 (MST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Bill Clark wrote (to the moderated linux-lvm@sistina.com list): > Not sure if this is a LVM problem or a ext2fs problem. It is happening > with the 2.4.2 kernel and the 0.9 release of the LVM user tools. > > kernel: Kernel panic: EXT2-fs panic (device lvm(58,0)): > load_block_bitmap: block_group >= groups_count - block_group = 131071, > groups_count = 24 > > There is a 1gig+ file on the filesystem, and most operations on it seem > to bring about the error. Basically, the error you are getting is impossible. In all calls to load_block_bitmap(), the "group number" is either checked directly, or "block" (which is what is used to find "group number") is checked to be < s_blocks_count, so by inference should return a valid group number. The only remote possibility is in ext2_free_blocks() if block+count overflows a 32-bit unsigned value. Only 2 places call ext2_free_blocks() with a count != 1, and ext2_free_data() looks to be OK. The other possibility is that i_prealloc_count is bogus - that is it! Nowhere is i_prealloc_count initialized to zero AFAICS. In most cases, this would return a "freeing blocks not in datazone" error, but depending on the values, it may just pass the test. This may also be the cause of the errors people have previously reported where it looks like they are freeing block numbers which look like ASCII data. This would happen in ext2_discard_prealloc() when we have a value for i_prealloc_count != 0 (easy) and i_prealloc_block points to some valid block number (less likely, but moreso on a large filesystem). Cheers, Andreas ========================================================================== diff -ru linux/fs/ext2/ialloc.c.orig linux/fs/ext2/ialloc.c --- linux/fs/ext2/ialloc.c.orig Fri Dec 8 18:35:54 2000 +++ linux/fs/ext2/ialloc.c Wed Mar 7 12:22:11 2001 @@ -432,6 +444,8 @@ inode->u.ext2_i.i_file_acl = 0; inode->u.ext2_i.i_dir_acl = 0; inode->u.ext2_i.i_dtime = 0; + inode->u.ext2_i.i_prealloc_count = 0; inode->u.ext2_i.i_block_group = i; if (inode->u.ext2_i.i_flags & EXT2_SYNC_FL) inode->i_flags |= S_SYNC; diff -ru linux/fs/ext2/inode.c.orig linux/fs/ext2/inode.c --- linux/fs/ext2/inode.c.orig Tue Jan 16 01:29:29 2001 +++ linux/fs/ext2/inode.c Wed Mar 7 12:05:47 2001 @@ -1048,6 +1038,8 @@ (((__u64)le32_to_cpu(raw_inode->i_size_high)) << 32); } inode->i_generation = le32_to_cpu(raw_inode->i_generation); + inode->u.ext2_i.i_prealloc_count = 0; inode->u.ext2_i.i_block_group = block_group; /* -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/