Conference star::system_management_expertise_center

181.0. "Proposal: mount attributes" by STAR::BARTON () Fri Jun 06 1997 11:57

This note discusses how we handle TNT_ST_VOL_MGMT_TYPE and the
mount attribute (TNT_ST_VOL_M_*) TLVs.  It proposes a protocol change, 
among other things.

Currently: 
    The protocol spec says that if MGMT_TYPE is DCL, then the client 
    can't request mount attributes because they don't apply.
    ("This attribute only applies to volumes whose TNT_ST_VOL_MGMT_TYPE
    is TNT_ST_MT_ARGUS.")

Problems with the current situation:
    The main problems are open issues which cannot be easily
    resolved by client action alone.
    - If a volume is managed by DCL and the user wants to see the
      mount attributes, what do we show?
    - The client could choose a defaulting strategy, e.g., default
      the mount attributes from the current runtime attributes (e.g.,
      TNT_ST_VOL_M_WINDOW from TNT_ST_VOL_WINDOW).  But to do this,
      the client must make two separate requests: one to get the
      management type, the second to get the mount attributes.
      This causes screen flicker and extra message traffic.
    - Suppose the user changes the management type from DCL to ARGUS
      to DCL to ARGUS.  How should we treat the values of the mount
      attributes?  None of our specs addresses this.

Proposal:
    1. Change the protocol to allow mount attributes to be returned
       on any root volume, regardless of management type.
    2. If management type is DCL, then when the server returns a mount 
       attribute
       - the value is a default value, which varies depending on the
         attribute; for most attributes the value is the value of
         the corresponding runtime attribute (e.g., the default for
         TNT_ST_VOL_M_WINDOW is TNT_ST_VOL_WINDOW); for a few attributes
         we will specify the default value (e.g., MEDIUM mount priority).
         We'll decide what to do in each case and document the decisions
         in the protocol spec.
    3. When the client sends a MODIFY request that changes management
       type from DCL to ARGUS, the client will also send values for
       mount attributes whose values change.  The server will
       - scan the request buffer to see if the management type has changed
       - change the management type to ARGUS
       - initialize mount attributes with default values
       - for all mount attributes sent by the client, update the attribute
         value appropriately
       - store management type and mount attributes in the ACS
    4. If management type is ARGUS, then when the server returns a mount 
       attribute
       - the value is the value in the ACS, either the default value or 
         the new value supplied by the client (in "3" above).
    5. When the client sends a MODIFY request that changes management type
       from ARGUS to DCL, the client will NOT send values for any mount
       attributes.  (The client will invalidate all mount attributes
       before encoding the request.)  When the server receives a request 
       to modify management type to DCL, the server discards old values 
       of mount attributes.  On subsequent GET requests for mount attributes, 
       the server will return default values as specified in "2" above.  
       (This means that when you change management type to DCL, you may 
       lose some information. TS.)