I think there is overall consensus that volume splitting functionality is a good idea. I would like to recommend that we avoid focusing on any particular implementation of the idea at the moment and discuss the use cases for which a user interface and implementations are required.
There are two different groups of users for which I can imagine volume splitting (or combining) would be of interest. Obviously there are afs administrators but there are also end users and I'm sure that afs administrators would like to be able to permit a subset of their users to be able to split or combine their volumes. For the afs administrator it is perfectly reasonable to assume a "vos" command interface which should not be tied to a cache manager. The afs administrator is comfortable working with the concept of volumes. It is therefore not unreasonable to require the administrator to refer to volume ids and paths relative to the volume root directory. For an end user, I would believe that an "fs" command would be more appropriate. The fs command can rely on a cache manager to take more general paths in the name space and resolve them into the necessary volume and relative path. The code could be implemented as common library that is shared by both interfaces. Proposals might include "fs volsplit" and "fs voljoin". The concerns I would have with end user splitting of volumes are: how does the volume id and name allocation get done in such a way that it doesn't violate organizational policies? is being a volume owner sufficient privilege to permit splitting? perhaps volume flags need to be specified to indicate whether a volume is permitted to be split or joined? Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
