[Info-vax] Unpleasant Disk Shadowing Surprise
Bob Koehler
koehler at eisner.nospam.encompasserve.org
Wed Oct 12 13:06:00 EDT 2011
In article <4e95c170$0$28524$c3e8da3$9b4ff22a at news.astraweb.com>, JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
> Bob Koehler wrote:
>
>> If your definition of real-time can't handle 3 minutes of
>> interruption, then you probably need to engineer a different solution
>> than the kind of shadowing approach you're using now.
>
> I seem to recall being told that VMS would seamlessly continue to run
> after the loss of a disk.
>
> Perhaps it is expected that the mount verification (which Rob Brooks
> confirmed would kick in) would complete in a second or two.
Things always take longer when they work. Failure can be blindingly
fast.
If the disk fully died, mount verification might have failed
much faster than it took to complete. Meanwhile VMS probably
would let you access any disk that was not in the same shadow set
or the same SCSI controller. So VMS kept going, the delay was
isolated to those resources related to the faulty hardware.
It looks like you're using host based shadowing and that approach
seems to tie up the whole shadow set during mount verification.
Other posters have discussed why that us so (common SCSI controller
and such). So maybe it's not appropriate to your needs. Multiple
hosts, multiple controllers, controller based shadowing, or other
approaches may suit your needs and not tie up all copies of your
data, so VMS can let your application continue.
I'm more familiar with host based shadowing in a non-realtime
environment, or hard real-time applications that are not compatable
with clustering, so you're working in an area where other folks
have nmore experience, but it still looks like you may need a
different solution, and I think the other posters have pointed them
out.
More information about the Info-vax
mailing list