Cool! Looks like I found a "bi-lingual" person! ;-) Andrey,
would you mind if I ask you to translate some other things
between ZFS and venti/fossil for me?
On Jan 4, 2009, at 9:24 PM, andrey mirtchovski wrote:
Well, I guess I really got spoiled by ZFS's ability to do things like
$ zfs snapshot pool/projects/f...@yourtextgoeshere
at the console type "snap". if you're allowing snaps to be mounted on
the local fs then the equivalent would be "mkdir /YourTextGoesHere;
bind /n/dump/... / /YourTextGoesHere".
Fair enough. But YourTextGoesHere then becomes a transient property
of my namespace, where in case of ZFS it is truly a tag for a snapshot.
note that zfs restricts where
the snapshot can be mounted :p venti snapshots are, by default, read
only.
Well, strictly speaking Solaris does have a reasonable approximation
of bind in a form of lofs -- so remapping default ZFS mount point to
something else is not a big deal.
$ zfs clone pool/projects/f...@yourtextgoeshere pool/projects/branch
that's as simple as starting a new fossil with -f 'somehex', where
"somehex" is the score of the corresponding snap.
this gives you both read-only snapshots,
Meaning?
and as many clones as you wish.
Cool!
note that you're cheating here, and by quite a bit:
Lets see about that ;-)
- snapshots are read only and generally unmountable (unless you go
through the effort of making them so by setting a special option,
which i'm not sure is per-snapshot)
Huh? That's weird -- I routinely access them via
/<pool>/<fs>/.zfs/snapshot/<snapshot name>
and I don't remember setting any kind of options. The visibility
of .zfs can be tweaked, but all it really affects is Tab in bash ;-)
- clones can only be created off of snapshots
But that does sound reasonable. What else there is except snapshots
and an active tree? Or are you objecting to the extra step that is
needed where you really want to clone the active tree?
- clones are read-writable but they can only be mounted within the
/pool/fs/branch hierarchy. if you want to share them you need to
explicitly adjust a lot of zfs settings such as 'sharenfs' and so on;
In general -- this is true :-( But I think there's a way now to do that.
If you're really interested -- I can take a look and let you know.
- none of this can be done remotely
Meaning?
- libzfs has an unpublished interface, so if one wants to, say, write
a 9p server to expose zfs functionality to remote hosts they must
either reverse engineer libzfs or use other means.
This one is a bit unfair. The interface is published alright. As much
as anything in Open Source is. It is also documented at the level
that would be considered reasonable for Linux. The fact that
it is not *stable* makes the usual thorough Solaris documentation
lacking.
But all in all, following along doesn't require much more extra
effort compared to following along any other evolving OS
project.
And yes, the situation has changed compared to what it used to
be when Solaris 10 just came out. If you had bad experience
with libzfs sometime ago -- I'm sorry, but if you try again you
might find it more to your linking.
Thanks,
Roman.
