[Info-vax] Uptime for OpenVMS

[Robert A. Brooks]

On 5/21/2011 10:54 AM, seasoned_geek wrote:
> On May 13, 8:18 pm, JF Mezei<jfmezei.spam... at vaxination.ca>  wrote:
>> Richard B. Gilbert wrote:
>>> Mount verification determines whether or not the disk that is physically
>>> mounted is, in fact, the disk that is supposed to be mounted; e
>>
>> Doesn't it also check to properly close files (and update various
>> pointers) that were not closed if the disk was improperly dismounted ?
>> If that is not "mount verification", what is that process called ?
>
> You are correct, it checks the caching, disk pointers, etc.  It is not
> uncommon to see mount verification occur on a single node which lost a
> sync/update message.

Uh, no.  Not at all.  Mount verification has absolutely nothing to do 
whatsoever with the file system XQP or RMS.  It's a device-level 
operation.  It does not "check caches or disk pointers".  It's triggered 
in response to an I/O error that's subject to mount verification.  Some 
errors, like ss$_drverr, do not trigger mount verification, and instead 
are immediately returned to the caller without retry.

The "state" of mount verification timeout is not a defined state, per 
se, in that there is no code that does something like "put device into
mount verification timeout".

If a device is mounted, not in mount verification, and the "valid"
bit (ucb$v_valid) is cleared, the device is considered to have timed out
of mount verification.

As mentioned earlier, mount verification can trigger DUDRIVER/MSCP 
"connection walking" or fibre/SCSI multipath path failover.


                                   -- Rob