Thoughts on extending sharemgr to other protocols

This is the beginning of a new series of articles on possible future enhancements to sharemgr.

The current implementation of sharemgr only supports NFS. Since the initial release, more has been learned about features that will be needed in the framework to support non-NFS protocols. The first change that became obvious is the need for another layer of object to describe shares for protocols such as CIFS that don't use paths as their identifiers. Sharemgr currently allows a single resource name to be associated with a share. This is fine for NFS where it isn't really used. Some protocols want to use the resource name as the share identifier. In that case, there is a need to provide for multiple resource names per share.

What does it mean for sharemgr to support resource objects? 

 First, the command line will need to be changed to accomodate this. Most places where a "-s path" option can be used, a "-r resource" should also be usable. For consistency, I'm proposing that resources are added like shares. That is:

    sharemgr add-share -s /path -r resource group

would add a share /path with resource named resource to group.  If /path already exists in group, then a new resource will be added to /path. Multiple add-share commands can be used to add as many resource names as needed. Note that resource names would need to be unique in the system and, due to requirements in some sharing protocols, would need to be checked in a case-insensitive manner. Some protocols would use resource names simply as an alias for the path while others may have properties associated with the resource. For NFS, resources are always just aliases.

    sharemgr remove-share -s /path -r resource group

would remove resource from the share /path if there are multiple resources. If resource is the last resource, the whole share would be removed. This is necessary in order to deal with sharing protocols that require having at least one resource name.

Now that there are potentially multiple resource names for a share, show command will need to accomodate them. The current syntax for output isn't up to the task. The XML output always gives detailed info, but what I'm proposing for a "show -vp" is something like:

    sharemgr show -vp
    default      nfs=()   newproto=()
               /tmp    nfs=(nosuid=true) newproto=(uid=4321)
                       resource-1=/tmp
                       resource-2=/tmp   newproto=(uid=5432)

The above shows that share with path /tmp is in a group with NFS and a new protocol newproto enabled. The share has properties for both nfs and newproto and two resource names - resource-1 and resource-2. Resource-2 has an override uid property for newproto. Note that since NFS only uses resource names as aliases, you won't ever see properties on the resource level for NFS.

Next: how will this impact current NFS users?

Posted at 02:15PM May 11, 2007 by Douglas McCallum in General  |