[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