On 5/9/2013 1:13 PM, Arne Wiebalck wrote:
> Dear list,
> 
> We've patched our AFS client some years ago adding a sysctl parameter
> that allows to change the R/O preference when crossing mount points. One
> use case is a software build machine that has to build for the standard
> /afs/cellname and cannot build into /afs/.cellname.
> 
> While our approach to achieve this via an additional sysctl is debatable
> (an additional option for afsd was suggested as an alternative), the
> general idea of making the R/O preference configurable may be
> interesting for others and their use cases.
> 
> This post is to see if people find the general idea worth adding to
> openafs, so feedback is welcome.
> 
> Cheers,
>  Arne

There are two sets of issues that are raised here.  The first is the
question of whether there should be an option that can be applied to a
cache manager that alters one of the basic AFS mount point semantics
such that a modified client when provided a canonical path obtains
different data than all of the other clients processing that same path.

By altering the mount point resolution semantic of the client to always
obtain the read/write volume instead of preferring .readonly volumes,
the change impacts not only the data in the "workstation" cell but also
the data in all other cells the client might contact.   I believe that
such a change is inappropriate considering that the cache manager
already provides alternative methods that could be used to achieve the
desired goal.  In particular, the ability to mount a volume other than
root.afs as /afs.

The second issue is whether or not it is safe at run time to change the
mount point resolution behavior.  The answer is that it is not safe.  By
changing the behavior paths suddenly begin to refer to objects which are
different than what they referred to prior the the change.   As a result
this can trigger both data corruption and an application instability in
a number of scenarios.

I do not believe that such an option should be provided by the OpenAFS
distribution.

Jeffrey Altman


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to