Joerg Schilling wrote:
Erik Trimble <[EMAIL PROTECTED]> wrote:
In order for an FV implementation to be useful for this stated purpose,
it must fulfill the following requirements:
(1) Clean interface for users. That is, one must NOT be presented with
a complete list of all versions unless explicitly asked for it, and it
should be simple to select a version based on some reasonable criteria
(date of creation/modification, version number, etc.)
(2) Simple way to decide if a file should be versioned or not. Either
automatically version all files (or none at all), or provide a mechanism
to turn FV on/off on a per-file or per-directory basis.
(3) Network-FS awareness. Without this, FV is severely limited. Given
my preconditions above (that is, the current usage pattern of us in the
non-FS world), limiting FV to those on the local system restricts its
usefulness to the point where it isn't worth the effort.
The only idea I get thast matches this criteria is to have the versions
in the extended attribute name space.
Jörg
Realistically speaking, that's my conclusion, if we want a nice clean,
well-designed solution. You need to hide the versioning info in the
meta-tags, and create a whole new API for accessing/manipulating them.
This easily solves (1) and (2) above, but (3) is the huge problem, as
having a new API means you need to change the SMB/NFS protocols to allow
for client machines to access the new API. With the new Windows NTFS
"versioning", we at least have something to hook into for Windows, but
UNIX clients will need to have a whole new suite of tools written, and a
raft of current apps modified to take advantage of FV.
That said, FV may very well be worth it, and it certainly is worthy of a
community-driven exploratory implementation.
-Erik
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
