On 10/6/06, Nicolas Williams <[EMAIL PROTECTED]> wrote:
On Fri, Oct 06, 2006 at 03:30:20PM -0600, Chad Leigh -- Shire.Net LLC wrote:
> On Oct 6, 2006, at 3:08 PM, Erik Trimble wrote:
> >OK. So, now we're on to FV. As Nico pointed out, FV is going to
> >need a new API. Using the VMS convention of simply creating file
> >names with a version string afterwards is unacceptible, as it
> >creates enormous directory pollution,
>
> Assumption, not supported. "Eye of the beholder."
No, you really need an API, otherwise you have to guess when to snapshot
versions of files.
First of all "snapshot versions of files" is a very confusing phrase
especially in this discussion. But, if you mean what I think you
mean, then the existing file API gives you all the information you
need . Whenever you create a new file, you create a new version. The
only thing that changes is, if an *old* version already exists, it
doesn't get deleted the way it used to.
> >Now we have a problem: how do we access FV for non-local (e.g.
> >SAMBA/NFS) clients? Since the VAST majority of usefulness of FV is
> >in the network file server arena,
>
> Assumption, and definitely not supported. It is very useful outside
> of the file sharing arena.
I agree with you, and I agree with Erik. We, Sun engineers that is,
need to look at the big picture, and network access is part of the big
picture.
Yes, I have to agree here also. So much of people's file access is
over a network these days that a local-only facility isn't very
interesting / useful.
> >You can't modify the SMB or NFS protocol (easily or quickly) to add
> >FV functionality (look how hard it was to add ACLs to these
> >protocols).
> >
> >About the only way I can think around this problem is to store
> >versions in a special subdir of each directory (e.g. .zfs_version),
> >which would then be browsable over the network, using tools not
> >normally FV-aware. But this puts us back into the problem of a
> >directory which potentially has hundreds or thousands of files.
>
> This directory way of doing it is not a good way. It fails the ease
> of use to the end user test.
No, it doesn't: it doesn't preclude having FV-aware UIs that make it
easier to access versions. All Erik's .zfs_version proposal is about is
remote access, not a user interface.
Requiring special software to access this kind of feature is death.
People don't want to learn new tools; they want to learn existing
tools. Depending on the user, that's ls, or awk, or grep, or find, or
Emacs dired, or this or that or the other thing.
One of the reasons ZFS snapshots (and other snapshots, in my limited
experience) work easily is that they appear as ordinary files within
the directory structure, and do *not* require special tools to access.
> The VMS way is far superior. The problem is that you have to make
> sure that apps that are not FV aware have no problems, which means
> you cannot just append something to the actual file name. It has to
> be some sort of meta data.
I.e., APIs.
I don't think I understand the issues being raised here. My
off-the-cuff impression is that they don't exist at all, or are at
least moderate molehills not mountains.
When writing an application for TOPS-20 or VMS, you didn't have to do
anything to specifically deal with file versioning. It just worked.
If the user wanted the most recent version of the file, they typed the
name without the version, or else with the most current version. If
they *did* want an older version, they had to type very slightly more,
by appending the version number. And (on TOPS-20) of course we had
filename completion and inline help to make it easy to refresh your
memory on what versions existed in the middle of doing this.
So, one small feature built into the filesystem OPEN code: if a
version is not specificied for a file, use the most recent version.
NO special code in any application is needed.
There are public-access TOPS-20 systems on the net today (I've got an
account on one, though that data is at home and I'm in Palo Alto this
week). And I've still got the small TOPS-20 system manual (I didn't
keep the big twenty-something volume set though) where I can look up
the details when I'm home. This technology isn't completely lost yet
:-).
--
David Dyer-Bennet, <mailto:[EMAIL PROTECTED]>, <http://www.dd-b.net/dd-b/>
RKBA: <http://www.dd-b.net/carry/>
Pics: <http://www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
