[OpenAFS] volume offline due to too low uniquifier (and salvage
cannot fix it)
Wed, 17 Apr 2013 08:19:17 +0000
I am actually not sure if the exact value 2^32- is the real problem. On ev=
ery wrap you should end up with a new uniqifier (~0) smaller then some rece=
nt existing uniquifier (~2^32).
So I am sort of driven now into thinking that this should occur on every wr=
But google does not find no-one complaining about this (except one person i=
n 1999 but on volumes with little use). Which would mean that not only we d=
iscovered the Higgs boson (the volume actually hosts the code used for Higg=
s analysis) but we are the first in the universe to wrap this counter for A=
On Apr 17, 2013, at 9:26 AM, Rainer Toebbicke <Rainer.Toebbicke@cern.ch>
> Well, you were always exposed to reusing uniquifiers as they wrap blindly=
in vnode.c, the only rule being 'never use 0'. The "validity check" which =
results in "bad volume uniquifier" in volume.c is incorrect but only fires =
if you attach a volume having a vnode with uniquifier 2^32-1. That risk is =
significantly greater than 2^-32 as they increase.
> Cheers, Rainer
> Le 16 avr. 2013 =E0 16:30, Derrick Brashear a =E9crit :
>> well, what will happen is you potentially reallocate a vnode with an pre=
viously-used uniquifier. it's risky but the risks are low.
>> On Tue, Apr 16, 2013 at 10:22 AM, Jakub Moscicki <Jakub.Moscicki@cern.ch=
>> I am wildly guessing that it is the per-volume uniquifier counter overfl=
owing 32 bits in a funny way.=20
>> I will patch the salvager and send you the details soon.
>> For the moment I patched volume.c to disable setting the salvage flag fo=
r "GetBitmap: bad volume uniquifier=85." to get access to the data. Do you =
see a big problem with that? I did it on an isolated server but not sure if=
this should go in production...
> Rainer Toebbicke
> European Laboratory for Particle Physics(CERN) - Geneva, Switzerland=20
> Phone: +41 22 767 8985 Fax: +41 22 767 7155