Adding a Managed Volume
Enabling the Volume
CLI Storage-Management Guide 9-53
bstnA6k(gbl-ns[wwmed])# volume /acct
bstnA6k(gbl-ns-vol[wwmed~/acct])# enable
bstnA6k(gbl-ns-vol[wwmed~/acct])# ...
The import happens asynchronously, so that you can issue more CLI commands while
the import happens in the background. To check the progress of the import, use
show
namespace [status]
, as described below in “Monitoring the Import.”
Enabling All Shares in the Volume
From gbl-ns-vol mode, you can enable all of the volume’s shares with a single
command. As with a direct volume, you use the
enable shares command to do this
(refer back to “Enabling All Shares in the Volume” on page 8-28). For example, the
following command sequence enables all shares in the “/acct” volume:
bstnA6k(gbl)# namespace wwmed
bstnA6k(gbl-ns[wwmed])# volume /acct
bstnA6k(gbl-ns-vol[wwmed~/acct])# enable shares
bstnA6k(gbl-ns-vol[wwmed~/acct])# ...
Taking Ownership of All Shares (optional)
Before a managed volume imports its shares, it checks the root directory in each share
for a special file that marks it as “owned” by an ARX. If this marker file exists, the
managed volume does not proceed with the import; no two volumes can manage the
same share. You may need to override this safety mechanism for a special case.
Consider an installation that uses legacy, filer-based applications to prepare for
disaster recovery: it copies all of its directories and files from a primary site to filers at
another site. If an ARX manages the directories at the primary site, it places its
ownership marker in the root of each share. The filer-based application copies the
marker files to the remote site, along with all data files. An ARX at the backup site
cannot import these shares because of the markers.
Comentarios a estos manuales