[OpenAFS] Re: afs_syscall (Samba as a client of OpenAFS)
Sean O'Malley
omalleys@msu.edu
Mon, 29 Sep 2008 09:18:01 -0400 (EDT)
On Sun, 28 Sep 2008, Volker Lendecke wrote:
> On Sun, Sep 28, 2008 at 09:49:34PM +0200, G=E9mes G=E9za wrote:
> > from which to me the suspicious line seems to be:
> > afs_syscall(0x14, 0, 0x400c5603, 0xbffcbfd4, 0) =3D -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
slow.
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
--------------------------------------
Sean O'Malley, Information Technologist
Michigan State University
-------------------------------------