Subject: Re: PR/34293 CVS commit: src/sys/dev
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Michael van Elst <mlelstv@serpens.de>
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 <mlelstv@serpens.de>
To: gnats-bugs@NetBSD.org
Cc: 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 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
Internet: mlelstv@serpens.de
"A potential Snark may lurk in every tree."