[OpenAFS] VLDB volume lock info

Andrew Deason adeason@sinenomine.net
Mon, 21 Jun 2010 17:26:10 -0500


A few days ago, Harald Barth asked (in the jabber room) how to get
information on why/when a volume was locked in the vldb.

I forgot that you can actually get this information if you have local
access to a dbserver; we just don't export it particularly usefully.
haba doesn't appear to be in the jabber room right now, and this may be
useful for other people, so I'm putting it here.

This information is stored in the vldb, but is not available to any VL
RPCs. You can extract the information with vldb_check. Run:

# vldb_check /usr/afs/db/vldb.DB0 -entries > /tmp/foo

and find the entry you want in the output; take root.cell for an
example:

[...]
address 135080: vlentry root.cell
   rw id = 536870915 ; ro id = 536870916 ; bk id = 537351386
   flags         = rw ro bk errorflag(0x7080)
   LockAfsId     = 0
   LockTimestamp = 1277156402
   cloneId       = 0
[...]

Due to a few bugs in vldb_check in different versions of OpenAFS,
vldb_check might output different (wrong) stuff. But the fields you
want, "flags" and "LockTimestamp", I think tend to be correct.

Anyway, LockTimestamp will tell you when the volume was locked. Ignore
LockAfsId; it's not implemented. The last part of 'flags' in 'errorflag'
will give you a reason for why the entry was locked. The flags that can
be set as a 'lock' operation are:

0x010 VLOP_MOVE    -- "vos move/convertROtoRW"
0x020 VLOP_RELEASE -- "vos release"
0x040 VLOP_BACKUP  -- "vos backup"
0x080 VLOP_DELETE/VLOP_ADDSITE
                   -- "vos delentry/addsite/remsite/changeloc/syncvldb/
                           syncserv/rename/lock"
0x100 VLOP_DUMP/VLOP_RESTORE
                   -- "vos dump/restore"

I wouldn't depend on this stuff always working exactly this way, since I
think this is hardly considered a public interface. (In particular,
vldb_check should probably be made to recognize the lock flags.) But for
now, this may be useful; I think this all works relatively sanely.

-- 
Andrew Deason
adeason@sinenomine.net