The following reply was made to PR kern/34293; it has been noted by GNATS.

From: Michael van Elst <mlelstv@serpens.de>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/34293 CVS commit: src/sys/dev
Date: Sun, 10 Sep 2006 16:50:21 +0200

 On Sun, Sep 10, 2006 at 05:07:19PM +0900, YAMAMOTO Takashi wrote:
 
 > > >  > If you limit dirty buffers to 1/2 of total buffer cache you will
 > > >  > still deadlock. It doesn't matter what limit you put on dirty
 > > >  > buffers. Whenever that limit it reached then vnd cannot process
 > > >  > them because for doing so it would have to exceed that limit. You
 > > >  > must make sure that the filesystem that vnd is calling through
 > > >  > VOP_STRATEGY _can_ allocate new buffers, even those that it
 > > >  > can use for writing.
 > > >  
 > > >  which filesystem are you talking about?
 > > 
 > > The filesystem where the virtual device resides on, in that
 > > my UFS.
 > 
 > how can vnd on UFS allocate new dirty buffer cache
 > in order to make a progress?
 
 VOP_STRATEGY could do this for updating metadata. I don't know
 wether UFS actually does this. From looking at iostat output
 while running your testcase it only does extra reads, so if
 it generates dirty buffers these don't end (quickly) on the device
 queue.
 
 > > >  	dd if=/dev/zero of=/mnt/a bs=1m seek=1m  (ENOSPC)
 > > >  	vnconfig vnd1 /mnt/a
 > > >  	dd if=/dev/zero of=/dev/vnd1d bs=1m seek=1m  (deadlock)
 
 > yes, they were intentional.
 > (to make sure it uses indirect blocks, w/o requiring much disk space.)
 
 I cannot reproduce that problem here. dd doesn't deadlock.
 
 
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."