[OpenAFS] proper way to bring down a file server?

[Jeffrey Altman]

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

On 2/23/2011 8:42 PM, Jonathan Nilsson wrote:
> Hello, first I'd like to say that I'm loving how AFS has simplified so
> many sysadmin tasks; thank you so much to all the AFS developers for
> making a great product that just keeps getting better!
>=20
> I have of course tested moving volumes around, and I figured that you
> could replace a server simply by moving all the volumes off the server
> and shutting it down.  Then at your leisure, build a new system from
> scratch, bring it online and move volumes onto it.
>=20
> I tried this, and it seems to have worked fine for most clients, but on=
e
> user got "connection timed out" when trying to login from from 2
> different CentOS 32-bit clients (one 1.4.14 with dkms modules, and
> another 1.4.12 with the kmod rpm, all from openafs.org
> <http://openafs.org>).  Other CentOS and Ubuntu clients did not have
> this problem.  Many other volumes were moved with no problems at the
> same time from the old server to the same new server as this user's
> unavailable volume.
>=20
> This was fixed with "fs flushmount".  Is this supposed to be necessary
> after you "vos move" a volume? =20

The cache manager looks up volume location information and considers it
valid for approximately two hours at which point the data is supposed to
be discarded.  When a volume is moved the clients are not notified on
the move.  Instead, the next time the client attempts to contact the
file server it believes the volume is located on, the file server is
supposed to return either a VNOVOL (volume not attached) or VMOVED
(volume has been moved) error.  When the clients receive these errors,
they issue a new query to the volume location database servers and retry
the request.

I say "supposed to" because depending on which file server version is in
use it may contain one of the bugs that results in a VOFFLINE error
being returned instead of VNOVOL or VMOVED.  When a VOFFLINE error
occurs the clients are not supposed to issue a new query to the VLDB
servers.  In a similar vein, if the file server is inaccessible, the
client does not issue a new VLDB query.  Therefore, it is important that
when file servers are being vacated for maintenance that they not be
shutdown until after the approximate two hour window has passed.

That being said, it does not sound as if that is the problem you
encountered since you indicate that "fs flushmount" solved the problem.
 "fs flushmount" does not cause the volume location data to become
invalid.  I suspect the clients which experienced the problem actually
had bad mount point target data in the cache.  If you see this problem
in the future, issue "fs listmount" first to confirm that the mount
point is in fact referring to the correct volume.

Jeffrey Altman


--------------enig1DE207293C0B39CDE58E721B
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)

iQEcBAEBAgAGBQJNZcDcAAoJENxm1CNJffh4WtQH/09UO4DiZ+j5cOH1S0UR9CF7
2R28pOEVISj+jU1O5Db2Dadwo+H1+3M2zkISjY+TwkO8wr/CoRRvhQA5MWKTI6/t
A4jYc1vAIZjo0VB7mxK9i0Ub+AuEbr+TKmqRTzTozht6Dm8b4MAWWlZmHcDLmIts
IZPfzSXJudziaKFw+B/p/NaogUJ2Ww/W1K1Gc5edC04Vn+5Pl5Oelr/cw2Ow+YAU
w/Gb+CXI73ngFL70Eo+b3RHrIPgI52qUF9FvuxA4oGbkzsz4NHUxE9yCwhaU+iIA
dxe7jKjKbPpakZR8+ig7hJnYm4bMXmgvzpm1bp6tmqYsMqDgo3J17+cIe28R9/8=
=++MK
-----END PGP SIGNATURE-----

--------------enig1DE207293C0B39CDE58E721B--