[OpenAFS] FW: TR-62286 Outlook PST files in AFS space

[Jeffrey Hutzelman]

On Sun, 20 May 2001 aeneous@speakeasy.org wrote:

> > I assume so..  However then we have a coordination issue to make
> > sure that we don't re-use the same RPC numbers as IBM/Transarc.
> > We have a similar problem with pioctl numbers.

I've been working on setting up what I hope will become a generally
recognized canonical list of AFS protocol constants, including things like
Rx service numbers, RPC numbers, and so on.  So far, I've compiled only a
few of the many lists required; I've been holding off on the rest until I
know whether the major implementors (OpenAFS, Arla, IBM) are willing to
support this sort of coordination.

Properly, pioctls are an implementation detail and not part of the AFS
protocol.  However, the UNIX implementors do seem to be interested in
maintaining some level of compatibility for those operations which they
have in common.

> two easy solutions:
> 1. put it on a different port. or
> 2. make it a different service.  call it "lk", for instance.

I'll avoid commenting on this issue in detaul, except to say that NFS's
"locking" is separate because it was hacked onto the side of an existing
protocol, not because that is a desirable design.  It's worth nothing that
NFS handles locking very poorly.

Applications which have critical dependencies on locking generally warn
users not to put their data in NFS, because of the poor locking semantics.
It is unlikely that we can do any better in AFS with a similar
kludge.  Even with a well-integrated locking protocol, the amount of work
and overhead involved in getting it right is significant.  DFS comes
close, but IIRC DFS tokens have some notable denial-of-service
vulnerabilities.

> As for pioctls -- 
> 1 just reserve a half-dozen up front, or
> 2 skip ahead a few thousand or
> 3 use a magic number in the arguments so the pioctl code can tell that it's an 
> OpenAFS call instead of an IBMAFS call.

It's quite difficult indeed to skip ahead "a few thousand" in a namespace
whose size is only 255.  If you look at the registry page on central.org,
you'll notice that I have proposed reserving a portion of the space for
implementation-specific operations.  I've done the same in the _ioctl_
space, even though that space is rather less crowded at the moment.

In any event, I think ioctl's are irrelevant here -- byte-range locking
in AFS would presumably be accomplished using the same UNIX locking
syscalls as are used for files in other filesystems.  Otherwise, why
bother?

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA