[OpenAFS] vos split interface question

[Russ Allbery]

Jeffrey Altman <jaltman@secure-endpoints.com> writes:

> For the afs administrator it is perfectly reasonable to assume a "vos"
> command interface which should not be tied to a cache manager.  The afs
> administrator is comfortable working with the concept of volumes.  It is
> therefore not unreasonable to require the administrator to refer to
> volume ids and paths relative to the volume root directory.

Hm.  I think you may have a higher expectation of what AFS administrators
are likely to understand than I do.  I think they will be able to figure
out paths relative to the root directory, but I think it's extremely
unintuitive for the path to be relative to the volume root directory and
not the current location.

I'm not sure there's much point in implementing relative paths to the
volume root if we can't implement arbitrary paths.  I would lean towards
just requiring fs getfid untli we can implement arbitrary paths.  At the
least, we should reserve the more intuitive -dir option for arbitrary
paths and use a different option for paths relative to the volume root.

> For an end user, I would believe that an "fs" command would be more
> appropriate.  The fs command can rely on a cache manager to take more
> general paths in the name space and resolve them into the necessary
> volume and relative path.

I cannot imagine ever allowing an end user to split volumes at Stanford.
We draw a hard management line at volume creation.  If we were to provide
this functionality to end users, we would do so via a remctl interface to
a system with AFS administrator privileges that would impose our naming
standards.  For example, we require registration of all volumes in a
database as part of the creation, which is handled by the wrappers that we
use.

I'm not sure that's really a useful path to explore.  It feels to me like
a significant change in the AFS authorization model, given that it means
VLDB changes which I believe currently can only be done by people in
UserList.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>