Source code for arlad.

[Love]

wwshen at engin.umich.edu writes:

> 
>    When I run the arlad, I have the following questions.
> Type: more /afs/umich.edu/README. Then I get the following
> information from the screen: ??? This is my questions???


The common way xfs rpc calls work are:

1. xfs get a request from the vfs layer.
2. xfs checks it cache, and returns if found
3. xfs asks arlad after the wanted information
4. arlad checks it's cache after the wanted information
   and if not found, it talk to the afs-servers.
5. arlad sends an install<insert-favorit-rpc-call-here>.
   Note that first rpc call is still on.
6. xfs insert the data that is got from arlad and the
   install<insert-favorit-rpc-call-here> message,
   and tells arla that the call is done.
7. arlad tells xfs the the first rpc-call is done.
8. if arlad sent an error to xfs, break loop and fail vfscall.
9. goto 2

> more /afs/umich.edu/README
> 
> SWW>> in process_message res=20
> proc_msg: byte = 20
> Rec message: opcode = 2 (getroot), size = 20
> 
> ??? 1. Why does arlad get the opcode for getroot from xfs. This
> may be related to the "more"???

That is part of where you want to find the vnode 
related to /afs/umich.edu/README. It does this by
looking up each compent of the name, this is done
in NetBSD by the function namei in
/afs/stacken.kth.se/src/NetBSD/1.3/sys/sys/kern/vfs_lookup.c
(simplified)

> ??? 2. Similar to Question 1. Why do we need this function for arlad???

(installroot, see above)

> SWW 03/29/98:
>  
>  read_data
>  
> mmap_copyrx2fd: file size=6144 content:
>  
>  ................ /* Unreadable text */
>   
> ??? 3. What does the arlad get from the file server ???

It's quite readable if you know what in there, problaby
you found the "directory-file" for the /afs. All parsing
by this file is done in arlad/adir.c



>  read_data
>  
> mmap_copyrx2fd: file size=21 content:
> #umich.edu:root.cell.
> 
> ??? 4. It seems that arlad communicates with the server
> again and get the cell name. why???

This is where arlad just fetched a mountpoint (created with
fs mkmount), they look this way.

Just for the fun of it you can try to do:
ln -s "#umich.edu:root.cell." foo ; ls foo


> ************************************
> cj>> read_attr calling do_read_attr
> SWW>> read_attr calling do_read_attr done ret=0
> Multi-send: opcode = 5 (installnode), size = 392
> 
> ??? 5. Why does arlad get the upcode installnode from xfs???

No, arlad sends it to xfs, see above.

> multi-sending wakeup: seq = 339, error = 0
> SWW>> Does the arlad send a message to xfs now???
> SWW>> in process_message res=292 the 1th time
> SWW>> in process_message res=324
> proc_msg: byte = 32
> Rec message: opcode = 10 (inactivenode), size = 32
> 
> ??? 6. What does this function do? It seems to be appeared 
> many times in this case???

Its xfs telling arlad that this vnode is not used by xfs
anymore (and can be garbage collected with fear).
The call really comes from the vfs-layer.

> mmap_copyrx2fd: file size=2048 content:
> 
>    ....
> ??? 7. Again, arlad gets some unreadable file from the server.
> Is it related to the file we want to read???

Se ans 3.

> open: before cm_getattr
> open: after cm_getattr
> open: before cm_open
> SWW 03/29/98: enter cm_open
>  
> ??? 8. Now we get the file but why does arlad do so many
> above functions? I can not understand the function inactivenode.??? 

Most of the functions are needed, you cant really get around
them. Remember most data are cached and the second time
there will be less talking between arla and xfs.


Love