From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 5 Jan 2009 21:49:15 -0800 From: Roman Shaposhnik In-reply-to: <14ec7b180901042124v45e6e5a0x4a9f405f78b4e49b@mail.gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <1a605cf7ccd9e5ba7aaf6f3ad42e0f4b@terzarima.net> <140e7ec30901031403y66a3d67epac5a9800026e7609@mail.gmail.com> <1231131954.11463.459.camel@goose.sun.com> <14ec7b180901042124v45e6e5a0x4a9f405f78b4e49b@mail.gmail.com> Subject: Re: [9fans] Changelogs & Patches? Topicbox-Message-UUID: 7a753d82-ead4-11e9-9d60-3106f5b1d025 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/foo@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/foo@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 ///.zfs/snapshot/ 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.