Re: one question

[Eric Mei <ericm mountainviewdata com>]

--
Eric

On Thu, 1 Feb 2001, Stephen C. Tweedie wrote:

> Hi,
> 
> On Thu, Feb 01, 2001 at 04:36:44PM -0500, Eric Mei wrote:
> > 
> > I'm one of developers of SnapFS, which based on Ext3. I got Assertion failure
> > from SnapFS, at ext3_new_block() in fs/ext3/balloc.c:
> > 
> > J_ASSERT (!test_and_set_bit(BH_Alloced, &bh->b_state))
> > 
> > If J_ASSERT is only use as debug, why it will modify data?
> 
> J_ASSERT is there to check the result of the test-and-set in that
> case.
What I mean here is that we usually don't put statments such as 
test_and_set_bit() which could modify data into ASSERT(),
because we will finally remove all debug facilities such as ASSERT()
and thus will cause different behavior of the program.

> Yep.  What version of ext3 is this?  That particular assert has never
> been triggered in the field to my knowledge, but it _could_
> conceivably happen due to certain on-disk or memory corruptions
> causing a bitmap block to be corrupted, so a block gets allocated
> twice.
> 
> The other possibility is that you may be using a block device driver
> which is copying bits of buffer_head state around itself (I've seen at
> least one driver do this and accidentally trigger ext3 assert fails as
> a result).  Is that possible?
> 
> Can you reproduce this?  If so, we might be able to narrow it down to
> see if it's being caused by a problem in ext3 or in SnapFS.
I use 0.0.5e. If I run ext3 alone, everything is ok. It seems that SnapFS didn't
invalidate buffers after certain opeartions. I will check it.

many thanks for your help
> Cheers,
>  Stephen