[OpenAFS] vos examine oddity

[Russ Allbery]

Jeffrey Hutzelman <jhutz@cmu.edu> writes:

> This is not a bug; you are just confused.

Well, that may very well be the case, but you don't seem to understand
what I was asking about.

> For illustrative purposes, let me quote the results of 'vos examine
> root.cell.readonly -c cs.cmu.edu':

That's a read-only replica, and those are the results that I would expect.
Now, let me show you again the example that I'm actually asking about:

dist.stow                        2003978528 RW     145143 K  On-line
    afssvr9.Stanford.EDU /vicepl 
    RWrite 2003978528 ROnly          0 Backup 2003978530 
    MaxQuota     200000 K 
    Creation    Thu Jun 19 14:09:38 2003
    Last Update Sun Dec 19 22:34:24 2004
    0 accesses in the past day (i.e., vnode references)

    RWrite: 2003978528    ROnly: 2003978529    Backup: 2003978530
    number of sites -> 4
       server afssvr9.Stanford.EDU partition /vicepl RW Site 
       server afssvr10.Stanford.EDU partition /viceph RO Site 
       server afssvr8.Stanford.EDU partition /vicepl RO Site 
       server afssvr9.Stanford.EDU partition /vicepl RO Site 

This *is* the parent of a volume group, it has a read-only replica which
is on the same server and the same partition, and yet the ROnly ID is
still zero.  Compare to this:

pubsw.maze                       1937072753 RW        238 K  On-line
    afssvr9.Stanford.EDU /vicepl 
    RWrite 1937072753 ROnly 1937072754 Backup 1937072755 
    MaxQuota       5000 K 
    Creation    Sat Oct 14 07:59:29 1995
    Last Update Thu Apr  1 03:00:33 2004
    0 accesses in the past day (i.e., vnode references)

    RWrite: 1937072753    ROnly: 1937072754    Backup: 1937072755
    number of sites -> 4
       server afssvr9.Stanford.EDU partition /vicepl RW Site 
       server afssvr17.Stanford.EDU partition /vicepb RO Site 
       server afssvr7.Stanford.EDU partition /vicepl RO Site 
       server afssvr9.Stanford.EDU partition /vicepl RO Site 

which is a very similar volume on the exact same server and partition,
which does have the ROnly ID filled in.

> If you want to associate RW and RO volume ID's, use the data from the
> VLDB, not the data from the volume headers.

I understand that's the best way to do it.  We currently gather this
information as a side effect of doing vos listvol, and it turns out that
it does include enough information for me to do what I want.  There are
some odd inconsistencies, though, and I thought I'd ask about them in case
anyone understood why they were present.

> Also bear in mind that you can get the VLDB information using 'vos
> listvl', and with considerably less fileserver load (actually, none!) 
> than is incurred by 'vos examine'.

Yes, but doing that doesn't get me volume access counts or let me locate
stray orphaned volumes that are not reflected in the VLDB, which is the
main point of doing vos listvol.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>