Hi Rainer, I am actually not sure if the exact value 2^32- is the real problem. On every wrap you should end up with a new uniqifier (~0) smaller then some recent existing uniquifier (~2^32).
So I am sort of driven now into thinking that this should occur on every wrap. But google does not find no-one complaining about this (except one person in 1999 but on volumes with little use). Which would mean that not only we discovered the Higgs boson (the volume actually hosts the code used for Higgs analysis) but we are the first in the universe to wrap this counter for AFS. ;-) kuba -- On Apr 17, 2013, at 9:26 AM, Rainer Toebbicke <[email protected]> wrote: > 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 à 16:30, Derrick Brashear a écrit : > >> well, what will happen is you potentially reallocate a vnode with an >> previously-used uniquifier. it's risky but the risks are low. >> >> On Tue, Apr 16, 2013 at 10:22 AM, Jakub Moscicki <[email protected]> >> wrote: >> Derrick, >> >> I am wildly guessing that it is the per-volume uniquifier counter >> overflowing 32 bits in a funny way. >> >> I will patch the salvager and send you the details soon. >> >> For the moment I patched volume.c to disable setting the salvage flag for >> "GetBitmap: bad volume uniquifier…." 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... >> >> kuba >> > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Rainer Toebbicke > European Laboratory for Particle Physics(CERN) - Geneva, Switzerland > Phone: +41 22 767 8985 Fax: +41 22 767 7155 > > > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
