[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:VAX and Alpha VMS
Notice:This is a new VMSnotes, please read note 2.1
Moderator:VAXAXP::BERNARDO
Created:Wed Jan 22 1997
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:703
Total number of notes:3722

591.0. "VMS V7.1, KZPDA and Volum-shadowing" by AEOENG::ANTHOINE_J () Wed May 14 1997 07:45

Hi,

     1_	Looking on the OpenVMS V7.1 SPD 25.01.50, I do not find the KZPDA device
	in the supported controllers list. This device is the default device
	for the Alpha-server 4100 system. Is it really unsupported ?

     2_ A customer is trying to test the availability of is system, based on 
	2 AS4000 5/300 with a FDDI cluster ( double attachment ), and, for each 
	system, 2 KZPDA, both connected to 2 RZ29 within a split BA36.
	For each system, 1 KZPDA is connected to the system disk and the other 	
	KZPDA is connected to the data RZ29. Both data RZ29 are in a shadow set
	with Volume-Shadowing.

	Once the shadow set mounted, the customer unpluggs one of the RZ29.
	The customer do not see any error or warning messages coming from 	
	Volume-shadowing or OpenVMS. The "show dev d" command lists all the 	
	devices (physical and shadow devices ). Why the system does not detect 	
	the disk disconnection ?

	Best regards,

	Jacques
T.RTitleUserPersonal
Name		DateLines
591.1Did they try some IOVMSSPT::JENKINSKevin M Jenkins VMS Support EngineeringWed May 14 1997 08:383
    May be a silly question, but after unplugging the drive did they attempt
    any IO's... in particular try creating a file... The shadowing code
    will only react to an IO that has failed.
591.2the system hangs on disk accessAEOENG::ANTHOINE_JWed May 14 1997 10:557
Hi Kevin,

	Of course, after a disk is unplugged, the customer is trying to access 
	to the disk. The system hangs on this operation without any messages.
	

	Jacques
591.3Wait MVTIMEOUT secondsGIDDAY::GILLINGSa crucible of informative mistakesWed May 14 1997 19:4911
  Jacques,
    If you remove a disk and issue an I/O, the system will first put the
  disk into "Mount Verify" state. The process issuing the I/O will wait for
  MVTIMEOUT seconds. If MVTIMEOUT expires, the device will be put into
  "Mount Verify Timeout" state and the pending I/O will fail with a VOLINV
  status. Subsequent I/Os will fail immediately.

    Note that the default value for MVTIMEOUT is 3600 (1 hour).

						John Gillings, Sydney CSC
591.4UTRTSC::utojvdbu1.uto.dec.com::JurVanDerBurgChange mode to Panic!Thu May 15 1997 02:5913
For shadowing there's more than MVTIMEOUT.

First of all, when you issue a read request you don't know to which member it goes. It may
very well go to the member which is still alive, so you should do multiple i/o's to the
shadowset. If the i/o hits the member which is disconnected then SHADOW_MBR_TMO
starts to count (default depends on VMS version, nowadays 120 seconds). If the disk is
not back within this time the member will be thrown out of the shadowset.

So make sure that the diskconnected device is hit with an i/o request (and watch out
that the request is not satisfied from the VIOC).

Jur.
591.5Try doing a WRITE ...STAR::ATOZJohn J. AndruszkiewiczThu May 15 1997 07:338
    One way to insure that both members are alive is to issue a write I/O
    ... so, I would create a TEST_WRITE.TXT file on both the system disk 
    and the data disk ... then pull one member of the data disk out, and
    issue $APPEND SYS$SYSDEVICE:TEST_WRITE.TXT DATA_DISK:TEST_WRITE.TXT
    ... in SHADOW_MBR_TMO seconds, the member will be removed.
    
    Regards, 
    		John