All of lore.kernel.org
 help / color / mirror / Atom feed
* [linux-lvm] EXT2-fs panic (device lvm(58,0)):
@ 2001-03-07 16:12 Bill Clark
  2001-03-07 19:57 ` Andreas Dilger
  0 siblings, 1 reply; 14+ messages in thread
From: Bill Clark @ 2001-03-07 16:12 UTC (permalink / raw)
  To: linux-lvm

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.  

Any ideas?

Thanx
Bill

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [linux-lvm] EXT2-fs panic (device lvm(58,0)):
@ 2001-03-07 20:35 Andreas Dilger
  2001-03-23  1:39 ` Stephen C. Tweedie
  0 siblings, 1 reply; 14+ messages in thread
From: Andreas Dilger @ 2001-03-07 20:35 UTC (permalink / raw)
  To: Linux kernel development list, Linux FS development list

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

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2001-03-23 19:13 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-03-07 16:12 [linux-lvm] EXT2-fs panic (device lvm(58,0)): Bill Clark
2001-03-07 19:57 ` Andreas Dilger
2001-03-07 21:05   ` Bill Clark
2001-03-08  5:52     ` Andreas Dilger
2001-03-08 14:53       ` Bill Clark
2001-03-08 16:46         ` Andreas Dilger
2001-03-09 13:27           ` Bill Clark
2001-03-11 21:23             ` Falcon
  -- strict thread matches above, loose matches on Subject: below --
2001-03-07 20:35 Andreas Dilger
2001-03-23  1:39 ` Stephen C. Tweedie
2001-03-23  2:04   ` Alexander Viro
2001-03-23  5:48     ` Andreas Dilger
2001-03-23 11:44       ` Alexander Viro
2001-03-23 19:11         ` Andreas Dilger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.