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. _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
