Very many thanks to the following for their helpful advice and comments.
This list is invaluable.
<alan_at_nabeth.cxo.dec.com>
<golden_at_falcon.invincible.com>
<haymanr_at_icefog.sois.alaska.edu>
<dgj_at_omega.rtpnc.epa.gov>
<warrent_at_infi.net>
<rockwell_at_rch.dec.com>
The Question why do I get the message "WRITE BACK cache operation NOT SUPPORTED"
when I boot was answered by <alan_at_nabeth.cxo.dec.com> amoungst others
I'm not sure, but I think it goes like this:
Digital UNIX can tell whether or not a write-back cache
is on one of the backplane controllers. It CAN NOT tell
whether the cache has battery backup. Believing that
controller level write-back caches without battery are
a bad thing (which is true), it prints the message.
It will probably still use them and probably has no way
to turn off the cache. By printing the warning, the
engineering group has done their best to absolve themselves
of any responsibility for data loss or file system corruption
as the result of the cache not having battery backup.
If the units are still accessible and the cache is still
turned on, then you're done. You've been warned of the
danger. If you trust the battery backup, then enjoy the
performance improvement.
<golden_at_falcon.invincible.com> added
In 3.2D they changed it to "Writeback supported if you have a battery backup".
I did some timings (time in sec safter issuing command until getting
prompt back) to verify that the write-back cache was working - It
certainly has a very significant impact on performance.
Write Through Write Back
newfs on 6Gbyte partition 351 43
cd /raid5; dump 0f - / | restore -rf - 122 32
----------------------------
Question 2 - will KZPSC work in a 250 4/266?
I did not get any positive answers but some encouraging ones.
Therefore I decided to try it before the 1000 goes into service this weekend.
Connected it all up
sh dev showed everything OK
boot -file genvmunix dra3
It all booted and ran without any noticeable problems.
all raid disks appeared where they should and mounted OK.
So I am happy that except for the single point of failure in the raid
controller we have a workable fall back position ( I will try to get a
spare controller to keep available)
Warren's two 2100 + HSZ40 solution would be nice but slightly outside our budget.
Many thanks for taking the time to reply.
Tim.
---------------------------
Here are the responses to the second question
<golden_at_falcon.invincible.com>
The issue won't be with power. The issue will be with whether the
console firmware recognizes the KZPSC. If you get a spare (or if you have
some downtime on your 1000) you could install the KZPSC into your '250
and see whether you can boot from it and whether it shows up in a
"show config" display. If it doesn't, make sure you have the latest and
greatest firmware. Since the RAID controller is supported in the minitower
alpha servers, you have a good chance of having firmware support in
your '250.
One caution: Be very very careful if you disconnect the external boxes
and move the card that you reconnect the cables properly. If you swap
them the KZPSC will probably declare your RAID arrays offline and you'll
have to fix the cables and re run the standalone utility to bring them
back to life.
Good luck,
Dave
<warrent_at_infi.net>
Best thing to do would be to go with an HSZ40 and a fully ASE installed
environment. We have two 2100's set up that way and it works great. We
can walk in there and turn off power to one of the machines and within
thirty seconds the other machine has taken over all functionality.
CAVEATS on this.... disks are identified by controller, slot, and nexus.
If you move the controller and the disks from one machine to another of
a different architecture, you CANNOT be certain that the disk will be
identified by the same numbers. MEANING, you cannot be certain that
anything will work....
Warren T .
<dgj_at_omega.rtpnc.epa.gov>
While I haven't faced the WB_cache problem, the challenge of
needing a hot swap or standby box is familiar to me. What I
do is (nearly always) make the system a dual-root system by
keeping a second root partition on disk, with my alternate
configuration(s). Default boot partition is set as a firmware
option, but you can boot from an alternate partition by just
calling it on the firmware command line (b alternate)
and it seems easy enough as a way to manage that need. Then
you can use the box for some ancillary function (like
someone's workstation) and retain the hot swap function.
In your case, it sounds like you'd have to swap cards, and
not having duplicates for those makes them a potential single point
of failure.
-Doug Gould.
Received on Thu Apr 18 1996 - 23:34:27 NZST