When attaching a volume, update the nextVnodeUnique field for the
volume, before we do any checks on the volume; for example, checking
inUse, which may result in a demand-salvage if we are running DAFS.
If we do not do this, we can schedule a demand-salvage without setting
nextVnodeUnique, and VUpdateVolume_r will update the volume header
uniquifier to nextVnodeUnique+200, when nextVnodeUnique is not set.
So, we will always set the uniquifier to 200. Fortunately, the salvage
should usually fix the uniquifer anyway.
So, set nextVnodeUnique before doing any of those checks, to avoid
screwing up the uniquifier when taking the volume offline.
Change-Id: Ib211bbf5e93efbebcb679259944e7abf211aa6e1
Reviewed-on: http://gerrit.openafs.org/1809
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
}
VOL_LOCK;
+ vp->nextVnodeUnique = V_uniquifier(vp);
if (VShouldCheckInUse(mode)) {
#ifndef FAST_RESTART
if (V_inUse(vp) && VolumeWriteable(vp)) {
}
}
- vp->nextVnodeUnique = V_uniquifier(vp);
vp->vnodeIndex[vSmall].bitmap = vp->vnodeIndex[vLarge].bitmap = NULL;
#ifndef BITMAP_LATER
if (programType == fileServer && VolumeWriteable(vp)) {