David Dyer-Bennet wrote:
On 10/6/06, Nicolas Williams <[EMAIL PROTECTED]> wrote:
> >Maybe Erik would find it confusing. I know I would find it
> >_annoying_.
>
> Then leave it set to 1 version
Per-directory? Per-filesystem?
Whatever. What's the actual issue here?
I don't recall that on TOPS-20 it was possible to not version. What
you could do is set your logout.cmd file to purge your space down to
one copy when you logged out.
But see, that assumes you have a logout-type functionality to use. Which
indeed is possible for command-line usage, but then only in a very
limited way. During a typical session, I access almost 20 NFS-mounted
directories. And anyone using autofs/automount trees gets even more.
You're saying that my logout script has to know about all of them to
keep things clean? That's unrealistic. And that still doesn't solve
the problem of people who use SAMBA or NFS from machines which don't
have an interactive shell logout system (i.e. Windows).
This worked fine for the users I knew; even on a system that didn't
have as much as a gigabyte of disk storage total to support a few
dozen software engineers.
The problem is we are comparing apples to oranges in user bases here.
TOPS-20 systems had a couple of dozen users (or, at most, a few
hundred). VMS only slightly more. UNIX/POSIX systems have 10s of
thousands. Plus, the number of files being created under typical modern
systems is at least two (and probably three or four) orders of magnitude
greater. I've got 100,000 files under /usr in Solaris, and almost 1,000
under my home directory. And I don't have anything significant in my
/home (no source code, no build/test trees, just misc business stuff).
What is managable with a few files quickly becomes unwieldy with more
than a few dozen.
This is what Nico and I are talking about: if you turn on file
versioning automatically (even for just a directory, and not a whole
filesystem), the number of files being created explodes geometrically.
> 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?
The version number is part of the file name in all the examples I know
about. I'd find it useless without that; it has to be a real part of
the filesystem, usable by everybody, not a special addon accessible
only with one or two dedicated applications.
Putting the version number/string into the file name is hard for me to
accept. It's what would lead to polluting my directories.
Set your ls default to not show versions. Isn't the problem then
solved? Maybe add that option to the GUI filesystem explorer as well.
But this requires modifying all the relevant apps, which is the same
amount of work as modifying them to use a new FV API. It's not
transparent to the end-user.
In practice, it never was a problem that I noticed, or that other
people noticed. And remember that this was on slower systems with
smaller screens and often rather slower screen update.
Do you not like the idea based on theory, or did you actually use
TOPS-20 for a while and find the versioning troublesome?
Putting the file version number as part of the file name breaks things.
Apps unaware of the special significance of this format will tend to
write similar names, which can screw everything royally.
Example:
Say we use <file>;<version>
In emacs, I edit FOO:2
it will write out a temp file "FOO:2~". So, how does the FS deal with
this the next time they need to create a new version?
The problem lies in that under VMS, the ';' was a special character, and
unusable in normal naming. I suspect a similar situation exists under
TOPS-20. No such luck in a POSIX filesystem - all printable (and many
unprintable) characters are valid for use in filenames. So you _CAN'T_
use them to deliniate File Versioning, without risking blowing the
entire scheme when some random app decides to either use your FV marker
for its own needs, or something similar to the emacs case above.
> 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.
And I find that completely unacceptable; useless. The whole point of
putting versioning in the filesystem is that that makes it accessible
to all programs.
But, because of the explosion in the number of files, you CAN'T
automatically show all versions. Users will NEVER accept this. The only
clean way to do this is to show file versions only upon request. Not by
default.
> >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.
File versions are created when a file is created. In the scenario
where, today, an existing file would be overwritten (deleted), instead
the old file is kept and the new file is given the version number +1
of the old file.
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.
None of those are candidates for file versioning, and a darned good
thing, too.
Honestly, as far as file versioning goes, the time to make a new version
is when calling open() with the appropriate arguments to allow for
append or modification. You obviously don't want to create a new version
if you are only opening a file for read-only access, and changing
version on fsync() is ludicrous, and on close() doesn't differentiate
between a file which has been modified or not.
Given this, we're back into the problem FV is supposed to solve. It is
entirely possible for an editor to keep open a file for a long time,
periodically writing out your changes without issuing a new open().
Word with auto-save turned off is a prime example. Given this, you've
only created a new version when you first load the document, and all
your intermediary changes are lost, since it only saves the document on
close(). Thus, in order to get benefits from FV, your editor must
issue periodic close() and open() commands on the same file, as you
edit, all without your intervention. Exactly how many editors do this?
I have no idea. So, the only way to enable FV is to require the user to
periodically push the "Save" button. Which is how much more different
than the current situation?
-Erik
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
