[OpenAFS] perpetual Connection timed out
Todd DeSantis
atd@us.ibm.com
Wed, 19 Mar 2008 16:22:53 -0400
--0__=08BBFE82DFFC646B8f9e8a93df938690918c08BBFE82DFFC646B
Content-type: multipart/alternative;
Boundary="1__=08BBFE82DFFC646B8f9e8a93df938690918c08BBFE82DFFC646B"
--1__=08BBFE82DFFC646B8f9e8a93df938690918c08BBFE82DFFC646B
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable
Hi -
If the problem is happening when you are trying to cd into
a volume, then this is probably a case where the linkData
field of the vcache structure has somehow become corrupted.
The "fs flush" and "fs flushv" commands will NOT address this
part of the flushing.
If you have the
fs flushmount <path to volume>
command, this will fix that problem.
Thanks
Todd
=
Jeffrey Altman =
<jaltman@secure-e =
ndpoints.com> =
To
Sent by: "Christopher D. Clausen" =
openafs-info-admi <cclausen@acm.org> =
n@openafs.org =
cc
Wesley Chow <wchow@athenacr.com>=
,
openafs-info@openafs.org =
03/19/2008 02:24 Subj=
ect
PM Re: [OpenAFS] perpetual Connecti=
on
timed out =
=
Please respond to =
jaltman@secure-en =
dpoints.com =
=
=
Christopher D. Clausen wrote:
> Wesley Chow <wchow@athenacr.com> wrote:
>> Mike Garrison wrote:
>>> On Mar 19, 2008, at 12:26 PM, Wesley Chow wrote:
>>>> On a few of our clients (running 1.4.1), we sometimes get
>>>> "Connection timed out" with a single volume. Other volumes on the
>>>> same server are
>>> 1.4.1 is almost 2 years old. Have you tried upgrading? 1.4.6 is
>>> recent.
>> Yep, I'll do that. I was just hoping there was a "bos restart"-like
>> command for clients that I could use in the meantime. It's not a
>> common problem anyway, so I'll just upgrade.
>
> fs checks; fs checkv
fs checkserver won't help because the server is already
responding to queries for other volumes.
fs checkvolume might help if the problem is that the
cache manager is confused on which server the volume
is located on.
When the problem occurs I would execute "cmdebug <host> -long" and
find the FID of the mount point and the volume and see what its
status is.
Then I would try executing "fs flushvolume" against both the volume
containing the mountpoint and the volume that is exhibiting the
problem.
Jeffrey Altman
=
--1__=08BBFE82DFFC646B8f9e8a93df938690918c08BBFE82DFFC646B
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
<html><body>
<p>Hi -<br>
<br>
If the problem is happening when you are trying to cd into<br>
a volume, then this is probably a case where the linkData<br>
field of the vcache structure has somehow become corrupted.<br>
<br>
The "fs flush" and "fs flushv" commands will NOT ad=
dress this<br>
part of the flushing.<br>
<br>
If you have the <br>
<br>
fs flushmount <path to volume><br>
<br>
command, this will fix that problem.<br>
<br>
Thanks<br>
<br>
Todd<br>
<br>
<img width=3D"16" height=3D"16" src=3D"cid:1__=3D08BBFE82DFFC646B8f9e8a=
93df938@us.ibm.com" border=3D"0" alt=3D"Inactive hide details for Jeffr=
ey Altman <jaltman@secure-endpoints.com>">Jeffrey Altman <jalt=
man@secure-endpoints.com><br>
<br>
<br>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=
<tr valign=3D"top"><td style=3D"background-image:url(cid:2__=3D08BBFE82=
DFFC646B8f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " widt=
h=3D"40%">
<ul>
<ul>
<ul>
<ul><b><font size=3D"2">Jeffrey Altman <jaltman@secure-endpoints.com=
></font></b><font size=3D"2"> </font><br>
<font size=3D"2">Sent by: openafs-info-admin@openafs.org</font>
<p><font size=3D"2">03/19/2008 02:24 PM</font>
<table border=3D"1">
<tr valign=3D"top"><td width=3D"168" bgcolor=3D"#FFFFFF"><div align=3D"=
center"><font size=3D"2">Please respond to<br>
jaltman@secure-endpoints.com</font></div></td></tr>
</table>
</ul>
</ul>
</ul>
</ul>
</td><td width=3D"60%">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=
<tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D=
"cid:3__=3D08BBFE82DFFC646B8f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
""><br>
<div align=3D"right"><font size=3D"2">To</font></div></td><td width=3D"=
100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D08BBFE82DFFC646B8f=
9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
<font size=3D"2">"Christopher D. Clausen" <cclausen@acm.or=
g></font></td></tr>
<tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D=
"cid:3__=3D08BBFE82DFFC646B8f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
""><br>
<div align=3D"right"><font size=3D"2">cc</font></div></td><td width=3D"=
100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D08BBFE82DFFC646B8f=
9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
<font size=3D"2">Wesley Chow <wchow@athenacr.com>, openafs-info@o=
penafs.org</font></td></tr>
<tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D=
"cid:3__=3D08BBFE82DFFC646B8f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
""><br>
<div align=3D"right"><font size=3D"2">Subject</font></div></td><td widt=
h=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D08BBFE82DFFC6=
46B8f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
<font size=3D"2">Re: [OpenAFS] perpetual Connection timed out</font></t=
d></tr>
</table>
<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
<tr valign=3D"top"><td width=3D"58"><img width=3D"1" height=3D"1" src=3D=
"cid:3__=3D08BBFE82DFFC646B8f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
""></td><td width=3D"336"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D=
08BBFE82DFFC646B8f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""></td></=
tr>
</table>
</td></tr>
</table>
<br>
<tt>Christopher D. Clausen wrote:<br>
> Wesley Chow <wchow@athenacr.com> wrote:<br>
>> Mike Garrison wrote:<br>
>>> On Mar 19, 2008, at 12:26 PM, Wesley Chow wrote:<br>
>>>> On a few of our clients (running 1.4.1), we sometimes =
get<br>
>>>> "Connection timed out" with a single volume.=
Other volumes on the<br>
>>>> same server are<br>
>>> 1.4.1 is almost 2 years old. Have you tried upgrading? 1.4=
.6 is<br>
>>> recent.<br>
>> Yep, I'll do that. I was just hoping there was a "bos res=
tart"-like<br>
>> command for clients that I could use in the meantime. It's not=
a<br>
>> common problem anyway, so I'll just upgrade.<br>
> <br>
> fs checks; fs checkv<br>
<br>
fs checkserver won't help because the server is already<br>
responding to queries for other volumes.<br>
<br>
fs checkvolume might help if the problem is that the<br>
cache manager is confused on which server the volume<br>
is located on.<br>
<br>
When the problem occurs I would execute "cmdebug <host> -lon=
g" and<br>
find the FID of the mount point and the volume and see what its<br>
status is.<br>
<br>
Then I would try executing "fs flushvolume" against both the =
volume<br>
containing the mountpoint and the volume that is exhibiting the<br>
problem.<br>
<br>
Jeffrey Altman<br>
<br>
</tt><br>
</body></html>=
--1__=08BBFE82DFFC646B8f9e8a93df938690918c08BBFE82DFFC646B--
--0__=08BBFE82DFFC646B8f9e8a93df938690918c08BBFE82DFFC646B
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <1__=08BBFE82DFFC646B8f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--0__=08BBFE82DFFC646B8f9e8a93df938690918c08BBFE82DFFC646B
Content-type: image/gif;
name="pic30336.gif"
Content-Disposition: inline; filename="pic30336.gif"
Content-ID: <2__=08BBFE82DFFC646B8f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==
--0__=08BBFE82DFFC646B8f9e8a93df938690918c08BBFE82DFFC646B
Content-type: image/gif;
name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <3__=08BBFE82DFFC646B8f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
--0__=08BBFE82DFFC646B8f9e8a93df938690918c08BBFE82DFFC646B--