[OpenAFS] Re: why afs backup is so poorly supported

[Marcus Watts]

Adam Megacz <megacz@cs.berkeley.edu> writes:
> Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> > and many of its features depend on the fact that all file access is
> > via the fileserver.
> 
> I agree.
> 
> I'm starting to come around to the conclusion that the on-disk format
> exists primarily for obfuscational purposes -- that is, it is the most
> effective way to discourage people from locally modifying shared files.
> 
> If you look at it that way, it makes a lot of sense.  I guess there
> really is no better way to reduce the chances that somebody
> (benevolent) with local root will decide that today is a fine day to
> "emacs /vicepa/your-volume-bits-here".

I doubt this was a deliberate intention, although it may have been
considered an accidental good feature.  In 1988, most clever people had
already figured out that you don't want to run regular things on your
fileserver.  Obfuscation might still have been seen as helpful when
explaining to bean-counter type people why the fileserver shouldn't
also be the mail server, or to make easier to pretend absolute ignorance
of the boss's porn collection.  However, the lack of any reasonable
way to manage AFS identities, mount points, and acls in the filesystem
was surely the over-riding concern.  Those problems are still largely
true today (although I suppose one could use ext2fs's extended attribute
space, for linux...)

> 
> I mean, they have local root, what are you going to do?
> 
> > AFS is not intended to solve the "share your local filesystem"
> > problem.  It was designed as a scalable, manageable distributed
> > filesystem
> > ... 
> > The two problems are very different, and require different
> > solutions.
> 
> They share a very large common subproblem.
> 
> In fact, the former is almost completely a subset of the latter.  I
> think this is a compelling argument for modularity.  Some of the
> vos-like features that are starting to show up in zfs are a good
> start...

The physical filesystem of your fileserver is purely an implementation
choice.  There have been many different implementations -- the Unix
"inode" flavor was an early popular choice.  There was an MVS based
flavor, which used its own database layout directly on top of a
physical storage device accessed by the use of memory mapping.  The
namei filesystem is in fact a fairly recent invention, and it won't be
the last one, its deficiencies are already well-known.

I don't know of any attempts to map AFS 3 directly onto local storage,
but the DFS (=AFS 4) folks did just this.  The DFS export of local
space had important limitations, and so would any such attempt that was
layered on top of any unix filesystem with any claim to generic
portability.  This is not unique to AFS/Unix, or even network
filesystems.  You can mount NTFS filesystems in linux, and EXT2FS
filesystems in windows, and in both cases, you lose functionality
wherever foreign filesystem semantics don't match host operating system
functionality.

If it's important to you to use the local filesystem directly as your
AFS store, you should be able to implement this fairly easily.  There's
nothing that magical about the AFS filesystem protocol that you can't
duplicate.  You'll have to do something about forging local user
credentials, which will be painful, and there will be features such as
acls, volumes, etc., which you'll just have to fudge - just like the
DCE folks.

If you come up with an implementation other people want to run, then
maybe it can become part of the openafs distribution.  In order for
that to happen, you (or somebody) will probably have to solve the
"departmental fileserver" keyfile problem; this is already on the list
of things-that-need-doing.

There's another possiblity that could also be of interest.  A
filesystem is nothing more than a specialized database system,
optimized for the storage of variable sized pieces of data.  A database
system is nothing more than a specialized filesystem, optimized for
complicated queries on multiple attribute data.  Even historically,
this was well recognized.  DEC RMS-11.  MTS line numbered files.  360
ckd dasd with record searching in hardware.  PICK OS.  Mumps-11.  Etc.
So, instead of bothering with the host os filesystem, one could choose
to use any popular database system instead.  For instance, take
oracle.  It has large blob support, ideal for byte structured files.
It also has commit/rollback, making it a trivial task to ensure
"application"(=AFS) data integrity.  PostgreSQL would be a fine open
source equivalent.  The Berkeley btree code (maybe with transactions)
would be another interesting choice - with interesting licensing
constraints (but reiserfs & zfs both have those problems as well).
Mysql is another possiblity.

					-Marcus Watts