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 predates fake-kaserver.
Thanks for any pointer! Geza > 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 > 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 > ------------------------------------- > > > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
