Re: Alternate solutions (Was: Re: NFS still has caching problem)

Theodore Y. Ts'o (tytso@mit.edu)
Fri, 26 Jul 1996 13:03:36 -0400


Date: Fri, 26 Jul 1996 00:03:25 -0400 (EDT)
From: G Sumner Hayes <sumner+@cmu.edu>

Not AFS, DFS. Even CMU is planning on shifting to DFS in the near
future as it addresses some of the problems in AFS.

Err... funny, I just came back from the Cartel meeting (a meeting of
CMU, Stanford, U Mich, MIT, and other schools to compare notes and with
our counterparts about providing good central I/S to our schools), where
people like John Leong and Walter Wong (the Andrew System Manager) were
there, and they didn't mention anything about a move to DFS anytime
soon.

A Linux DFS implementation would be a Very Good Thing, IMO.

Certainly, it wouldn't be a bad thing. However, DCE and DFS are *very*
complicated. The place to start is the freeware OSF/1 release of the
DCE RPC, which requires among other things DCE threads (which wasn't
released). So you'd have to take the DCE RPC, and port it to use a
modern POSIX threads interface.

Next, you'd have to write the client-side interfaces of the DCE
directory server (if not a server-side interface to actually test the
client-side code, if you don't have a DCE environment).

Next, you'd have to rewrite the DCE Security Service (client and
server), which is based on Kerberos V5, but has a lot of extra hair
added, and which has been changed to be based on DCE RPC. Just about
the only part of DCE which you wouldn't have to reverse engineer and
reimplement is the DCE Time Service --- we could use NTP instead.

Finally, after all of this infrastructure is recreated, you could think
about trying to cram all of the client side stuff of all of the above
into the kernel, and then try to implement the DCE DFS.

Good luck. It's doable, but it's a very, very, very big project.

- Ted