[OpenAFS] Re: afs_syscall (Samba as a client of OpenAFS)
Mon, 29 Sep 2008 18:23:24 +0200
Unfortunately I need to solve this in a way or other.
What I've seen looking at the openafs source code (1.4.7) is that while
there are many comments about afs_syscall through the source there
doesn't seem to be any use of it. Looking at the openafs 1.4.7 changelog
the only mention of afs_syscall dates from 2001-02-12 17:15 which
Thanks for any pointer!
> On Sun, 28 Sep 2008, Volker Lendecke wrote:
>> On Sun, Sep 28, 2008 at 09:49:34PM +0200, G�mes G�za wrote:
>>> from which to me the suspicious line seems to be:
>>> afs_syscall(0x14, 0, 0x400c5603, 0xbffcbfd4, 0) = -1 ENOSYS (Function
>>> not implemented)
>>> which I simply don't understand, because the box otherwise is a fully
>>> functional openafs client (and server) test system.
>> Yes, that's very likely the case. Probably the AFS syscall
>> conventions have changed since I wrote the fake kaserver.
> I am pretty sure they have since that code is pretty old and there is a
> newer token format to accodmodate krb5 and different key encryption types.
> IMHO. It would actually be more useful to skip the fakekaserver piece and
> use a krb5 ticket to afs token translation like aklog does it and skip
> anything to do with krb4 altogether. It doesn't help afs cells that still
> use krb4 but those are on the deprecated list anyway.
> Not to discourage you, because I would love to see this done.
> The acl mapping was very slow, and I didnt get quotas to work correctly.
> (it was about 2x as fast to use pam_krb5/pam_afs_session, and unix acls
> mapping as it was to use the afs vfs module) This was either samba late
> 2.x or early 3.0.x pre that big rewrite.
> A -BIG- part of the problem is the Samba IDMAPPING. Windows like to
> "pre-cache" the directory below the current one. so you open up a folder
> with 4000 directories and it wants to pre-cache all of those. It gets
> I don't believe I tested the afs vfs -after- we turned on -fake-stat on
> the afs clients. That actually gave a considerable performance improvement
> given in our case the 4000 directories are all separate volumes.
> Sean O'Malley, Information Technologist
> Michigan State University