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 -