[OpenAFS] convertROtoRW

[Juha Jäykkä]

--Sig_=p1wMLWEM5JqgNFBXP5qsyt
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> Well, it's presumably not going to magically reappear on the same
> partition as the new one.  So, the usual rules apply...

Good point. =3D) What really happens here is we just shut down one extra
fileserver (just the AFS processes, not the machine), so it reappeared
when the server was started again - but on a different location as the
new one, naturally.

> - An RW volume that is not on the server the VLDB says it should be on
> is orphaned.  No client will find that volume.  If the server indicated
> by the VLDB also contains a copy of that volume, then _that_ version
> will be live and accessible to clients.

This is what we saw. Indeed, the whole thing went very smoothly. Thanks a
lot!

> You reconcile by picking one of the volumes, deciding it is the correct=20
> authoritative one, and nuking the other one just to be sure.  If you=20
> actually want to look at the contents to decide, you will need to dump
> one of the volumes and restore it with a different ID.  Note that you
> can use 'vos dump' to dump volumes that the VLDB knows nothing about.

Well, since we were just rehearsing for an actual disaster, we naturally
knew which one was the correct one. And in a real disaster, the original
copy probably never comes back - broken discs have a tendency to stay
broken. If its some other component that broke, like the motherboard,
there is a very high probability that the new RW volume has already
received writes by the time the old one comes back. In this case we might
make use of that offline-dumping-restoring-with-a-different-ID -trick to
make the changes made to the old RW volume between loss of server and
last recloning of the volume available to users. This seems a neat trick,
thanks for this, too! =3D)=20

Hm.. in practise I think in this scenario, we'd probably just take the
discs (which are still ok) from the dead server and stick them into a
working one. Will this cause any other problems except that we need to
tell the VLDB that the volumes are on a different server now? We can even
make them appear on the same partition as they originally were since all
our AFS volumes reside on LVM2 volumes. I admit this would mean a little
extra work in first moving the contents of the disc the the LVM volume
already in existence, joining the disc to the volume, growing the FS of
the enlarged volume, but it can be done if need be - it's probably not
worth the pain unless it's necessary.


Cheers,
-Juha

--=20
                 -----------------------------------------------
                | Juha J=C3=A4ykk=C3=A4, juolja@utu.fi			|
		| Laboratory of Theoretical Physics		|
		| Department of Physics, University of Turku	|
                | home: http://www.utu.fi/~juolja/              |
                 -----------------------------------------------

--Sig_=p1wMLWEM5JqgNFBXP5qsyt
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFENgjl7vTl80R54xwRAg++AKC1VWXzK0ktl3+S6Y/NA7kI6Y0VEwCfYSXS
L7nrhMbmJPjVPoUCRstYeUA=
=/2S9
-----END PGP SIGNATURE-----

--Sig_=p1wMLWEM5JqgNFBXP5qsyt--