Date: Tue, 17 Feb 1998 10:12:21 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: multi-version FS Message-ID: <199802171012.DAA09362@usr07.primenet.com> In-Reply-To: <199802170911.JAA14813@gilberto.physik.RWTH-Aachen.DE> from "Christoph Kukulies" at Feb 17, 98 09:11:02 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Yesterday I had a visit from some sales people of Rational Technologies > who are offering a version control/management under NT (named ClearCase) > which is kind of GUI based (explorer centric) and which establishes a > multi version FS under NT (they say 'developed by the people who > designed the VMS file system' - well, I cannot judge if this can be > considered a big plus :-). Anyway, is there such a thing as a > MVFS (multi version FS) under FreeBSD and would it be worth > taking a look at it ? Versioning operates by creating a namespace incursion into the globbing namespace. The biggest problem with a multiversion FS is that globbing on NT, 95, DOS, and VMS systems is done in the directory lookup system call instead of in the shell. This is a problem for BSD in many way: 1) BSD must push irrelevent data across the user-kernel interface. This makes BSD much higher overhead in all but the "all files" case. 2) For a multiversion FS to function, the file name without the version identifier means "the most recent version". BSD should probably support a kernel globbing mechanism to avoid wasteful dirent transfers. To do this would require modifications to nearly any program that can take file arguments, and be real tough to deal with. Without a kernel globbing mechanism, you could present the most recent version as the name; however, you will fail to get what you want when you say "ls *.c", unless you hack the shell to understand any name without a semicolon to be understood as being suffixed with ";*". Even so, this means you need to prevent the use of semicolon in naming, except as it preceeds the numeric tail. This quickly becaomes a huge problem. You *could* make the most recent version behave as a hard link to the name without the numeric tail. In effect, you would be creating a variant symbolic link type. This is less satisfying than the kernel globbing incursion fix because it breaks some aspects of versioning, but it's probably sufficient for what you need. Doing this trades a namespace incursion for the most recent version of the file (the numeric tail is not presented). This has an impact on the ability to do things like renaming to a specific version number, as frequently occurs in VMS common usage, With this caveat, a stacking FS layer that implements VOP_READDIR againt an underlying FS, and forces a bypass on everything but directory entry manipulation VOP's, would be pretty trivial, if FS stacking worked reliably. You would probably also want to add a user space purge program that understood the semantics, and perhaps a new VOP to allow you to set the limits on how many versions you save (this would actually be better as a tunable in a hidden file on the volume root of the remounted FS. Basically: / | \ | \ /control /root <- presented as root to consumer This is the same way I've described quotas working in the past, though with the quotas, you would probably want to incur into the root directory namespace instead of pushing the hierarchy one. This is because you may want to apply quitas to existing FS's that you couldn't push dow. The namespace issues of a versioning FS layer are so complex that you would probably eat the overhead of always having the code on on an FS where you plan to use it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802171012.DAA09362>