[OpenAFS-devel] Proposed change for handling backup volumes

[Kris Van Hees]

On Mon, Jul 07, 2003 at 11:50:36PM +0200, Harald Barth wrote:
> As this is a change in the behaviour of the kernel, I suppose this
> changes this behaviour for all users? If so, this is not something
> I would use more than once at startup to change the default behaviour.
> 
> I suppose for most of us, the behaviour when traversing mountpoints from
> backup volumes is of limited significance. So what would break with the
> following behaviour:
> 
> In ro volume -#foo-> in ro volume foo (if available, otherwise rw)
> In rw volume -#foo-> in rw volume foo
> In ba volume -#foo-> in ba volume foo (if available, otherwise rw)
>                         ^^
> 
> In ro volume -%foo-> in rw volume foo
> In rw volume -%foo-> in rw volume foo
> In ba volume -%foo-> in rw volume foo
> 
> The folks that want to "get back" to the rw side of the universe
> can allways use rw (%) mountpoints, which in backup volumes have
> the same behaviour as type preserving (#) mountpoints.

Very good point.  So overall, worrying about the behaviour when this mechanism
would be switched on or off is irrelevant since it is just not something you
would do.  The semantics you describe above is exactly what happens with the
patch I submitted.

> > Now, since this is something that can be enabled at runtime, I either need to
> > add code to force re-evaluation of all mountpoints (since the result from the
> > evaluation would be cached), or people who use this would need to issue any
> > 'fs flushv' commands to accomplish the same on request of the user.
> 
> I don't think enabling on runtime is a good idea. The client should be
> one or the other. In addition, /proc is very OS speciffic.

That is a good point.  Solaris of course can tweak this with adb, and such, but
indeed an afsd option is probably very much needed to support all architectures
across the board.  I think that providing /proc still has some merit in the
sense that the same is already done with a few other things that can be tweaked
in OpenAFS (e.g. hardmount variables).  But an afsd switch definitely seems in
dire need.

	Kris