Analysis by John Burke
New Technology Yields New Ways
To Shoot Yourself In The Foot
It was not all that long ago that a 2Gb disk drive was large. Today we have 9 Gb disk drives. And who knows what 1998 will bring? A natural question to ask is the impact these new, larger drives may have on performance. Or, as one poster put it:
"We are upgrading our 932 to a 928. We currently have two - 2Gb , one - 4Gb and four small HP-IB drives. We want to upgrade to a 928 with two 9Gb drives. Is this a good idea?"
Mike Paivinen of HP provided the following description of things to consider before making any such disk consolidation move:
"9Gb drives aren't inherently slower than the drives that you currently have. However, the proposed change to your disk farm could have significant impact on system performance.
"In general, MPE/iX works best if the number of I/Os per LDEV is in the 15-to-20 I/Os per-second range. Generally, when the disk I/O activity is in this range, the system's performance is not I/O bound. So, let's say that on your system, you are doing 80 I/Os per second across your seven disk drives. Chances are that your system is not limited by the disk I/O activity. However, if you reduce the number of disk drives from seven to two, then you will be trying to do 40 I/Os per second per drive. I guarantee that you will see a dramatic reduction in your system's performance. On the other hand, if your system is only doing 30 I/Os per second across all seven drives, then you are probably okay in reducing the number of disks down to two.
"Bottom line? Before making any changes, be sure you understand the performance of your current disk subsystem."
Stan Sieler provided some test results illustrating the performance characteristics for several drives:
"We installed a Seagate "9-Gb" drive on one of our HP 3000s a few weeks ago. (NOTE: you need MPE/iX 5.5 Power Patch 2 or later.) Here are some timings for various HP and Seagate disk drives (as measured on a 3000 here):
| Steady | Worst | Random | |||
| Drive Type | Rd/Sec | Rd/Sec | Rd/Sec | Interface | # MBs |
| HP97556 | 186.2 | 23.3 | 36.4 | SCSI | 645 |
| ST19171N | 119.2 | 32.2 | 53.7 | SCSI | 8,683 |
| HPC2490AM | 105.6 | 30.0 | 56.3 | SCSI | 2,033 |
| ST15230 | 89.1 | - | 56.8 | SCSI | 4,095 |
| HPC2474S | 66.1 | 23.3 | 35.1 | SCSI | 1,292 |
| HPC2203A | 65.4 | 19.0 | 28.5 | HPIB | 639 |
'Worst' throws the read head from sector 0 to sector 'n', where 'n' is the last sector of the disk. The disks above are of different sizes.
'Random' throws the read head around randomly, from sector 0 to sector 'n', where 'n' is the last sector of the disk.
All 'SCSI' above are single-ended SCSI-II (no Fast/Wide SCSI).
'MB' is 1,0485,576 bytes (1,024 * 1,024). The ST19171N disk is commonly called a 9-Gb disk by marketing people because 8,683 MBs of storage is 9,104,785,408 bytes of storage."
A Rose by any Other Name...
A conversion thread was started by the following question:
"Does anybody know if there is an orderable product from HP that will convert your 9000 HP-UX system to a 3000 MPE/iX system? I was asked this question by an existing 9000 customer who is looking at software that only runs on the 3000."
Ron Seybold, Editor-in-Chief of the NewsWire, replied with HP's official position as reported last year:
"It's not on the price list, but you can buy it if you ask for it. CSY's redoubtable Dave Snow, voice of product planning for HP systems, also reported in an April 1996 story:
"Snow said HP is offering to do conversions from HP's G, I, E and K-Class HP 9000s, as well as from T-500 systems, to the HP 3000. 'Customers can contact our local sales force and we'll work with them to make that happen,' he said. 'We've had some selected customers who have asked for that, and we've been working with them.' "
Adding to this were a couple of real life stories:
"I also know it is possible to go from a 9000 to a 3000 to a 9000 to a 3000. Our disaster recovery center has one set of boxes, but supports both HP 3000s and HP 9000s using the same boxes. During testing, or real disasters, they simply change the machine to be whatever that particular customer needs. They seem to be able to do this very easily, so it can't be that difficult."
And: "We just completed demos at two HP 3000 Customer Events and our HP 3000 was actually an HP9000 E55. The local engineers kindly loaded MPE/iX 5.5, gave it an HPSUSAN of our choice, and voila!, she works. I believe it was the equivalent of the HP 3000 988LX and, I must say, it flew!
"So, it is certainly physically possible to go from a 9000 to a 3000. By the way, it's just a feeling, but I could have sworn the box looked happier as an HP 3000."
A Little Knowledge Can Be A Dangerous Thing
A tale of woe: "Over July 4th, we upgraded our 967 to a 987, and
added several new 4Gb drives. This went remarkably
well. On Sunday, though, I noticed two weekend jobs had died with sector
errors on LDEV 15 (a new drive). This seemed like a
bad thing. A call to the RC confirmed it, and someone was dispatched from
the local HP office with a new drive.
"Here's where I tried to get creative. Because we had not run a successful backup since the reload (due to problems validating our backup software on the new machine), I faced the prospect of reloading to Friday's full, and rerunning all Saturday's production (and telling users they had lost their work). Then I thought of that great utility MPEX.
"Since so many jobs ran and only two aborted with errors, I felt very few files on LDEV 15 might actually be hosed. So I did a LISTF @.@.@ (ONDEVICE(15)), which gave me a 115 page listing. I then used MPEX to ALTFILE @.@.@ (ONDEVICE(15));LDEV=16 to move the files off. I expected only the damaged files would fail, and that appeared to be the case. And I was pleased to see that almost all the damaged files were non- production, or static production that had not changed.
"I seemed to be hitting it lucky! I did another LISTF @.@.@ (ONDEVICE(15)) after the ALTFILE ended, and it only showed those files that had been involved in the errors...a few pages! So, HP pulled the bad drive, put in the new. We added it with VOLUTIL and brought the system back up.
"Guess what. Nothing was working. We were getting errors on files that were not even listed as being on LDEV 15. The error was VOLUME SET NOT MOUNTED MOUNT PROBLEM FSERR 113 on files like HPPXUDC.PUB.SYS. MPEX never listed any extent of HPPXUDC on LDEV 15.
"Soooo...any ideas why this did not work? Could it have worked? We ended up with the reload and rerun of production."
Stan Sieler explained why it did not work and also, in one incredibly long sentence, a way it might have worked:
"MPEX has a flaw wherein it doesn't consider the location of a file's label for ONDEVICE. Thus, if HPPXUDC.PUB.SYS happened to have a label on LDEV 15, and data on LDEVs 1, 2 and 19, the ONDEVICE(15) check would incorrectly say 'nope, it's not on 15'.
"Depending upon the number of bad sectors, and whether or not any happened to affect directories or the label table (or other nonuser data), he might have been able to do a disk-to-disk copy (bad disk to good disk) and boot up with the new drive (which now looks like the same volume as the old drive), and then restore the (previously known) bad files from a backup tape (because their disk contents would be partially unknown after the disk-to-disk copy -- thus avoiding any reload, and avoiding any question about deleting/adding volumes!"
Other comments included:
"You did great right up to the part where you replaced the faulty drive. What you should have done before that point was to take a partial backup back to the last full backup -- then replace the drive and follow with an install. Conclude by restoring all files from backup.
"You cannot simply replace an existing volume in the system volume set without later performing an install. And the response center should have told you that."
Also,"I will add that maybe you just might want to do the partial twice. Just in case you have the tape go bad, which is what happened to me last week. The CE even asked me to see both the full (from the night before) and the partial for that day before he would start swapping out my drives. (This was done very politely and with a nice comment of 'just to make sure this goes flawlessly'.)"
And, "What the HP CE should have done prior to replacing the LDEV 15 was copy the data from LDEV 15 to tape using a program from HP called DISK2TP. The CE could then replace the drive. Lastly, copy the data from tape to the newly replaced LDEV 15, using TAPE2DSK. This should bring the system back to a usable state.
"(I am not sure of the exact names of these programs, but they are available from the CEs. We have used them many times to salvage marginal disk drives. I am sure the CE can give you the exact name. This is similar to COPYUTIL in HP-UX. Of course, I still would have a good system backup as my main line of defense. The DISK2TP and TAPE2DSK are used only to save time and avoid a long reload."
And, "The COPYUTIL command exists on MPE boxes as well. But I would not recommend it, except for last resort purposes. In fact, there is no guarantee that you will be able to use the result (should work most of the time though). And it is painfully slow."
And, finally, "We've used DTDUTIL (Disk-to-Tape-to-Disk) several times to recover data from disks in danger of imminent failure, but I'm not certain if this is certified for all disk devices and/or interfaces. Also, because the system must be started in single-disk, single user mode, it cannot be used for LDEV 1. However, it's saved us from volume set reloads several times on our older system."