[OpenAFS] Re: [OpenAFS-devel] interface for vos split

[Russ Allbery]

"Steven Jenkins" <steven.jenkins@gmail.com> writes:

> I can see why some would like that better, but, for me, the most obvious
> is:
>
> /usr/afs/bin/vos split -id osd.1 -newname osd.1.a -dirname /afs/mycell./a/b/c
>
> i.e., an absolute path.

I expect more of our users to use relative paths (to the current working
directory) than absolute paths, actually.

> The problem with that is that it more or less requires the user of vos
> split to be running in a cache manager so that the volumes and paths
> between / and the directory to split at can be resolved.

> Putting that into a vos command is very difficult.  And traditionally
> vos commands have had no dependencies on a cache manager (getting
> credentials and determining the local cell information are the primary
> exceptions, but there are no filesystem dependencies).

I can see this problem, and from a layering perspective inside AFS, it's
an annoying one.

However, I think I can also say with fairly high confidence that the end
user really does not care about this at all and would even be mystified by
it.  I've never run vos from a system that didn't have a cache manager,
and I'm a fairly sophisticated user.  The distinction made here is one
that I doubt anyone in my team would even know.

It's certainly reasonable to sacrifice usability sometimes to reduce code
complexity.  That may be a good idea to do here -- I don't really have a
strong opinion.  I just wanted to mention that if the command doesn't just
take arbitrary paths, either absolute or relative to the current working
directory, to find the directory on which to split, we are sacrificing
usability and the typical user reaction is going to be "why can't it do
that?"

> fs getfid is in the cache manager.  Since vos is user-space, it doesn't
> have access to the same routines.

I don't think user-space is the word that you want here, since fs is also
a user-space command.  But I know what you mean.

> An RPC to the volserver was suggested as the best way to handle that.

I think that's icky.  I'd use the cache manager.

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