[OpenAFS] vos split interface question
Thu, 8 Jan 2009 13:42:55 -0500
I've been recently looking at Rx OSD again, and the vos split
functionality in particular. I have some questions about the user
interface that I think the community as a whole might want to give
First, a refresher on vos split:
# /usr/afs/bin/vos help split
/usr/afs/bin/vos splitvolume: split a volume at a certain directory.
Usage: /usr/afs/bin/vos splitvolume -id <volume name or ID> -newname
<name of the new volume> -dirvnode <vnode number of directory where
the volume should be split> [-cell <cell name>] [-noauth] [-localauth]
[-verbose] [-encrypt] [-noresolve] [-help]
so you can use vos split to take a large, unwieldy volume and break it
into more manageable pieces.
With respect to the interface, the user of vos split has to provide
the vnode of the directory where the volume should be split. Now,
this is not extremely difficult, as fs getfid /path/to/directory will
yield the fid, so the user can extract the vnode from that. For
# fs getfid /afs/steven.endpoint.com/osd.1/bin.1.4.8-osd.hartmut
(536871265.19.333) contained in volume 536871265
# /usr/afs/bin/vos split -id osd.1 -newname osd.1.a -dirvnode 19
However, there was a discussion some time back that requiring the user
to know the vnode is cumbersome, and that a better interface would let
the use specify the relative path from the root of the volume: e.g.,
# /usr/afs/bin/vos split -id osd.1 -newname osd.1.a -dirname
So some questions on that:
1- Is the current user interface undesirable?
2- Is the suggested interface better?
3- If the suggested interface is better, how should the interface be
implemented? The suggestion I received was to add an RPC to vos;
would we want that interface exposed (e.g., as a vos command), or
would it be better to stay as an internal RPC (much as AFSVolForward
4- If the suggested interface is not better, what suggestions are
there for a more clear interface?
My personal thought is that while the current interface is a little
awkward, the new interface I sketched above is a little more
user-friendly but not necessarily a lot better.
I suggest that we simply keep the current interface, but if the new
interface(s) is(are) needed, I can add that.
End Point Corporation