PROBLEM: (89942) (PATCH ID: OSF520-105) ******** Enabler for Enterprise Volume Manager product. PROBLEM: (90910, FR_G02528) (PATCH ID: OSF520-226) ******** This patch prevents a vold from core dumping when removing a disk from rootdg using voldiskadm or voldg. An example of the stack trace from an unstriped vold: 10 raise(0x3ff801229d8, 0x100000006, 0x3ff801869b4, 0x0, 0x3ff801a9c44) [0x3ff 801869b0] 11 abort(0x12007f66c, 0x17a4, 0x3ff80577ae0, 0x0, 0x600000000) [0x3ff801a9c40] 12 clsm_update_devs(dg = 0x140019d00, pending = 1) ["../../../../../../src/usr /sbin/lsm/clsm/vold/clsmintf.c":3711, 0x12007f668] 13 vold_dm_dis_da(dm = 0x1400ae400, clnt = 0x140018f80, remove = 1) ["../../.. /../../../src/usr/sbin/lsm/common/vold/da.c":1763, 0x120024288] 14 req_dm_dis_da(clnt = 0x140018f80, req = 0x3ffc0641170) ["../../../../../../ src/usr/sbin/lsm/common/vold/da.c":1582, 0x120023d24] More (n if no)? 15 request_loop() ["../../../../../../src/usr/sbin/lsm/common/vold/request.c": 568, 0x120061d50] 16 main(argc = 2, argv = 0x11fffc018) ["../../../../../../src/usr/sbin/lsm/com mon/vold/main.c":708, 0x120050420] PROBLEM: (90665, GB_G02495) (PATCH ID: OSF520-331) ******** This patch prevents a KMF (kernel memory fault) panic, in voldiskiostart(), when an I/O is attempted on an lsm device that is not accessible. A typical stack trace follows: 14 panic 15 trap 16 _XentMM 17 voldiskiostart 18 volkiostart 19 spec_strategy 20 read_raw_page 21 get_raw_vd_attrs 22 bs_bfdmn_tbl_activate 23 bs_bfset_activate_int 24 bs_bfset_activate 25 advfs_mountfs 26 msfs_mount 27 cfs_do_pfs_mount 28 cfs_fo_handle_pfs_mounting 29 cfs_fo_handle_bid_accept 30 cfs_fo_thread PROBLEM: (83901) (PATCH ID: OSF520-318) ******** This patch fixes a situation in which when a cluster member fails, mirrored volumes are left in a state such that recovery is always necessary when members boot, even if no additional recovery should be necessary. The problem is that without this fix a node booting does not clear its own recovery flags after recovery has completed. This results in volumes being recovered at every node boot, even if the volume was never marked dirty on the node being booted. PROBLEM: (86483, 92796, 90530, 91558, 92215, 92229) (PATCH ID: OSF520-447) ******** PROBLEM: Cannot create new diskgroups when vold is in noloadbalance mode. LSM appears to have a problem creating diskgroups when vold is in "noloadbalance" mode. # volsetup dsk2 dsk3 Checking for an existing LSM configuration Initialize vold and the root disk group: Add disk dsk2 to the root disk group as dsk2: Addition of disk dsk2 as dsk2 succeeded. Add disk dsk3 to the root disk group as dsk3: Addition of disk dsk3 as dsk3 succeeded. Initialization of vold and the root disk group was successful. # vold -k -r reset -d ; voldctl stop # vold -x noloadbalance # voldisksetup -i dsk4 # voldg init tstdg dsk4 lsm:voldg: ERROR: Disk group tstdg: cannot create: Disk group has no valid configuration copies Problem appears to be that NOLOADBALANCE code disables config/log allocation. This needs to be special cased to allow for DG creation. PROBLEM: LSM does not work correctly with third-party disks. # ls /dev/qb qa15a qa15c qa15e qa15g rqa15a rqa15c rqa15e rqa15g temp qa15b qa15d qa15f qa15h rqa15b rqa15d rqa15f rqa15h # voldiskadd qa15 No matching disks were returned. # disklabel -rwn /dev/qb/rqa15c # disklabel -r /dev/qb/rqa15c # /dev/qb/rqa15c: type: unknown disk: qd label: flags: bytes/sector: 512 sectors/track: 64 tracks/cylinder: 256 sectors/cylinder: 16384 cylinders: 128 sectors/unit: 2097152 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: . . . # voldiskadd qa15 No matching disks were returned. PROBLEM: Cluster nodes can panic during boot trying to enable a non-existent klog object. Node 1: ______ malloc: zero-size request from: ffffffff0008ea8c trap: invalid memory read access from kernel mode faulting virtual address: 0xfffffe04fe417f30 pc of faulting instruction: 0xffffffff00042ef0 ra contents at time of fault: 0xffffffff00042ef0 sp contents at time of fault: 0xfffffe072bfef800 panic (cpu 0): kernel memory fault Node 2: ______ ics_mct: Node 1 is now down clsm_sync_peer_disks: failure sending sync data clsm: sync dumpDisks() failed! clsm: failed to sync peer PROBLEM: Vold can dump core if an old configuration database exists on a disk. PROBLEM: When cluster_root is under lsm control, minimal information is available prior to cluster root being mounted. Error messages were being printed for devices which are under lsm control, but not part of rootdg. PROBLEM: It is possible on a large configuration for lsm to start before the kernel to kernel sync has completed. This is very bad as it can cause panics, proposal collisions, and other unexpected behavior. The fix blocks LSM from starting in user mode until the sync has been completed, or an attempt that failed due to a lack of peer configurations that were capable of syncing had also completed. PROBLEM: (90741, 90746, 90759, 90809, 90830, 90875, 91002, 91353, 91497, 92735, 92870, 93570, 91688, 92773) (PATCH ID: OSF520-542) ******** PROBLEM: Vold autoconfiguration problem in a cluster If LSM discovers new LSM disks, each cluster member will create a separate record for each disk, resulting in multiple records for the same disk. The new disks are discovered via the "voldctl enable" command. If an LSM disk is cloned in hardware, for example, and made available to Tru64 UNIX, and then to LSM by running the "voldctl enable" command, the following output will appear, assuming dsk10 is a new disk and this is a 3-node cluster. # voldctl enable # voldisk list DEVICE TYPE DISK GROUP STATUS dsk0 sliced - - unknown dsk1 sliced - - unknown dsk2 sliced dsk2 rootdg online dsk3 sliced - - unknown dsk4 sliced - - unknown dsk5 sliced - - unknown dsk6 sliced - - unknown dsk7 sliced - - unknown dsk8 sliced dsk8 dg1 online dsk9 sliced dsk9 dg1 online dsk10 sliced - - online dsk10 sliced - - online dsk10 sliced - - online The autoconfiguration functionality in vold was not being distributed properly. With this fix, newly discovered disks will be treated as a configuration change and other cluster members will then get up to date, not treat the disk as newly discovered even if another member has already found it. PROBLEM: Loss of LSM volume special device files after a "voldctl enable" call The "voldctl enable" command was not being distributed properly in a cluster such that newly discovered LSM volumes could be ignored by other cluster members and their corresponding special devices files could be removed. With this fix, all disk groups should be up to date before processing a "voldctl enable" call, thus accounting for newly discovered volumes. PROBLEM: volsave problem saving LSM disk flags The volsave command was not saving the "reserved" or "spare" LSM disk flags, meaning they could not be restored automatically. With this fix, volsave will save the "reserved" and "spare" disk flags if appropriate. The volrestore command will restore them if appropriate. As a result, the volclonedg command was updated to take advantage of this new functionality, so if the parent disk group has these flags set on any of its disks, the clone disk group will as well. Note that this functionality is necessary to ensure the disk group clone has the same configuration as its parent. PROBLEM: cannot run volsave from one cluster member and volrestore from another If the volsave command is run from one cluster member, and then volrestore is run from another, the following volrestore error will occur. # volrestore LSM configuration was saved on host tender.zk3.dec.com Use -f option to override this warning and restore configuration on host track.zk3.dec.com The volsave and volrestore commands were using local host information in a cluster, rather than clusterwide information. With this fix, they will use the information in the /etc/vol/volboot file, not the local hostname, so if in a cluster, the cluster alias will be used. PROBLEM: volsave command not displaying variables when I18N turned on If i18n is turned on, meaning the message catalog is being used to output messages, the volsave command is not displaying variables, as shown in the following example. # volsave LSM configuration being saved to LSM Configuration saved successfully to The volsave command is not displaying the directory name. With this fix, the variables are exported properly. Therefore, commands such as volclonedg, which parse the output of volsave, will be able to run properly. PROBLEM: The volclonedg command has an option, -r, that allows users to specify "no recovery" for mirored volumes. If any plexes were detached from a volume in the parent disk group, they should be detached in the clone disk group to avoid data integrity issues. This ensures future recovery of that volume uses the most up-to-date data plex. This fix checks the parent disk group for volumes with detached plexes and makes sure they are detached in the clone disk group. Volclonedg uses the volrestore command to get information about the parent disk group from it's associated volsave metadata. This fix also makes sure the volrestore command is run minimally, thus keeping the time it will take to run volclonedg reasonable and avoid scalability issues. PROBLEM: The volclonedg command will not set up the disk group clone configuration properly if the disk clones were created on a different host or cluster. The volclonedg command uses the volrestore command to restore the configuration. With this fix, it uses the "-f" option to volrestore to ignore host or cluster name checks. Without this fix, the volclonedg command will not be able to create the disk group clone configuration. PROBLEM: The volclonedg command does not work if any disks in the disk group to clone has a nopriv disk. That is correct behavior. However, the command is also failing if ANY disk group has a nopriv disk, not just the disk group to clone. This fix enables volclonedg to use the volsave metadata saved from the parent disk group to determine if it has any nopriv disks, thus using the appropriate LSM configuration information. PROBLEM: (92566, 90844, ORNG-617, DK_G02609) (PATCH ID: OSF520-589) ******** This patch allows the proper synchronization of disk errors and failures in a cluster under CLSM control. Before the patch the command: "voldisk list" will not be consistent on all nodes after a voldisk rm is executed on a failing or failed disk. The output on the node where the disk was removed will remove it. However all other nodes will still show the disk with 'error' as its status. On one of the nodes where the voldisk rm command was not executed: dsk103 sliced - - error - - orange02 orange removed was:dsk103 On node where voldisk rm was executed only the disk media information was displayed, as expected. - - orange02 orange removed was:dsk103 PROBLEM: (88526, 88541, 88562, wc.sec.002.ssrt) (PATCH ID: OSF520-791) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file access. HP has corrected this potential vulnerability. PROBLEM: (DSATM0D2R, 93380, HPAQ50CLP) (PATCH ID: OSF520-747) ******** This patch corrects performance issues on starting of Cluster Logical Storage Manager with large configurations. PROBLEM: (88488) (PATCH ID: OSF520-790) ******** A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file access. HP has corrected this potential vulnerability. PROBLEM: (89390, HPAQK1D53, HPAQ51LNHH, TKT360311, DE_G04616, SE_G04994) (PATCH ID: OSF520-754) ******** This patch is to prevent vold from core dumping on booting with the message: commit: not holding dg lock PROBLEM: (93135) (PATCH ID: OSF520-837) ******** This code change to the volreconfig command will prevent inconsistent LSM volumes when the name of a volume is the same as that created by a volencap of a disk partition. An example would be to have as an existing volume "vol-dsk2b", and to later conduct a "volencap dsk2b" to encapsulate that partition, which creates a default name for the volume of "vol-dsk2b". PROBLEM: (95147, 95058) (PATCH ID: OSF520-843) ******** When using LSM's volclonedg command to clone a LSM disk group whose underlying disks have been snapped or cloned in hardware, a new disk group is created. If there was a filesystem on one of the LSM volumes in the parent disk group, we now have a copy of that data. When trying to mount the filesystem on the new volume, the vold on another cluster member was dumping core and the new disk group was deported. This only occurred when smsd was running. The problem is smsd queries cluster members for information and may do so from each cluster member. If the cluster member is out of date with respect to the LSM configuration, we may get LSM configuration errors.