[OpenAFS] vos examine oddity
Russ Allbery
rra@stanford.edu
Fri, 28 Jan 2005 16:51:42 -0800
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/>