Maintenance Pack NB_SMU_51_4_M.solaris_dm.tar provides fixes to the VERITAS Storage Migrator (tm) for UNIX on Solaris platforms.

Article:TECH45084  |  Created: 2005-01-22  |  Updated: 2006-01-29  |  Article URL http://www.symantec.com/docs/TECH45084
Article Type
Technical Solution


Environment

Issue



Maintenance Pack NB_SMU_51_4_M.solaris_dm.tar provides fixes to the VERITAS Storage Migrator (tm) for UNIX on Solaris platforms.

Solution



SMU 5.1GA Pack NB_SMU_51_4_M README November 21, 2005
================================================================================
This Maintenance Pack provides fixes to the VERITAS Storage Migrator (VSM).

================================================================================


=================
PACK DEPENDENCIES
=================

-- Installation of this Maintenance Pack requires version 1.19.4.23 of
the Vrts_pack.install.

-- NetBackup Maintenance Pack NB_51_4_M must be installed prior to
installing this Maintenance Pack.


I. DOWNLOAD INSTRUCTIONS
II. INSTALLATION INSTRUCTIONS
III. UNINSTALL INSTRUCTIONS
IV. DESCRIPTIONS OF PROBLEMS FIXED
Current Pack
NB_SMU_51_3_M
NB_SMU_51_2_M
NB_SMU_51_1_M

=========================
I. DOWNLOAD INSTRUCTIONS
=========================
1) Download NB_SMU_51_4_M_<6 digit number>.<platform>.tar into the /tmp
directory.

where <6 digit number> is an internal tracking identifier

where <platform> is hp_11, sgi_dm, or solaris_dm

2) untar NB_SMU_51_4_M_<6 digit number>.<platform>.tar

/bin/tar xvf NB_SMU_51_4_M_<6 digit number>.<platform>.tar

This will create the files:
Vrts_pack.install
VrtsNB_SMU_51_4_M.README
VrtsNB_SMU_51_4_M.<platform>.tar.Z


==============================
II. INSTALLATION INSTRUCTIONS
==============================
As root on the Storage Migrator server:

1) Stop the VSM daemons and all VSM activity by running

/usr/openv/hsm/bin/migVSMshutdown

2) Install Maintenance Pack binaries.

cd /tmp
/bin/sh Vrts_pack.install

3) Restart daemons.

/usr/openv/hsm/bin/migVSMstartup


============================
III. UNINSTALL INSTRUCTIONS
============================
1) Stop the VSM daemons and all VSM activity by running

/usr/openv/hsm/bin/migVSMshutdown

2) Change directory to the patch save directory.
Substitute the pack name for ${PACK} in the following command:

cd /usr/openv/pack/${PACK}/save

3) Run the un-install script:

./Vrts_pack.uninstall

4) Verify that the pack uninstalled successfully by checking
/usr/openv/pack/pack.history.

5) Restart daemons.

/usr/openv/hsm/bin/migVSMstartup


==================================
IV. DESCRIPTION OF PROBLEMS FIXED
==================================
The following are descriptions of the problems fixed. Please read the entire
document before installing.

README Conventions:

Description
Describes a particular problem fix contained in this Maintenance Pack.

** Description **
Describes a problem that can lead to potential data loss. Please
read these problem descriptions carefully.

Workaround
Any available workarounds to a problem are also listed. Workarounds
can be used INSTEAD of applying the patch, however, Symantec strongly
recommends the "best practice" of being at the latest patch level.

Additional Notes
Any additional information regarding this problem or feature is included.


=============
Current pack
=============

================================================================================
Etrack Incident = ET331247

Description:
miggetvol performance was very poor (8 hours for a VOLDB
with 981 entries, with an FHDB of 500MB and FNDB of 250 MB).

--------------------------------------------------------------------------------
Etrack Incident = ET346316

Description:
migdbcheck did not correctly handle filenames that contained the
pipe/vertical bar character.
--------------------------------------------------------------------------------
Etrack Incident = ET346320

Description:
When there was a lot of caching from tape activity, a process could hang
while holding a lock on the MOTAB, causing all other processes that
needed MOTAB access to be blocked.
--------------------------------------------------------------------------------
Etrack Incident = ET342848

Description:
In the VSM scheduler GUI, the HSM name was being used by the migrd daemon
instead of the file system mount point. The vxfs_get_mntinfo call was
previously being called with the HSM name (fsname). The migrd daemon now
uses the mountpoint associated with the HSM name during this call.

--------------------------------------------------------------------------------
Etrack Incident = ET390736

Description:
In migd, the NFS server-daemon, starvation avoidance code creates one user
event for each attempt to read the file. Becasue the NFS client repeatedly
retries the read request for a purged migrated file, this can result in
many user events. This issue causes a lot of system resources to be used.
On HP-UX 11 systems, it can cause DMAPI requests to fail with errno == 11.
--------------------------------------------------------------------------------
Etrack Incident = ET402179

Description:
VSM could not manage filesystems whose mount points had pathnames
of 32 or more characters in length. The migrd log would have error
messages such as:

Cannot determine primary node for /export/local_...integrate_perm

--------------------------------------------------------------------------------

Etrack Incident = ET409350

Description:
Migcopy can get into a loop where it continues to re-issue log messages.

To duplicate the problem.
(1) Migrate a file.
(2) Run migbatch so that migcopy will run to make a copy of the file.
(3) While micopy is making its copy, remove the original file.

The result will be the migcopy loop. The log will show the following
errors until migcopy is killed:

06/01 13:06:57 [1407]migcopy[1560]: 5A0630 gran 5: fh=3E80M2E7FE1
off=x4000000
06/01 13:06:57 [1407]migcopy[1560]: ERROR: Reverting to single buffered
I/O.
06/01 13:06:57 [1407]migcopy[1560]: WARNING: Error accessing granule -
Attempting to find another copy.
06/01 13:06:57 [1407]migcopy[1560]: ERROR: dk_read: dm_read_invis failed
for
offset 83886080, length 16777216, bytes read = -1
06/01 13:06:57 [1407]migcopy[1560]: perror 13: Permission denied
06/01 13:06:57 [1407]migcopy[1560]: ERROR: read_gran: read_one_block failed
with granule_todo=16777216, done=0
06/01 13:06:57 [1407]migcopy[1560]: WARNING: Error accessing granule -
Attempting to find another copy.
06/01 13:06:57 [1407]migcopy[1560]: ERROR: dk_read: dm_read_invis failed
for
offset 83886080, length 16777216, bytes read = -1
06/01 13:06:57 [1407]migcopy[1560]: perror 13: Permission denied
06/01 13:06:57 [1407]migcopy[1560]: ERROR: read_gran: read_one_block failed
with granule_todo=16777216, done=0
06/01 13:06:57 [1407]migcopy[1560]: WARNING: Error accessing granule -
Attempting to find another copy.
06/01 13:06:57 [1407]migcopy[1560]: ERROR: dk_read: dm_read_invis failed
for
offset 83886080, length 16777216, bytes read = -1
06/01 13:06:57 [1407]migcopy[1560]: perror 13: Permission denied
================================================================================

=============
NB_SMU_51_3_M
=============
Etrack Incident = ET287030

Description:
After a system crash the VOLDB may not reflect recently copied files that
the FHDB records as having been successfully copied. The VOLDB record
changes may not yet have been "sync"ed out to disk.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET296458

Description:
migdbcheck would sometimes terminate with a SEGV and core dump.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET299145

Description:
Deleting a hierarchy via the Java GUI would sometimes cause migrd
to dump core.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET310302

Description:
migrd could hang in a CPU loop while deleting hierarchies that had
scheduler items.

Workaround:
Use the VSM GUI to delete scheduler items prior to deleting hierarchy.


(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET312833

Description:
migchangefs sometimes added invalid entries at the end of the migconf file.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET317390

Description:
migd was not performing threshhold checking and automatic
nospace processing. This was a regression in 5.1_2_M.

Workaround:
Revert to the 5.1GA version of migd.

(All VSM Servers)



=============
NB_SMU_51_2_M
=============

Etrack Incident = ET232893

Description:
VSM did unnecessary repeated unmounts and mounts (one for each granule of
data) of the secondary media when the primary media copy was unavailable.

Workaround:
If there are continuing problems with a given VSM copy level (such as,
copy 1), use the LEVEL_PREFERRED file to force VSM to begin with a
different copy.

For example, assume the database directory for the HSM named "music" is
/usr/openv/hsm/database/music/database. Assume that mounts from level 1
are failing and that we wish to always try level 2 first.

Then the following command will make copy 2 the preferred cache level for
this HSM.

echo 2 > /usr/openv/hsm/database/music/database/music.LEVEL_PREFERRED

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET260207

Description:
The VSM-Java GUI could not keep track of which file was selected in the
right window after the column sorting was done.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET259795

Description:
The VSM-Java GUI has an algorithm to prevent offering management of certain
file systems (for example, /tmp and /var). This algorithm neglected to
provide for mount-point pathnames that started similarly to the banned
names but were actually different. For example, /var needs to be banned
however /variety should be eligible for management. The error was that
names such as /variety were banned due to its similarity with /var.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET262992

Description:
In a clustered environment, VSM failover from node A to node B, and then
back again, resulted in the loss of VSM-scheduled jobs on node A.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET270158

Description:
Unexpected syntax errors were encountered when running support.sh. This
change guards against these errors.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET267248

Description:
When migVSMstate was used in rapid succession to change the file system
state to IDLE and then ACTIVE, the IDLING file might not get cleared,
leaving some applications thinking that the file system was still in the
IDLING state.

Workaround:
Wait at least 11 seconds after seeing the file system go IDLE before
changing the state again.

(All VSM Servers)
================================================================================


=============
NB_SMU_51_1_M
=============
Etrack Incident = ET206352

Description:
The miglogscan could core dump if a caching operation was in progress at
the time the log files were restarted.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET206359

Description:
The Storage Migrator File Browser could not see files within directories
that have spaces in their name.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET222089

Description:
migstage would unnecessarily cache from secondary media if there were no
"dk" entry in the FHDB for a migrated file.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET234546

Description:
migmerge fails to backup a large FHDB, instead logging error 72,
"value too large to be stored in datatype".

(All VSM Servers)
================================================================================


Attachments

NB_SMU_51_4_M_280471.solaris_dm.tar (10 MBytes)


Legacy ID



280471


Article URL http://www.symantec.com/docs/TECH45084


Terms of use for this information are found in Legal Notices