Conference star::system_management_expertise_center

179.0. "Issue: MODIFY_VOLUME and mounted volumes" by STAR::BARTON () Mon May 12 1997 16:35

Issue: MODIFY_VOLUME changes that ought to take effect immediately but don't.

The TNT_FN_ST_MODIFY_VOLUME function can supposedly modify attributes
of a mounted volume, just as the DCL command SET VOLUME does.  On
closer inspection, however, it looks like we can't do this without
jumping into kernel mode.  Should we only modify attribute values
on disk, and tell users they have to remount the volume to get the
effect of the changes?

Here's an example.  If I type 

    $ SET VOLUME DUA5: /WINDOWS=10

the following happens:

  - the new value of the windows parameter is written to the volume home
    block on disk
  - the new value of the windows parameter is written to the VCB in non-paged
    pool on the system from which I issued the command
  - the value of the windows parameter is NOT CHANGED on other cluster nodes,
    even if the volume is mounted on other nodes.

The SETVOLUME image has to jump into kernel mode to modify the VCB.
We were not planning on jumping into kernel mode, so we would not be
able to change the value of the windows parameter on any live system.
The user would have to dismount and remount the volume in order to get
the change.  In other words, Argus's behavior is different from (and arguably
less powerful than) DCL's.  Is this what we want?

Another question: if we stick with our current plan, what is the difference in
the MODIFY_VOLUME function between changing TNT_ST_VOL_WINDOW and
TNT_ST_VOL_M_WINDOW?  Should it be possible to modify TNT_ST_VOL_WINDOW at all?

I think this generalizes to many MODIFY_VOLUME attributes, though
probably not all.  For example, if we modify the security attributes
(owner and protection) with $SET_SECURITY, I believe they are replicated
to all cluster nodes.