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."
No, you really need an API, otherwise you have to guess when to snapshot versions of files. > >not to mention user confusion. > > Assumption, not supported. Maybe Erik would find it confusing. I know I would find it _annoying_. > >So, FV has to be invisible to non-aware programs. > > yes Interesting that you agree with this when you disagree with Erik's other points! To me this statement implies FV APIs. > >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. > >unless we can use FV over the network, it is useless. > > Wrong Yes, but we have to provide for it. > >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 easier to access versions. All Erik's .zfs_version proposal is about is remote access, not a user interface. > 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. The big question though is: how to snapshot file versions when they are touched/created by applications that are not aware of FV? Certainly not with every write(2). At fsync(2), close(2), open(2) for write/append? What if an application deals in multiple files? Etc... Automatically capturing file versions isn't possible in the general case with applications that aren't aware of FV. > >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. > 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. (I really wouldn't want building code to result in lots of file versions of intermediate and end-result files!) Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
