Re: [linux-lvm] lvm deadlock with 2.4.x kernel?

[Chris Mason <mason@suse.com>]

On Tuesday, May 15, 2001 06:32:24 PM -0600 Andreas Dilger
<adilger@turbolinux.com> wrote:

>> reiserfs should catch blocks that don't have the proper bits set when it
>> starts i/o, and then it makes sure the block hasn't been relogged while
>> the i/o was in progress.  It sends warnings not an oops though, check
>> your log files.  If we were losing journal bits, and the log code didn't
>> catch it, the result should be silent corruption.  
>> 
>> Since he is seeing deadlock, it seems more likely reiserfs is trying to
>> lock a buffer for i/o, and that is hanging for some reason....
> 
> But what does PV_FLUSH do?  Calls fsync_dev() to flush dirty buffers to
> disk, and sync_supers() and waits for buffer I/O completion.  This is
> unlikely to be the cause of a problem, because that happens on each
> sync call.
> 
> It then calls __invalidate_buffers(dev, 0), which destroys everything
> but dirty buffers (on ALL buffer lru lists).  

Unless I'm reading it wrong (2.4.4), __invalidate_buffers destroys all
buffers that are clean and have b_count == 0.  Reiserfs keeps b_count > 0
for all metadata buffers that have been logged, while ext3 allows the count
to be zero (but keeps them in the dirty list).

__invalidate_buffers also waits on any locked buffers.  Any chance one of
the other LVM ioctls grabs some lvm lock before calling PV_FLUSH?

You're right though, pv_flush certainly doesn't look like it could cause
any deadlocks.

-chris