There were two additional responses to my question, which arrived after I
posted the first summary. I've added the additions to the original summary.
Once again, my apologies for posting this followup so late, but I had some
vacation time last week and I'm just now getting caught up with my email.
Thanks to all who responded:
dyang_at_buckeye.cb.lucent.com (Daniel Yang)
alan_at_nabeth.cxo.dec.com
Martyn.Johnson_at_cl.cam.ac.uk (Martyn Johnson)
My original question:
====================
System: Digital Alpha 8400 running Digital Unix 3.2e
This is a new system, and we're still in the process of setting it up and
configuring it. The system disk is mirrored using LSM, and both the system
disk and mirror disk are internal disks.
Can anyone advise what we can expect if we take a disk hit (boot disk
crashes while we're running)? The documentation is a bit vague in that it
indicates we will "be able to" reboot from the mirror, which we assumed,
but does not specify that we will have no other options EXCEPT to reboot
from the mirror.
As a sort of pseudo-test, we tried physically removing the system disk
while the system was running, but idle (root logged on, no applications
running, no users accessing anything). The system continued to function,
but somewhat slowly. Once the system disk was returned to the box,
everything went back to normal. Obviously, this was not a true test. We
want to set our expectations to the reasonable rather than the improbable,
so can anyone tell us whether we will absolutely need to completely reboot
the system from the mirror, or will it be transparent to us? Will rebooting
from the mirror eliminate the sluggishness we observed? Does anyone have
any experiences/advice to share?
Responses:
=========
---------------------------------------------------------------
From: dyang_at_buckeye.cb.lucent.com (Daniel Yang)
I've been told from DEC that DEC does not support secondary bootable disk.
What we have done in our project is to make a bootable disk as shelf copy disk:
1, Have the root mirrored;
2, Deattach all other mirror volumes except root on one of the disks
(Defined as
DK2);
3, Yank the disks DK2 (HOT);
4, Label DK2 and store it;
5, Put a new empty disk in it
6, recreate the mirrors;
We have some scripts to see if all volumes are OK when machine booting, if
not, then create one, including root mirrors.
---------------------------------------------------------------
From: alan_at_nabeth.cxo.dec.com
I'm not sure what Mr. Yang considers a secondary bootable
disk, but you can have as many bootable disks as you want
to throw disk space and controllers at the problem. You
will have to keep the backups in sync with the main disk
by yourself and if the system does crash and primary boot
disk is lost you'll need to specify the new disk at the
console.
I'd guess that Mr. Yang would like to see something like:
set bootdef_dev2 alternate-boot
and have the console use the alternate should the primary
fail to boot. A feature such as this is really under the
control of the groups writing console firmware and not
the operating system.
In the case of having a mirror boot device, each member
of the mirror is equal (up to the timing of the last write),
so booting from the other member of the mirror should be
the same as booting from the primary. Once the system is
running the two (or n) members should be equal.
---------------------------------------------------------------
From: Martyn.Johnson_at_cl.cam.ac.uk (Martyn Johnson)
Chapter 4 of the LSM manual covers the topic fairly thoroughly, I think.
If you mirror your system disc (root and swap), then a failure of either disc
should be transparent. Section 4.7 of the manual does warn that there may be a
performance hit, which is what you have observed.
You can boot off any of the mirrors. I have tried this, and it works.
Specifically I have a couple of 3000/500 systems; one boot disc is internal
(rz3) and the other is an external disc on the secondary built-in SCSI bus
(rz8). I can boot off either DKA300 or DKB000.
Two caveats:
Only one boot disc can be remembered in the console subsystem's non-volatile
configuration. So if your normal boot disc fails, the system will not
AUTOMATICALLY boot off the other one in future. You would have to boot it
manually. Maybe this is what Daniel Yang is getting at.
Second, you can't boot off a disc on a controller that the boot ROM doesn't
know how to access. My machines have lots of discs on Turbochannel SCSI
controllers, but these can't be used as boot discs because there is no way of
naming them to the console subsystem.
Received on Fri Jul 19 1996 - 20:47:51 NZST