Maintenance Pack NB_SMU_51_7_M.sgi_dm.tar provides fixes to the Veritas Storage Migrator (tm) for UNIX on SGI IRIX platforms.

Article:TECH59443  |  Created: 2008-01-09  |  Updated: 2008-01-16  |  Article URL http://www.symantec.com/docs/TECH59443
Article Type
Technical Solution


Environment

Problem



Maintenance Pack NB_SMU_51_7_M.sgi_dm.tar provides fixes to the Veritas Storage Migrator (tm) for UNIX on SGI IRIX platforms.

Solution



SMU 5.1GA Pack NB_SMU_51_7_M README April 9, 2008
Requirement: NB_CLT_51_7_M
================================================================================
** All 5.1 MP7 Maintenance Packs for NetBackup server, client, all Add-on
products, Database Agents, and Java user interface must be applied so that the
entire system is at the same Maintenance Pack level. **

This Maintenance Pack provides fixes to the Veritas Storage Migrator (tm).
================================================================================


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

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

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


I. KNOWN ISSUES
II. DOWNLOAD INSTRUCTIONS
III. INSTALLATION INSTRUCTIONS
IV. UNINSTALL INSTRUCTIONS
V. CURRENT MAINTENANCE PACK INDEX
VI. MAINTENANCE PACK CONTENT
Conventions
Current Maintenance Pack
NB_SMU_51_7_M
Maintenance Pack History
NB_SMU_51_6_M
NB_SMU_51_5_M
NB_SMU_51_4_M
NB_SMU_51_3_M
NB_SMU_51_2_M
NB_SMU_51_1_M



===============
I. KNOWN ISSUES
===============
There are no known issues associated with this pack.



=========================
II. DOWNLOAD INSTRUCTIONS
=========================
1) Download NB_SMU_51_7_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_7_M_<6 digit number>.<platform>.tar

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

This will create the files:
Vrts_pack.install
VrtsNB_SMU_51_7_M.README
VrtsNB_SMU_51_7_M.postinstall (on solaris_dm ONLY)
VrtsNB_SMU_51_7_M.<platform>.tar.Z




==============================
III. INSTALLATION INSTRUCTIONS
==============================
As root on the Veritas Storage Migrator (VSM) 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




==========================
IV. 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




=================================
V. CURRENT MAINTENANCE PACK INDEX
==================================

This section contains a master index for all UNIX packages of Etracks that
have been fixed in this release, sorted according to the containers that
they comprise.


NB_51_7_M
---------
864299 803914 855261 809097 626028 796294 916377 931956 799780 588059
974381 974444 864404 765989 974543 974560 974576 613967 974593 851795
960587 791344 792614 641161 990875 853611 992950 992224 838850 994257
832058 999760 834091 569133 648728 1012143 937822 1024942 900036 830908
794492 851131 1028406 1018104 1011098 1017070 1018057 1008445 1048007 1047980
641107 865175 1050394 1026333 961803 1052552 1051475 1044733 1039798 922083
856171 786038 1086514 1069421 996445 544464 1054434 1089297 1072959 1098168
609285 788888 1099541 1027606 538369 1112394 701769 1081406 1115243 1103634
936894 1125018 778028 700174 801849 1130931 1146631 1153680 1154413 1153705
1143280 1153682 1157916 1138473 1157873 1139684 1159798 1178479 1163511 1174600
1128916 1196687 1204221 1177688 767310 1162318 1205880 1187782 1109610 1212575
1208127 1214792 1215485 1062059 1219900 1213933 1211654 1224500 1201520 1229733
1205887 1229842 1232677

NB_ADC_51_7_M
-------------
1061658 864986 1179362 1027606 1207931 1115341 1210134 1214177 1224610 1211654


NB_CLT_51_7_M
-------------
864299 803914 855261 809097 626028 796294 916377 931956 592675 799780
634887 588059 974381 974444 864404 765989 974543 974560 974576 613967
974593 851795 960587 791344 792614 641161 853590 970485 990875 853611
992950 992224 838850 994257 832058 999760 834091 569133 648728 1012143
937822 1024942 900036 830908 794492 851131 1028406 1018104 1011098 1017070
1018057 1008445 1048007 1047980 641107 865175 1050394 1026333 961803 1052552
1051475 1044733 1039798 922083 856171 786038 1086514 1069421 996445 544464
1054434 1089297 1072959 843819 1098168 609285 788888 1099541 1027606 538369
1112394 701769 1081406 1115243 1103634 936894 1044592 1125018 778028 700174
801849 1130931 1146631 1153680 1154413 1153705 1143280 1153682 1157916 1138473
1157873 1139684 1159798 1178479 1163511 1174600 1128916 1196687 1204221 1177688
786840 767310 1162318 1205880 857477 936801 927552 850960 1187782 1109610
1204204 1212575 1208127 1214792 1215485 1030196 1062059 1219900 1213933 796520
1037547 932186 1204966 1211654 1224500 1201520 1229733 1205887 1229842 1232677


NB_DB2_51_7_M
-------------
855604 857632 860184 634873 1211654

NB_DMP_51_7_M
-------------
968678 1020130 1051661 647774 848039 1211654

NB_ENC_51_7_M
-------------
1211654

NB_GDM_51_7_M
-------------
1211654

NB_INX_51_7_M
-------------
899875 1211654

NB_JAV_51_7_M
-------------
627154 1132843 1187773 1052118 1223808

NB_LOT_51_7_M
-------------
969296 1087403 866340 1211654

NB_ORA_51_7_M
-------------
703738 798183 922330 923487 643840 962849 892842 545686 614431 967520
996123 995113 999688 416963 999686 1175312 1095134 1224663 1211654

NB_SAP_51_7_M
-------------
1211654

NB_SMC_51_7_M
-------------
1211654

NB_SMU_51_7_M
-------------
866957 966607 1013022 1078478 1101107 1211654

NB_SYB_51_7_M
-------------
586573 1211654

NB_VLT_51_7_M
-------------
857213 973097 1104858 1169330 1218761 1211654




============================
VI. MAINTENANCE PACK CONTENT
============================
This section contains the Maintenance Pack conventions, content, and historical
content that is applicable to the release.

Conventions:
------------
The following list describes the conventions used in the subsections that
following this section. Each item listed in the Current Maintenance Pack
subsection describes a feature, enhancement, or issue fixed with this
Maintenance Pack.

Description
Describes a particular problem 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 available patch level.

Additional Notes
Any additional information regarding a problem is included.



Current Maintenance Pack
------------------------
Each item listed in this section describes a feature, enhancement, or change
that comprises this Maintenance Pack. Please read this section thoroughly to
understand the contents of this update.
--------------------------------------------------------------------------------
Etrack Incident = ET866957
Associated Primary Etrack = ET861002
Titan cases: 220-082-818

Description:
This fix ensures that the VOLDB does not get truncated if the database
filesystem fills during a merge operation.
--------------------------------------------------------------------------------
Etrack Incident = ET966607
Associated Primary Etrack = ET960560
Titan cases: 220-088-901

Description:
migtrans kept the VOLDB open, holding a lock on the VOLDB.LK file, for the
duration of its run. This prevented nospace processing, if necessary, from
being able to run to completion because migmerge could not get a lock.
--------------------------------------------------------------------------------
Etrack Incident = ET1013022

Description:
migsetdb would sometimes log a spurious "FHDB not locked" message and in
some cases could get into an infinite loop when trying to set a volume to
be empty.
--------------------------------------------------------------------------------
Etrack Incident = ET1078478

Description:
The VSM Java GUI (migsa) incorrectly grays out commands when it is
connected to the file system primary node in a cluster.
--------------------------------------------------------------------------------
Etrack Incident = ET1101107
Titan cases: 220-102-240

Description:
Consolidation ran even though an incorrect method was specified for an
input volume. Although no granules were consolidated, the volume was
still recycled. The fix verifies that the correct method has been
specified for all input volumes before continuing with consolidation.

Workaround:
Make sure that the correct method is specified for all consolidation input
volumes.
--------------------------------------------------------------------------------
Etrack Incident = ET1211654
Associated Primary Etrack = ET1174784
Titan cases: 220-147-432

Description:
Buffer overflow areas have been identified and corrected in daemons running
on Veritas NetBackup master, media, and client servers. Successful access
to a vulnerable Veritas NetBackup server and the ability to successfully
execute arbitrary code could potentially result in unauthorized access with
elevated privileges on a system.
--------------------------------------------------------------------------------



Maintenance Pack History
------------------------

This section contains an accumulative list of all Maintenance Pack information
contained in previous releases.

=============
NB_SMU_51_6_M
=============

Etrack Incident = ET543111
Associated Primary Etrack = ET763865
Titan cases: 240-209-323 280-540-098

Description:
It is possible for a DMAPI read managed region to exist on a portion of a
file that is actually still on disk. In VxFS levels 3.5 and earlier this
is not a problem. For Solaris VxFS 4.0 (and later releases) this DMAPI
read managed region causes a problem when a process attempts to read the
file.

The VSM daemon migd loops forever processing the event, and the event
is continually regenerated.

If this happens, the following type of entries are in the Global VSM log
(/tmp/hsm.log).

01/27 15:12:40 [1]migd[29660]: INFO: token=4559 DM_EVENT_READ (17),
offset=0 len =8192 sum=8192 dmapi handle=
00000000045cc738000e114000000000000000002cc64a4b0000010000000000

01/27 15:12:40 [1]migd[29660]: INFO: token=4561 DM_EVENT_READ (17),
offset=0 len =8192 sum=8192 dmapi handle=
00000000045cc738000e114000000000000000002cc64a4b0000010000000000

etc....

This is a problem on Solaris only because VxFS 4.0 is not supported on
HP-UX systems. VxFS is not available on SGI/Irix systems.
--------------------------------------------------------------------------------
Etrack Incident = ET545862
Titan cases: 280-549-534

Description:
If a migrated file has been renamed, an attempt to migcat the file fails.

In following data is reported in the HSM log:
2/16 16:55:23 [29646]migin[29650]: starting reload of file 1F40MB85C16
02/16 16:55:23 [29646]migin[29650]: proc_start
/usr/openv/hsm/bin/admincmd/migcopy
02/16 16:55:23 [29650]migcopy[29654]: Streaming -M -s 1846908 -t 1 -o user8
/tmp/miginlvaq65
02/16 16:55:23 [29650]migcopy[29654]: reading from /tmp/miginlvaq65
02/16 16:55:23 [29650]migcopy[29654]: ERROR: copy_file: dm_path_to_handle
failed
for
02/16 16:55:23 [29650]migcopy[29654]: perror 2: No such file or directory
02/16 16:55:23 [29650]migcopy[29654]: REPORT: 1F40MB85C16 1 5071 3 0 0 0 11533
02/16 16:55:23 [29650]migcopy[29654]: ERROR: Failed to copy 0xB85C16; tret = 3
02/16 16:55:23 [29650]migcopy[29654]: ERROR: copy_for_method() ret=3

Workaround:
To resolve this issue, rename the file back to it's original name before
doing the migcat.
--------------------------------------------------------------------------------
Etrack Incident = ET536672
Titan cases: 230-102-748

Description:
A problem can occur when a tape written by VSM on an SGI (IRIX) system is
read by VSM on a Solaris or HP-UX system. When the last granule for the
file contains an odd number of bytes, and when the last byte has the top
bit set, the checksum calculation on SGI differs from the checksum
calculation on Solaris or HP-UX by 1. This causes a cache of the file on
Solaris or HP-UX to fail with a CRC error.

The fix is to detect this "off by 1" condition in migcopy and to allow the
checksum difference. When the off by one condition occurs, the following
two INFO messages are logged in the HSM log.

1/27 17:00:42 [5345]migcopy[5346]: INFO: On media crc 3579 != 3580 current crc
for Handle 3E8M1974A at offset 0x0.
01/27 17:00:42 [5345]migcopy[5346]: INFO: The difference will be ignored -
assuming the granule came from IRIX.

Workaround:
You can use the "-c" option on migstage to cache a file back and ignore
crc errors. This will allow the "manual" cache of such a file on a
non-SGI platform.
--------------------------------------------------------------------------------
Etrack Incident = ET615596

Description:
"migconfg <hsmname>" deletes the <hsmname> entry from the VSM global
configuration file.

Workaround:
Always specify either "-a" or "-d", whichever is appropriate, to add or
delete an entry from the global configuration file.
--------------------------------------------------------------------------------
Etrack Incident = ET616179

Description:
migsweep might never select any files for migration.
--------------------------------------------------------------------------------
Etrack Incident = ET634148
Titan cases: 280-547-439

Description:
When backing up files on a VSM managed file system, bpbkar would keep the
FHDB open and locked, which would lock out all VSM activity for the
duration of the backup.

Workaround:
To avoid this issue, do not run NetBackup backups and VSM processes
concurrently.




=============
NB_SMU_51_5_M
=============

Etrack Incident = ET513662

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



=============
NB_SMU_51_4_M
=============
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:
If an hsmname and its mountpoint with respect to root were
different, scheduled jobs for that HSM did not run.
--------------------------------------------------------------------------------
Etrack Incident = ET390736

Description:
Too many DMAPI user events were generated when an NFS server was
exporting a VSM managed filesystem. The generated user events use system
resources. The system resources were freed when the file needed by the
NFS server was finally cached by VSM.

On HP-UX 11 systems, the resource usage by the user events could cause
other HSM operations to fail with perror = 11 (EAGAIN).
--------------------------------------------------------------------------------
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 = ET408740

Description:
Ensure that the VxFS 4.1 file system changelog does not get selected
for migration.
--------------------------------------------------------------------------------
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_7_M.sgi_dm_302633.tar (75.9 MBytes)


Legacy ID



302633


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


Terms of use for this information are found in Legal Notices