[OpenAFS] Re: vldb_check

Andrew Deason adeason@sinenomine.net
Wed, 18 May 2011 13:22:04 -0500

On Tue, 17 May 2011 21:54:02 -0400
Jeff Blaine <jblaine@kickflop.net> wrote:

> Okay, what does all of this *mean*? :)
> syncsite# vldb_check vldb.DB0
> Header's maximum volume id is 2023892829 and largest id found in VLDB is 
> 2023892825

I think this one's kinda self-explanatory. There are vl entries for
volume IDs that are larger than the "largest volume id" field.

> Name Hash 225: Bad entry at 318748: Not a valid vlentry

Volume entries are stored in a hash table based on their name (and also
in hash tables based on their IDs). One of the entries on hash chain 225
points at a location in the db that is not actually a vl entry (it is
either an entry for storing multihomed addresses, an unused entry, or

> Name Hash 3971: Bad entry 'src.amake.011': Already in the name hash

The same vl entry is on the same name hash chain twice.

> Name Hash 7266: Bad entry 'u.ltal': Incorrect name hash chain (should be 
> in 8179)

The entry for u.ltal is on hash chain 7266, but the string hashing
function should put it on 8179.

> bk Id Hash 518: Bad entry 'u.thar': Incorrect Id hash chain (should be 
> in 4053)
> 906: 4f0f1

Same thing, but the volume ID hash table instead of the volume name hash

906 is the entry index for the entry, 4f0f1 is...

0x00001 -> VL entry
0x00010 -> on RW id hash chain
0x00020 -> on RO id hash chain
0x00040 -> on BK id hash chain
0x00080 -> on name id hash chain
0x01000 -> linked from an RW entry
0x02000 -> linked from an RO entry
0x04000 -> linked from a  BK entry
0x08000 -> linked from another entry via the name hash pointers
0x40000 -> something is bad about it being on the BK id hash chain
(either it's on there twice, or it's on the wrong chain)

> Free vlentry at 134340 not on free chain

134340 is a vlentry that is free, but it's not on the chain of free vl

> 1836: Volume 'u.mmerm' not found in name hash 7322 (next 1609 next in chain)

That volume isn't in the name hash chain 7322 like it should be. The
entry itself says that entry 1609 is the next one on the name hash
chain, but nothing refers to 7322 on the name hash chain.

Andrew Deason