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

From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: PR/34293 CVS commit: src/sys/dev
Date: Thu, 7 Sep 2006 19:36:30 +0200

 On Thu, Sep 07, 2006 at 12:55:03PM +0000, YAMAMOTO Takashi wrote:
 > The following reply was made to PR kern/34293; it has been noted by GNATS.
 > 
 > From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
 > To: mlelstv@serpens.de
 > 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: Thu,  7 Sep 2006 21:51:01 +0900 (JST)
 > 
 >  > >  does your "mkfs.ext2" use a block device, rather than a raw device?
 >  > 
 >  > It's not mine but it does.
 >  
 >  ok, then i think i understand the problem.
 >  we should throttle activities creating dirty buffers.
 >  maybe by having a flag for getblk and friends to tell
 >  "we are not going to dirty the buffer".
 
 If I remember previous discussions there was some opposition in
 restricting writes this way. Please check the discussions about
 untarring source trees and waiting for X11 to respond again.
 
 Throttling getblk does not prevent the deadlock. For that you need
 to distinguish between the upper filesystem or block device, that
 needs to be throttled and the lower filesystem (or rather lowest
 if you start nesting deeper), that must be kept running to avoid the
 deadlock.
 
 There is also the problem about feedback. How would you know when
 to throttle (or rather when to stop)?. You could have a mechanism
 that looks at all the device queues, if buffers pile up there
 because the device is too slow, you stop generating more.
 
 But throttling getblk isn't good enough, you only want to throttle
 getting buffers that end in the particular slow device queue. And
 getblk doesn't have that information.
 
 The SoC-Project that adds congestion control to filesystems might
 eventually address this problem correctly.
 
 
 >  what your patch does is the opposite.  ie. throttling attempts of
 >  cleaning buffers.  i believe it makes the situation worse.
 
 The patch does not throttle attempts of cleaning buffers. The
 bottleneck for cleaning buffers is still the underlying filesystem
 where the virtual device file resides.
 
 With the patch when vnd throttles the writer it does two things:
 
 it prevents it from generating more dirty buffers and
 
 it delays the requeuing of dirty buffers _when the underlying
    filesystem is too slow to process them_.
 
 As a result it may not utilize the buffer cache effectively.
 You could provide a knob to control the queue length, currently
 that's hardcoded 8 for local filesystems and 2 for NFS.
 
 It also affects vnd operation only, unlike anything that interfers
 with the more global getblk.
 
 
 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."