Fixes for the per volume nextVnodeUnique counter roll over. Uniquifier number 1
is reserved for the root vnode, so reset the unique count to 2 when the
nextVnodeUnique counter rolls over.
Update the disk backed V_uniquifier count when the in-memory nextVnodeUnique
counter rolls over during the creation of a new vnode. If the nextVnodeUnique
rolls over when V_uniquifier is UINT32_MAX, then the V_uniquifier is not updated
and remains at UINT32_MAX until the next VUpdateVolume_r() call for the volume.
This bug is usually masked by the VBumpVolumeUsage(), which on every 128 volume
accesses, bumps the V_uniquifier to be 200 more than the current
nextVnodeUnique counter. This causes the V_uniquifier to roll over before
reaching UINT32_MAX. (The number of access before updating the headers is set
in the usage_threshold volume package option, which is currently set to 128 by
default.)
The following shows the unique counters for a series of vnode
creation/deletions before this commit. The nextVnodeUnique rolls over to 1,
and the uniquifier is not reset. The `usage_threshold' was set to a value
greater than 200 to avoid the VBumpVolumeUsage() calls during this test run.
fid =
536870918.4.
4294967294, nextVnodeUnique =
4294967295, uniquifier =
4294967295
fid =
536870918.4.
4294967295, nextVnodeUnique = 0, uniquifier =
4294967295
fid =
536870918.4.1, nextVnodeUnique = 2, uniquifier =
4294967295
fid =
536870918.4.2, nextVnodeUnique = 3, uniquifier =
4294967295
The following shows the unique counters after this commit:
fid =
536870918.4.
4294967294, nextVnodeUnique =
4294967295, uniquifier =
4294967295
fid =
536870918.4.
4294967295, nextVnodeUnique = 0, uniquifier =
4294967295
fid =
536870918.4.2, nextVnodeUnique = 3, uniquifier = 203
fid =
536870918.4.3, nextVnodeUnique = 4, uniquifier = 203
Change-Id: I438670200bf97baeac1486eda7df4cf243aabfc4
Reviewed-on: http://gerrit.openafs.org/10616
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>