Recurring problem: processes block accessing UFS file system

[Don Lewis]

On  3 Jan, Greg Rivers wrote:
> On Tue, 3 Jan 2006, Don Lewis wrote:

>> Pid 87117 is playing with buf 0xdc76fe30 which is not locked, and is
>> sleeping on the buf's b_xflags member.  It looks like 87117 is waiting
>> for an in-progress write to complete.  There are a large number of other
>> sendmail processes waiting in this same place.
>>
>> How about "show buffer 0xdc76fe30"?
>>
> 
> db> show buffer 0xdc76fe30
> buf at 0xdc76fe30
> b_flags = 0x200000a0<vmio,delwri,cache>
> b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0
> b_bufobj = (0xc8985610), b_data = 0xe1d6b000, b_blkno = 365086368
> lockstatus = 0, excl count = 0, excl owner 0xffffffff
> b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b858d4, 0xa8de1000),(0xc8984108, 0x2b858d5, 0xa8c62000),(0xc8984108, 0x2b858d6, 0xa8de3000),(0xc8984108, 0x2b858d7, 0xa8e64000)
> db>

Hmn, it would be nice if DDB printed b_vflags so that we would know the
state of BV_BKGRDINPROG and BV_BKGRDWAIT.  As it is, we don't know if
the background write got lost or if we missed the wakeup.

At this point, I think it might be easier to do post-mortem debugging on
a core file with kgdb and kernel.debug.  Unless there is an obvious race
condition, I suspect this will be a tough slog.