[OpenAFS] Balancing usecnts of RO volumes

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6120B56F017648308EA29035
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12/17/2011 9:41 PM, Garance A Drosihn wrote:
> Hello.  A minor question here.
>=20
> I was curious if there was some way to encourage clients to load-
> balance their references across multiple RO volumes.  I have a
> volume which is fairly large (for us), and is often referenced
> about 10,000 times an hour.  I wanted to move that volume to new
> fileserver partitions.
>
>[...]
>
> It's probably true that this volume is referenced from a small
> number of client machines (web servers), and those machines are
> rarely rebooted.  But is there some way to encourage the clients
> to balance out the references?  The volume hasn't been very busy
> today, but I've seen other days where the RO on afsfs13/a has been
> referenced 500,000 times, and the one on afsfs12/b less than 2,000
> times.
>=20
> I do plan to move these specific volumes around some more over the
> winter break, so the state of this volume will be changing anyway.
> But it seemed like an interesting question.

The behavior that is getting the Unix clients into this situation
is the vos release.  At the point the release occurs the RO on the same
partition as the RW becomes the only up to date version of the volume.
Any clients that attempt to read from the RO during the incremental dump
to the other RO sites will be forced to read the data from the source
machine.  Once a client is reading from a server it stays on that
server.  (The windows client behaves differently and will only stay on
the server it is reading from until the volume location data is
refreshed after two hours.)

At the present time there is no method of avoiding this side effect of a
volume release.  However, Derrick (and Jake over the Summer) have
implemented a new vos release option "-stayup" which ensures that all
of the replication sites are updated simultaneously.  See gerrit
patchsets 6249 through 6256.  This code is still being tested but you
are welcome to take a look.

Jeffrey Altman


--------------enig6120B56F017648308EA29035
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJO7ZbLAAoJENxm1CNJffh4VJMIAJoL2rsYs5HoPurPRE+CXSAa
A8ncByl1yGpzEN/TcXtCELaQYLpvPX/RKrCpK1OFtPQKA6nk2J9FC1s8jRRxcUxk
8WNGyvYnygIASSn0ugIDF8NLPaDBERoGrcQABMeBbWETF2oJdFjxclJQUWp7JnH8
R8o4xnk6Q/dCYqCZtciMMgrzK3vUbM8OnsSEh/nYjYXdLYs7fo7lisT91kmsQs+K
8BMT3z3eHmkqRCmA9HN8jrb4Vpfw8fH1aoH0//s8LBfT2TKDO8Cy6PC0fYtecrZx
yhBBMPDetOAAhhk6jXkVgjO7lNqU0UwMQEBB5Ae+IZp99uqP35ffidmvVJuOx0E=
=F9GX
-----END PGP SIGNATURE-----

--------------enig6120B56F017648308EA29035--