[OpenAFS-devel] Solaris afs.rc file damage

[Dean Anderson]

There may not be any degradation. The performance differences come if
you have to replace every syscall with an open/ioctl/close cycle.  This
long cycle is only necessary if your syscall api can't muster a file
discriptor and the open first/close last.  However, I don't think afsd
should have much problem with that. It seems easy enough to have a
global file descriptor in the afsd, so that it doesn't need to
open/close each time.  The afsd can just open the driver once, and close
it on exit.  In that case, the overhead of a syscall is the same as
ioctl.  But it will change the internal afsd syscall api. It doesn't
seem like changing that api would be a big deal.  Is this more complex
than it appears?

		--Dean


On Thu, 12 Apr 2007, Tom Keiser wrote:

> On 4/12/07, Dale Ghent <daleg@umbc.edu> wrote:
> > On Apr 11, 2007, at 5:42 PM, Dean Anderson wrote:
> >
> > > So, I suspect the question should be: Could the afs kernel module be
> > > turned into a driver with an ioctl?  There's a lot in there, and if
> > > anything breaks the general premise that a system call can be cast
> > > as an
> > > ioctl, this would probably be it...
> >
> > This would cure a lot of problems for us. Making OpenAFS Zones-
> > compatible in Solaris is one of them.
> >
> > A afs psudeo device in Solaris would be the best of both worlds... we
> > don't have to play grab-ass with syscall numbers every other Solaris
> > rev, it's easier to implement/maintain, it's still our own interface,
> > and we do things the same way that pretty much everything else in the
> > world does it.
> >
> > I betcha we can also register "/dev/afs" with Sun so that they don't
> > step on that namespace. Either way it would be far easier than asking
> > them to put aside a reserved syscall number for a 3rd party app such
> > as ours. Asking for *that* would probably gets us a "not no, but hell
> > no" response.
> >
> > So, yeah, the AFS syscall is an anachronism that just needs to have a
> > fork stuck in it, plain and simple.
> >
> 
> I can't agree with this until benchmarks show the performance
> degredation of moving everything to ioctls is not statistically
> significant.  There are changes going into the tree which will make
> afs_syscall a signficant factor in system performance for all aspects
> of OpenAFS.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000