]> git.michaelhowe.org Git - packages/o/openafs.git/commit
FBSD: do not FlushAllVCaches
authorBen Kaduk <kaduk@mit.edu>
Fri, 17 Jun 2011 06:22:34 +0000 (02:22 -0400)
committerDerrick Brashear <shadow@dementia.org>
Mon, 20 Jun 2011 03:47:50 +0000 (20:47 -0700)
commitec0527e8ca664de233a711f92e998b94672b352a
treee8f3942e0d7093828036b48e671b77f1f1351b58
parent2322d8238a2382d0c84dc1382d7a4370c8096a9b
FBSD: do not FlushAllVCaches

In normal operation, any AFS vcache with associated data will have
an associated vnode, which will be on the list of vnodes associated
with the /afs mountpoint.  We already call FreeBSD's vflush() in
our afs_unmount, which walks the list of vnodes associated with the
mountpoint and calls vgonel() on them, which calls VOP_CLOSE and
VOP_RECLAIM on the vnode.  Our implementation of VOP_RECLAIM already
calls FlushVCache, so in normal operation, FlushAllVCaches() will
be a no-op.
However, in the presence of bugs, it is actively harmful, causing
panics.  For example, if a vnode has been reclaimed but FlushVCache
failed (which we cannot report back since the VFS will panic in this
case), and we attempt to flush it again, the associated vnode has
already been cleaned up and we will panic.  Likewise if our list of
vcaches becomes corrupt and has a vcache with bad or missing vnode
for some other reason, we will panic.

Since there is no gain in normal operation and abnormal operation
is more likely to panic than save data, skip the extra flush.

Reviewed-on: http://gerrit.openafs.org/4847
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 03a54723eaf23b2aad0d026ba5f1a8e7343b3763)

Change-Id: I866fb196f8368362bcd673ffb4908ab21a46c544
Reviewed-on: http://gerrit.openafs.org/4854
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
src/afs/afs_call.c