Re: [zfs-discuss] A versioning FS

[Chad Leigh -- Shire.Net LLC]

On Oct 6, 2006, at 3:53 PM, Nicolas Williams 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."

versions of files.

No, you really need an API, otherwise you have to guess when to snapshot

What does "snapshot versions of files" mean?

My line "Assumption, not supported. "Eye of the beholder"" was in reference to "enormous directory polution"

not to mention user confusion.

Assumption, not supported.

Maybe Erik would find it confusing. I know I would find it _annoying_.

Then leave it set to 1 version

So, FV has to be invisible to non-aware programs.

yes

points!  To me this statement implies FV APIs.

Interesting that you agree with this when you disagree with Erik's other

It has to do with the implementation details. I don't know what sort of APIs you are saying are needed. Maybe they are needed and maybe they would be handy. I am not disputing that. The above should be simple to do however -- a program does an open of a file name "foo.bar". ZFS / the file system routine would use the most recent version by default if no version info is given.

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.

Sure

unless we can use FV over the network, it is useless.

Wrong

Yes, but we have to provide for it.

I never said that file sharing is not useful (in this or any context). I just said that FV is not useless except in the "over the network" use. And if it did not support filesharing scenarios, at least in the beginning, it still has great use. The same way that apache does not support lockfiles on nfs file systems, does not make apache or nfs "useless", FV that is not 100% in every nook and cranny does not make it useless. I would find it of tremendous use just in managing system and configuration files.

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

remote access, not a user interface.

easier to access versions. All Erik's .zfs_version proposal is about is

one UI is the command line shell

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.

Well, file system level meta data that the file system uses may or may not need APIs to expose it -- depends on how the final implementation works. However, I never came out against APIs

touched/created by applications that are not aware of FV?

The big question though is: how to snapshot file versions when they are

Don't use the word snapshot as it may draw in unintended comparisons to snapshot features.

Certainly not with every write(2).

no

At fsync(2), close(2), open(2) for
write/append?

probably

What if an application deals in multiple files?

so?

Etc...


with applications that aren't aware of FV.

Automatically capturing file versions isn't possible in the general case

In most cases it is possible. At worst you make a copy on open and work on the copy, making it the most recent version.

While this may indeed mean that you have all of your changes
around, figuring out which version has them can be massively time-
consuming.

Your assumption.  (And much less hard than using snapshots).

I agree that with ZFS snapshots it could be hard to find the file
versions you want.  I don't agree that the same isn't true with FV
*except* where you have FV-aware applications.

How so?  The shell / desktop is enough of a UI to deal with it.

Yes, any time you do a close() or equivalent. The idea is not to
implement a universal undo stack.

Or open(2) for write, fsync(2)s, unlinks.  Maybe.  It could work for
some apps and not for others.

See my comments above -- worst case is to copy the file on open and then do everything on the copy as normal.

of intermediate and end-result files!)

(I really wouldn't want building code to result in lots of file versions

Chad

No harm as they get deleted by the build process anyway. And if you "enhance" the FV, you can set directories like scratch directories to not allow more than 1 FV per file.

Nico
--

---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss