[OpenAFS-devel] Proposed change for handling backup volumes

[Derrick J Brashear]

On Mon, 7 Jul 2003, Harald Barth wrote:

>
> > I've implemented a change that makes it possible to request (under control of
> > a kernel module variable (on Linux under control of /proc/sys/afs/bkVolPref))
> > EvalMountPoint to give preference to a backup volume (if one exists) rather
> > than the RO volume (if that exists), if you are crossing a mountpoint from a
> > backup volume.
>
> 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.

If you're using my desktop machine for instance, I reserve the right as
the owner of the machine to change it out from under you at my whim. On a
timeshare system, of course you'd set it or unset it and be done.

> I suppose for most of us, the behaviour when traversing mountpoints from
> backup volumes is of limited significance.

Yup.

> 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)

only the last one should ever change.

> In ro volume -%foo-> in rw volume foo
> In rw volume -%foo-> in rw volume foo
> In ba volume -%foo-> in rw volume foo

these stay the same.

> 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.

you mean currently, yes?

> > 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.

Ignore the discussion of /proc, we already provide a /proc on Linux, if
you want to argue that point, argue it generically. We already have
variables which you set that way on Linux, and with e.g. adb or
/etc/system on Solaris, etc, so that door is already open. The real issue
is semantics for a .backup tree, I think.