[OpenAFS] user home directory replication

Jonathan Nilsson jnilsson@uci.edu
Wed, 14 Jul 2010 10:43:36 -0700


--001636ed6755b1e96e048b5c8783
Content-Type: text/plain; charset=UTF-8

The discussions on this list have been immensely interesting to read/follow,
and I thank you all for the help that has already been provided to me the
few time's I've needed to query the list about certain issues.

Now I have a question about "best practices" to which I have not found a
satisfactory answer in the Admin or User Guides.

The Admin Guide [1] states the following about replicating home directories:

> Replication is also not appropriate for volumes that change frequently. You
> must issue the *vos release* command every time you need to update a
> read-only volume to reflect changes in its read/write source.
>
> For both of these reasons, replication is appropriate only for popular
> volumes whose contents do not change very often, such as system binaries and
> other volumes mounted at the upper levels of your filespace. User volumes
> usually exist only in a read/write version since they change so often.
>
[1] http://docs.openafs.org/AdminGuide/ch02s05.html#HDRWQ50

I would like to replicate home directories (and other AFS volumes that are
primarily accessed read/write) for the purpose of faster disaster recovery
in certain common cases, such as local hardware failure on an AFS File
Server.  I am planning to do this by always mounting these volumes with the
"-rw" flag, then simply adding a replication site, and running a script that
will "vos release" all these volumes every so often.

At first, my concern was that perhaps "vos release" operations would have to
copy the entire volume each time.  However, during testing the first vos
release took several minutes, and then subsequent vos release were
significantly faster, appearing only to copy new/modified data.  Does anyone
have any more detail on how the vos release operation works? Is it actually
differential? block-level or file-level?

I can't think of any reason NOT to proceed with this... so if anyone who has
tried this has any advice, it'd be much appreciated!

--
Jonathan Nilsson, jnilsson@uci.edu
Social Sciences Computing Services
949.824.1536, SSPA 4110, UC Irvine

--001636ed6755b1e96e048b5c8783
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The discussions on this list have been immensely interesting to read/follow=
, and I thank you all for the help that has already been provided to me the=
 few time&#39;s I&#39;ve needed to query the list about certain issues.<br>



<br>Now I have a question about &quot;best practices&quot; to which I have =
not found a satisfactory answer in the Admin or User Guides.<br><br>The Adm=
in Guide [1] states the following about replicating home directories:<br>

<blockquote style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><p>Replication is=
 also not appropriate for volumes that change
      frequently. You must issue the <span class=3D"bold"><strong>vos
      release</strong></span> command every time you need to update a=20
read-only
      volume to reflect changes in its read/write source.</p><p>For both
 of these reasons, replication is appropriate only for
      popular volumes whose contents do not change very often, such as
      system binaries and other volumes mounted at the upper levels of
      your filespace. User volumes usually exist only in a read/write
      version since they change so often.</p></blockquote>[1] <a href=3D"ht=
tp://docs.openafs.org/AdminGuide/ch02s05.html#HDRWQ50">http://docs.openafs.=
org/AdminGuide/ch02s05.html#HDRWQ50</a><br><br>I would like to replicate ho=
me directories (and other AFS volumes that are primarily accessed read/writ=
e) for the purpose of faster disaster recovery in certain common cases, suc=
h as local hardware failure on an AFS File Server.=C2=A0 I am planning to d=
o this by always mounting these volumes with the &quot;-rw&quot; flag, then=
 simply adding a replication site, and running a script that will &quot;vos=
 release&quot; all these volumes every so often.<br>

<br>At first, my concern was that perhaps &quot;vos release&quot; operation=
s would have to copy the entire volume each time.=C2=A0 However, during tes=
ting the first vos release took several minutes, and then subsequent vos re=
lease were significantly faster, appearing only to copy new/modified data.=
=C2=A0 Does anyone have any more detail on how the vos release operation wo=
rks? Is it actually differential? block-level or file-level?<br>

<br>I can&#39;t think of any reason NOT to proceed with this... so if anyon=
e who
 has tried this has any advice, it&#39;d be much appreciated!<br><br clear=
=3D"all">--<br>Jonathan Nilsson, <a href=3D"mailto:jnilsson@uci.edu" target=
=3D"_blank">jnilsson@uci.edu</a><br>

Social Sciences Computing Services<br>949.824.1536, SSPA 4110, UC Irvine<br=
>


--001636ed6755b1e96e048b5c8783--