Dynamic root.afs (was Re: [OpenAFS] Directory layout for new cells)
Derek Atkins
warlord@MIT.EDU
16 Nov 2000 12:46:15 -0500
"Neulinger, Nathan R." <nneul@umr.edu> writes:
> Dunno... I wouldn't think that would have to be a prerequisite. I mean - you
> have truly-dynamic root.afs creation, and you have boot-time root.afs
> creation. If you do boot time (easy first-shot approach), just have it
> process the CellServDB at the client. Later iterations of it could add
> cells. Probably would want to have the client automatically add a mount to
> the pseudo volume if it gets a 'fs newcell' command.
>
> Second iteration of the code would be fully dynamic, using cellservdb and
> all the afsdb recs. (Do you really want to use the AFSDB records, or do you
> want to use SRV records? I would think the latter might be a better idea,
> since suport of TXT/SRV is going to be forced by the fact that microsoft
> uses them extensively with ADS.
I think that the approaches for these two mechanisms need not be the
same. In the former case, you just need to supply a mechanism to
build root.afs from fs newcell commands. I don't think that would be
terribly difficult to do. In the latter case, however, you would need
a mechanism for the kernel to request the DNS records for the newly
requested cell (be they AFSDB or SRV, I don't particularly care).
I would certainly prefer not to include DNS directly in the kernel
module, which implies a callback to some user-space process to perform
the DNS request. I'm not sure how this would work, except, perhaps,
another afsd thread that sits waiting for 'callbacks' from the kernel?
Hrm, that might be a reasonable approach for the kernel to know
whether to build root.afs or not -- if the process calls the 'wait for
AFSDB request' afs_call, then the kernel knows it can make requests
for a dynamic root.afs. When it wants to make a request, it wakes up
that thread and returns to user-space; the process then wakes up, does
the DNS request, and then responds back to the kernel with the DNS
response, finally waiting for more requests.
Hrm. I think I like this approach. :)
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available