[OpenAFS-devel] VLDB flag bits

[Nathaniel W Filardo]

--gDGSpKKIBgtShtf+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 25, 2014 at 09:43:37AM -0400, Jeffrey Altman wrote:
> On 7/25/2014 4:38 AM, Nathaniel W Filardo wrote:
> > Salutations -devel@,
> >=20
> > I have three related sets of questions for you.
> >=20
> > First, conflicting serverFlags bits:
> >=20
> > Which of afs/vldbint.h or afs/volser.h do I believe?  They agree on "new
> > repsite", "rw", "ro", and "backup" volumes, but then one says "rwrepl",
> > "dontuse" while the other says "uuid", "dontuse", "rwrepl":
> >=20
> > afs/volser.h
> >> #define NEW_REPSITE 0x01
> >> #define ITSROVOL    0x02
> >> #define ITSRWVOL    0x04
> >> #define ITSBACKVOL  0x08
> >> #define ITSRWREPL   0x10
> >> #define RO_DONTUSE  0x20
>=20
> These are used within the volserver and in the RPCs to the volserver.
>=20
> > afs/vldbint.h
> >> #define VLSF_NEWREPSITE 0x01 /* flags for indiv. server entry */
> >> #define VLSF_ROVOL 0x02
> >> #define VLSF_RWVOL 0x04
> >> #define VLSF_BACKVOL 0x08
> >> #define VLSF_UUID 0x10
> >> #define VLSF_DONTUSE 0x20
> >> #define VLSF_RWREPLICA 0x40 /* Volume is a RW replica */
>=20
> These are used within the vlserver and in the RPCs to the vlserver.

But src/volser/vsprocs.c:/^UV_ReleaseVolume, for example, says:

> vcode =3D VLDB_GetEntryByID(afromvol, RWVOL, &entry);
>[...]
> for (i =3D 0; i < entry.nServers; i++) {
>     if (entry.serverFlags[i] & ITSROVOL) {
>[...]

and src/volser/vsutils.c:/^VLDB_GetEntryByID calls ubik_VL_GetEntryByID,
which looks to be a vlserver RPC?  Forgive me if I'm still missing
something.
=20
> > Second, VLOP flags:
> >=20
> > While here, why are VLOP flags defined in vldbint.h with self-styled bo=
gus
> > clashing names in volser.h?
>=20
> The original set of VLOP flags do not cover all desired situations but
> they cannot be extended because otherwise an unknown value could be sent
> to a client that doesn't recognize it.  As a result overloading of
> values was performed.   New VLOP_ macros were created for the new
> operations for code clarity.

I was more asking about the location of the definitions than the clashing.
=20
> > And third, please send help, I am so confused:
> >=20
> > I believe the following assertions, could someone please tell me their
> > validity?
> >=20
> >   1) A clone volume is identified by the cloneId field, which may only =
be
> >      set if the RO_EXISTS bit is on.  There's not really a separate ent=
ry
> >      for the clone volume; the semantics are inherited from the one with
> >      VLSF_ROVOL turned on.
>=20
> There is a special readonly temporary clone that is used as part of vos
> release.   Other clones can be created but they do not get recorded in
> the VLDB.

OK.  Could you please look at the logic in
http://gerrit.openafs.org/#patch,sidebyside,10966,7,src/volser/vos-foreach.c
line 245 and tell me that it's not crazy?

> >   2) VLSF_BACKVOL is not used in practice; the VLDB marks backup volumes
> >      with VLSF_RWVOL.
>=20
> Backup volumes must exist on the same site (server/partition) as the RW
> volume.   At one point in history long ago this might not have been true.

That does not really answer the question.  What is VLSF_BACKVOL indicating,
if anything?  It is asserted only in src/libafscp/afscp_volume.c and seems
to get some play in src/vlserver/vlprocs.c:/^SVL_ListAttributesN2 (but to
what end I cannot follow) and is consulted in
src/vlserver/vldb_check.c:/^readentry .  ITSBACKVOL has a similarly sparse
occurrence throughout the code.  src/volser/vsprocs.c:/^CheckVolume will
assert it (and pass the resulting entry to a VLDB RPC!);
src/bucoord/commands.c:/^EvalVolumeSet2 checks for it, and
src/libadmin/vos/afs_vosAdmin.c:/^copyVLDBEntry checks for it.

Thanks again,
--nwf;

--gDGSpKKIBgtShtf+
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlPSajQACgkQTeQabvr9Tc89YgCggh+Mv/RULXW25JVPOiS4Haxo
hbIAnihvBZ2yuwKjZV5ui10Xmtc1ZPt3
=J8AK
-----END PGP SIGNATURE-----

--gDGSpKKIBgtShtf+--