Re: [linux-lvm] LVM 0.9 snapshot and ext3

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

On Wed, Nov 29, 2000 at 03:18:06AM -0700, Andreas Dilger wrote:

> > Maybe LVM isn't cleaning up the buffer properly when it runs out of space
> > in the snapshot...
> 
> Judging by the assertion (the buffer is still locked), and the fact that
> this flag BH_Lock is what's set when a buffer is being written, and
> cleared by wait_on_buffer(), LVM may need to be waiting on it's snapshot
> I/Os to complete if it will later destroy the snapshot...

Right.  There are only two ways the assertion can fail: the buffer is
locked for read, or for write.  By this stage, ext3 has frozen all of
the filesystem operations which were working on this buffer, but may
have started collecting new updates while the old ones are committing,
so there is the possibility of ext3 doing concurrent access while we
are doing this journal operation.

So, is somebody else doing a read?  It could be ext3, conceivably, if
we had had an IO error previously on the buffer and the BH_uptodate
flag had been cleared: a subsequent access to the buffer by another
process would try to reread the buffer off disk, locking it
temporarily.  Could you load the ext3 kdb debugging extensions and run
a "bh <buffer_head address>" on the buffer-head once the oops drops
you into kdb monitor mode?  That way, we can find out whether the
dirty bit has been set on the buffer_head. 

Cheers,
 Stephen