tru64 managers.
I have just tried an experiment which seemed to fail for lack of LSM
configuraiton data.
I had 3 JBODs + 5 stripped disks mirrored. All 16 disks were in rootdg.
I split the mirror and attached one half of it to another server, and tried
to boot from the mirrored boot disk. It recognised the partiton as bootable
and got all the way until LSM was due to start. It then fell over saying it
could not find LSM configuration data. This surprised me becasue I thought
I had configured all the disks in rootdg with a copy of this data.
However on further research I came across table 8.3 below.
Table 8-3: LSM Database and Kernel Change Log Guidelines
Disks Per Disk Group Size of Private Region (in Blocks)
Configuration and Kernel Change Log Copies Per Disk
1 to 3 512 Two copies in each private region
4 to 8 512 One copy in each private region
9 to 32 512 One copy on four to eight disks, zero copies on remaining
disks
33 to 128 1024 One copy on four to eight disks, zero copies on
remaining disks
129 to 256 1536 One copy on four to eight disks, zero copies on
remaining disks
257 or more 2048 One copy on four to eight disks, zero copies on
remaining disks
lsm_dist_copies
8.3.1.7 Distributing the Database and Logs Across Different Buses
anch_0668For disk groups with large numbers of disks, place the disks that
contain configuration database and kernel change log copies on different
buses. This provides you with better performance and higher availability.
conf_lsm_mir_vol
Am I correct in thinking that LSM will only write the configuration data to
8 disks in rootdg, and that it was possible that this is why my experiment
had failed, because the eight disks were still on the original machine?
I hope I have explained this OK, because this could have potentially
uncovered a can of worms for my network server setup.
thanks in anticipation
Graham Charley
ABCDef - Sap Basis
* Ext: 35959 direct: 01904 605959 fax: 01904 604562
* Nestle UK Ltd, HROB1, Haxby Road, York YO91 1XY
Received on Mon Dec 18 2000 - 12:53:43 NZDT