vn disks

[Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>]

Hello all

As has been discussed some time ago, I took a crack at a 'mount_vnd' 
implementation a-la OpenBSD, as it seems that this would be a handy
tool to have. (Overall goal: being able to use VN devices simply / at boot)

As our vnconfig has diverged significantly with respect to the original
implementation and OpenBSD, and as our vnconfig installs under /usr/sbin 
- rather than trying to merge the related features / flags / etc into a 
'monolithic' hardlinked vnconfig/mount_vnd binary as is done in OpenBSD, 
I just made a very simple mount_vnd that only has the attach-related 
features for file backed vnode disks.

However, in the course of implementing, I found that (even on OpenBSD) 
mount/fsck don't have a provision for boot-time mounting vnode disks 
properly - as the fstab parsing assumes all devices are "devices"
(also mount needed a hack to mount to a non dir under /dev)

This could easily be worked around by adding a 3rd pass to mount/fsck
so that vnd's could be configured in phase 2 (passno==1), and then
mounted in phase 3 (passno==2).

This brings up a few questions:

1) Is the basic mount_vnd approach kosher? or would people prefer
   not to have a separate tool / have me merge the functionality
   (this brings up further vnconfig related questions)
2) All OK with the 3rd mount/fsck pass? It would simply take
   another loop in the related code IIRC (has been a cpl days)

Vnconfig / general vn(4) implementation related questions:

1) We have tmpfs. Are swap backed VN devices needed still?
2) If merging functionality - there's alot of 'stuff' in vnconfig
   for vn debugging - seems like this is perhaps a bit extraneous
   and could be cleaned - rationale follows
3) If mount_vnd is added - I'd think it makes sense to remove
   the 'vntab' functionality - comments?

As far as the other branches of VN - there are a few nifty features
I'd think would nice to port over (compressed and encrypted vns from net 
and openbsd respectively)- and a cleaner / simpler base would make for 
easier porting.

Anyhow - probably not worth too many cycles thinking about -

The minimal implementation would be adding a basic mount_vnd
and 3rd fsck pass (with appropriate docs, etc) - and wouldn't
conflict with anything else - which is what I propose currently.
just wanted to run it by the team / (re)mention the other thoughts 
kicking around.

Also to note, this would allow a hackish way to use quotas in 
combination with hammer (until a proper quota is implemented) by storing 
VND disks on hammer that are configured for boot - though of course you 
would lose the 'instant on' capability.

Cheers all,

- Chris

ps: *messy* tarball of my workspace in
http://leaf.dragonflybsd.org/~cat/mount_vnd.tar.gz -