[OpenAFS] Re: vos move fails to work on new openafs fileserver, seems fine from
other hosts
Fred Drueck
fdruec1@uic.edu
Thu, 5 Apr 2018 19:15:13 -0500
--089e0826553037cc71056922f391
Content-Type: text/plain; charset="UTF-8"
On Thu, Apr 5, 2018 at 6:56 PM, Fred Drueck <fdruec1@uic.edu> wrote:
> Hello other OpenAFS users,
>
> I've recently setup a new file server to try and facilitate upgrading our
> OpenAFS servers to a newer version of debian (the current stable distro:
> stretch).
>
> The server and db server setup seems to have gone smoothly, but I've got
> problems with moving the AFS volumes.
>
> If I try to do a vos move from the old fileserver to the new one, the move
> will fail with:
>
> Failed to move data for the volume 536881885
>
> VOLSER: Problems encountered in doing the dump !
>
> However, if I work on the old file server, or another openafs client
> system (in fact, I've got another debian stretch system using the exact
> same version the debian openafs-client package) I can move the volume to
> the new server.
>
> And I can verify by looking at the /vicepc directory that the file is
> there, the vldb says it's there but if I try to move the file back to the
> older server working on the new server it will fail with a message that the
> volume is not found, something like:
>
> The volume 536881885 is not on the specified site.
> The current site is : server newserver.math.uic.edu partition /vicepc
>
> OK ... but that's exactly the arguments I passed to vos as the -fromserver
> and -toserver
>
> And, if I switch over to another openafs-client or the old AFS file server
> I can issue the vos command to move the volume back just fine.
>
> Anybody have any ideas what's going wrong?
>
> -Fred
>
Looking through the logs, the only thing I saw that looked maybe relevant
was:
Thu Apr 5 19:02:45 2018 VReadVolumeDiskHeader: Couldn't open header for
volume 536881887 (errno 2).
but if that's such a problem then why can the other AFS clients happily
manipulate the volume?
It's puzzling.
-Fred
--089e0826553037cc71056922f391
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Thu, Apr 5, 2018 at 6:56 PM, Fred Drueck <span dir=3D"l=
tr"><<a href=3D"mailto:fdruec1@uic.edu" target=3D"_blank">fdruec1@uic.ed=
u</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr">Hello other OpenAFS users,<div><br></div><div>I've r=
ecently setup a new file server to try and facilitate upgrading our OpenAFS=
servers to a newer version of debian (the current stable distro: stretch).=
</div><div><br></div><div>The server and db server setup seems to have gone=
smoothly, but I've got problems with moving the AFS volumes.</div><div=
><br></div><div>If I try to do a vos move from the old fileserver to the ne=
w one, the move will fail with:</div><div><br></div><div><div>Failed to mov=
e data for the volume 536881885=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>=C2=A0 =C2=
=A0VOLSER: Problems encountered in doing the dump !</div></div><div><br></d=
iv><div>However, if I work on the old file server, or another openafs clien=
t system (in fact, I've got another debian stretch system using the exa=
ct same version the debian openafs-client package) I can move the volume to=
the new server.</div><div><br></div><div>And I can verify by looking at th=
e /vicepc directory that the file is there, the vldb says it's there bu=
t if I try to move the file back to the older server working on the new ser=
ver it will fail with a message that the volume is not found, something lik=
e:</div><div><br></div><div><div>The volume 536881885 is not on the specifi=
ed site.</div><div>The current site is : server <a href=3D"http://newserver=
.math.uic.edu" target=3D"_blank">newserver.math.uic.edu</a> partition /vice=
pc</div></div><div><br></div><div>OK ... but that's exactly the argumen=
ts I passed to vos as the -fromserver and -toserver</div><div><br></div><di=
v>And, if I switch over to another openafs-client or the old AFS file serve=
r I can issue the vos command to move the volume back just fine.</div><div>=
<br></div><div>Anybody have any ideas what's going wrong?</div><span cl=
ass=3D"gmail-HOEnZb"><font color=3D"#888888"><div><br></div><div>-Fred</div=
></font></span></div>
</blockquote></div><br></div><div class=3D"gmail_extra"><span style=3D"colo=
r:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:nor=
mal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;=
letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-=
decoration-style:initial;text-decoration-color:initial;float:none;display:i=
nline">Looking through the logs, the only thing I saw that looked maybe rel=
evant was:</span><br class=3D"gmail-Apple-interchange-newline"></div><div c=
lass=3D"gmail_extra"><span style=3D"color:rgb(34,34,34);font-family:arial,s=
ans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;f=
ont-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:st=
art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px=
;background-color:rgb(255,255,255);text-decoration-style:initial;text-decor=
ation-color:initial;float:none;display:inline"><br></span></div><div class=
=3D"gmail_extra">Thu Apr=C2=A0 5 19:02:45 2018 VReadVolumeDiskHeader: Could=
n't open header for volume 536881887 (errno 2).<br><div><br></div><div>=
but if that's such a problem then why can the other AFS clients happily=
manipulate the volume?</div><div><br></div><div>It's puzzling.</div><d=
iv><br></div><div>-Fred</div></div></div>
--089e0826553037cc71056922f391--