Subject: Re: port-xen/29775: Cannot use a vnode disk for domU
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 03/31/2005 09:27:53
--yQbNiKLmgenwUfTN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Mar 24, 2005 at 02:33:38PM +0100, Manuel Bouyer wrote:
> On Wed, Mar 23, 2005 at 04:52:53PM -0800, Jason Thorpe wrote:
> >=20
> > This is really a known problem. The vnd driver needs to be rewritten =
=20
> > badly. It needs to queue up requests and defer everything to a =20
> > kthread that actually does the work.
>=20
> This shouldn't be too hard to do, and is better than hacking xbd to not
> do I/O from interrupt context. I'll try to look at this this week end.
The same vnd lossage was also triggered from cgd, which can also call
its own start routine (and thus underlying device's strategy) from a
completion interrupt of a previous request, if more have been queued
awaiting resources. That was where the known problem Jason referred
to arose.
Thankyou very much, Manuel!
Now that it's done from a thread that can sleep, teaching vnd to use
VOP_BALLOC when VOP_BMAP fails on write (and just constructing
zero-filled buffers on read) - and thus dealing with holey files - is
quite feasible. With Chuck's recent direct-io changes, though,
perhaps the whole thing can move up to use VOP_RDWR and eliminate much
code without skewing the cache.
--
Dan.
--yQbNiKLmgenwUfTN
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)
iD8DBQFCSzX5EAVxvV4N66cRArakAKCwTvCopwTwj4tpkZYpcCzTcwCZnwCgwj34
1U9T9UrMi/BKsgIyWvTPhDQ=
=XGiD
-----END PGP SIGNATURE-----
--yQbNiKLmgenwUfTN--