--On Thursday, January 08, 2009 10:44:19 AM -0800 Russ Allbery
<[email protected]> wrote:
"Steven Jenkins" <[email protected]> writes:
# fs getfid /afs/steven.endpoint.com/osd.1/bin.1.4.8-osd.hartmut
File /afs/steven.endpoint.com/osd.1/bin.1.4.8-osd.hartmut
(536871265.19.333) contained in volume 536871265
then
# /usr/afs/bin/vos split -id osd.1 -newname osd.1.a -dirvnode 19
That's going to be a bit hard to explain to junior staff who aren't really
AFS admins, just people who are supposed to maintain disk space.
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
bin.1.4.8-osd.hartmut
I'd like this a lot better.
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
works today)
Why wouldn't vos do the same thing that fs getfid currently does to get
the vnode?
It should, of course, double-check that the directory name given is within
the volume that one is splitting.
Or relative directory names could actually be taken as relative to the
volume root (unless they start with ./ or ../). This is relatively easy,
if you are running 1.5.5 or newer with dynroot turned on (or, on Linux,
even without dynroot turned on) -- just look at
/afs/.:mount/<cell>:<volume>/<path>
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
