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

Thu, 24 Feb 2011 08:40:13 +0100

--Apple-Mail-1-250952077
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 24, 2011, at 6:14 AM, Andrew Deason <adeason@sinenomine.net> wrote:

> On Thu, 24 Feb 2011 03:22:19 +0100
> Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
>=20
>> When a VOFFLINE error occurs the clients are not supposed to issue a
>> new query to the VLDB servers.
>=20
> Regardless of whatever bugs on the fileserver may be in play, clients
> should indeed issue a new query on VOFFLINE.

bugs on the fileserver? how about 'none'?

> A VOFFLINE error can be the
> result of incorrect/stale volume location information (if a volume is
> offline on one server but online another), and so the current
> information should be looked up when it occurs.

huge waste of RPCs for a legitimate operating condition albeit an undesirabl=
e one. you'll create a vldb storm if a 'popular' volume goes offline.

>> In a similar vein, if the file server is inaccessible, the client does
>> not issue a new VLDB query.
>=20
> ...this is intentional? Why doesn't it? We could be contacting the wrong
> server because we have stale location information.
>=20

We could. But that's basically true of any error, and if we run to mommy on e=
very error, eventually mommy can't handle us being so pesky and melts down

--Apple-Mail-1-250952077
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><body bgcolor=3D"#FFFFFF"><div><br><br><br><div><br></div></div><div><=
br>On Feb 24, 2011, at 6:14 AM, Andrew Deason &lt;<a href=3D"mailto:adeason@=
sinenomine.net">adeason@sinenomine.net</a>&gt; wrote:<br><br></div><div></di=
v><blockquote type=3D"cite"><div><span>On Thu, 24 Feb 2011 03:22:19 +0100</s=
pan><br><span>Jeffrey Altman &lt;<a href=3D"mailto:jaltman@secure-endpoints.=
com">jaltman@secure-endpoints.com</a>&gt; wrote:</span><br><span></span><br>=
<blockquote type=3D"cite"><span>When a VOFFLINE error occurs the clients are=
 not supposed to issue a</span><br></blockquote><blockquote type=3D"cite"><s=
pan>new query to the VLDB servers.</span><br></blockquote><span></span><br><=
span>Regardless of whatever bugs on the fileserver may be in play, clients</=
span><br><span>should indeed issue a new query on VOFFLINE. </span></div></b=
lockquote><div><br></div><div><br></div>bugs on the fileserver? how about 'n=
one'?<div><br><blockquote type=3D"cite"><div><span>A VOFFLINE error can be t=
he</span><br><span>result of incorrect/stale volume location information (if=
 a volume is</span><br><span>offline on one server but online another), and s=
o the current</span><br><span>information should be looked up when it occurs=
.</span><font class=3D"Apple-style-span" color=3D"#000000"><font class=3D"Ap=
ple-style-span" color=3D"#0023A3"><br></font></font></div></blockquote><div>=
<br></div>huge waste of RPCs for a legitimate operating condition albeit an u=
ndesirable one. you'll create a vldb storm if a 'popular' volume goes offlin=
e.</div><div><br><blockquote type=3D"cite"><div><blockquote type=3D"cite"><s=
pan>In a similar vein, if the file server is inaccessible, the client does</=
span><br></blockquote><blockquote type=3D"cite"><span>not issue a new VLDB q=
uery.</span><br></blockquote><span></span><br><span>...this is intentional? W=
hy doesn't it? We could be contacting the wrong</span><br><span>server becau=
se we have stale location information.</span><br><span></span><br></div></bl=
ockquote><div><br></div>We could. But that's basically true of any error, an=
d if we run to mommy on every error, eventually mommy can't handle us being s=
o pesky and melts down<br></div></body></html>=

--Apple-Mail-1-250952077--