> Adding those lines verbatim to a file 'config', I then ran: > vnfs -c 16k config > and got back: > handle da...0d > I don't yet fully understand the implications of that 16 char hex string, > so I'm not posting it here, but I didn't seem to need it anywhere else.
It was just a debugging print. It's the root handle that clients need to know to connect to the NFS server. It used to be randomly generated each time vnfs started, but I found it was much easier to use a fixed one. The bytes you didn't post are the first 8 bytes of sha1sum /dev/zero. > On my venti server, I got a *lot* of these messages: > venti/venti: bucket overflow XXX > but I think I understand that (this is a junk venti server used for > experimentation, so i didn't spend any time sizing things appropriately) Right, your index is too small. > 4) It looks like libdiskfs allows vnfs to serve up arbitrary disk image > formats (hfs, ffs, ufs, &c), which is awesome, but it'd be nice if it could > also serve vac snapshots. Anything peculiar about vac that inhibits this, > or is it just a matter of extra code in libdiskfs (or in vnfs, to switch > between libdiskfs and something for vac)? Better to just use vacfs -m if you want to view vac, and skip NFS entirely. NFS doesn't let you see close events, so you have to make up handles that can last an arbitrarily long time. This is pretty easy if you're serving a fixed set of Unix file system disk images: the handle specifies the particular disk image and the inode in that disk image. There's no similarly easy handle to use for vac archives. (Also remember that the handle has to have enough information to make dotdot work!) Also, vac -a is a viable alternative to vbackup, and it lets you exclude certain directories or files from the backup. Russ
