Various facts:
1. MV on a writelock error sends the IRP back thru DK or whatever as a 
MV IRP but does not initiate Mount Verify. (This apparently is designed
to allow reads to continue.)

2. DKdriver will block these IRPs in stop_new_io if there are any class
busy bits set other than mntverip. If mntverip is set the IRPs will get
by if nothing else is pending. If mntverip is set and DKdriver is working
on other I/O, they are turned into ss$_parity.
IRPs that are blocked here just are put on the start of the IRP queue.

3. If dkdriver is NOT busy at all the requests will go thru. (TST_SINGLE
does this.) (This includes dk NOT in MV).


Thus a thread of these writes can go thru dkdriver even if MV is started.

4. It looks like dudriver uses rwaitcnt for something similar, so it can
stall I/O when it must be busy. The mvirp flag is used only to force
normal (not fastpath) processing and control how synch is handled.

5. Writelock returns on disk in MOUNTVER.MAR get to WRITLCK_HNDLR for
processing.  The IRP gets the MVIRP bit set and, if MV is not in progress,
it delays and sends the IRP to ioc_std$initiate. The delay is about 1 sec.

6. If mount ver. IS in progress, such an IRP will get sent to the
driver code, i.e., to driver MV start, which is supposed to queue
the IRP.



This means that a driver error condition of whatever sort will get
the IRP queued eventually. Cluster transition does set MV on all
volumes, and once this is set, driver MV start is guaranteed to be
called before a write is retried.

An IRP sent would then be blocked normally before getting into dk or du
if it got into MV, or when an error otherwise occurred. If only the mountver
code runs, one of these write IRPs would still be queued.


So synch issues with dk aren't as bad as I thought.
glenn everhart