Re: ramdisk corruption problems - was: RE: pivot_root and initrd kern el panic woes

[Daniel Phillips <phillips@bonn-fries.net>]

On December 30, 2001 07:19 am, Andrew Morton wrote:
> Question: can someone please define BH_New?  Its lifecycle seems
> very vague.

That's because it is.  (vague)  In its current incarnation, BH_New is
valid right after calling xxx_get_block, otherwise it's like a floating
signal.  This is just sloppy.

> We never actually seem to *clear* it anywhere for 
> ext2, and it appears that the kernel will keep on treating a
> clearly non-new buffer as "new" all the time.  ext3 explicitly
> clears BH_New in get_block(), if it finds the block was already
> present in the file.  I did this because we need the newness
> info for internal purposes.

As I understand it, BH_New is set because xxx_get_block created a
block and didn't initialize it - the initialization is expected to
be done by someone else.  So somebody better pick it up before the
block starts transitioning to other states.  The correct model
would use scalars for block states, not bits, and we would
enumerate all the correct transitions.  Since that isn't going to
happen any time soon, we could clear BH_New every time we set some
other state bit.  Or maybe BUG if we ever change another state bit
and BH_NEW is still set, indicating somebody forgot to initialize
the buffer.

Hmm, I'm just taking a look at ext3/inode.c, line 863 - you've just
called getblk, and you will act on BH_New.  Does that code ever get
executed?

--
Daniel