On Thu, Jan 8, 2009 at 2:49 PM, Russ Allbery <[email protected]> wrote: > "Steven Jenkins" <[email protected]> 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/ _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
