[OpenAFS-devel] AFS/DFS Mount points

[Jeffrey Hutzelman]

On Sunday, April 10, 2005 08:08:39 PM -0700 Christer Bern=E9rus=20
<bernerus@medic.chalmers.se> wrote:

> On 10 apr 2005, at 18.50, Jeffrey Hutzelman wrote:
>
>>>
>>
>> Fortunately, at least for AFS, no transition is required at all,
>> because the problem simply does not exist.  While it is true that AFS
>> mount points are represented as symlinks whose target begins with # or
>> % (denoting the type of mount point), the thing that makes them mount
>> points and not symlinks is their mode.  It is possible to create
>> symlinks to targets starting with '#' or '%' by making an
>> RXAFS_Symlink() call, and clients will treat such links correctly.  It
>> is simply not possible to create such links using the symlink()
>> syscall on an OpenAFS client, because the cache manager interprets
>> such requests as requests to create mount points.
>
> This, IMHO, seems to be a very odd way of implementing things. If I get
> this right, first you create a new type of object in the file system,
> then you make a special RXAFS_api to be able to create the old type of
> object that would otherwise have been created, then you map over an
> existing API to create the new type of object, and finally create an
> administration application to use for creating the new type of object
> that internally will have to use the *old* API. Phew!

It sounds to me like you're confused.

symlink(2) is a system call.
RXAFS_Symlink() is the corresponding fileserver RPC.

Both operations are used for creating symbolic links, and also for creating =

mount points.  This is because as far as the fileserver is concerned, there =

is no difference between a mount point and a symbolic link(*) -- a mount=20
point is just a symlink with a special mode, and only the client cares=20
about that.  Of course, this detail is hidden from user-mode applications;=20
such a program cannot distinguish between mount points and ordinary=20
directories except by using special pioctl() operations for manipulating=20
mount points.

Now, the thing to bear in mind is that one of the IN arguments to=20
RXAFS_Symlink is an AFSStoreStatus, containing various attributes of the=20
link to be created, including its mode.  So to create a mount point, the=20
client simply passes in the correct mode.  The symlink() syscall, however,=20
does not take such an argument.  So the OpenAFS cache manager's=20
implementation of symlink() guesses what the application means, based on=20
the first character of the provided link target.  If the first character is =

'#' or '%', then it uses mode 0644, indicating a mount point; otherwise it=20
uses mode 0755, indicating a symbolic link.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA