Back to sharemgr - interactions with SMF

Today's article will describe in more detail how sharemgr interacts with the SMF system.

As was mentioned earlier, each sharemgr group is implemented as an instance of the svc:/network/shares/group service. The configuration information for each share is kept in the SMF repository.

The "default" instance always exists and is where shares that were originally specified in the /etc/dfs/dfstab file will be stored. Also, shares that are started with the "share" command will appear as transient shares in the default group.

The other group that always exists is the "zfs" group. This is a special case group where none of the shares are stored in the SMF repository since ZFS manages the configuration information. This group exists in order to start shares at boot time. ZFS interactions will be covered in a future article.

Share groups provide a boot time advantage for large configurations since all of the instances of the group service are started in parallel by SMF. The startup also eliminates the need to run the share command for each share (the traditional model just ran the commands in /etc/dfs/dfstab as a script). The sharemgr command sees the full configuration and starts each share directly. The NFS service (svc:/network/nfs/server) has a dependency on the group service. This causes all of the enabled group instances to be started when the nfs/server service is started.

Associated with a group are protocol specific property sets. These are implemented in the SMF repository as property groups. The details of these property groups are currently subject to change and the details really are protocol specific.  NFS is currently supported but we will likely add more in the future.  The property groups come in two forms.  One for the general properties associated with the protocol and others that are different negotiated property spaces.  For NFS, this latter is how the security properties are handled. Properties are currently implemented using the same name that is defined in share_nfs(1m) and can be seen with the svcprop command.

Shares are also currently implemented as property groups. Since SMF has limitations on which characters that can be used in a property or property group name, the names used for shares are constructed with a GUID (Globally Unique IDentifier) using libuuid. The "path" property within the constructed property group contains the share path. Other properties may also appear in the property group for a share. If you are looking at properties with svcprop, the property groups with a name of the form "S-<GUID>" are related to individual shares. This is for information purposes only. Since the properties and property groups could change in the future, it isn't advisable to modify them directly.

Whenever the sharemgr or sharectl commands make a change to properties that would have an effect on the state of the service, the appropriate parts are notified. Changes to shares directly update the service's idea of the configuration using a protocol specific plugin module. Sharectl issues the appropriate restart commands to the affected protocol service modules.

Because the groups are implemented as service instances, it is possible to enable/disable groups individually thus giving the administrator more control over how and when things are shared.  

Comments:

Post a Comment:
Comments are closed for this entry.
About

dougm

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today