On Thu, Apr 21, 2005 at 12:50:03PM +0200, Manuel Bouyer wrote:
> On Wed, Apr 20, 2005 at 06:48:13PM -0700, Chuck Silvers wrote:
> > this is probably PR 12189.
> > the vnd code has serious design flaws.
> > 
> > you can reduce the likelihood of hitting that problem
> > by using the raw vnd device instead of the block vnd device
> > as much as possible.
> 
> Now that vnd I/O to file is done though a kernel thread, can't this
> be solved more easily ?

no, more threads don't help the problems described in PR 12189.

the threads do solve another problem that hasn't been previously discussed,
which is that since the number of mutually recursive calls between vnd
and the file system drivers is not explicitly limited anywhere, we could
easily overflow the kernel stack.  now that each entry back into vnd
gets to start over with a fresh stack, that problem no longer exists.

I think the best way to solve both of the problems I described in the PR
is to pre-load the file's entire bmap and cache it in kernel memory
(ie. not in the buffer cache) while configuring a vnd.  writing dirty
buffer cache buffers back to the underlying storage will then not require
reading other buffers, thus avoiding the hidden dependencies between
buffers that are the heart of the problem.

to make this work out, we would also need to make sure that we either
prevent (ie. fail) changes to the file's bmap while we're caching it
outside the buffer cache, or else update the cached copy too and
synchronize with I/O in flight (see PR 26983).  either of these will
require changing every file system driver (well, every fs that creates
dirty buffer cache buffers).

-Chuck