[OpenAFS] [Elders] OpenAFS Project List

[Phil.Moore@msdw.com]

>>>>> "Phil" == Phil Moore <Phil.Moore@msdw.com>:
>>>>> "Russ" == Russ Allbery <rra@stanford.edu>:

Phil> Did anyone on this list ever see my presentation at Decorum '97?  VMS
Phil> is the single most important thing I ever did for AFS at MSDW, and its
Phil> the backbone of our entire UNIX development environment (and but for
Phil> politics and stupidity, could have been so for NT, but...)

Phil> VMS is discussed, at a high level, in:

Phil> http://www.mindspring.com/~wpm/decorum97/

Russ> Yup, having a relational database with information about what's
Russ> where has been a huge win for us, even though right now we use
Russ> it almost exclusively for reporting purposes and not to actually
Russ> drive any management tools.  I'm looking at extending what we're
Russ> doing further to support things like usage statistics on our
Russ> software volumes.

VMS went very, very far, down the opath of automated administration,
to the point where our AFS administrators almost never even use "vos"
directly to create volumes.

In a large scale environment like ours, this was essential, since we
have a high turnover rate, and keeping people around with the level of
AFS expertise necessary to get the manual operations right isn't
feasible.

What I would like to do, if I can find the time (and I *will* hunt for
it), is to create a single-cell, standalong version of VMS that works
with a mySql database, as a proof of principle.

If enough people get inspired by the ideas in VMS, which are really
about namespace management for scalable change control in a VERY large
environment, then perhaps VMS has a future outside of MSDW.

We'll see.... (don't hold your breath on this just yet -- you will
turn blue, I promise).

Phil> We use networker with vosasm, last time I looked, which was 3 years
Phil> ago.  I don't think that's changed, but all we'll be doing is making
Phil> sure the networker/vosasm backup option is sufficiently documented.

Russ> Is this the Boxhill vosasm?  I thought that stuff wasn't
Russ> available any longer?  (We used it for years and years, but then
Russ> eventually switched to ADSM so that we could get per-file
Russ> backups and better scaling; vosasm did okay, but Networker
Russ> itself just wouldn't scale to the size of our cell.)

Yes, it is.  And yes, networker scalability has not been stellar (I'm
trying to be nice).  As for availability, I have no idea; you are
likely correct.

It is an option, and we'll have to be objective about documenting the
pros/cons.  Lack of availability will be a pretty big con ;-)

Phil> The old perl4 API I wrote is very, very long in the tooth, and while
Phil> its powerful, its also slow (fork/exec's to hell and back), and I've
Phil> since learned the ins/outs of perl5 XS programming, and enough about
Phil> OO design to get myself into trouble.

Phil> I'll be participating in the development of the new XS based modules,
Phil> and see what kind of value I can add to that effort.

Russ> There's an existing XS-based Perl 5 module written some time
Russ> back by Roland Schemers here at Stanford, and I think that's the
Russ> work that other people are picking up and improving.  (The pure
Russ> version won't compile any more and hasn't since about AFS 3.4,
Russ> IIRC.  Too much stuff has changed in the library interfaces.)

Norbert Gruener <nog@MPA-Garching.MPG.DE> and I have already started
communicating off-line, and this is something I am very keen to see
succeed.

There has never been anything on CPAN, and IM!HO, that is really
required for wide acceptance in the perl development community.  

This is likely to be the one area where I am able tto contribute the
most (other than tacking copyrights on existing MSDW code, and tossing
it over the wall), given my background.

This, I hope we can deliver on, incrementally, this year.

Russ> All of our internal tools right now just fork and exec the
Russ> various standard client programs.

And that turns out to be the biggest performance bottleneck in the
larger applications we;'ve developed (eg. behemoth systems like VMS,
but also simple command line utilities).