Subject: Re: PR/34293 CVS commit: src/sys/dev
To: None <,,>
From: Michael van Elst <>
List: netbsd-bugs
Date: 09/10/2006 07:20:03
The following reply was made to PR kern/34293; it has been noted by GNATS.

From: Michael van Elst <>
Subject: Re: PR/34293 CVS commit: src/sys/dev
Date: Sun, 10 Sep 2006 09:18:41 +0200

 On Sun, Sep 10, 2006 at 06:45:03AM +0000, 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.
 >  > If my patch doesn't make sense, then try to understand why it works.
 >  now i've tried your patch.  it didn't work for me.
 That's probably because you have a completely different test that
 shows a different problem.
 >  vndthread just got deadlock on "getnewbuf" without your
 >  throttling code triggered at all.
 >  	(/bigfile is 512M file w/o holes on ufs.)
 >  	vnconfig vnd0 /bigfile
 >  	newfs -F /dev/rvnd0d
 >  	mount /dev/vnd0d /mnt
 >  	dd if=/dev/zero of=/mnt/a bs=1m seek=1m  (ENOSPC)
 That creates a sparse file starting at offset 1TB.
 >  	vnconfig vnd1 /mnt/a
 >  	dd if=/dev/zero of=/dev/vnd1d bs=1m seek=1m  (deadlock)
 That would write the sparse file starting from offset 1TB.
 >  (i can't follow your recipe in the PR because i don't have 10G disk space.)
 You can probably use a smaller file as long as enough data gets
 written. mkfs.ext2 just writes the ext2-metadata, so a simple dd
 would require a much smaller file.
 >  > The writer does never clean blocks. The writer can only create
 >  > more dirty blocks. The blocks are "clean" again when they
 >  > are processed by the device, i.e. in some iodone routine
 >  > which is called in an interrupt. How should a sleeping process
 >  > prevent that? In particular, at that time the writer is stopped
 >  > in vndstrategy, we definitely know that the vndthread _is_ busy
 >  > cleaning buffers, because that is the stop condition. We therefore
 >  > make _sure_ that it can do so.
 >  i think that our definitions of "writer" are different.
 >  mine is "callers of vndstrategy."
 >  yours is "callers of write(2)".  right?
 Mine is "callers of vndstrategy", for writing the block device
 that's the same as "callers of write(2)".
 I have a look at your patch.
                                 Michael van Elst
                                 "A potential Snark may lurk in every tree."