[OpenAFS] Anyone seen this weirdness...
Todd DeSantis
atd@us.ibm.com
Fri, 14 Apr 2006 13:40:18 -0600
--0__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290
Content-type: multipart/related;
Boundary="1__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290"
--1__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290
Content-type: multipart/alternative;
Boundary="2__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290"
--2__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable
Hi -
As Jeff mentions, the fileserver and the clients would be
doing lots of
from fileserver - BreakCallback
from clients - FetchData
if the other users were trying to read files from that directory
that contained the files you were deleting.
There is a Meltdown script that is available on the IBM AFS
Support Web page and you can monitor the fileserver threads
while this is going on and you could see that the threads
were probably decreasing.
How many fileserver threads are you using, 128 ?
This Meltdown script is just a wrapper around the rxdebug
command and we would normally let it run in 10 second
increments.
Meltdown.pl -s <server> -p <port> -t <seconds>
so
Meltdown.pl -s <fileserver> -p 7000 -t 10
There is a link at the bottom of the following page where you
can download the Meltdown.pl perl script. You may need to
edit the first line to point to your perl location
http://www-1.ibm.com/support/docview.wss?rs=3D0&q=3D%2bAFS+tool&uid=3Ds=
wg21112323&loc=3Den_US&cs=3Dutf-8&cc=3DUS%23%29=3Den
Thanks
Todd
=
Jeffrey Altman =
<jaltman@secure-e =
ndpoints.com> =
To
Sent by: Robert Banz <banz@umbc.edu> =
openafs-info-admi =
cc
n@openafs.org openafs-info@openafs.org =
Subj=
ect
Re: [OpenAFS] Anyone seen this =
04/13/2006 04:08 weirdness... =
PM =
=
=
=
=
=
Robert Banz wrote:
>>
>> Could you do some rxdebug calls to the fileserver next time? So we
>> know why it's getting unresponsive.
>> It could be running out of threads. I don't expect that, but it coul=
d
>> be ...
>
> The 'symptoms' seem to be, for the most part, volume-specific. Slow
> response to accessing that volume, followed by the clients seeing a
> timeout on it. So, guts-o-the-fileserver folk, is there a volume-wid=
e
> lock that gets set by a particular fileserver thread when it's being
> acted upon? Since deleting a whole-bunch-of-files (a /bin/rm -fr <di=
r>)
> is happening, that's a whole lot of requests coming in in-series to t=
hat
> volume, being taken care of on (probably) a first-come, first-served
> basis, leaving little room for other clients to get an op in on that
> volume?
Lets say that there are N clients who are all attempting to use
the contents of directory "D" in the read-write volume "V". Client 1
is making changes to the contents of the directory and clients 2 to N
are reading the directory.
In order for each of the N clients to read the directory, they need
to perform a FetchData RPC which registers a callback with the file
server on "D". Now each time that client 1 makes a change to the
contents of "D", each of the callbacks that are currently registered
with the file server must be broken in order to notify clients 2 to N
that the data they have cached is no longer valid. If clients 2 to N
are actively using "D", then when the callback break is received from
the file server they will in turn attempt to perform a new FetchData
operation to obtain the latest data value. This in turn registers a
new callback.
Now if client 1 is performing 30,000 individual RemoveFile RPCs it is
going to extremely hard for any of the other clients to maintain to be
able to maintain a callback until all 30,000 RPCs are completed. As
soon as a FetchData operation completes, the callback will be broken
and the cache contents will be invalidated.
I don't believe there is a bug here its just a negative side effect
of client side caching and the fact that the file system is only given
one file name at a time to act on.
Jeffrey Altman
#### smime.p7s has been removed from this note on April 14, 2006 by Tod=
d
DeSantis
=
--2__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
<html><body>
<p>Hi -<br>
<br>
As Jeff mentions, the fileserver and the clients would be<br>
doing lots of<br>
<br>
from fileserver - BreakCallback<br>
from clients - FetchData <br>
<br>
if the other users were trying to read files from that directory<br>
that contained the files you were deleting.<br>
<br>
There is a Meltdown script that is available on the IBM AFS<br>
Support Web page and you can monitor the fileserver threads<br>
while this is going on and you could see that the threads <br>
were probably decreasing.<br>
<br>
How many fileserver threads are you using, 128 ?<br>
<br>
This Meltdown script is just a wrapper around the rxdebug<br>
command and we would normally let it run in 10 second<br>
increments.<br>
<br>
Meltdown.pl -s <server> -p <port> -t <seconds><br>
<br>
so<br>
<br>
Meltdown.pl -s <fileserver> -p 7000 -t 10<br>
<br>
There is a link at the bottom of the following page where you<br>
can download the Meltdown.pl perl script. You may need to<br>
edit the first line to point to your perl location<br>
<br>
<a href=3D"http://www-1.ibm.com/support/docview.wss?rs=3D0&q=3D%2bAFS+t=
ool&uid=3Dswg21112323&loc=3Den_US&cs=3Dutf-8&cc=3DUS%23%29=3Den">http:/=
/www-1.ibm.com/support/docview.wss?rs=3D0&q=3D%2bAFS+tool&uid=3D=
swg21112323&loc=3Den_US&cs=3Dutf-8&cc=3DUS%23%29=3Den</a><b=
r>
<br>
<br>
Thanks<br>
<br>
Todd<br>
<br>
<img width=3D"16" height=3D"16" src=3D"cid:1__=3D08BBFBC3DFF882908f9e8a=
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__=3D08BBFBC3=
DFF882908f9e8a93df938@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">04/13/2006 04:08 PM</font></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%" valign=3D"middle"><img width=3D"58"=
height=3D"1" src=3D"cid:3__=3D08BBFBC3DFF882908f9e8a93df938@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__=3D08BBFBC3DFF882908f=
9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
<font size=3D"2">Robert Banz <banz@umbc.edu></font></td></tr>
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img width=3D"58"=
height=3D"1" src=3D"cid:3__=3D08BBFBC3DFF882908f9e8a93df938@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__=3D08BBFBC3DFF882908f=
9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
<font size=3D"2">openafs-info@openafs.org</font></td></tr>
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img width=3D"58"=
height=3D"1" src=3D"cid:3__=3D08BBFBC3DFF882908f9e8a93df938@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__=3D08BBFBC3DFF88=
2908f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
<font size=3D"2">Re: [OpenAFS] Anyone seen this weirdness...</font></td=
></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__=3D08BBFBC3DFF882908f9e8a93df938@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=
08BBFBC3DFF882908f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""></td></=
tr>
</table>
</td></tr>
</table>
<br>
<tt>Robert Banz wrote:<br>
>><br>
>> Could you do some rxdebug calls to the fileserver next time? S=
o we<br>
>> know why it's getting unresponsive.<br>
>> It could be running out of threads. I don't expect that, but i=
t could<br>
>> be ...<br>
><br>
> The 'symptoms' seem to be, for the most part, volume-specific. &nb=
sp;Slow<br>
> response to accessing that volume, followed by the clients seeing =
a<br>
> timeout on it. So, guts-o-the-fileserver folk, is there a vo=
lume-wide<br>
> lock that gets set by a particular fileserver thread when it's bei=
ng<br>
> acted upon? Since deleting a whole-bunch-of-files (a /bin/rm=
-fr <dir>)<br>
> is happening, that's a whole lot of requests coming in in-series t=
o that<br>
> volume, being taken care of on (probably) a first-come, first-serv=
ed<br>
> basis, leaving little room for other clients to get an op in on th=
at<br>
> volume?<br>
</tt><br>
<tt>Lets say that there are N clients who are all attempting to use<br>=
the contents of directory "D" in the read-write volume "=
V". Client 1<br>
is making changes to the contents of the directory and clients 2 to N<b=
r>
are reading the directory.<br>
</tt><br>
<tt>In order for each of the N clients to read the directory, they need=
<br>
to perform a FetchData RPC which registers a callback with the file<br>=
server on "D". Now each time that client 1 makes a chan=
ge to the<br>
contents of "D", each of the callbacks that are currently reg=
istered<br>
with the file server must be broken in order to notify clients 2 to N<b=
r>
that the data they have cached is no longer valid. If clients 2 t=
o N<br>
are actively using "D", then when the callback break is recei=
ved from<br>
the file server they will in turn attempt to perform a new FetchData<br=
>
operation to obtain the latest data value. This in turn registers=
a<br>
new callback.<br>
</tt><br>
<tt>Now if client 1 is performing 30,000 individual RemoveFile RPCs it =
is<br>
going to extremely hard for any of the other clients to maintain to be<=
br>
able to maintain a callback until all 30,000 RPCs are completed. =
As<br>
soon as a FetchData operation completes, the callback will be broken<br=
>
and the cache contents will be invalidated.<br>
</tt><br>
<tt>I don't believe there is a bug here its just a negative side effect=
<br>
of client side caching and the fact that the file system is only given<=
br>
one file name at a time to act on.<br>
</tt><br>
<tt>Jeffrey Altman<br>
</tt><br>
<br>
<br>
#### smime.p7s has been removed from this note on April 14, 2006 by Tod=
d DeSantis<br>
<i>(See attached file: smime.p7s)</i><br>
</body></html>=
--2__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290--
--1__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <1__=08BBFBC3DFF882908f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--1__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290
Content-type: image/gif;
name="pic00521.gif"
Content-Disposition: inline; filename="pic00521.gif"
Content-ID: <2__=08BBFBC3DFF882908f9e8a93df938@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==
--1__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290
Content-type: image/gif;
name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <3__=08BBFBC3DFF882908f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
--1__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290--
--0__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290
Content-type: application/octet-stream;
name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-ID: <43F0__=08BBFBC3DFF882908f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCCAwow
ggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3WjBzMQ8wDQYDVQQE
EwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFs
dG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/bWwZHdx5p1+y6iiCd4vvYEVDxouY
Fp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhMS8B987ls81dKOIUphTF2jOzq8gsFmeA1
5yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOmRY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6f
aiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRXwMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g6
83nIgSnGpwYIwuJheBqSEZfLYWa+1KdD6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEA
AaM5MDcwJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBBAUAA4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY
11bcWDmp6JKif+pVG+8LIySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3
gQZTAa9ZnUI0su9Gy/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0G
CSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAe
Fw0wNTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE
KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZIhvcN
AQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRabmfjm5sFRsxJ
QjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxEAPbQupRZ4vK9iTwU
I1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9qIQdQoMwW5uxv1fQpUPyI
h5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3VrmmjqDrzeciBKcanBgjC4mF4GpIR
l8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25XwIDAQABozkwNzAnBgNVHREEIDAe
gRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEE
BQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOKi3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsj
JIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+faj
ltBxph2pHeG02um90tI85aEgs5cwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY
BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz
IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG
9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMw
NzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0
eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2
vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r
/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T
AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhh
d3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxn
D3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRi
x9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VP
MYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EC
Aw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0wNjA0MTMyMDA4NTNaMCMGCSqGSIb3DQEJBDEWBBQqCYibUbGWffVtLeQ09TWG8ckBPTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpB
MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEF
AASCAQBxSQtHODahd+rM6WyCFRyYgj/rbyj247N7ZphJwbbKMCDah774bThBrfFBlwUbbFBx8SZI
IL6wqb70oYT1C8uzj4bFlryJWfuiEgAbZvM0jJ3zhRMQ4hE4peQz/BMtfjkWgYG/wbDM8Q3Zh9jV
QZlFzuKsO3zkGSS2iFcgpqKSEMHMtwo6ZbP14X2Q+YBQQPIzqTgFHGUU69gt8SHXiV8prOayOj2B
xQqBXSJKQ/dDleYV1ZOpaUFZbKit22tz2tRy/UkOT41yjO4vHvhY2+iQYRi0kLqydP78YSDcp+8v
1hGD0Xm74sfU95BzgwV9bz+V3Egnkx9z856uXlMp+8RXAAAAAAAA
--0__=08BBFBC3DFF882908f9e8a93df938690918c08BBFBC3DFF88290--