Fix a logic bug in fs flushall in which only the first volume in each
hash chain is reset (invalidated). Instead, reset all the volumes in
the volume hash.
This bug was introduced in commit
4197bbecd9d0b2ff0b8eaec75a0df9a64f713cf0
(libafs: fs flushall for unix cm)
Also, when flushing a single volume with fs flushvolume, don't bother
searching all the hash chains, instead start on the hash chain
containing the volume being flushed.
Reviewed-on: http://gerrit.openafs.org/11892
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit
82e02157fec248293e7336f0e0b3d1c9da545228)
Change-Id: I5dddbaed265ee1ce5dc14e88e22abcb29d96db58
Reviewed-on: http://gerrit.openafs.org/11894
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>
ReleaseWriteLock(&afs_xdcache);
ObtainReadLock(&afs_xvolume);
- for (i = 0; i < NVOLS; i++) {
+ for (i = all ? 0 : VHash(volume); i < NVOLS; i++) {
for (tv = afs_volumes[i]; tv; tv = tv->next) {
if (all || tv->volume == volume) {
afs_ResetVolumeInfo(tv);
- break;
+ if (!all)
+ goto last;
}
}
}
+ last:
ReleaseReadLock(&afs_xvolume);
/* probably, a user is doing this, probably, because things are screwed up.