[geeks] Versioning FIlesystem

[David A de Gruyl]

* on [03-05-23 21:44] vance at neurotica.com wrote:
>On Fri, 23 May 2003, David A de Gruyl wrote:

>>
>> If a new filesystem type was created, then the kernel level junk would
>> have to be introduced into any OS that intended to read said filesystem.
>> But, if it is just UFS or similar with additional cruft, then another OS
>> could read it, without the automatic versioning taking place.
>What I'm saying is that if the support for versioning is *specified as
>required* for the new filesystem, then the kernel level stuff would just
>have to be introduced in the new filesystem driver.

I generally agree with you.  You would not want to mount (for example) 
an NTFS filesystem w/o the driver.  I think that this is a significant 
enough departure from the normal filesystem to warrant a type change.

>> I am sort of torn on which way I would prefer.  I think that the fs
>> support should be included in the target OSes, on the one hand.  But the
>> ability to read the files on another (unmodified) OS is also valuable.

>There's just too much that could go wrong if you allow a user to edit
>stuff willy-nilly with no concern about maintaining version integrity.

agreed.  I actually had not thought about reusing an existing fs type 
and allowing access to machines without the modified kernel / fs code, 
until it was mentioned here.  But I accepted that it might be useful.  I 
actually think that it is less useful than it looks.  For the primary 
use, I think that a file server should not be dual booting.  I think 
that if you want this fs, you it should be ported to your desired 
platform.

>> maximum number of revisions to keep, etc.  And to make the revisions 
>> be kept in the smallest portable diff format rather than as full 
>> copies. But editing an older version should be editing the applied 
>> diff, not the diff itself.  Blech.

>That's how VMS does it.  It stores complete revisions of files.  Not just
>diffs.  I don't agree with making it a mount option, however.  It would
>make it far too easy to circumvent version integrity.

The mount option came from SCO.  As far as full file / vs diffs.  Please 
look at  one of my other posts to this thread.  I think that records 
could be used for fine enough grained diffs.  I should look into the 
specifications of the VMS filesytem.



>> Well, this idea came up from "The Unix Hater's Handbook".  And I noticed
>> that it was still fairly unaddressed.  I am starting to understand why.
>> Even blessed rm would have to have a new option to actually remove
>> files, and not just send them in to old version stasis.  And all the
>> fileutils, and find would have to be able to read the version
>> information.

>What version information specifically?  You would only have a bunch of
>files.  find would only need to be modified to match all versions of a
>file.  rm would only have to be modified to only remove the latest
>version.  Plus, a purge command would probably be necessary.

Ok, but you would also need to change the filesystem interactive 
commands.  Also, should ls be made to show only the most recent version, 
or all (or an option for both)? 

>> Is it worth the effort to even look into?  Which OS should I look at --
>> limited choice of Open/Net/FreeBSD and Linux.  I do not have source code
>> licenses for non-free OS.  I am leaning towards OpenBSD, because I
>> rarely have spaghetti code problems there.

>I would use NetBSD, simply because of the wide hardware support.  You'll
>reach a very wide audience very quickly.  It's definitely worth doing, and
>I'll help in any way I can.

I would be inclined to start with OpenBSD, mostly because I really have 
it available.  But I do have machines, and some of them even 
occasionally run NetBSD.  Let me think about it and look into the 
filesystem code on the two OSes.

Linux is probably way out.  I have no patience for that kernel.

As Ross mentioned in a previous post, I have a fair amount of free time 
for a while, so I might get started on this.  It is possible that I 
might even get somewhere.

Serves me right.

David


-- 
David de Gruyl <david at bhaermandegruyl.org>
Princeton(ish), NJ