Windows: Make CM resilient to transient VNOVOL
The 1.6.0 and 1.6.1 file servers send transient VNOVOL errors which
are no indicative of the volume not being present. For example,
VNOVOL can be sent during a transition to a VBUSY state prior to
salvaging or when cloning a .backup volume instance. As a result
the cache manager must attempt at least one retry when a VNOVOL is
receive but there are no changes to the volume location information.
This patchset records the VNOVOL error in the cm_req_t structure
If the volume is replicated, the volume's server reference into a busy state.
If the volume is not replicated, the thread is paused for two seconds.
In both cases, the request is retried. If the VNOVOL error is received
a second time from the same server, the volume server reference is
deleted as before. This is done to prevent repeated requests to the
VLDB server and the file server that are expected to fail. The server
reference will be restored to the volume on the next volume location
update.
Reviewed-on: http://gerrit.openafs.org/7353
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
(cherry picked from commit
1af906799b2de90d41139dadaf2dd654e4fd2df3)
Change-Id: Ib8ce6dc389be92c00e9519efb253be0ca9cec05f
Reviewed-on: http://gerrit.openafs.org/8623
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>