Re: [foxboro] Software disk mirroring
- From: "Schouten, Frits JF" <Frits.Schouten@xxxxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Wed, 12 Feb 2003 06:14:23 +1100
Can somebody please explain what's wrong with having Mirrored disk on a 51E
which is by the way running 6.2.1
We have 51E boxes running Mirrored as well as concatinated disks without any
problems for quite some time now and even have a backup mechanism that takes
the Mirrored disk offline and takes a backup of that one and put it back in
service.
I have successfully restored a system using the backup tape from a mirrored
hard disk. This was key to the acceptance of this backup method.
So, what's the problem? Am I missing something here?
Regards,
Frits Schouten.
NZSteel.
-----Original Message-----
From: William C Ricker [mailto:wcricker@xxxxxxxxxxxxxxx]
Sent: Wednesday, 12 February 2003 07:40
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Software disk mirroring
For one of our clients, Foxboro installed it on a 51E. This was done
back at version 6.1.
Since then, I don't believe any particular attention has been
paid to it. Based on recent work we have done for three other
clients, I am convinced that it probably doesn't continue to
work there, as it didn't with these other clients. These other
client's systems included AW51A, and AW51B, with 4.3.x, 6.2 and
6.3 software.
Of the three, two had abandoned it; disconnecting the second
drive and putting it on the shelf. The third simply assumed
it was running (wrongly).
The problems start were dosumentation states errors are reported
to the system monitor. They aren't. Problems are reported to
the Sun/Solaris monitor, ending up with messages in the
'messages' files under /var/adm, but most people never look there.
Different cards were used in different Sun boxes for the
2nd SCSI interface. Some software uses device addressing from
the older card while other uses addressing for the new one.
The command set, while simple, can be botched. An error in command
order can yield a 'disturbed' mddb data base replica set, causing
both disks in the pair to be un-bootable, a fact that will only
become known the next time you decide to reboot. Some obvious
errors in entering commands are not checked and reported or
confirmed.
It is possible that the EE PROM address used in booting from the
second drive (on failure of the first) may be incorrect.
Both the old (dump_8MM) and new (backup) dump-to-tape programs
have problems. The old one may look at the status of the pair
using the wrong device address. The new one always gets it's
mddb slice from the primary drive. If it's not there, a one
line error message in the midst of many lines of valid progess
messages easily gets lost, and the tape can't be used to produce
a bootable disk. The documentation doesn't tell you you must
only make tapes from the primary.
For yet another client, we have put together a display, script
and compound to monitor the mirrored pair, and report/alarm
errors. This provides a base level of knowledge of when the
function is actually working.
We can't be too calalier about modifying the standard Foxboro
scripts as we (an integrator) are not in control of the update
process for most of our customers. We must generally impliment
changes outside the standard modules, or by documentation or
proceedure. Hence, we have not looked at the script set for this
function with any eye to correcting some of these problems.
And finally, there was a note about making a loaded, on the shelf
backup disk by using the 'unmirror_sys' command. Our testing
did not yield the backup reliably. To be sure, we could boot
from the backup more often that not, but probably 3 or 4 out of
10 tries would give us a disk that would not boot. We tried this
on AW51A at 4.3 and AW51B at 6.3.
Oh. Wait a minute. the original question was:
>> Has anyone been "allowed" by Foxboro to deploy Medusa based disk
>> mirroring on a 64 bit Sun box (D or E)?
The answer is , yes. And they do install it for clients, as well.
William C. Ricker
FeedForward, Inc.
Marietta, GA, USA
wcricker@xxxxxxxxxxxxxxx
770-426-4422
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: http://www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
EOM
NOTICE - This message and any attached files may contain information that is
confidential and/or subject of legal privilege intended only for use by the
intended recipient. If you are not the intended recipient or the person
responsible for delivering the message to the intended recipient, be advised
that you have received this message in error and that any dissemination,
copying or use of this message or attachment is strictly forbidden, as is
the disclosure of the information therein. If you have received this
message in error please notify the sender immediately and delete the
message.
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: http://www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts: