[OpenAFS-devel] Proposed change for handling backup volumes

[Harald Barth]

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

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.

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


Warning: I'm still dreaming of several generations of backup volumes.
I do not know how that would fit into the above scheme. Multi
generations of backup volumes should probably be discussed in another
thread. 

vos backup foo -generations 

would do the same thing as vos backup foo but the created volume will
get another name. For example foo.ba<some-number> the first time and
foo.ba<some-number+1> the next time and so on. As I am painfully aware
that I do not know enough about vldb and volser stuff (but it is
probably time to change that ASAP) I do not know how much implications
such a change would have to the rest of the AFS universe.

Ok, this was not quite conforming to "Subject:" ;-)

Harald.