On Tuesday, October 25, 2005 06:10:51 PM +0200 Peter Somogyi
<[EMAIL PROTECTED]> wrote:
I've looked into the libafs source, and found the root cause of our
problem: afs_pioctl.c, DECL_PIOCTL(PUnlog):
...
# ifdef UKERNEL
/* set the expire times to 0, causes
* afs_GCUserData to remove this entry
*/
tu->ct.EndTimestamp = 0;
tu->tokenTime = 0;
# endif /* UKERNEL */
GCUserData will still remove the entry (and destroy the connections)
without that code, it just won't do so until some time after the tokens
expire. I'm not sure why someone thought it was important to get them
right away on the next pass in the UKERNEL case. I agree that including
those operations will make unlog'd PAG's go away faster, but at the expense
of some churning in the cases where people unlog and then immediately get
new tokens. I don't know if there might be other negative effects.
- is our "km_afs" rpm wrong (km_afs-1.4-rc4 - generated based upon our
special openafs.spec) that it doesn't define UKERNEL, or our openafs.spec
is wrong that it doesn't define UKERNEL?
Neither. It's not supposed to be defined.
- why the above code part depends on UKERNEL flag?
Presumably someone thought it was really important to nuke the connections
on the next pass in the UKERNEL case.
- what does UKERNEL means really? What effect can I have if I turn it on
somehow?
It's define when building the user-mode cache manager library. It is never
defined when building kernel modules. If you turn it on, you will get the
effect that your module will break, if it compiles at all.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
