Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Apr 2001 17:28:25 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        bakul@bitblocks.com (Bakul Shah)
Cc:        tlambert@primenet.com (Terry Lambert), fs@FreeBSD.ORG, bakul@FreeBSD.ORG
Subject:   Re: versioned files via snapshot evilness.
Message-ID:  <200104271728.KAA01251@usr07.primenet.com>
In-Reply-To: <200104262348.TAA10209@sheffield.cnchost.com> from "Bakul Shah" at Apr 26, 2001 04:48:56 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> > This is the folded namespace approach.  In the user's "view"
> > onto the filesystem, they would see only the "file" name, and
> > when they reference the file, they get the most recent version
> > in the directory.
> 
> Likely my example was not clear.  The user gets both views:
> as a file and a dir, depending on the open mode.  For
> example, as a file when you do open("foo",...) and as a dir
> when you do open("foo/", ...).  Either a trailing slash or
> with an open mode or something to select between the two.

This is not permitted by POSIX.

> If you want the latest HEAD version  you open "foo".  If you
> want a specific version 1.2, you open "foo/1/2".  Should
> there be further branching 1.2.{1,2,..n}, opening "foo/1/2"
> will automatically give you the latest sub version.  So this
> scheme extends very nicely to a tree of versions as opposed
> to the '; <version>' scheme which is flat.

How would you enforce version limits on these trees?  In a flat
space in VMS, it is rather trivial to set up an ACL that will
limit you to 6 versions simultaneously, and delete version 9 when
you create version 16.

In your approach, there is no way to delete the tree out from
under yourself safely.  You end up having to keep all versions
(at least those with children) for all time.

Realize also that the VMS version system was very clever; since
VMS had a record oriented FS, only the records which changed
were in the new version.  This means that the VMS system was
much closer to an SCCS system (I guess hence the common case of
calling such things "revision control" or "version control"
systems).  In other words, versioning leveraged very heavily
off the FILES-11 fielsystem.

For a UNIX version of this, without a new FS type that internally
implemented record-oriented storage (and the concommitant ability
to defragment the FS space), you would need to copy the entire
file.

You can't even break it up on disk blocks and share them, since
you can never tell when a user space program has implied a
multi-stage commit operation and gathered it into itself, and
had data change -- and then change back.  The fact that data
written to an area is the same as the data previously in the
are is therefore not usable as a hint to determine whether or
not the "unmodified" page should be replicated into the new
version of the file, or not.  Effectively, this would mean
that you couldn't just "cheat" and imply "copy on write"
semantics on disk blocks to create new versions.

Further, opening a file for write implied the versioning operation.
Only the last close indicated that subsequent opens would result
in a new version (this was overridden, in the case of opening a
specific version).  Your implication of a tree of versions _must_
necessarily destroy the ability to open without creating a new
version, when closing following a write/trucate operation.


> > You still need a seperate handler for the namespace escape to do
> > the version redirection of the name, or to select the most recent
> > version, if no escape is present.  This still leaves you hanging
> > out to try over listing all version of the file from the user's
> > point of view, as VMS did, without a ";<version>" namespace
> > intrusion (as opposed to an escape).
> 
> What is wrong with `ls -R foo' if you want to list every
> created version and `ls foo/1/2/*' if you want to list all
> the same level sub versions of 1.2?

How about "it's disallowed by POSIX"?


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104271728.KAA01251>