[geeks] Versioning FIlesystem

[David A de Gruyl]

[this is a long one, main question is "is it worth the effort" -- see 
below]

* on [03-05-23 09:24] vance at neurotica.com wrote:
>On Thu, 22 May 2003, Jonathan C. Patschke wrote:

>> > Couldn't you put kernel-level filesystem support in that, every time
>> > you write a file, writes a file with a newer version number?
>>
>> Yes, but I'd do it as part of the way the system maps namespaces, rather
>> than in the driver for a specific file system.  The problem becomes that
>> you'd have a second "special" character in addition to '/'.  The ':'
>> character makes the most sense.  The point being that you'd get
>> versioning 'for free'.  Of course, you'd probably also need to hack the
>> stat() system call to appropriately show the amount of consumed space
>> for the most recent version in a field separate from the total space,
>> and, at that point, you'd have to add that support to ls and such.

>Doesn't all the automation go out the window if you decide to mount the
>filesystem on another OS?  I mean, if the versioning is in the spec for
>the filesystem, then wouldn't a driver for that filesystem in any new OS
>would have to support it?

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.

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.  

If ffs/ext3/or something is used as a base, and the additional 
information is housed in files with the name <name>:0 or something, then 
the userland programs and the system calls related to files would have 
to change, but versioning could be done on a per file basis.  somehow.

I think that it might be better to make it a mount option for 
filesystem, and if that option is set, then the oddball stuff happens.
If it is not, then the extra files would look like extra files.  I would 
still like to have extra information in the file attributes for the 
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.

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.

In order to make this an integrated part of the operating system, a new 
paradigm for the unix filesystem operations would have to develop.  You 
would have to remember that rm does not work the same on every platform, 
and that you can't always recover old versions.  I think that I (for 
one) could wrap my head around this one.

And I would want it to work over NFS so that for a first pass the local 
machine would provide the most recent version, but would still provide 
versioning on the local disk.  Maybe a "newnfs" could be set up to 
provide a versioning nfs mount option.  Allowing the remote machine 
access to the less recent version.

If you look at the way this is handled in Samba for VMS, I think they 
stuck with the first option above.

As we all know, a major deficiency in the UNIX world has always been 
it's filesystem -- in terms of granularity of permissions and 
attributes.  ACLs have been deveolped to handle this.  They are, for the 
most part, tacked on as afterthoughts.  Perhaps it would be better to 
integrate these with the attributes mentioned above.  

I am aware that this will drastically increase the amount of storage 
required for certain files, but disks are cheap.

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.  

David

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