[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: one question


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

> I found the 'BH_Alloced' flag only occures at two place: one is balloc.c as
> above, the other is at journal_forget() in fs/jfs/transaction.c:
> J_ASSERT (!test_and_set_bit(BH_Freed, &bh->b_state));
> clear_bit(BH_Alloced, &bh->b_state);
> here after assert, we clear the bit right away. So the other question is: If one
> block was new alloced, BH_Alloced was set in it's buffer_header and there is no
> way to clear it until the buffer was destroyed. Is that right? In my case,
> dese it means that Ext3 allocate a block which is already allocated?

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]