[OpenAFS-devel] interface for vos split

[Steven Jenkins]

On Thu, Jan 8, 2009 at 2:49 PM, Russ Allbery <rra@stanford.edu> wrote:
> "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.
>

Let me clarify a bit more here: your analysis gets quite close to why
I don't care for the -dirname syntax.

fs getfid (like virtually all of the fs subcommands) is implemented by
marshalling arguments and then making a PIOCTL call into the kernel.
Without a cache manager, you can't get a response to that PIOCTL.
Even with a cache manager running, you would need to marshal up the
arguments and make a PIOCTL, which means linking vos.c in with new
libraries.  vos is already huge; I think making it understand how to
do PIOCTL calls would be significant enough to where we would look at
getting rid of fs entirely (i.e., if vos can do one PIOCTL, adding the
rest is relatively straightforward).

I think that would be a bad idea -- hopefully that explanation helps
explain my perspective, but if not, feel free to ask for more
clarification.

On the other hand, if we try to implement relative name mangling in
vos (e.g., via a new volserver RPC), users will constantly question
"Why can't I use an absolute path here?".

Thus it seems to me most straightforward from a user-experience
viewpoint to require the vnode.  and not provide a -dirname option,
but make sure the man page shows how to use fs gettfid to determine
the vnode.  The user experience would not necessarily be ideal, but it
would be consistent, thus less frustrating to the user in the long
run.

-- 
Steven Jenkins
End Point Corporation
http://www.endpoint.com/