Subject: Re: puvnd (pass to userland vnd)?
To: Dieter Baron <dillo@danbala.tuwien.ac.at>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 03/13/2007 17:13:33
--U+NfgObvpQT1Q9Yq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 09, 2007 at 08:30:39AM +0100, Dieter Baron wrote:
> > You should be able to use vnd with a file vnode backed by a puffs
> > filesystem (for example, encfs or lzofs).  vnd will turn the block ops
> > into vnops just as it does now, and puffs will forward the vnops.
>=20
>   That sounds rather awkward, at least from a user's point of view.  I
>   want it to be as simple as
> 	$ pubconfig pub0 pub-server-program args

Sure, but you're considering the case of the userspace process dealing
with a particular file format, like .dmg or vmware .vmdk.  That's a
fine idea, at least for file formats that aren't suitably represented
as a filesystem (like archives).

The counterpoint is that people might want to host vnd files on all
kinds of filesystems, perhaps often on network or replicated
filesystems; you don't want to be writing the network or replication
code twice, once for vfs and once for vnd.

Of course, you should be able to do both, one on top of the other, if
it makes sense.

> > That being said, for specialised block-device-like formats, maybe a
> > pass-to-userspace block driver (not via vnd) would be useful too,
> > rather than going via vfs and back.  (ie, the operations passed would
> > be ops like strategy, start, .., from the block layer).
>=20
>   Yes, that's pretty much what I had in mind.

Beware of another limitation: the block layer is basically
asynchronous, so your userspace process needs to deal with many
parallel requests.  That's fine for the "remote-vnd" interface, but it
also applies to the userspace process's access to the underlying file,
once it's done its translation work.  Parallel Async IO to a file from
userspace is currently not especially pretty (there's no AIO, so
you're pretty much stuck with the hassle of using lots of threads).

--
Dan.
--U+NfgObvpQT1Q9Yq
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iD8DBQFF9kEMEAVxvV4N66cRAkRtAJ4xCDAtrPYnu686gTei8wSXsA+gHgCfYIEi
kdPC82uYmjT0tqP7GkDoSfA=
=YGAr
-----END PGP SIGNATURE-----

--U+NfgObvpQT1Q9Yq--