[OpenAFS] Weirdness after 'vos move's - Epilogue

Terence M. McCoy terry@nd.edu
Thu, 16 Mar 2017 11:52:05 -0400


--001a1140abbef1befa054adb0a66
Content-Type: text/plain; charset=UTF-8

It's always a good idea to routinely collect volume usage information, that
way you know for sure how busy a volume is and has been in the past.  I do
a "vos listvol -extended" call on all my file servers hourly. In one
instance that I can remember it actually did provide a precursor that an
hardware failure was starting to happen as it impacted this hourly query
when the results from the failing AFS partition were being returned very
slowly (SCSI transport error)

On Sun, Mar 5, 2017 at 10:22 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Sun, Mar 05, 2017 at 08:48:20PM -0500, Garance A Drosehn wrote:
> > On 20 Feb 2017, at 16:07, Garance A Drosehn wrote:
> >
> > While 'listvol' of the broken file server shows those volumes,
> > if I do a 'vos examine' for each volume then the VLDB shows
> > the volumes exist on other file servers.  This makes sense,
> > since the vos-moves had failed before they finished.
> >
> > I'm pretty confident that all I need to do now is enter the
> > commands so the file server is completely removed from our
> > cell.  Then I'll destroy these virtual disks, create some new
> > virtual disks and use those to build a new file server, from
> > scratch.
>
> That does seem to follow from the previous paragraph.
>
> Glad you've got things settled without too much excitement.
>
> -Ben
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>



-- 
|
|  Terry McCoy                                  email:  terry@nd.edu
|  Sr Systems Engineer                     phone:  (574) 631-4274
|
|  Office of Information Technologies
|  B014 Information Technology Center
|  University of Notre Dame
|  Notre Dame, Indiana  46556

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

<div dir=3D"ltr">It&#39;s always a good idea to routinely collect volume us=
age information, that way you know for sure how busy a volume is and has be=
en in the past.=C2=A0 I do a &quot;vos listvol -extended&quot; call on all =
my file servers hourly. In one instance that I can remember it actually did=
 provide a precursor that an hardware failure was starting to happen as it =
impacted this hourly query when the results from the failing AFS partition =
were being returned very slowly (SCSI transport error)</div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Sun, Mar 5, 2017 at 10:22 PM,=
 Benjamin Kaduk <span dir=3D"ltr">&lt;<a href=3D"mailto:kaduk@mit.edu" targ=
et=3D"_blank">kaduk@mit.edu</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><span class=3D"">On Sun, Mar 05, 2017 at 08:48:20PM -0500, Garance=
 A Drosehn wrote:<br>
&gt; On 20 Feb 2017, at 16:07, Garance A Drosehn wrote:<br>
&gt;<br>
</span><span class=3D"">&gt; While &#39;listvol&#39; of the broken file ser=
ver shows those volumes,<br>
&gt; if I do a &#39;vos examine&#39; for each volume then the VLDB shows<br=
>
&gt; the volumes exist on other file servers.=C2=A0 This makes sense,<br>
&gt; since the vos-moves had failed before they finished.<br>
&gt;<br>
&gt; I&#39;m pretty confident that all I need to do now is enter the<br>
&gt; commands so the file server is completely removed from our<br>
&gt; cell.=C2=A0 Then I&#39;ll destroy these virtual disks, create some new=
<br>
&gt; virtual disks and use those to build a new file server, from<br>
&gt; scratch.<br>
<br>
</span>That does seem to follow from the previous paragraph.<br>
<br>
Glad you&#39;ve got things settled without too much excitement.<br>
<br>
-Ben<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
OpenAFS-info mailing list<br>
<a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br=
>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" rel=3D"=
noreferrer" target=3D"_blank">https://lists.openafs.org/<wbr>mailman/listin=
fo/openafs-info</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div>|</div><div>| =C2=A0Terry McCoy =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=A0email: =C2=A0<a href=3D"mailto:terry@nd.edu" target=3D"_bl=
ank">terry@nd.edu</a></div><div>| =C2=A0Sr Systems Engineer =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 phone: =C2=A0(574) =
631-4274</div><div>|</div><div>| =C2=A0Office of Information Technologies</=
div><div>| =C2=A0B014 Information Technology Center</div><div>| =C2=A0Unive=
rsity of Notre Dame</div><div>| =C2=A0Notre Dame, Indiana =C2=A046556</div>=
<div><br></div><div><br></div></div></div>
</div>

--001a1140abbef1befa054adb0a66--