Brian Hechinger wrote:
On Thu, Oct 05, 2006 at 11:19:19AM -0700, David Dyer-Bennet wrote:
On 10/5/06, Jeremy Teo <[EMAIL PROTECTED]> wrote:
What would a version FS buy us that cron+ zfs snapshots doesn't?
Finer granularity; no chance of missing a change.
TOPS-20 did this, and it was *tremendously* useful . Snapshots, source
control, and other alternatives aren't, in fact, alternatives.
They're useful in and of themselves, very useful indeed, but they
don't address the same needs as versioning.
VMS _still_ does this, and it's one of my favorite features of the OS.
-brian
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
I too remember VMS and the FS versioning feature.
Doing versioning at the file-system layer allows block-level changes to
be stored, so it doesn't consume enormous amounts of extra space. In
fact, it's more efficient than any versioning software (CVS, SVN,
teamware, etc) for storing versions.
However, there are three BIG drawbacks for using versioning in your FS
(that assumes that it is a tunable parameter and can be turned off for a
FS when not desired):
(1) File listing symantics become a bit of a mess. VMS stores versions
as <filename>;<version> That is, it uses the semi-colon as a
divider. Now, I'm not at all sure how we can make ZFS POSIX-compliant
and still do something like this. Versioning filesystems tend to be a
complete mess - it is hard to present usable information about which
versions are available, and at the same time keep things clean. Even
keeping versions in a hidden dir (say .zfs_versions) in each directory
still leaves that directory filled with a huge mess of files.
(2) File Versioning is no replacement for source code control, as you
miss all the extra features (tagging, branching, comments, etc) that go
with a file version check-in.
(3) Many apps continuously save either temp copies or actual copies of
the file you are working on. This leads to a version explosion, where
you end up with 100s of versions of a commonly used file. This tends to
be worse than useless, as people have an incredibly hard time figuring
out which (older) version they might actually want to look at. And,
this problem ISN'T ever going to go away, as it would require apps to
understand filesystem features for ZFS, which isn't going to happen.
I'd discourage File Versioning at this late stage in UNIX. Source Code
control systems fulfill the need for serious uses, and casual usage is
obviated by the mantra of "save early, save often" that has been beaten
into the userbase. Trying to change that is a recipe for disaster.
Maybe when we change filesystems to a DB, we can look at automatic
versioning again, as a DB can mitigate #1 and #3 issues above, and can
actually implement #2 completely. OracleFS, here I come. (<groan>)
-Erik
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
