mirror of
https://git.openafs.org/openafs.git
synced 2025-01-18 15:00:12 +00:00
ab660e2537
Change UV_ReleaseVolume() to use the new GetLockedEntry() function. Add logic to GetLockedEntry() to support the special semantics of VL_SetLock for VLOP_RELEASE, to preserve the current behavior of UV_ReleaseVolume() with the VL_RERELEASE error code. The special semantics of the VL_RERELEASE error code with VLOP_RELEASE are a bit odd: this situation can currently only happen with our vlserver if the vlentry has the VLOP_RELEASE flag set but no lock timestamp. The only way that situation can occur with our current 'vos' is during a small window after a partially failed 'vos release'. Around where UV_ReleaseVolume() prints the message "The volume %lu could not be released to the following %d sites", we call VLDB_ReplaceEntry() with LOCKREL_TIMESTAMP, clearing just the lock timestamp but not the lock flags. We then jump to the 'rfail' label where we ubik_VL_ReleaseLock() with all LOCKREL_* flags are set, clearing the lock flags. So, the only time in this codepath where the lock timestamp is cleared but the VLOP_RELEASE flag is set is after the mentioned VLDB_ReplaceEntry() call but before the ubik_VL_ReleaseLock() call. If that last ubik_VL_ReleaseLock() fails, or if vos dies before reaching it, then the vlentry is left in a state that causes the VL_RERELEASE error code in the future. This behavior has existed since at least OpenAFS 1.0. Currently, the handling of this special VL_RERELEASE case is completely silent, so it's not clear that this is happening, if it does manage to happen. These special semantics are not really safe, since two vos processes could encounter a VL_RERELEASE volume at the same time, and go through the 'vos release' process in parallel thinking they have the vlentry locked, causing all kinds of problems. This behavior may be changed in the future, but for now just preserve the existing special handling of VL_RERELEASE. Add a warning message, though, to make this special situation not silent. No functional change (other than error messages) should be incurred by this commit. [adeason@sinenomine.net: Add VL_RERELEASE warning message and additional related comments.] Change-Id: I9da50677233f63235de730b5d234a9b575e196fd Reviewed-on: https://gerrit.openafs.org/14352 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> |
||
---|---|---|
build-tools | ||
doc | ||
src | ||
tests | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.splintrc | ||
acinclude.m4 | ||
CODING | ||
configure-libafs.ac | ||
configure.ac | ||
CONTRIBUTING | ||
INSTALL | ||
libafsdep | ||
LICENSE | ||
Makefile-libafs.in | ||
Makefile.in | ||
NEWS | ||
NTMakefile | ||
README | ||
README-WINDOWS | ||
regen.sh |
AFS is a distributed file system that enables users to share and access all of the files stored in a network of computers as easily as they access the files stored on their local machines. The file system is called distributed for this exact reason: files can reside on many different machines, but are available to users on every machine. OpenAFS 1.0 was originally released by IBM under the terms of the IBM Public License 1.0 (IPL10). For details on IPL10 see the LICENSE file in this directory. The current OpenAFS distribution is licensed under a combination of the IPL10 and many other licenses as granted by the relevant copyright holders. The LICENSE file in this directory contains more details, thought it is not a comprehensive statement. See INSTALL for information about building and installing OpenAFS on various platforms. See CODING for developer information and guidelines. See NEWS for recent changes to OpenAFS.