On Fri, Oct 06, 2006 at 04:06:37PM -0600, Chad Leigh -- Shire.Net LLC wrote: > 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." > > > >No, you really need an API, otherwise you have to guess when to > >snapshot > >versions of files. > > What does "snapshot versions of files" mean?
The act of creating file versions ala VMS. > My line "Assumption, not supported. "Eye of the beholder"" was in > reference to "enormous directory polution" Ah. 'Twasn't clear. > > > >>>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 Per-directory? Per-filesystem? > > > >>>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. > > 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. How can version information be given without changing the APIs or putting the version number/string into the file name? Putting the version number/string into the file name is hard for me to accept. It's what would lead to polluting my directories. Now, if the default is 1 version (i.e., keep the current version only), then I might live with it because I'd never change that setting. But if we don't encode the version number/string in the file name and instead enhance APIs and UIs so that by default I can keep N>1 versions without them polluting my directories, THEN I would set N>1. > one UI is the command line shell Indeed! And command-line tools, like ls(1), find(1), etc... What I'm saying is that I'd like to be able to keep multiple versions of my files without "echo *" or "ls" showing them to me by default. I'd like an option for ls(1), find(1) and friends to show file versions, and a way to copy (or, rather, un-hide) selected versions files so that I could now refer to them as usual -- when I do this I don't care to see version numbers in the file name, I just want to give them names. And, maybe, I'd like a way to write globs that match file versions (think of extended globboing, as in KSH). GUIs would, presumably, have a way show/hide file versions, search for them, select them, etc... > >Certainly not with every write(2). > > no Good. > >At fsync(2), close(2), open(2) for > >write/append? > > probably Which? > >What if an application deals in multiple files? > > so? So, file versions aren't useful unless the application explicitly decides tells the OS when to make them. Similarly with applications that keep files open but keep writing transactions in ways that the OS can't isolate without input from the app. E.g., databases. fsync(2) helps here, but lots and lots of fsync(2)s would result in no useful versioning. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
