Date: Sat, 28 Apr 2001 11:19:22 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Terry Lambert <tlambert@primenet.com> Cc: fs@FreeBSD.ORG Subject: Re: versioned files via snapshot evilness. Message-ID: <200104281819.OAA00877@glatton.cnchost.com> In-Reply-To: Your message of "Fri, 27 Apr 2001 17:28:25 -0000." <200104271728.KAA01251@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Please see my previous response. I already said posix won't
like this. Not sure it would like kernel globbing either
(needed to expand "<file>;*" ).
> 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.
I wouldn't. When I used VMS I didn't find version limits
useful except to save space and for that I'd rather just use
the quota system.
> 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.
rm foo/1/2/3 # delete the latest version of foo 1.2.3
rm -rf foo/1/2/3/ # delete all sub-versions of foo 1.2.3
But undoubtedly there are other holes. I am well aware that
to turn this on-the-spur-of-the-moment idea into reality
requires a proper, careful design that handles all the
boundary conditions and corner cases. And it may turn out to
be a non-trivial task. I simply wanted to point out that the
concept of file namespace can be extended in a uniform manner
to cover this and other cases -- of course, it is a lot
harder to extend a well defined interface naturally than to
simply add another incompatible interface.
Doesn't Atria or Clearcase or Rational have a versioning
filesystem? Though I know nothing about it.
> 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.
That is why in my example I envisioned a `cvs' filesystem.
I would simply use foo,v (rcs) or s.foo (sccs) or something
like it. I wouldn't want this facility to be pervasive where
every filesystem must provide this support.
> 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.
I believe the trend is to divorce the on-disk representation
of a file (or a filesystem) from a *view* provided on it.
This is already the case in a limited sense -- ffs, ex2fs,
xfs and so on all provide pretty much the same interface.
A single file ala rcs or sccs provides one way to store the
data -- certainly not as efficient as VMS. But as long as
the _view_ is the same one should allow any representation,
including caching whole files for frequently used versions of
a file.
> 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.
If the view semantics are to not create a new version until
there is an actual write (a reasonable expectation), one can
implement that though it would be more complex.
-- bakul
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?200104281819.OAA00877>