From coletteEvins@contempi.de Mon Oct 01 05:06:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHE2-0002ew-S9 for nfsv4-archive@lists.ietf.org; Mon, 01 Oct 2007 05:06:02 -0400 Received: from [74.14.254.112] (helo=QUBCPQ14-1242496624.sdsl.bell.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcHDq-0004qd-Vo for nfsv4-archive@lists.ietf.org; Mon, 01 Oct 2007 05:05:51 -0400 Received: from mikes-comptable ([174.132.101.146] helo=mikes-comptable) by QUBCPQ14-1242496624.sdsl.bell.ca ( sendmail 8.13.3/8.13.1) with esmtpa id 1nByIG-000CFN-wr for nfsv4-archive@lists.ietf.org; Mon, 1 Oct 2007 05:08:06 -0400 Message-ID: <000c01c8040a$80a88150$70fe0e4a@mikescomptable> From: "colette Evins" To: Subject: tnerruof Date: Mon, 1 Oct 2007 05:07:33 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C803E8.F996E150" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b ------=_NextPart_000_0009_01C803E8.F996E150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Morning, nfsv4-archive Alert, alert, alert! Start trade D.M.X.C Five day price: ~$0.50 tneiatso tnegz tnedagir tnarre-t ------=_NextPart_000_0009_01C803E8.F996E150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Morning, nfsv4-archive
Alert, alert, alert!
Start trade D.M.X.C
Five day price: ~$0.50
tneiatso
tnegz
tnedagir
tnarre-t
------=_NextPart_000_0009_01C803E8.F996E150-- From Dana102@nhsai.org Mon Oct 01 19:11:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcUQK-0007U3-Ql for nfsv4-archive@lists.ietf.org; Mon, 01 Oct 2007 19:11:36 -0400 Received: from [189.169.163.132] (helo=[189.169.15.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcUQK-0008HW-3l for nfsv4-archive@lists.ietf.org; Mon, 01 Oct 2007 19:11:36 -0400 Received: from DANIELA ([196.190.1.35] helo=DANIELA) by [189.169.15.124] ( sendmail 8.13.3/8.13.1) with esmtpa id 1UzZLl-000EVK-fP for nfsv4-archive@lists.ietf.org; Mon, 1 Oct 2007 18:11:41 -0500 Message-ID: <000a01c80480$6699f570$7c0fa9bd@DANIELA> From: "Dana hook" To: Subject: seichuum Date: Mon, 1 Oct 2007 18:11:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C80456.7DC3ED70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 ------=_NextPart_000_0007_01C80456.7DC3ED70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CWTE: C'Watre International, Inc Trade Alert. CWTE just announced trading on the OTC. CWTE has the = potential to return 5 times your money with this tight capital = structure. This means the stock can see $1.50 when news is realesed. CWTE has a = womens line of ageless cosmetics that is overwhelming the celebrity industry. Keep an eye for news to hit the market and create a frenzy in = this stock. When investors find out who's using it, the stock could go well beyond our target. nfsv4-archive, contact your broker NOW for CWTE! seednehe sednamed seicogen seetad sedrostn se'etnac P.S. Are there really your photos? http://gotudoronline.com/pictures/ and http://gotudoronline.com/view_gallery.exe ------=_NextPart_000_0007_01C80456.7DC3ED70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
CWTE: C'Watre International, Inc
Trade Alert. CWTE just announced trading on = the OTC. C WTE has the potential to return 5 times your money with this tight = capital structure.
This means the stock can see $1.50 when news = is=20 realesed. CWTE has a womens line of ageless cosmetics that is = overwhelming the celebrity
industry. Keep an eye for news to hit the = market and=20 create a frenzy in this stock. When investors find out who's using it, = the=20 stock could
go well beyond our target.
nfsv4-archive, contact your broker NOW for = CWTE!
seednehe
sednamed
seicogen
seetad
sedrostn
se'etnac
P.S. Are there really your photos? http://gotudoronline.com/pictures/ and http://gotudoronline.com/view_gallery.exe ------=_NextPart_000_0007_01C80456.7DC3ED70-- From florindiqnu@magicpaint.de Mon Oct 01 19:59:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcVAW-0006AQ-6q for nfsv4-archive@lists.ietf.org; Mon, 01 Oct 2007 19:59:20 -0400 Received: from [74.206.84.102] (helo=[74.206.84.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcVAQ-0000sD-IT for nfsv4-archive@lists.ietf.org; Mon, 01 Oct 2007 19:59:15 -0400 Received: from Thorn ([130.193.133.174]:11067 "EHLO Thorn" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [74.206.84.102] with ESMTP id S22IWQOTACHZCWXC (ORCPT ); Mon, 1 Oct 2007 19:59:32 -0400 Message-ID: <000d01c80487$05e5a010$6654ce4a@Thorn> From: "Jaered florindi" To: Subject: thoughtm Date: Mon, 1 Oct 2007 19:58:54 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C80465.7ED40010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a ------=_NextPart_000_0004_01C80465.7ED40010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CWTE: C'Watre International, Inc Trade Alert. CWTE just announced trading on the OTC. CWTE has the = potential to return 5 times your money with this tight capital = structure. This means the stock can see $1.50 when news is realesed. CWTE has a = womens line of ageless cosmetics that is overwhelming the celebrity industry. Keep an eye for news to hit the market and create a frenzy in = this stock. When investors find out who's using it, the stock could go well beyond our target. nfsv4-archive, contact your broker NOW for CWTE! tiaugalb thin-fru thy{stem tickey tihsamad {tietnir ------=_NextPart_000_0004_01C80465.7ED40010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
CWTE: C'Watre International, Inc
Trade Alert. CWTE just announced trading on = the OTC. C WTE has the potential to return 5 times your money with this tight = capital structure.
This means the stock can see $1.50 when news = is=20 realesed. CWTE has a womens line of ageless cosmetics that is = overwhelming the celebrity
industry. Keep an eye for news to hit the = market and=20 create a frenzy in this stock. When investors find out who's using it, = the=20 stock could
go well beyond our target.
nfsv4-archive, contact your broker NOW for = CWTE!
tiaugalb
thin-fru
thy{stem
tickey
tihsamad
{tietnir
------=_NextPart_000_0004_01C80465.7ED40010-- From Sammie-kuzma@fiddlesandfun.com Tue Oct 02 06:18:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcepS-00054W-E1 for nfsv4-archive@lists.ietf.org; Tue, 02 Oct 2007 06:18:14 -0400 Received: from [85.102.184.229] (helo=[85.102.184.229]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcepM-0006qK-EP for nfsv4-archive@lists.ietf.org; Tue, 02 Oct 2007 06:18:09 -0400 Received: from a-ivmu7ut02hw6s ([180.121.101.116] helo=a-ivmu7ut02hw6s) by [85.102.184.229] ( sendmail 8.13.3/8.13.1) with esmtpa id 1kUuic-000DPS-Zz for nfsv4-archive@lists.ietf.org; Tue, 2 Oct 2007 13:18:46 +0300 Message-ID: <000301c804dd$87d0f100$e5b86655@aivmu7ut02hw6s> From: "Sammie kuzma" To: Subject: eveydest Date: Tue, 2 Oct 2007 13:18:09 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C804F6.AD1E2900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ------=_NextPart_000_0006_01C804F6.AD1E2900 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Crash! Boom! Bang! C.W.T.E has the potential to return 500% to your money within 7 trading = days. Hot news released today! Check this out. nfsv4-archive, call ur broker NOW. ------=_NextPart_000_0006_01C804F6.AD1E2900 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
Crash! Boom! Bang!
C.W.T.E has the potential to return 500% to = your money=20 within 7 trading days.
Hot news released today! Check this = out.
nfsv4-archive, call ur broker=20 NOW.
------=_NextPart_000_0006_01C804F6.AD1E2900-- From Thadkundu@concellodesober.com Tue Oct 02 16:46:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icocz-0002QW-9P for nfsv4-archive@lists.ietf.org; Tue, 02 Oct 2007 16:46:01 -0400 Received: from 83-13-155.netrunf.cytanet.com.cy ([83.168.13.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icocy-0000Gq-GH for nfsv4-archive@lists.ietf.org; Tue, 02 Oct 2007 16:46:01 -0400 Received: from selectrics ([107.160.110.25]:31354 "EHLO selectrics" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 83-13-155.netrunf.cytanet.com.cy with ESMTP id S22NDWZEKJHAOMNC (ORCPT ); Tue, 2 Oct 2007 23:46:28 +0300 Message-ID: <000c01c80535$3ddd2d90$9b0da853@selectrics> From: "Thad kundu" To: Subject: hoshitor Date: Tue, 2 Oct 2007 23:46:00 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8054E.632A6590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0006_01C8054E.632A6590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.coselran.com/ Yo man nfsv4-archive We have been successfully helping men like you to enlarge their penises = since 1995 Thad kundu ------=_NextPart_000_0006_01C8054E.632A6590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.coselran.com/
Yo man nfsv4-archive
We have been successfully helping men like you = to=20 enlarge their penises since 1995
Thad kundu
------=_NextPart_000_0006_01C8054E.632A6590-- From Mladygnbz@tripleracing.com Tue Oct 02 21:23:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsxL-0005Ff-KM for nfsv4-archive@lists.ietf.org; Tue, 02 Oct 2007 21:23:19 -0400 Received: from [84.36.13.164] (helo=[84.36.13.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcsxH-0006U3-8X for nfsv4-archive@lists.ietf.org; Tue, 02 Oct 2007 21:23:17 -0400 Received: from pepsi ([173.165.97.177]:19331 "EHLO pepsi" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [84.36.13.164] with ESMTP id S22MRDILVLDGKTJJ (ORCPT ); Wed, 3 Oct 2007 03:23:28 +0200 Message-ID: <000201c8055b$ec187dd0$a40d2454@pepsi> From: "Jatin Mlady" To: Subject: itnagiak Date: Wed, 3 Oct 2007 03:22:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C8056C.AFA14DD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.2 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0004_01C8056C.AFA14DD0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable http://www.coximnews.com/ How it is going nfsv4-archive Do women really care about penis size? The answer is yes Jatin Mlady ------=_NextPart_000_0004_01C8056C.AFA14DD0 Content-Type: text/html; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable
http://www.coximnews.com/
How it is going nfsv4-archive
Do women really care about penis size? The = answer is yes
Jatin Mlady
------=_NextPart_000_0004_01C8056C.AFA14DD0-- From Staceyparkishmarlboro@canadiandriver.com Tue Oct 02 22:49:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcuJ0-0004Yx-TD for nfsv4-archive@lists.ietf.org; Tue, 02 Oct 2007 22:49:46 -0400 Received: from dpc6935218017.direcpc.com ([69.35.218.17] helo=joe224346f8b1e) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcuIy-0000IB-Tj for nfsv4-archive@lists.ietf.org; Tue, 02 Oct 2007 22:49:46 -0400 Received: from referring by canadiandriver.com with SMTP id acgXb4MB1w for ; Tue, 2 Oct 2007 21:47:50 +0600 From: "Wiley Marks" To: Subject: Thank you, we are ready to lend you some cash regardless of Credit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Finding rates low enough to suit is never an easy task. What if I were to tell you that there actually is a simple way to find the a lower rate for you? What if I told you that the rates were lower than any other one out there? You would of course be doubtful of what I said, but why not check for yourself? http://contriculation.com/ Lenders should be offering you the best deals and not make you search for them. Stop fighting for lenders let them fight for you! Make them work for your business by giving you the lowest rates around! If you want a lower interest rate,and peace of mind then.. http://contriculation.com/ Bad credit seems to be a major deterrent for lenders these days but again, what if there was somewhere out there who didn't care for your credit status? Low credit rating? No problem. http://contriculation.com/ Carmen English From Chadwickwhittiercretinous@economist.com Wed Oct 03 16:48:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdB8W-0004GT-8y for nfsv4-archive@lists.ietf.org; Wed, 03 Oct 2007 16:48:04 -0400 Received: from [68.160.231.213] (helo=cheryl.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdB8V-0006Yd-SA for nfsv4-archive@lists.ietf.org; Wed, 03 Oct 2007 16:48:04 -0400 Received: from despite by economist.com with SMTP id ul2rV8crCn for ; Wed, 3 Oct 2007 16:46:22 +0500 From: "Morton Spence" To: Subject: Re: Thanks, we accepted your application Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Finding rates low enough to suit is never an easy task. What if I were to tell you that there actually is a simple way to find the a lower rate for you? What if I told you that the rates were lower than any other one out there? You would of course be doubtful of what I said, but why not check for yourself? http://contriculation.com/ Lenders should be offering you the best deals and not make you search for them. Stop fighting for lenders let them fight for you! Make them work for your business by giving you the lowest rates around! If you want a lower interest rate,and peace of mind then.. http://contriculation.com/ Bad credit seems to be a major deterrent for lenders these days but again, what if there was somewhere out there who didn't care for your credit status? Low credit rating? No problem. http://contriculation.com/ Duncan Cabrera From jeqnine_Klomp@aefas.com Wed Oct 03 17:16:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdBaP-0004Dx-TU for nfsv4-archive@lists.ietf.org; Wed, 03 Oct 2007 17:16:53 -0400 Received: from [83.148.92.148] (helo=pc19.polylan.netvisio.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdBZr-0007Mr-Fv for nfsv4-archive@lists.ietf.org; Wed, 03 Oct 2007 17:16:19 -0400 Received: from user-c5bdf7b4e0 ([176.112.68.135] helo=user-c5bdf7b4e0) by pc19.polylan.netvisio.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1SrLBa-000KJA-oA for nfsv4-archive@lists.ietf.org; Thu, 4 Oct 2007 00:16:41 +0300 Message-ID: <000901c80602$a377ae50$945c9453@userc5bdf7b4e0> From: "jeqnine Klomp" To: Subject: ckeylike Date: Thu, 4 Oct 2007 00:16:18 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C8061B.C8C4E650" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C8061B.C8C4E650 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable http://eartllink.net/ Yo man nfsv4-archive girls lover a big, think cock - get yours now! jeqnine Klomp ------=_NextPart_000_0005_01C8061B.C8C4E650 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
http://eartllink.net/
Yo man nfsv4-archive
girls lover a big, think cock - get yours = now!
jeqnine Klomp
------=_NextPart_000_0005_01C8061B.C8C4E650-- From nfsv4-bounces@ietf.org Wed Oct 03 17:28:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdBk0-0006Za-9I; Wed, 03 Oct 2007 17:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdBjy-0005Cq-Nv for nfsv4@ietf.org; Wed, 03 Oct 2007 17:26:46 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdBjm-0003HB-P2 for nfsv4@ietf.org; Wed, 03 Oct 2007 17:26:40 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l93LQCmE010808 for ; Wed, 3 Oct 2007 17:26:12 -0400 (EDT) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l93LPIkl021883 for ; Wed, 3 Oct 2007 17:26:10 -0400 (EDT) From: Glasgow_Jason@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.47]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 17:25:59 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Oct 2007 17:26:08 -0400 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F005612D59@CORPUSMX40A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for an additional recommended attribute Thread-Index: AcgGBAOCEB8QxoGuQR2kHvwC0AlEFw== To: X-OriginalArrivalTime: 03 Oct 2007 21:25:59.0517 (UTC) FILETIME=[FDF130D0:01C80603] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, HTML_70_90 0.1, NO_REAL_NAME 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __HTML_MSWORD 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: -4.0 (----) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Subject: [nfsv4] Request for an additional recommended attribute X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0139804941==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============0139804941== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80604.03F942D3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80604.03F942D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In describing how the pNFS block client will implement fencing, it became necessary to define the maximum time that an I/O can be outstanding. The client needs to communicate its value to the pNFS server. The most appropriate means of doing so seems to be to provide a per server R/W recommended attribute, which clients can write. =20 I propose updating section 5.6 "Recommended Attributes - Definitions" with the following =20 maximum_io_time 74 uint32 R/W The default maximum time that a client I/O to a data server can be active. Clients may update this value. =20 =20 =20 This parameter is defined in the next version of the pNFS block layout spec as follows: =20 -- "maximum_io_time" is the maximum time it can take for a client I/O to the storage system to either complete or fail; this value is often 30 seconds or 60 seconds, but may be longer in some environments. . If the maximum client I/O time cannot be bounded, this timed lease mechanism MUST NOT be used. The client can use GETATTR to query the server's default setting of "maximum_io_time". The server must respond with the maximum I/O time in seconds. If the client's maximum I/O time is greater than the server's default, then the client MUST use SETATTR to inform the server of its maximum_I/O time. -- =20 Are there comments on introducing this new attribute into the NFSv4 minor version 1 spec? Is this a valid means of communicating a client specific value to the server? =20 -Jason Glasgow =20 =20 ------_=_NextPart_001_01C80604.03F942D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In describing how = the pNFS block client will implement fencing, it became necessary to define the = maximum time that an I/O can be outstanding.  The client needs to = communicate its value to the pNFS server.  The most appropriate means of doing so seems = to be to provide a per server R/W recommended attribute, which clients can = write.

 

I propose updating = section 5.6 "Recommended Attributes – Definitions" with the = following

 

maximum_io_time  74 uint32    R/W   The default maximum time that a = client

         =             &= nbsp;           &n= bsp;  I/O to a data server can be active.

           &= nbsp;           &n= bsp;            Clients may update this value.

 

 

 

This parameter is = defined in the next version of the pNFS block layout spec as = follows:

 

--

"maximum_io_time" is the maximum time it can take for a client I/O to the storage system = to either complete or fail; this value is often 30 seconds or 60 seconds, = but may be longer in some environments. .  If the maximum client I/O time = cannot be bounded, this timed lease mechanism MUST NOT be used.  The client = can use GETATTR to query the server's default setting of = "maximum_io_time".  The server must respond with the maximum I/O time in seconds.  If = the client's maximum I/O time is greater than the server's default, then the client = MUST use SETATTR to inform the server of its maximum_I/O = time.

--

 

Are there comments = on introducing this new attribute into the NFSv4 minor version 1 = spec?  Is this a valid means of communicating a client specific value to the = server?

 

-Jason = Glasgow

 

 

------_=_NextPart_001_01C80604.03F942D3-- --===============0139804941== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============0139804941==-- From vincenzo@happy55.com Wed Oct 03 22:39:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdGcr-0002Ed-TA for nfsv4-archive@lists.ietf.org; Wed, 03 Oct 2007 22:39:45 -0400 Received: from [213.255.92.154] (helo=ip-154-92-dsl-customer.fontel.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdGcr-000852-4R for nfsv4-archive@lists.ietf.org; Wed, 03 Oct 2007 22:39:45 -0400 Received: from LABORATORIONT ([101.123.120.191] helo=LABORATORIONT) by ip-154-92-dsl-customer.fontel.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1mgJVX-000PWN-Hq for nfsv4-archive@lists.ietf.org; Thu, 4 Oct 2007 04:40:58 +0200 Message-ID: Date: Thu, 4 Oct 2007 04:40:39 +0200 From: "vincenzo Lostetter" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: laffe Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea How it is going nfsv4-archive Did you know.. 88% of ladies want a man that is big, they say its more fulfilling vincenzo Lostetter http://ekitchy.com/ From nfsv4-bounces@ietf.org Thu Oct 04 00:10:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdI0a-0005dB-Bx; Thu, 04 Oct 2007 00:08:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdI0Y-0005Hx-Pz for nfsv4@ietf.org; Thu, 04 Oct 2007 00:08:18 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdI0M-0006KN-3p for nfsv4@ietf.org; Thu, 04 Oct 2007 00:08:12 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9447pLA017277 for ; Thu, 4 Oct 2007 00:07:51 -0400 (EDT) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9446wDO010431 for ; Thu, 4 Oct 2007 00:07:42 -0400 (EDT) From: Glasgow_Jason@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.47]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 00:07:28 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8063C.1A2A45FB" Date: Thu, 4 Oct 2007 00:07:27 -0400 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F005612E39@CORPUSMX40A.corp.emc.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-nfsv4-pnfs-block-04 Thread-Index: AcgGOeh53639M8+dS8Oi0AcZnMTY9gAAhhjw To: X-OriginalArrivalTime: 04 Oct 2007 04:07:28.0751 (UTC) FILETIME=[143E97F0:01C8063C] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, BASE64_ENC_TEXT! .75, HTML_70_90 0.1, NO_REAL_NAME 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __HTML_MSWORD 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __PHISH_PHRASE1_B 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 92f4ac7693cb66b41244b5f5744bcc9d Subject: [nfsv4] FW: draft-ietf-nfsv4-pnfs-block-04 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8063C.1A2A45FB Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8063C.1A2A45FB" ------_=_NextPart_002_01C8063C.1A2A45FB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I submitted draft-ietf-nfsv4-pnfs-block-04. Please see summary of changes below. =20 Jason =20 ________________________________ From: Glasgow, Jason=20 Sent: Wednesday, October 03, 2007 11:52 PM To: 'internet-drafts@ietf.org' Cc: Glasgow, Jason; Black, David Subject: draft-ietf-nfsv4-pnfs-block-04 =20 Attached is an updated I-D, draft-ietf-nfsv4-pnfs-block-04.txt =20 It updates the nfsv4 working group I-D, draft-ietf-nfsv4-pnfs-block-03.txt =20 The new version has several editorial changes and clarifications as well these technical changes: =20 - Added Client Fencing section. =20 - Added sections on CB_RECALL_ANY. =20 - Added information about device ids to clarify their usage. =20 =20 - Described where the pnfs_block_deviceaddr4 data structure is found to be accurate with draft-ietf-nfsv4-minorversion1-14. =20 - Updated references from -08 to -14. =20 - Removed root_id from pnfs_block_deviceaddr4. =20 - Changed 'byte' to 'octet'. =20 - Clarify the block size and stripe size in volume data structures. =20 =20 - Rename 'volume' and 'id' to be 'vol_id' consistently.=20 =20 =20 ------_=_NextPart_002_01C8063C.1A2A45FB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I submitted draft-ietf-nfsv4-pnfs-block-04.

Please see summary = of changes below.

 

Jason

 


From: = Glasgow, Jason
Sent: Wednesday, October = 03, 2007 11:52 PM
To: = 'internet-drafts@ietf.org'
Cc: Glasgow, Jason; = Black, David
Subject: draft-ietf-nfsv4-pnfs-block-04

 

Attached is an = updated I-D, draft-ietf-nfsv4-pnfs-block-04.txt

 

It updates the = nfsv4 working group I-D, = draft-ietf-nfsv4-pnfs-block-03.txt

 

The new version has = several editorial changes and clarifications as well these technical = changes:

 

- Added Client = Fencing section.

 

- Added sections on CB_RECALL_ANY.

 

- Added information = about device ids to clarify their usage. 

 

-  Described = where the pnfs_block_deviceaddr4 data structure is found to =

   be = accurate with draft-ietf-nfsv4-minorversion1-14.

 

-  Updated = references from -08 to -14.

 

-  Removed = root_id from pnfs_block_deviceaddr4.

 

-  Changed = 'byte' to 'octet'.

 

-  Clarify the = block size and stripe size in volume data structures.  =

 

-  Rename = 'volume' and 'id' to be 'vol_id' consistently.

 

 

------_=_NextPart_002_01C8063C.1A2A45FB-- ------_=_NextPart_001_01C8063C.1A2A45FB Content-Type: text/plain; name="draft-ietf-nfsv4-pnfs-block-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-nfsv4-pnfs-block-04.txt Content-Disposition: attachment; filename="draft-ietf-nfsv4-pnfs-block-04.txt" DQoKCgoKCgogDQogDQpORlN2NCBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBEYXZpZCBMLiBCbGFjayANCkludGVybmV0IERyYWZ0ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVwaGVuIEZyaWRlbGxhIA0KRXhwaXJlczog QXByaWwgMjAwOCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEphc29uIEds YXNnb3cgDQpJbnRlbmRlZCBTdGF0dXM6IFByb3Bvc2VkIFN0YW5kYXJkICAgICAgICAgICAgICAg ICAgICAgIEVNQyBDb3Jwb3JhdGlvbiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAzLCAyMDA3IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgIHBORlMgQmxvY2svVm9sdW1lIExheW91 dCANCiAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1uZnN2NC1wbmZzLWJsb2NrLTA0LnR4 dCANCgoKU3RhdHVzIG9mIHRoaXMgTWVtbyANCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJu ZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCAgICAgICANCiAgIGFueSBhcHBs aWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyAg ICAgICANCiAgIGF3YXJlIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBv ZiB3aGljaCBoZSBvciBzaGUgICAgICAgDQogICBiZWNvbWVzIGF3YXJlIHdpbGwgYmUgZGlzY2xv c2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mICAgICAgIA0KICAgQkNQIDc5LiAN CgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l dCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgDQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4gDQoKICAg SW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzIA0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgDQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSANCiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgDQoKICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQgDQoKICAgVGhl IGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3Nl ZCBhdCANCiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCANCgogICBUaGlz IEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIGluIFNlcHRlbWJlciAyMDA3LiANCgpBYnN0cmFj dCANCgogICBQYXJhbGxlbCBORlMgKHBORlMpIGV4dGVuZHMgTkZTdjQgdG8gYWxsb3cgY2xpZW50 cyB0byBkaXJlY3RseSBhY2Nlc3MgDQogICBmaWxlIGRhdGEgb24gdGhlIHN0b3JhZ2UgdXNlZCBi eSB0aGUgTkZTdjQgc2VydmVyLiAgVGhpcyBhYmlsaXR5IHRvIA0KICAgYnlwYXNzIHRoZSBzZXJ2 ZXIgZm9yIGRhdGEgYWNjZXNzIGNhbiBpbmNyZWFzZSBib3RoIHBlcmZvcm1hbmNlIGFuZCANCiAg IHBhcmFsbGVsaXNtLCBidXQgcmVxdWlyZXMgYWRkaXRpb25hbCBjbGllbnQgZnVuY3Rpb25hbGl0 eSBmb3IgZGF0YSANCiAgIGFjY2Vzcywgc29tZSBvZiB3aGljaCBpcyBkZXBlbmRlbnQgb24gdGhl IGNsYXNzIG9mIHN0b3JhZ2UgdXNlZC4gIFRoZSANCiAgIG1haW4gcE5GUyBvcGVyYXRpb25zIGRy YWZ0IHNwZWNpZmllcyBzdG9yYWdlLWNsYXNzLWluZGVwZW5kZW50IA0KICAgZXh0ZW5zaW9ucyB0 byBORlM7IHRoaXMgZHJhZnQgc3BlY2lmaWVzIHRoZSBhZGRpdGlvbmFsIGV4dGVuc2lvbnMgDQoK IA0KIA0KIA0KQmxhY2sgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwMDggICAg ICAgICAgICAgICAgICAgW1BhZ2UgMV0gDQogDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAg ICBwTkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAg DQoKICAgKHByaW1hcmlseSBkYXRhIHN0cnVjdHVyZXMpIGZvciB1c2Ugb2YgcE5GUyB3aXRoIGJs b2NrIGFuZCB2b2x1bWUgDQogICBiYXNlZCBzdG9yYWdlLiANCgpDb252ZW50aW9ucyB1c2VkIGlu IHRoaXMgZG9jdW1lbnQgDQoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCANCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5P VCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICAgZG9j dW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMtMjExOSBbUkZD MjExOV0uIA0KClRhYmxlIG9mIENvbnRlbnRzIA0KCiAgIDEuIEludHJvZHVjdGlvbi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMyANCiAgIDIuIEJsb2NrIExheW91 dCBEZXNjcmlwdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzIA0KICAgICAg Mi4xLiBCYWNrZ3JvdW5kIGFuZCBBcmNoaXRlY3R1cmUgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LiAzIA0KICAgICAgMi4yLiBHRVRERVZJQ0VMSVNUIGFuZCBHRVRERVZJQ0VJTkZPLi4uLi4uLi4u Li4uLi4uLi4uLi4uLiA0IA0KICAgICAgICAgMi4yLjEuIFZvbHVtZSBJZGVudGlmaWNhdGlvbi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDQgDQogICAgICAgICAyLjIuMi4gVm9sdW1lIFRvcG9s b2d5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gNSANCiAgICAgICAgIDIuMi4zLiBH RVRERVZJQ0VMSVNUIGFuZCBHRVRERVZJQ0VJTkZPIGRldmljZWlkNC4uLi4uLi4uLiA4IA0KICAg ICAgMi4zLiBEYXRhIFN0cnVjdHVyZXM6IEV4dGVudHMgYW5kIEV4dGVudCBMaXN0cy4uLi4uLi4u Li4uLi4gOSANCiAgICAgICAgIDIuMy4xLiBMYXlvdXQgUmVxdWVzdHMgYW5kIEV4dGVudCBMaXN0 cy4uLi4uLi4uLi4uLi4uLi4uMTEgDQogICAgICAgICAyLjMuMi4gTGF5b3V0IENvbW1pdHMgLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICAgICAgIDIuMy4zLiBMYXlvdXQg UmV0dXJucyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEyIA0KICAgICAgICAgMi4z LjQuIENsaWVudCBDb3B5LW9uLVdyaXRlIFByb2Nlc3NpbmcuLi4uLi4uLi4uLi4uLi4uLi4xMyAN CiAgICAgICAgIDIuMy41LiBFeHRlbnRzIGFyZSBQZXJtaXNzaW9ucy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xNCANCiAgICAgICAgIDIuMy42LiBFbmQtb2YtZmlsZSBQcm9jZXNzaW5nIC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xNSANCiAgICAgICAgIDIuMy43LiBDbGllbnQgRmVuY2luZyAu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2IA0KICAgICAgMi40LiBDcmFzaCBSZWNv dmVyeSBJc3N1ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTggDQogICAgICAyLjUu IFJlY2FsbGluZyByZXNvdXJjZXM6IENCX1JFQ0FMTF9BTlkgLi4uLi4uLi4uLi4uLi4uLi4uLjE4 IA0KICAgICAgMi42LiBUcmFuc2llbnQgYW5kIFBlcm1hbmVudCBFcnJvcnMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjE5IA0KICAgMy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xOSANCiAgIDQuIENvbmNsdXNpb25zLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMSANCiAgIDUuIElBTkEgQ29uc2lkZXJhdGlv bnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjEgDQogICA2LiBSZXZpc2lv biBIaXN0b3J5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIxIA0KICAg Ny4gQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjIyIA0KICAgOC4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjIzIA0KICAgICAgOC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMjMgDQogICAgICA4LjIuIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMyANCiAgIEF1dGhvcidzIEFkZHJlc3Nl cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMyANCiAgIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI0IA0K ICAgRGlzY2xhaW1lciBvZiBWYWxpZGl0eS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4yNCANCiAgIENvcHlyaWdodCBTdGF0ZW1lbnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMjUgDQogICBBY2tub3dsZWRnbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjUgDQogICAgDQoKCgoKIA0KIA0KQmxhY2sgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICAgW1BhZ2Ug Ml0gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVt ZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgIA0KMS4gSW50cm9k dWN0aW9uIA0KCiAgIEZpZ3VyZSAxIHNob3dzIHRoZSBvdmVyYWxsIGFyY2hpdGVjdHVyZSBvZiBh IHBORlMgc3lzdGVtOiANCgogICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgfCstLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0rIA0KICAgICAgIHx8Ky0tLS0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCANCiAgICAgICB8fHwgICAgICAg ICAgIHwgICAgICAgIE5GU3Y0ICsgcE5GUyAgICAgICAgICAgIHwgICAgICAgICAgIHwgDQogICAg ICAgK3x8ICBDbGllbnRzICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgU2Vy dmVyICB8IA0KICAgICAgICArfCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgfCANCiAgICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgDQogICAgICAgICAgICAgIHx8fCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rIA0KICAgICAgICAg ICAgICB8fHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAg ICAgICAgICAgICAgfHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgDQogICAgICAgICAgICAgIHx8fCAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rICAgICAg ICAgICAgICB8IA0KICAgICAgICAgICAgICB8fHwgICAgICAgICAgICAgICAgfCstLS0tLS0tLS0t LSsgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgfHwrLS0tLS0tLS0tLS0tLS0tLXx8Ky0t LS0tLS0tLS0tKyAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgIHwrLS0tLS0tLS0tLS0tLS0t LS18fHwgICAgICAgICAgIHwgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tK3x8ICBTdG9yYWdlICB8LS0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArfCAgU3lzdGVtcyAgfCANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyANCiAgICANCiAgICAgICAgICAgICAgICAgICAgICAg IEZpZ3VyZSAxIHBORlMgQXJjaGl0ZWN0dXJlIA0KCiAgIFRoZSBvdmVyYWxsIGFwcHJvYWNoIGlz IHRoYXQgcE5GUy1lbmhhbmNlZCBjbGllbnRzIG9idGFpbiBzdWZmaWNpZW50IA0KICAgaW5mb3Jt YXRpb24gZnJvbSB0aGUgc2VydmVyIHRvIGVuYWJsZSB0aGVtIHRvIGFjY2VzcyB0aGUgdW5kZXJs eWluZyANCiAgIHN0b3JhZ2UgKG9uIHRoZSBTdG9yYWdlIFN5c3RlbXMpIGRpcmVjdGx5LiAgU2Vl IHRoZSBwTkZTIHBvcnRpb24gb2YgDQogICBbTkZTVjQuMV0gZm9yIG1vcmUgZGV0YWlscy4gIFRo aXMgZHJhZnQgaXMgY29uY2VybmVkIHdpdGggYWNjZXNzIGZyb20gDQogICBwTkZTIGNsaWVudHMg dG8gU3RvcmFnZSBTeXN0ZW1zIG92ZXIgc3RvcmFnZSBwcm90b2NvbHMgYmFzZWQgb24gDQogICBi bG9ja3MgYW5kIHZvbHVtZXMsIHN1Y2ggYXMgdGhlIFNDU0kgcHJvdG9jb2wgZmFtaWx5IChlLmcu LCBwYXJhbGxlbCANCiAgIFNDU0ksIEZDUCBmb3IgRmlicmUgQ2hhbm5lbCwgaVNDU0ksIFNBUyku ICBUaGlzIGNsYXNzIG9mIHN0b3JhZ2UgaXMgDQogICByZWZlcnJlZCB0byBhcyBibG9jay92b2x1 bWUgc3RvcmFnZS4gIFdoaWxlIHRoZSBTZXJ2ZXIgdG8gU3RvcmFnZSANCiAgIFN5c3RlbSBwcm90 b2NvbCBpcyBub3Qgb2YgY29uY2VybiBmb3IgaW50ZXJvcGVyYWJpbGl0eSBoZXJlLCBpdCB3aWxs IA0KICAgdHlwaWNhbGx5IGFsc28gYmUgYSBibG9jay92b2x1bWUgcHJvdG9jb2wgd2hlbiBjbGll bnRzIHVzZSBibG9jay8gDQogICB2b2x1bWUgcHJvdG9jb2xzLiANCgoyLiBCbG9jayBMYXlvdXQg RGVzY3JpcHRpb24gDQoKMi4xLiBCYWNrZ3JvdW5kIGFuZCBBcmNoaXRlY3R1cmUgDQoKICAgVGhl IGZ1bmRhbWVudGFsIHN0b3JhZ2UgYWJzdHJhY3Rpb24gc3VwcG9ydGVkIGJ5IGJsb2NrL3ZvbHVt ZSBzdG9yYWdlIA0KICAgaXMgYSBzdG9yYWdlIHZvbHVtZSBjb25zaXN0aW5nIG9mIGEgc2VxdWVu dGlhbCBzZXJpZXMgb2YgZml4ZWQgc2l6ZSANCiAgIGJsb2Nrcy4gIFRoaXMgY2FuIGJlIHRob3Vn aHQgb2YgYXMgYSBsb2dpY2FsIGRpc2s7IGl0IG1heSBiZSByZWFsaXplZCANCiAgIGJ5IHRoZSBT dG9yYWdlIFN5c3RlbSBhcyBhIHBoeXNpY2FsIGRpc2ssIGEgcG9ydGlvbiBvZiBhIHBoeXNpY2Fs IA0KICAgZGlzayBvciBzb21ldGhpbmcgbW9yZSBjb21wbGV4IChlLmcuLCBjb25jYXRlbmF0aW9u LCBzdHJpcGluZywgUkFJRCwgDQoKIA0KIA0KQmxhY2sgICAgICAgICAgICAgICAgICAgIEV4cGly ZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQogICAgDA0KCgoKCgoK SW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAg ICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgYW5kIGNvbWJpbmF0aW9ucyB0aGVyZW9mKSBpbnZv bHZpbmcgbXVsdGlwbGUgcGh5c2ljYWwgZGlza3Mgb3IgDQogICBwb3J0aW9ucyB0aGVyZW9mLiAN CgogICBBIHBORlMgbGF5b3V0IGZvciB0aGlzIGJsb2NrL3ZvbHVtZSBjbGFzcyBvZiBzdG9yYWdl IGlzIHJlc3BvbnNpYmxlIA0KICAgZm9yIG1hcHBpbmcgZnJvbSBhbiBORlMgZmlsZSAob3IgcG9y dGlvbiBvZiBhIGZpbGUpIHRvIHRoZSBibG9ja3Mgb2YgDQogICBzdG9yYWdlIHZvbHVtZXMgdGhh dCBjb250YWluIHRoZSBmaWxlLiAgVGhlIGJsb2NrcyBhcmUgZXhwcmVzc2VkIGFzIA0KICAgZXh0 ZW50cyB3aXRoIDY0IGJpdCBvZmZzZXRzIGFuZCBsZW5ndGhzIHVzaW5nIHRoZSBleGlzdGluZyBO RlN2NCANCiAgIG9mZnNldDQgYW5kIGxlbmd0aDQgdHlwZXMuICBDbGllbnRzIG11c3QgYmUgYWJs ZSB0byBwZXJmb3JtIEkvTyB0byANCiAgIHRoZSBibG9jayBleHRlbnRzIHdpdGhvdXQgYWZmZWN0 aW5nIGFkZGl0aW9uYWwgYXJlYXMgb2Ygc3RvcmFnZSANCiAgIChlc3BlY2lhbGx5IGltcG9ydGFu dCBmb3Igd3JpdGVzKSwgdGhlcmVmb3JlIGV4dGVudHMgTVVTVCBiZSBhbGlnbmVkIA0KICAgdG8g NTEyLW9jdGV0IGJvdW5kYXJpZXMsIGFuZCBTSE9VTEQgYmUgYWxpZ25lZCB0byB0aGUgYmxvY2sg c2l6ZSB1c2VkIA0KICAgYnkgdGhlIE5GU3Y0IHNlcnZlciBpbiBtYW5hZ2luZyB0aGUgYWN0dWFs IGZpbGVzeXN0ZW0gKDQga2lsb2J5dGVzIA0KICAgYW5kIDgga2lsb2J5dGVzIGFyZSBjb21tb24g YmxvY2sgc2l6ZXMpLiAgVGhpcyBibG9jayBzaXplIGlzIA0KICAgYXZhaWxhYmxlIGFzIHRoZSBO RlN2NC4xIGxheW91dF9ibGtzaXplIGF0dHJpYnV0ZS4gW05GU1Y0LjFdIA0KCiAgIFRoZSBwTkZT IG9wZXJhdGlvbiBmb3IgcmVxdWVzdGluZyBhIGxheW91dCAoTEFZT1VUR0VUKSBpbmNsdWRlcyB0 aGUgDQogICAibGF5b3V0aW9tb2RlNCBsb2dhX2lvbW9kZSIgYXJndW1lbnQgd2hpY2ggaW5kaWNh dGVzIHdoZXRoZXIgdGhlIA0KICAgcmVxdWVzdGVkIGxheW91dCBpcyBmb3IgcmVhZC1vbmx5IHVz ZSBvciByZWFkLXdyaXRlIHVzZS4gIEEgcmVhZC1vbmx5IA0KICAgbGF5b3V0IG1heSBjb250YWlu IGhvbGVzIHRoYXQgYXJlIHJlYWQgYXMgemVybywgd2hlcmVhcyBhIHJlYWQtd3JpdGUgDQogICBs YXlvdXQgd2lsbCBjb250YWluIGFsbG9jYXRlZCwgYnV0IHVuLWluaXRpYWxpemVkIHN0b3JhZ2Ug aW4gdGhvc2UgDQogICBob2xlcyAocmVhZCBhcyB6ZXJvLCBjYW4gYmUgd3JpdHRlbiBieSBjbGll bnQpLiAgVGhpcyBkcmFmdCBhbHNvIA0KICAgc3VwcG9ydHMgY2xpZW50IHBhcnRpY2lwYXRpb24g aW4gY29weSBvbiB3cml0ZSBieSBwcm92aWRpbmcgYm90aCANCiAgIHJlYWQtb25seSBhbmQgdW4t aW5pdGlhbGl6ZWQgc3RvcmFnZSBmb3IgdGhlIHNhbWUgcmFuZ2UgaW4gYSBsYXlvdXQuICANCiAg IFJlYWRzIGFyZSBpbml0aWFsbHkgcGVyZm9ybWVkIG9uIHRoZSByZWFkLW9ubHkgc3RvcmFnZSwg d2l0aCB3cml0ZXMgDQogICBnb2luZyB0byB0aGUgdW4taW5pdGlhbGl6ZWQgc3RvcmFnZS4gIEFm dGVyIHRoZSBmaXJzdCB3cml0ZSB0aGF0IA0KICAgaW5pdGlhbGl6ZXMgdGhlIHVuLWluaXRpYWxp emVkIHN0b3JhZ2UsIGFsbCByZWFkcyBhcmUgcGVyZm9ybWVkIHRvIA0KICAgdGhhdCBub3ctaW5p dGlhbGl6ZWQgd3JpdGVhYmxlIHN0b3JhZ2UsIGFuZCB0aGUgY29ycmVzcG9uZGluZyByZWFkLQ0K ICAgb25seSBzdG9yYWdlIGlzIG5vIGxvbmdlciB1c2VkLiANCgoyLjIuIEdFVERFVklDRUxJU1Qg YW5kIEdFVERFVklDRUlORk8gDQoKMi4yLjEuIFZvbHVtZSBJZGVudGlmaWNhdGlvbiANCgogICBT dG9yYWdlIFN5c3RlbXMgc3VjaCBhcyBzdG9yYWdlIGFycmF5cyBjYW4gaGF2ZSBtdWx0aXBsZSBw aHlzaWNhbCANCiAgIG5ldHdvcmsgcG9ydHMgdGhhdCBuZWVkIG5vdCBiZSBjb25uZWN0ZWQgdG8g YSBjb21tb24gbmV0d29yaywgDQogICByZXN1bHRpbmcgaW4gYSBwTkZTIGNsaWVudCBoYXZpbmcg c2ltdWx0YW5lb3VzIG11bHRpcGF0aCBhY2Nlc3MgdG8gDQogICB0aGUgc2FtZSBzdG9yYWdlIHZv bHVtZXMgdmlhIGRpZmZlcmVudCBwb3J0cyBvbiBkaWZmZXJlbnQgbmV0d29ya3MuICANCiAgIFRo ZSBuZXR3b3JrcyBtYXkgbm90IGV2ZW4gYmUgdGhlIHNhbWUgdGVjaG5vbG9neSAtIGZvciBleGFt cGxlLCANCiAgIGFjY2VzcyB0byB0aGUgc2FtZSB2b2x1bWUgdmlhIGJvdGggaVNDU0kgYW5kIEZp YnJlIENoYW5uZWwgaXMgDQogICBwb3NzaWJsZSwgaGVuY2UgbmV0d29yayBhZGRyZXNzIGFyZSBk aWZmaWN1bHQgdG8gdXNlIGZvciB2b2x1bWUgDQogICBpZGVudGlmaWNhdGlvbi4gIEZvciB0aGlz IHJlYXNvbiwgdGhpcyBwTkZTIGJsb2NrIGxheW91dCBpZGVudGlmaWVzIA0KICAgc3RvcmFnZSB2 b2x1bWVzIGJ5IGNvbnRlbnQsIGZvciBleGFtcGxlIHByb3ZpZGluZyB0aGUgbWVhbnMgdG8gbWF0 Y2ggDQogICAodW5pcXVlIHBvcnRpb25zIG9mKSBsYWJlbHMgdXNlZCBieSB2b2x1bWUgbWFuYWdl cnMuICBBbnkgYmxvY2sgcE5GUyANCiAgIHN5c3RlbSB1c2luZyB0aGlzIGxheW91dCBNVVNUIHN1 cHBvcnQgYSBtZWFucyBvZiBjb250ZW50LWJhc2VkIHVuaXF1ZSANCiAgIHZvbHVtZSBpZGVudGlm aWNhdGlvbiB0aGF0IGNhbiBiZSBlbXBsb3llZCB2aWEgdGhlIGRhdGEgc3RydWN0dXJlIA0KICAg Z2l2ZW4gaGVyZS4gDQoKIA0KIA0KQmxhY2sgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDIwMDcgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQogICAgDA0KCgoKCgoKSW50ZXJu ZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1h cmNoIDIwMDcgDQogICAgDQoKICAgc3RydWN0IHBuZnNfYmxvY2tfc2lnX2NvbXBvbmVudDQgeyAg LyogIGRpc2sgc2lnbmF0dXJlIGNvbXBvbmVudCAqLyANCgogICAgICBvZmZzZXQ0IHNpZ19vZmZz ZXQ7ICAgICAgICAvKiBvY3RldCBvZmZzZXQgb2YgY29tcG9uZW50IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgd2l0aGluIHNpZ25hdHVyZSBibG9jayAqLyANCgogICAgICBv cGFxdWUgIGNvbnRlbnRzPD47ICAgICAgICAvKiBjb250ZW50cyBvZiB0aGlzIGNvbXBvbmVudCBv ZiB0aGUgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaWduYXR1cmUgKHRo aXMgaXMgb3BhcXVlKSAqLyANCgogICB9OyANCgogICBOb3RlIHRoYXQgdGhlIG9wYXF1ZSAiY29u dGVudHMiIGZpZWxkIGluIHRoZSANCiAgICJwbmZzX2Jsb2NrX3NpZ19jb21wb25lbnQ0IiBzdHJ1 Y3R1cmUgTVVTVCBOT1QgYmUgaW50ZXJwcmV0ZWQgYXMgYSANCiAgIHplcm8tdGVybWluYXRlZCBz dHJpbmcsIGFzIGl0IG1heSBjb250YWluIGVtYmVkZGVkIHplcm8tdmFsdWVkIA0KICAgb2N0ZXRz LiAgVGhlcmUgYXJlIG5vIHJlc3RyaWN0aW9ucyBvbiBhbGlnbm1lbnQgKGUuZy4sIG5laXRoZXIg DQogICBzaWdfb2Zmc2V0IG5vciB0aGUgbGVuZ3RoIGFyZSByZXF1aXJlZCB0byBiZSBtdWx0aXBs ZXMgb2YgNCkuICBUaGUgDQogICBzaWdfb2Zmc2V0IHJlcHJlc2VudHMgYW4gb2Zmc2V0IGZyb20g dGhlIHN0YXJ0IG9mIGEgc2lnbmF0dXJlIGJsb2NrIA0KICAgKGRlZmluZWQgYmVsb3cpLiANCgog ICBUaGUgcE5GUyBjbGllbnQgYmxvY2sgbGF5b3V0IGRyaXZlciB1c2VzIHRoaXMgdm9sdW1lIGlk ZW50aWZpY2F0aW9uIA0KICAgdG8gbWFwIHBuZnNfYmxvY2tfdm9sdW1lX3R5cGU0IFZPTFVNRV9T SU1QTEUgZGV2aWNlaWQ0cyB0byBpdHMgbG9jYWwgDQogICB2aWV3IG9mIGEgTFVOLiANCgoyLjIu Mi4gVm9sdW1lIFRvcG9sb2d5IA0KCiAgIFRoZSBwTkZTIGJsb2NrIHNlcnZlciB2b2x1bWUgdG9w b2xvZ3kgaXMgZXhwcmVzc2VkIGFzIGFuIGFyYml0cmFyeSANCiAgIGNvbWJpbmF0aW9uIG9mIGJh c2Ugdm9sdW1lIHR5cGVzIGVudW1lcmF0ZWQgaW4gdGhlIGZvbGxvd2luZyBkYXRhIA0KICAgc3Ry dWN0dXJlcy4gDQoKICAgZW51bSBwbmZzX2Jsb2NrX3ZvbHVtZV90eXBlNCB7IA0KCiAgICAgIFZP TFVNRV9TSU1QTEUgPSAwLCAgICAgIC8qIHZvbHVtZSBtYXBzIHRvIGEgc2luZ2xlIExVICovIA0K CiAgICAgIFZPTFVNRV9TTElDRSAgPSAxLCAgICAgIC8qIHZvbHVtZSBpcyBhIHNsaWNlIG9mIGFu b3RoZXIgdm9sdW1lICovIA0KCiAgICAgIFZPTFVNRV9DT05DQVQgPSAyLCAgICAgIC8qIHZvbHVt ZSBpcyBhIGNvbmNhdGVuYXRpb24gb2YgbXVsdGlwbGUgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB2b2x1bWVzICovIA0KCiAgICAgIFZPTFVNRV9TVFJJUEUgPSAzICAgICAgIC8q IHZvbHVtZSBpcyBzdHJpcGVkIGFjcm9zcyBtdWx0aXBsZSANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHZvbHVtZXMgKi8gDQoKICAgfTsgDQoKICAgc3RydWN0IHBuZnNfYmxvY2tf c2ltcGxlX3ZvbHVtZV9pbmZvNCB7IA0KCiAgICAgIGRldmljZWlkNCAgICAgICAgIHZvbF9pZDsg ICAgIC8qIHRoaXMgdm9sdW1lIGlkICovIA0KCiAgICAgIGludDY0X3QgICAgICAgICAgIHNpZ19v ZmZzZXQ7ICAgIC8qIG9mZnNldCBpbiA1MTIgb2N0ZXQgYmxvY2tzICANCiANCiANCkJsYWNrICAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgIFtQ YWdlIDVdIA0KICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9W b2x1bWUgTGF5b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZyb20gc3RhcnQgb2Ygdm9sdW1lIGlmIHBvc2l0 aXZlIA0KCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZyb20gZW5kIG9m IHZvbHVtZSBpZiBuZWdhdGl2ZSANCgogICAgICBwbmZzX2Jsb2NrX3NpZ19jb21wb25lbnQ0ICBk czxNQVhfU0lHX0NPTVA+OyAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAvKiBkaXNrIHNpZ25hdHVyZSAqLyANCgogICB9OyAN CgogICAgDQoKICAgc3RydWN0IHBuZnNfYmxvY2tfc2xpY2Vfdm9sdW1lX2luZm80IHsgDQoKICAg ICAgZGV2aWNlaWQ0ICAgICAgICB2b2xfaWQ7ICAvKiB0aGlzIHZvbHVtZSBpZCAqLyANCgogICAg ICBvZmZzZXQ0ICAgICAgICAgIHN0YXJ0OyAgIC8qIG9mZnNldCBvZiB0aGUgc3RhcnQgb2YgdGhl IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2xpY2UgaW4gNTEyIG9jdGV0 IGJsb2NrcyAqLyANCgogICAgICBsZW5ndGg0ICAgICAgICAgIGxlbmd0aDsgIC8qIGxlbmd0aCBv ZiBzbGljZSBpbiA1MTIgb2N0ZXQgYmxvY2tzIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKi8gDQoKICAgICAgZGV2aWNlaWQ0ICAgICAgICB2b2x1bWU7ICAvKiB2b2x1bWUg d2hpY2ggaXMgc2xpY2VkICovIA0KCiAgIH07IA0KCiAgICANCgogICBzdHJ1Y3QgcG5mc19ibG9j a19jb25jYXRfdm9sdW1lX2luZm80IHsgDQoKICAgICAgZGV2aWNlaWQ0ICAgICAgICAgdm9sX2lk OyAgICAgLyogdGhpcyB2b2x1bWUgaWQgKi8gDQoKICAgICAgZGV2aWNlaWQ0ICAgICAgICAgdm9s dW1lczw+OyAgLyogdm9sdW1lcyB3aGljaCBhcmUgY29uY2F0ZW5hdGVkICovIA0KCiAgIH07IA0K CiAgICANCgogICBzdHJ1Y3QgcG5mc19ibG9ja19zdHJpcGVfdm9sdW1lX2luZm80IHsgDQoKICAg ICAgZGV2aWNlaWQ0ICAgICAgICAgdm9sX2lkOyAgICAgICAgLyogdGhpcyB2b2x1bWUgaWQgKi8g DQoKICAgICAgbGVuZ3RoNCAgICAgICAgICAgc3RyaXBlX3VuaXQ7ICAgLyogc2l6ZSBvZiBzdHJp cGUgaW4gNTEyIG9jdGVjdCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYmxvY2tzICovIA0KCiAgICAgIGRldmljZWlkNCAgICAgICAgIHZvbHVtZXM8PjsgICAgIC8q IHZvbHVtZXMgd2hpY2ggYXJlIHN0cmlwZWQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFjcm9zcyAtLSBNVVNUIGJlIHNhbWUgc2l6ZSAqLyANCgogDQogDQpCbGFj ayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAg ICBbUGFnZSA2XSANCiAgICAMDQoKCgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxv Y2svVm9sdW1lIExheW91dCAgICAgICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICB9OyAN CgogICAgDQoKICAgdW5pb24gcG5mc19ibG9ja192b2x1bWU0IHN3aXRjaCAocG5mc19ibG9ja192 b2x1bWVfdHlwZTQgdHlwZSkgeyANCgogICAgICAgICBjYXNlIFZPTFVNRV9TSU1QTEU6IA0KCiAg ICAgICAgICAgICAgIHBuZnNfYmxvY2tfc2ltcGxlX3ZvbHVtZV9pbmZvNCBzaW1wbGVfaW5mbzsg DQoKICAgICAgICAgY2FzZSBWT0xVTUVfU0xJQ0U6IA0KCiAgICAgICAgICAgICAgIHBuZnNfYmxv Y2tfc2xpY2Vfdm9sdW1lX2luZm80IHNsaWNlX2luZm87IA0KCiAgICAgICAgIGNhc2UgVk9MVU1F X0NPTkNBVDogDQoKICAgICAgICAgICAgICAgcG5mc19ibG9ja19jb25jYXRfdm9sdW1lX2luZm80 IGNvbmNhdF9pbmZvOyANCgogICAgICAgICBjYXNlIFZPTFVNRV9TVFJJUEU6IA0KCiAgICAgICAg ICAgICAgIHBuZnNfYmxvY2tfc3RyaXBlX3ZvbHVtZV9pbmZvNCBzdHJpcGVfaW5mbzsgDQoKICAg fTsgDQoKICAgIA0KCiAgIHN0cnVjdCBwbmZzX2Jsb2NrX2RldmljZWFkZHI0IHsgDQoKICAgICAg cG5mc19ibG9ja192b2x1bWU0ICAgdm9sdW1lczw+OyAgLyogYXJyYXkgb2Ygdm9sdW1lcyAqLyAN CgogICB9OyANCgogICAgDQoKICAgVGhlICJwbmZzX2Jsb2NrX2RldmljZWFkZHI0IiBkYXRhIHN0 cnVjdHVyZSBpcyBhIHN0cnVjdHVyZSB0aGF0IA0KICAgYWxsb3dzIGFyYml0cmFyaWx5IGNvbXBs ZXggbmVzdGVkIHZvbHVtZSBzdHJ1Y3R1cmVzIHRvIGJlIGVuY29kZWQuICANCiAgIFRoZSB0eXBl cyBvZiBhZ2dyZWdhdGlvbnMgdGhhdCBhcmUgYWxsb3dlZCBhcmUgc3RyaXBlcywgDQogICBjb25j YXRlbmF0aW9ucywgYW5kIHNsaWNlcy4gTm90ZSB0aGF0IHRoZSB2b2x1bWUgdG9wb2xvZ3kgZXhw cmVzc2VkIA0KICAgaW4gdGhlIHBuZnNfYmxvY2tfZGV2aWNlYWRkcjQgZGF0YSBzdHJ1Y3R1cmUg d2lsbCBhbHdheXMgcmVzb2x2ZSB0byBhIA0KICAgc2V0IG9mIHBuZnNfYmxvY2tfdm9sdW1lX3R5 cGU0IFZPTFVNRV9TSU1QTEUuICBUaGUgYXJyYXkgb2Ygdm9sdW1lcyANCiAgIGlzIG9yZGVyZWQg c3VjaCB0aGF0IHRoZSByb290IHZvbHVtZSBpcyB0aGUgbGFzdCBlbGVtZW50IG9mIHRoZSANCiAg IGFycmF5LiAgQ29uY2F0LCBzbGljZSBhbmQgc3RyaXBlIHZvbHVtZXMgTVVTVCByZWZlciB0byB2 b2x1bWVzIA0KICAgZGVmaW5lZCBieSBsb3dlciBpbmRleGVkIGVsZW1lbnRzIG9mIHRoZSBhcnJh eS4gDQoKICAgVGhlICJwbmZzX2Jsb2NrX2RldmljZV9hZGRyNCIgZGF0YSBzdHJ1Y3R1cmUgaXMg cmV0dXJuZWQgYnkgdGhlIA0KICAgc2VydmVyIGFzIHRoZSBzdG9yYWdlLXByb3RvY29sLXNwZWNp ZmljIG9wYXF1ZSBmaWVsZCBkYV9hZGRyX2JvZHkgaW4gDQogICB0aGUgImRldmljZV9hZGRyNCIg c3RydWN0dXJlIGJ5IHN1Y2Nlc3NmdWwgR0VUREVWSUNFTElTVCBhbmQgDQogDQogDQpCbGFjayAg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgICBb UGFnZSA3XSANCiAgICAMDQoKCgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2sv Vm9sdW1lIExheW91dCAgICAgICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICBHRVRERVZJ Q0VJTkZPIG9wZXJhdGlvbnMuIFtORlNWNC4xXS4gIFR5cGljYWxseSB0aGUgc2VydmVyIGluIA0K ICAgcmVzcG9uc2UgdG8gYSBHRVRERVZJQ0VMSVNUIHJlcXVlc3Qgd2lsbCByZXR1cm4gYSBzaW5n bGUgDQogICAiZGV2bGlzdF9pdGVtNCIgaW4gdGhlIGdkbHJfZGV2aW5mb19saXN0IGFycmF5LiAg VGhpcyBpcyBiZWNhdXNlIHRoZSANCiAgICJvcGFxdWUgZGFfYWRkcl9ib2R5IiBmaWVsZCBpbnNp ZGUgdGhlICJkZXZpY2VfYWRkcjQiIGVuY29kZXMgdGhlIA0KICAgZW50aXJlIHZvbHVtZSBoaWVy YXJjaHkuICBJbiB0aGUgY2FzZSBvZiBjb3B5LW9uLXdyaXRlIGZpbGUgc3lzdGVtcywgDQogICB0 aGUgImdkbHJfZGV2aW5mb19saXN0IiBhcnJheSB3aWxsIGNvbnRhaW4gdHdvIGRldmljZXNfaXRl bTRzLCBvbmUgDQogICBkZXNjcmliaW5nIHRoZSByZWFkLW9ubHkgdm9sdW1lIGhpZXJhcmNoeSwg YW5kIG9uZSBkZXNjcmliaW5nIHRoZSANCiAgIHdyaXRhYmxlIHZvbHVtZSBoaWVyYXJjaHkuIA0K CiAgIEFzIG5vdGVkIGFib3ZlLCBhbGwgZGV2aWNlX2FkZHI0IHN0cnVjdHVyZXMgZXZlbnR1YWxs eSByZXNvbHZlIHRvIGEgDQogICBzZXQgb2Ygdm9sdW1lcyBvZiB0eXBlICJwbmZzX2Jsb2NrX3Zv bHVtZV90eXBlNCBWT0xVTUVfU0lNUExFIiAgVGhlc2UgDQogICB2b2x1bWVzIGFyZSBlYWNoIHVu aXF1ZWx5IGlkZW50aWZpZWQgYnkgYSBzZXQgb2Ygc2lnbmF0dXJlIGNvbXBvbmVudHMgDQogICBs b2NhdGVkIHdpdGhpbiByZXNwZWN0aXZlIHNpZ25hdHVyZSBibG9ja3MuICBFYWNoIFZPTFVNRV9T SU1QTEUgDQogICB2b2x1bWUgc3BlY2lmaWVzIHRoZSBsb2NhdGlvbiBvZiBpdHMgc2lnbmF0dXJl IGJsb2NrIGluIHRlcm1zIG9mIDUxMiANCiAgIG9jdGV0IGJsb2Nrcy4gIFRoZSAiaW50NjRfdCBz aWdfb2Zmc2V0IiBpcyBhIHNpZ25lZCBxdWFudGl0eSB3aGljaCANCiAgIHdoZW4gcG9zaXRpdmUg cmVwcmVzZW50cyBhbiBvZmZzZXQgZnJvbSB0aGUgc3RhcnQgb2YgdGhlIHZvbHVtZSwgYW5kIA0K ICAgd2hlbiBuZWdhdGl2ZSByZXByZXNlbnRzIGFuIG9mZnNldCBmcm9tIHRoZSBlbmQgb2YgdGhl IHZvbHVtZS4gDQoKICAgTmVnYXRpdmUgb2Zmc2V0cyBhcmUgcGVybWl0dGVkIGluIG9yZGVyIHRv IHNpbXBsaWZ5IHRoZSBjbGllbnQgDQogICBpbXBsZW1lbnRhdGlvbiBvbiBzeXN0ZW1zIHdoZXJl IHRoZSBkZXZpY2UgbGFiZWwgaXMgZm91bmQgYXQgYSBmaXhlZCANCiAgIG9mZnNldCBmcm9tIHRo ZSBlbmQgb2YgdGhlIHZvbHVtZS4gSWYgdGhlIHNlcnZlciB1c2VzIG5lZ2F0aXZlIA0KICAgb2Zm c2V0cyB0byBkZXNjcmliZSB0aGUgc2lnbmF0dXJlLCB0aGVuIHRoZSBjbGllbnQgYW5kIHNlcnZl ciBNVVNUIA0KICAgTk9UIHNlZSBkaWZmZXJlbnQgdm9sdW1lIHNpemVzLiAgTmVnYXRpdmUgb2Zm c2V0cyBTSE9VTEQgTk9UIGJlIHVzZWQgDQogICBpbiBzeXN0ZW1zIHRoYXQgZHluYW1pY2FsbHkg cmVzaXplIHZvbHVtZXMgdW5sZXNzIGNhcmUgaXMgdGFrZW4gdG8gDQogICBlbnN1cmUgdGhhdCB0 aGUgZGV2aWNlIGxhYmVsIGlzIGFsd2F5cyBwcmVzZW50IGF0IHRoZSBvZmZzZXQgZnJvbSB0aGUg DQogICBlbmQgb2YgdGhlIHZvbHVtZSBhcyBzZWVuIGJ5IHRoZSBjbGllbnRzLiANCgoyLjIuMy4g R0VUREVWSUNFTElTVCBhbmQgR0VUREVWSUNFSU5GTyBkZXZpY2VpZDQgDQoKICAgVGhlICJkZXZp Y2VpZDQgZGxpX2lkIiByZXR1cm5lZCBpbiB0aGUgZGV2bGlzdF9pdGVtNCBvZiBhIHN1Y2Nlc3Nm dWwgDQogICBHRVRERVZJQ0VMSVNUIG9wZXJhdGlvbiBpcyBhIHNob3J0aGFuZCBpZCB1c2VkIHRv IHJlZmVyZW5jZSB0aGUgd2hvbGUgDQogICB2b2x1bWUgdG9wb2xvZ3kuIERlY29kaW5nIHRoZSAi cG5mc19ibG9ja19kZXZpY2VhZGRyNCIgcmVzdWx0cyBpbiBhIA0KICAgZmxhdCBvcmRlcmluZyBv ZiA1MTIgb2N0ZXQgZGF0YSBibG9ja3MgbWFwcGVkIHRvIFZPTFVNRV9TSU1QTEUgDQogICBkZXZp Y2VpZDRzLiBDb21iaW5lZCB3aXRoIHRoZSBkZXZpY2VpZDQgbWFwcGluZyB0byBhIGNsaWVudCBM VU4gDQogICBkZXNjcmliZWQgaW4gMi4yLjEgVm9sdW1lIElkZW50aWZpY2F0aW9uLCBhIGxvZ2lj YWwgdm9sdW1lIG9mZnNldCAgDQogICBjYW4gYmUgbWFwcGVkIHRvIGEgNTEyIGJsb2NrIG9uIGEg cE5GUyBjbGllbnQgTFVOLiBbTkZTVjQuMV0gIFdpdGggDQogICB0aGUgZXhjZXB0aW9uIG9mIHRo ZSByb290IHZvbHVtZSBpZCwgdGhlIGRldmljZSBpZHMgcmV0dXJuZWQgaW4gdGhlIA0KICAgdm9s dW1lcyBhcnJheSBvZiBhIHBuZnNfYmxvY2tfZGV2aWNlYWRkcjQgZGF0YSBzdHJ1Y3R1cmUgc2hv dWxkIG5vdCANCiAgIGJlIHBhc3NlZCBhcyBhcmd1bWVudHMgaW4gYSBHRVRERVZJQ0VJTkZPIHJl cXVlc3QuICBUaGVzZSBub24tcm9vdCANCiAgIHZvbHVtZSBkZXZpY2UgaWRzIGFyZSBuZXZlciBy ZXR1cm5lZCBieSBMQVlPVVRHRVQgaW4gdGhlIA0KICAgInBuZnNfYmxvY2tfbGF5b3V0NCB2b2xf aWQiIGZpZWxkLiAgSWYgYSBub24tcm9vdCBkZXZpY2UgaWQgaXMgcGFzc2VkIA0KICAgYXMgYW4g YXJndW1lbnQgaW4gYSBHRVRERVZJQ0VJTkZPIHJlcXVlc3QsIHRoZSBzZXJ2ZXIgU0hPVUxEIHJl dHVybiANCiAgIE5GUzRFUlJfSU5WQUwuIA0KCgoKCiANCiANCkJsYWNrICAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdIA0KICAg IAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0 ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCjIuMy4gRGF0YSBTdHJ1Y3R1cmVzOiBF eHRlbnRzIGFuZCBFeHRlbnQgTGlzdHMgDQoKICAgQSBwTkZTIGJsb2NrIGxheW91dCBpcyBhIGxp c3Qgb2YgZXh0ZW50cyB3aXRoaW4gYSBmbGF0IGFycmF5IG9mIDUxMi0NCiAgIG9jdGV0IGRhdGEg YmxvY2tzIGluIGEgbG9naWNhbCB2b2x1bWUuICBUaGUgZGV0YWlscyBvZiB0aGUgdm9sdW1lIA0K ICAgdG9wb2xvZ3kgY2FuIGJlIGRldGVybWluZWQgYnkgdXNpbmcgdGhlIEdFVERFVklDRUlORk8g b3IgDQogICBHRVRERVZJQ0VMSVNUIG9wZXJhdGlvbiAoc2VlIGRpc2N1c3Npb24gb2Ygdm9sdW1l IGlkZW50aWZpY2F0aW9uLCANCiAgIHNlY3Rpb24gMi4yIGFib3ZlKS4gIFRoZSBibG9jayBsYXlv dXQgZGVzY3JpYmVzIHRoZSBpbmRpdmlkdWFsIGJsb2NrIA0KICAgZXh0ZW50cyBvbiB0aGUgdm9s dW1lIHRoYXQgbWFrZSB1cCB0aGUgZmlsZS4gIFRoZSBvZmZzZXRzIGFuZCBsZW5ndGggDQogICBj b250YWluZWQgaW4gYW4gZXh0ZW50IGFyZSBzcGVjaWZpZWQgaW4gdW5pdHMgb2Ygb2N0ZXRzLiAN CgogICBlbnVtIHBuZnNfYmxvY2tfZXh0ZW50X3N0YXRlNCB7IA0KCiAgICAgUkVBRF9XUklURV9E QVRBICA9IDAsIC8qIHRoZSBkYXRhIGxvY2F0ZWQgYnkgdGhpcyBleHRlbnQgaXMgdmFsaWQgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgcmVhZGluZyBhbmQgd3JpdGluZy4gKi8g DQoKICAgICBSRUFEX0RBVEEgPSAxLCAgICAgICAgLyogdGhlIGRhdGEgbG9jYXRlZCBieSB0aGlz IGV4dGVudCBpcyB2YWxpZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciByZWFk aW5nIG9ubHk7IGl0IG1heSBub3QgYmUgd3JpdHRlbi4gDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAqLyANCgogICAgIElOVkFMSURfREFUQSA9IDIsICAgICAvKiB0aGUgbG9jYXRpb24g aXMgdmFsaWQ7IHRoZSBkYXRhIGlzIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW52 YWxpZC4gSXQgaXMgYSBuZXdseSAocHJlLSkgYWxsb2NhdGVkIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgZXh0ZW50LiBUaGVyZSBpcyBwaHlzaWNhbCBzcGFjZSBvbiB0aGUgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB2b2x1bWUuICovIA0KCiAgICAgTk9ORV9EQVRBID0g MyAgICAgICAgIC8qIHRoZSBsb2NhdGlvbiBpcyBpbnZhbGlkLiBJdCBpcyBhIGhvbGUgaW4gDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZmlsZS4gVGhlcmUgaXMgbm8gcGh5c2lj YWwgc3BhY2Ugb24gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdm9sdW1lLiAq LyANCgogICB9OyANCgogICBzdHJ1Y3QgcG5mc19ibG9ja19leHRlbnQ0IHsgDQoKICAgICBvZmZz ZXQ0ICAgICAgICAgZmlsZV9vZmZzZXQ7ICAgICAvKiB0aGUgc3RhcnRpbmcgb2N0ZXQgb2Zmc2V0 IGluIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZmlsZSAq LyANCgogICAgIGxlbmd0aDQgICAgICAgICBleHRlbnRfbGVuZ3RoOyAgIC8qIHRoZSBzaXplIGlu IG9jdGV0cyBvZiB0aGUgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGV4dGVudCAqLyANCgogICAgIG9mZnNldDQgICAgICAgICBzdG9yYWdlX29mZnNldDsgIC8qIHRo ZSBzdGFydGluZyBvY3RldCBvZmZzZXQgaW4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRoZSB2b2x1bWUgKi8gDQoKICAgICBwbmZzX2Jsb2NrX2V4dGVudF9zdGF0 ZTQgZXM7ICAgICAvKiB0aGUgc3RhdGUgb2YgdGhpcyBleHRlbnQgKi8gDQoKICAgfTsgDQoKICAg IA0KCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAg ICAgICAgICAgICAgICAgIFtQYWdlIDldIA0KICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAg ICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0K ICAgIA0KCiAgIHN0cnVjdCBwbmZzX2Jsb2NrX2xheW91dDQgeyANCgogICAgICBkZXZpY2VpZDQg ICAgICAgICAgdm9sX2lkOyAgICAgICAvKiBpZCBvZiBsb2dpY2FsIHZvbHVtZSBvbiB3aGljaCAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmlsZSBpcyBzdG9yZWQu ICovIA0KCiAgICAgIHBuZnNfYmxvY2tfZXh0ZW50NCBleHRlbnRzPD47ICAgIC8qIGV4dGVudHMg d2hpY2ggbWFrZSB1cCB0aGlzIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBsYXlvdXQuICovIA0KCiAgIH07IA0KCiAgIFRoZSBibG9jayBsYXlvdXQgY29uc2lzdHMg b2YgYSBkZXZpY2VpZDQsIHNob3J0aGFuZCBmb3IgdGhlIHdob2xlIA0KICAgdG9wb2xvZ3kgb2Yg dGhlIGxvZ2ljYWwgdm9sdW1lIG9uIHdoaWNoIHRoZSBmaWxlIGlzIHN0b3JlZCwgZm9sbG93ZWQg DQogICBieSBhIGxpc3Qgb2YgZXh0ZW50cyB3aGljaCBtYXAgdGhlIGxvZ2ljYWwgcmVnaW9ucyBv ZiB0aGUgZmlsZSB0byANCiAgIHBoeXNpY2FsIGxvY2F0aW9ucyBvbiB0aGUgdm9sdW1lLiAgVGhl ICJzdG9yYWdlIG9mZnNldCIgZmllbGQgd2l0aGluIA0KICAgZWFjaCBleHRlbnQgaWRlbnRpZmll cyBhIGxvY2F0aW9uIG9uIHRoZSBsb2dpY2FsIHZvbHVtZSBkZXNjcmliZWQgYnkgDQogICB0aGUg InZvbHVtZSIgZmllbGQgaW4gdGhlIGxheW91dC4gIFRoZSBjbGllbnQgaXMgcmVzcG9uc2libGUg Zm9yIA0KICAgdHJhbnNsYXRpbmcgdGhpcyBsb2dpY2FsIG9mZnNldCBpbnRvIGFuIG9mZnNldCBv biB0aGUgYXBwcm9wcmlhdGUgDQogICB1bmRlcmx5aW5nIFNBTiBsb2dpY2FsIHVuaXQuICAgIA0K CiAgIEVhY2ggZXh0ZW50IG1hcHMgYSBsb2dpY2FsIHJlZ2lvbiBvZiB0aGUgZmlsZSBvbnRvIGEg cG9ydGlvbiBvZiB0aGUgDQogICBzcGVjaWZpZWQgbG9naWNhbCB2b2x1bWUuICBUaGUgZmlsZV9v ZmZzZXQsIGV4dGVudF9sZW5ndGgsIGFuZCBlcyANCiAgIGZpZWxkcyBmb3IgYW4gZXh0ZW50IHJl dHVybmVkIGZyb20gdGhlIHNlcnZlciBhcmUgYWx3YXlzIHZhbGlkLiBUaGUgDQogICBpbnRlcnBy ZXRhdGlvbiBvZiB0aGUgc3RvcmFnZV9vZmZzZXQgZmllbGQgZGVwZW5kcyBvbiB0aGUgdmFsdWUg b2YgZXMgDQogICBhcyBmb2xsb3dzIChpbiBpbmNyZWFzaW5nIG9yZGVyKTogIA0KCiAgIG8gIFJF QURfV1JJVEVfREFUQSBtZWFucyB0aGF0IHN0b3JhZ2Vfb2Zmc2V0IGlzIHZhbGlkLCBhbmQgcG9p bnRzIHRvIA0KICAgICAgdmFsaWQvaW5pdGlhbGl6ZWQgZGF0YSB0aGF0IGNhbiBiZSByZWFkIGFu ZCB3cml0dGVuLiANCgogICBvICBSRUFEX0RBVEEgbWVhbnMgdGhhdCBzdG9yYWdlX29mZnNldCBp cyB2YWxpZCBhbmQgcG9pbnRzIHRvIHZhbGlkLyANCiAgICAgIGluaXRpYWxpemVkIGRhdGEgd2hp Y2ggY2FuIG9ubHkgYmUgcmVhZC4gIFdyaXRlIG9wZXJhdGlvbnMgYXJlIA0KICAgICAgcHJvaGli aXRlZDsgdGhlIGNsaWVudCBtYXkgbmVlZCB0byByZXF1ZXN0IGEgcmVhZC13cml0ZSBsYXlvdXQu IA0KCiAgIG8gIElOVkFMSURfREFUQSBtZWFucyB0aGF0IHN0b3JhZ2Vfb2Zmc2V0IGlzIHZhbGlk LCBidXQgcG9pbnRzIHRvIA0KICAgICAgaW52YWxpZCB1bi1pbml0aWFsaXplZCBkYXRhLiBUaGlz IGRhdGEgbXVzdCBub3QgYmUgcGh5c2ljYWxseSByZWFkIA0KICAgICAgZnJvbSB0aGUgZGlzayB1 bnRpbCBpdCBoYXMgYmVlbiBpbml0aWFsaXplZC4gIEEgcmVhZCByZXF1ZXN0IGZvciANCiAgICAg IGFuIElOVkFMSURfREFUQSBleHRlbnQgbXVzdCBmaWxsIHRoZSB1c2VyIGJ1ZmZlciB3aXRoIHpl cm9zLiBXcml0ZSANCiAgICAgIHJlcXVlc3RzIG11c3Qgd3JpdGUgd2hvbGUgc2VydmVyLXNpemVk IGJsb2NrcyB0byB0aGUgZGlzazsgb2N0ZXRzIA0KICAgICAgbm90IGluaXRpYWxpemVkIGJ5IHRo ZSB1c2VyIG11c3QgYmUgc2V0IHRvIHplcm8uICBBbnkgd3JpdGUgdG8gDQogICAgICBzdG9yYWdl IGluIGFuIElOVkFMSURfREFUQSBleHRlbnQgY2hhbmdlcyB0aGUgd3JpdHRlbiBwb3J0aW9uIG9m IA0KICAgICAgdGhlIGV4dGVudCB0byBSRUFEX1dSSVRFX0RBVEE7IHRoZSBwTkZTIGNsaWVudCBp cyByZXNwb25zaWJsZSBmb3IgDQogICAgICByZXBvcnRpbmcgdGhpcyBjaGFuZ2UgdmlhIExBWU9V VENPTU1JVC4gDQoKICAgbyAgTk9ORV9EQVRBIG1lYW5zIHRoYXQgc3RvcmFnZV9vZmZzZXQgaXMg bm90IHZhbGlkLCBhbmQgdGhpcyBleHRlbnQgDQogICAgICBtYXkgbm90IGJlIHVzZWQgdG8gc2F0 aXNmeSB3cml0ZSByZXF1ZXN0cy4gUmVhZCByZXF1ZXN0cyBtYXkgYmUgDQogICAgICBzYXRpc2Zp ZWQgYnkgemVyby1maWxsaW5nIGFzIGZvciBJTlZBTElEX0RBVEEuIE5PTkVfREFUQSBleHRlbnRz IA0KICAgICAgbWF5IGJlIHJldHVybmVkIGJ5IHJlcXVlc3RzIGZvciByZWFkYWJsZSBleHRlbnRz OyB0aGV5IGFyZSBuZXZlciANCiAgICAgIHJldHVybmVkIGlmIHRoZSByZXF1ZXN0IHdhcyBmb3Ig YSB3cml0ZWFibGUgZXh0ZW50LiANCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdIA0KICAgIAwNCgoKCgoK CkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0ICAgICAgICAg ICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIEFuIGV4dGVudCBsaXN0IGxpc3RzIGFsbCByZWxl dmFudCBleHRlbnRzIGluIGluY3JlYXNpbmcgb3JkZXIgb2YgdGhlIA0KICAgZmlsZV9vZmZzZXQg b2YgZWFjaCBleHRlbnQ7IGFueSB0aWVzIGFyZSBicm9rZW4gYnkgaW5jcmVhc2luZyBvcmRlciAN CiAgIG9mIHRoZSBleHRlbnQgc3RhdGUgKGVzKS4gDQoKMi4zLjEuIExheW91dCBSZXF1ZXN0cyBh bmQgRXh0ZW50IExpc3RzIA0KCiAgIEVhY2ggcmVxdWVzdCBmb3IgYSBsYXlvdXQgc3BlY2lmaWVz IGF0IGxlYXN0IHRocmVlIHBhcmFtZXRlcnM6IGZpbGUgDQogICBvZmZzZXQsIGRlc2lyZWQgc2l6 ZSwgYW5kIG1pbmltdW0gc2l6ZS4gIElmIHRoZSBzdGF0dXMgb2YgYSByZXF1ZXN0IA0KICAgaW5k aWNhdGVzIHN1Y2Nlc3MsIHRoZSBleHRlbnQgbGlzdCByZXR1cm5lZCBtdXN0IG1lZXQgdGhlIGZv bGxvd2luZyANCiAgIGNyaXRlcmlhOiAgDQoKICAgbyAgQSByZXF1ZXN0IGZvciBhIHJlYWRhYmxl IChidXQgbm90IHdyaXRlYWJsZSkgbGF5b3V0IHJldHVybnMgb25seSANCiAgICAgIFJFQURfREFU QSBvciBOT05FX0RBVEEgZXh0ZW50cyAoYnV0IG5vdCBJTlZBTElEX0RBVEEgb3IgDQogICAgICBS RUFEX1dSSVRFX0RBVEEgZXh0ZW50cykuIA0KCiAgIG8gIEEgcmVxdWVzdCBmb3IgYSB3cml0ZWFi bGUgbGF5b3V0IHJldHVybnMgUkVBRF9XUklURV9EQVRBIG9yIA0KICAgICAgSU5WQUxJRF9EQVRB IGV4dGVudHMgKGJ1dCBub3QgTk9ORV9EQVRBIGV4dGVudHMpLiAgSXQgbWF5IGFsc28gDQogICAg ICByZXR1cm4gUkVBRF9EQVRBIGV4dGVudHMgb25seSB3aGVuIHRoZSBvZmZzZXQgcmFuZ2VzIGlu IHRob3NlIA0KICAgICAgZXh0ZW50cyBhcmUgYWxzbyBjb3ZlcmVkIGJ5IElOVkFMSURfREFUQSBl eHRlbnRzIHRvIHBlcm1pdCB3cml0ZXMuICANCgogICBvICBUaGUgZmlyc3QgZXh0ZW50IGluIHRo ZSBsaXN0IE1VU1QgY29udGFpbiB0aGUgc3RhcnRpbmcgb2Zmc2V0LiANCgogICBvICBUaGUgdG90 YWwgc2l6ZSBvZiBleHRlbnRzIGluIHRoZSBleHRlbnQgbGlzdCBNVVNUIGNvdmVyIGF0IGxlYXN0 IA0KICAgICAgdGhlIG1pbmltdW0gc2l6ZSBhbmQgbm8gbW9yZSB0aGFuIHRoZSBkZXNpcmVkIHNp emUuICBPbmUgZXhjZXB0aW9uIA0KICAgICAgaXMgYWxsb3dlZDogdGhlIHRvdGFsIHNpemUgTUFZ IGJlIHNtYWxsZXIgaWYgb25seSByZWFkYWJsZSBleHRlbnRzIA0KICAgICAgd2VyZSByZXF1ZXN0 ZWQgYW5kIEVPRiBpcyBlbmNvdW50ZXJlZC4gDQoKICAgbyAgRXh0ZW50cyBpbiB0aGUgZXh0ZW50 IGxpc3QgTVVTVCBiZSBsb2dpY2FsbHkgY29udGlndW91cyBmb3IgYSANCiAgICAgIHJlYWQtb25s eSBsYXlvdXQuICBGb3IgYSByZWFkLXdyaXRlIGxheW91dCwgdGhlIHNldCBvZiB3cml0YWJsZSAN CiAgICAgIGV4dGVudHMgKGkuZS4sIGV4Y2x1ZGluZyBSRUFEX0RBVEEgZXh0ZW50cykgTVVTVCBi ZSBsb2dpY2FsbHkgDQogICAgICBjb250aWd1b3VzLiAgRXZlcnkgUkVBRF9EQVRBIGV4dGVudCBp biBhIHJlYWQtd3JpdGUgbGF5b3V0IE1VU1QgYmUgDQogICAgICBjb3ZlcmVkIGJ5IGFuIElOVkFM SURfREFUQSBleHRlbnQuICBUaGlzIG92ZXJsYXAgb2YgUkVBRF9EQVRBIGFuZCANCiAgICAgIElO VkFMSURfREFUQSBleHRlbnRzIGlzIHRoZSBvbmx5IHBlcm1pdHRlZCBleHRlbnQgb3ZlcmxhcC4g DQoKICAgbyAgRXh0ZW50cyBNVVNUIGJlIG9yZGVyZWQgaW4gdGhlIGxpc3QgYnkgc3RhcnRpbmcg b2Zmc2V0LCB3aXRoIA0KICAgICAgUkVBRF9EQVRBIGV4dGVudHMgcHJlY2VkaW5nIElOVkFMSURf REFUQSBleHRlbnRzIGluIHRoZSBjYXNlIG9mIA0KICAgICAgZXF1YWwgZmlsZV9vZmZzZXRzLiAN CgoyLjMuMi4gTGF5b3V0IENvbW1pdHMgDQoKICAgc3RydWN0IHBuZnNfYmxvY2tfbGF5b3V0dXBk YXRlNCB7IA0KCiAgICAgIHBuZnNfYmxvY2tfZXh0ZW50NCBjb21taXRfbGlzdDw+Oy8qIGxpc3Qg b2YgZXh0ZW50cyB0byB3aGljaCBub3cgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbnRhaW4gdmFsaWQgZGF0YS4gKi8gDQoKCgogDQogDQpCbGFjayAgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDEx XSANCiAgICAMDQoKCgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2svVm9sdW1l IExheW91dCAgICAgICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICAgICAgICBib29sICAg ICAgICAgICAgICAgbWFrZV92ZXJzaW9uOyAvKiBjbGllbnQgcmVxdWVzdHMgc2VydmVyIHRvDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3JlYXRlIGNvcHktb24t d3JpdGUgaW1hZ2Ugb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB0aGlzIGZpbGUuICovIA0KCiAgIH07IA0KCiAgIFRoZSAicG5mc19ibG9ja19sYXlvdXR1cGRh dGU0IiBzdHJ1Y3R1cmUgaXMgdXNlZCBieSB0aGUgY2xpZW50IGFzIHRoZSANCiAgIGJsb2NrLXBy b3RvY29sIHNwZWNpZmljIGFyZ3VtZW50IGluIGEgTEFZT1VUQ09NTUlUIG9wZXJhdGlvbi4gIFRo ZSANCiAgICJjb21taXRfbGlzdCIgZmllbGQgaXMgYW4gZXh0ZW50IGxpc3QgY292ZXJpbmcgcmVn aW9ucyBvZiB0aGUgZmlsZSANCiAgIGxheW91dCB0aGF0IHdlcmUgcHJldmlvdXNseSBpbiB0aGUg SU5WQUxJRF9EQVRBIHN0YXRlLCBidXQgaGF2ZSBiZWVuIA0KICAgd3JpdHRlbiBieSB0aGUgY2xp ZW50IGFuZCBzaG91bGQgbm93IGJlIGNvbnNpZGVyZWQgaW4gdGhlIA0KICAgUkVBRF9XUklURV9E QVRBIHN0YXRlLiAgVGhlIGVzIGZpZWxkIG9mIGVhY2ggZXh0ZW50IGluIHRoZSANCiAgIGNvbW1p dF9saXN0IE1VU1QgYmUgc2V0IHRvIFJFQURfV1JJVEVfREFUQS4gIEltcGxlbWVudGVycyBzaG91 bGQgYmUgDQogICBhd2FyZSB0aGF0IGEgc2VydmVyIG1heSBiZSB1bmFibGUgdG8gY29tbWl0IHJl Z2lvbnMgYXQgYSBncmFudWxhcml0eSANCiAgIHNtYWxsZXIgdGhhbiBhIGZpbGUtc3lzdGVtIGJs b2NrICh0eXBpY2FsbHkgNEtCIG9yIDhLQikuICBBcyBub3RlZCANCiAgIGFib3ZlLCB0aGUgYmxv Y2stc2l6ZSB0aGF0IHRoZSBzZXJ2ZXIgdXNlcyBpcyBhdmFpbGFibGUgYXMgYW4gTkZTdjQgDQog ICBhdHRyaWJ1dGUsIGFuZCBhbnkgZXh0ZW50cyBpbmNsdWRlZCBpbiB0aGUgImNvbW1pdF9saXN0 IiBNVVNUIGJlIA0KICAgYWxpZ25lZCB0byB0aGlzIGdyYW51bGFyaXR5IGFuZCBoYXZlIGEgc2l6 ZSB0aGF0IGlzIGEgbXVsdGlwbGUgb2YgDQogICB0aGlzIGdyYW51bGFyaXR5LiAgSWYgdGhlIGNs aWVudCBiZWxpZXZlcyB0aGF0IGl0cyBhY3Rpb25zIGhhdmUgbW92ZWQgDQogICB0aGUgZW5kLW9m LWZpbGUgaW50byB0aGUgbWlkZGxlIG9mIGEgYmxvY2sgYmVpbmcgY29tbWl0dGVkLCB0aGUgDQog ICBjbGllbnQgTVVTVCB3cml0ZSB6ZXJvZXMgZnJvbSB0aGUgZW5kLW9mLWZpbGUgdG8gdGhlIGVu ZCBvZiB0aGF0IA0KICAgYmxvY2sgYmVmb3JlIGNvbW1pdHRpbmcgdGhlIGJsb2NrLiAgRmFpbHVy ZSB0byBkbyBzbyBtYXkgcmVzdWx0IGluIA0KICAganVuayAodW5pbml0aWFsaXplZCBkYXRhKSBh cHBlYXJpbmcgaW4gdGhhdCBhcmVhIGlmIHRoZSBmaWxlIGlzIA0KICAgc3Vic2VxdWVudGx5IGV4 dGVuZGVkIGJ5IG1vdmluZyB0aGUgZW5kLW9mLWZpbGUuIA0KCiAgIFRoZSAibWFrZV92ZXJzaW9u IiBmaWVsZCBvZiB0aGUgc3RydWN0dXJlIGlzIGEgZmxhZyB0aGF0IHRoZSBjbGllbnQgDQogICBt YXkgc2V0IHRvIHJlcXVlc3QgdGhhdCB0aGUgc2VydmVyIGNyZWF0ZSBhIGNvcHktb24td3JpdGUg aW1hZ2Ugb2YgDQogICB0aGUgZmlsZSAocE5GUyBjbGllbnRzIG1heSBiZSBpbnZvbHZlZCBpbiB0 aGlzIG9wZXJhdGlvbiAtIHNlZSANCiAgIHNlY3Rpb24gMi4yLjQsIGJlbG93KS4gIEluIGFudGlj aXBhdGlvbiBvZiB0aGlzIG9wZXJhdGlvbiB0aGUgY2xpZW50IA0KICAgd2hpY2ggc2V0cyB0aGUg Im1ha2VfdmVyc2lvbiIgZmxhZyBpbiB0aGUgTEFZT1VUQ09NTUlUIG9wZXJhdGlvbiANCiAgIHNo b3VsZCBpbW1lZGlhdGVseSBtYXJrIGFsbCBleHRlbnRzIGluIHRoZSBsYXlvdXQgdGhhdCBpcyBw b3NzZXNzZXMgDQogICBhcyBzdGF0ZSBSRUFEX0RBVEEuICBGdXR1cmUgd3JpdGVzIHRvIHRoZSBm aWxlIHJlcXVpcmUgYSBuZXcgDQogICBMQVlPVVRHRVQgb3BlcmF0aW9uIHRvIHRoZSBzZXJ2ZXIg d2l0aCBhbiAiaW9tb2RlIiBzZXQgdG8gDQogICBMQVlPVVRJT01PREVfUlcuIA0KCjIuMy4zLiBM YXlvdXQgUmV0dXJucyANCgogICBzdHJ1Y3QgcG5mc19ibG9ja19sYXlvdXRyZXR1cm40IHsgDQoK ICAgICAgcG5mc19ibG9ja19leHRlbnQ0IHJlbF9saXN0PD47ICAgLyogbGlzdCBvZiBleHRlbnRz IHRoZSBjbGllbnQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdp bGwgbm8gbG9uZ2VyIHVzZS4gKi8gDQoKICAgfTsgDQoKICAgVGhlICJyZWxfbGlzdCIgZmllbGQg aXMgYW4gZXh0ZW50IGxpc3QgY292ZXJpbmcgcmVnaW9ucyBvZiB0aGUgZmlsZSANCiAgIGxheW91 dCB0aGF0IGFyZSBubyBsb25nZXIgbmVlZGVkIGJ5IHRoZSBjbGllbnQuICBJbmNsdWRpbmcgZXh0 ZW50cyBpbiANCiAgIHRoZSAicmVsX2xpc3QiIGZvciBhIExBWU9VVFJFVFVSTiBvcGVyYXRpb24g cmVwcmVzZW50cyBhbiBleHBsaWNpdCANCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdIA0KICAgIAwNCgoK CgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0ICAgICAg ICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIHJlbGVhc2Ugb2YgcmVzb3VyY2VzIGJ5IHRo ZSBjbGllbnQsIHVzdWFsbHkgZG9uZSBmb3IgdGhlIHB1cnBvc2Ugb2YgDQogICBhdm9pZGluZyB1 bm5lY2Vzc2FyeSBDQl9MQVlPVVRSRUNBTEwgb3BlcmF0aW9ucyBpbiB0aGUgZnV0dXJlLiANCgog ICBOb3RlIHRoYXQgdGhlIGJsb2NrL3ZvbHVtZSBsYXlvdXQgc3VwcG9ydHMgdW5pbGF0ZXJhbCBs YXlvdXQgDQogICByZXZvY2F0aW9uLiBXaGVuIGEgbGF5b3V0IGlzIHVuaWxhdGVyYWxseSByZXZv a2VkIGJ5IHRoZSBzZXJ2ZXIsIA0KICAgdXN1YWxseSBkdWUgdG8gdGhlIGNsaWVudCdzIGxlYXNl IHRpbWVyIGV4cGlyaW5nIG9yIHRoZSBjbGllbnQgDQogICBmYWlsaW5nIHRvIHJldHVybiBhIGxh eW91dCBpbiBhIHRpbWVseSBtYW5uZXIsIGl0IGlzIGltcG9ydGFudCBmb3IgDQogICB0aGUgc2Fr ZSBvZiBjb3JyZWN0bmVzcyB0aGF0IGFueSBpbi1mbGlnaHQgSS9PcyB0aGF0IHRoZSBjbGllbnQg DQogICBpc3N1ZWQgYmVmb3JlIHRoZSBsYXlvdXQgd2FzIHJldm9rZWQgYXJlIHJlamVjdGVkIGF0 IHRoZSBzdG9yYWdlLiAgDQogICBGb3IgdGhlIGJsb2NrL3ZvbHVtZSBwcm90b2NvbCwgdGhpcyBp cyBwb3NzaWJsZSBieSBmZW5jaW5nIGEgY2xpZW50IA0KICAgd2l0aCBhbiBleHBpcmVkIGxheW91 dCB0aW1lciBmcm9tIHRoZSBwaHlzaWNhbCBzdG9yYWdlLiAgTm90ZSwgDQogICBob3dldmVyLCB0 aGF0IHRoZSBncmFudWxhcml0eSBvZiB0aGlzIG9wZXJhdGlvbiBjYW4gb25seSBiZSBhdCB0aGUg DQogICBob3N0L2xvZ2ljYWwtdW5pdCBsZXZlbC4gIFRodXMsIGlmIG9uZSBvZiBhIGNsaWVudCdz IGxheW91dHMgaXMgDQogICB1bmlsYXRlcmFsbHkgcmV2b2tlZCBieSB0aGUgc2VydmVyLCBpdCB3 aWxsIGVmZmVjdGl2ZWx5IHJlbmRlciANCiAgIHVzZWxlc3MgKmFsbCogb2YgdGhlIGNsaWVudCdz IGxheW91dHMgZm9yIGZpbGVzIGxvY2F0ZWQgb24gdGhlIA0KICAgc3RvcmFnZSB1bml0cyBjb21w cmlzaW5nIHRoZSBsb2dpY2FsIHZvbHVtZS4gIFRoaXMgbWF5IHJlbmRlciB1c2VsZXNzIA0KICAg dGhlIGNsaWVudCdzIGxheW91dHMgZm9yIGZpbGVzIGluIG90aGVyIGZpbGVzeXN0ZW1zLiANCgoy LjMuNC4gQ2xpZW50IENvcHktb24tV3JpdGUgUHJvY2Vzc2luZyANCgogICBEaXN0aW5ndWlzaGlu ZyB0aGUgUkVBRF9XUklURV9EQVRBIGFuZCBSRUFEX0RBVEEgZXh0ZW50IHR5cGVzIGluIA0KICAg Y29tYmluYXRpb24gd2l0aCB0aGUgYWxsb3dlZCBvdmVybGFwIG9mIFJFQURfREFUQSBleHRlbnRz IHdpdGggDQogICBJTlZBTElEX0RBVEEgZXh0ZW50cyBhbGxvd3MgY29weS1vbi13cml0ZSBwcm9j ZXNzaW5nIHRvIGJlIGRvbmUgYnkgDQogICBwTkZTIGNsaWVudHMuIEluIGNsYXNzaWMgTkZTLCB0 aGlzIG9wZXJhdGlvbiB3b3VsZCBiZSBkb25lIGJ5IHRoZSANCiAgIHNlcnZlci4gIFNpbmNlIHBO RlMgZW5hYmxlcyBjbGllbnRzIHRvIGRvIGRpcmVjdCBibG9jayBhY2Nlc3MsIGl0IGlzIA0KICAg dXNlZnVsIGZvciBjbGllbnRzIHRvIHBhcnRpY2lwYXRlIGluIGNvcHktb24td3JpdGUgb3BlcmF0 aW9ucy4gIEFsbCANCiAgIGJsb2NrL3ZvbHVtZSBwTkZTIGNsaWVudHMgTVVTVCBzdXBwb3J0IHRo aXMgY29weS1vbi13cml0ZSBwcm9jZXNzaW5nLiANCgogICBXaGVuIGEgY2xpZW50IHdpc2hlcyB0 byB3cml0ZSBkYXRhIGNvdmVyZWQgYnkgYSBSRUFEX0RBVEEgZXh0ZW50LCBpdCANCiAgIE1VU1Qg aGF2ZSByZXF1ZXN0ZWQgYSB3cml0YWJsZSBsYXlvdXQgZnJvbSB0aGUgc2VydmVyOyB0aGF0IGxh eW91dCANCiAgIHdpbGwgY29udGFpbiBJTlZBTElEX0RBVEEgZXh0ZW50cyB0byBjb3ZlciBhbGwg dGhlIGRhdGEgcmFuZ2VzIG9mIA0KICAgdGhhdCBsYXlvdXQncyBSRUFEX0RBVEEgZXh0ZW50cy4g TW9yZSBwcmVjaXNlbHksIGZvciBhbnkgZmlsZV9vZmZzZXQgDQogICByYW5nZSBjb3ZlcmVkIGJ5 IG9uZSBvciBtb3JlIFJFQURfREFUQSBleHRlbnRzIGluIGEgd3JpdGFibGUgbGF5b3V0LCANCiAg IHRoZSBzZXJ2ZXIgTVVTVCBpbmNsdWRlIG9uZSBvciBtb3JlIElOVkFMSURfREFUQSBleHRlbnRz IGluIHRoZSANCiAgIGxheW91dCB0aGF0IGNvdmVyIHRoZSBzYW1lIGZpbGVfb2Zmc2V0IHJhbmdl LiBXaGVuIHBlcmZvcm1pbmcgYSB3cml0ZSANCiAgIHRvIHN1Y2ggYW4gYXJlYSBvZiBhIGxheW91 dCwgdGhlIGNsaWVudCBNVVNUIGVmZmVjdGl2ZWx5IGNvcHkgdGhlIA0KICAgZGF0YSBmcm9tIHRo ZSBSRUFEX0RBVEEgZXh0ZW50IGZvciBhbnkgcGFydGlhbCBibG9ja3Mgb2YgZmlsZV9vZmZzZXQg DQogICBhbmQgcmFuZ2UsIG1lcmdlIGluIHRoZSBjaGFuZ2VzIHRvIGJlIHdyaXR0ZW4sIGFuZCB3 cml0ZSB0aGUgcmVzdWx0IA0KICAgdG8gdGhlIElOVkFMSURfREFUQSBleHRlbnQgZm9yIHRoZSBi bG9ja3MgZm9yIHRoYXQgZmlsZV9vZmZzZXQgYW5kIA0KICAgcmFuZ2UuIFRoYXQgaXMsIGlmIGVu dGlyZSBibG9ja3Mgb2YgZGF0YSBhcmUgdG8gYmUgb3ZlcndyaXR0ZW4gYnkgYW4gDQogICBvcGVy YXRpb24sIHRoZSBjb3JyZXNwb25kaW5nIFJFQURfREFUQSBibG9ja3MgbmVlZCBub3QgYmUgZmV0 Y2hlZCwgDQogICBidXQgYW55IHBhcnRpYWwtYmxvY2sgd3JpdGVzIG11c3QgYmUgbWVyZ2VkIHdp dGggZGF0YSBmZXRjaGVkIHZpYSANCiAgIFJFQURfREFUQSBleHRlbnRzIGJlZm9yZSBzdG9yaW5n IHRoZSByZXN1bHQgdmlhIElOVkFMSURfREFUQSBleHRlbnRzLiAgDQogICBGb3IgdGhlIHB1cnBv c2VzIG9mIHRoaXMgZGlzY3Vzc2lvbiwgImVudGlyZSBibG9ja3MiIGFuZCAicGFydGlhbCANCiAg IGJsb2NrcyIgcmVmZXIgdG8gdGhlIHNlcnZlcidzIGZpbGUtc3lzdGVtIGJsb2NrIHNpemUuICBT dG9yaW5nIG9mIA0KICAgZGF0YSBpbiBhbiBJTlZBTElEX0RBVEEgZXh0ZW50IGNvbnZlcnRzIHRo ZSB3cml0dGVuIHBvcnRpb24gb2YgdGhlIA0KICAgSU5WQUxJRF9EQVRBIGV4dGVudCB0byBhIFJF QURfV1JJVEVfREFUQSBleHRlbnQ7IGFsbCBzdWJzZXF1ZW50IHJlYWRzIA0KIA0KIA0KQmxhY2sg ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICBb UGFnZSAxM10gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2Nr L1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgTVVTVCBi ZSBwZXJmb3JtZWQgZnJvbSB0aGlzIGV4dGVudDsgdGhlIGNvcnJlc3BvbmRpbmcgcG9ydGlvbiBv ZiB0aGUgDQogICBSRUFEX0RBVEEgZXh0ZW50IE1VU1QgTk9UIGJlIHVzZWQgYWZ0ZXIgc3Rvcmlu ZyBkYXRhIGluIGFuIA0KICAgSU5WQUxJRF9EQVRBIGV4dGVudC4gDQoKICAgSW4gdGhlIExBWU9V VENPTU1JVCBvcGVyYXRpb24gdGhhdCBub3JtYWxseSBzZW5kcyB1cGRhdGVkIGxheW91dCANCiAg IGluZm9ybWF0aW9uIGJhY2sgdG8gdGhlIHNlcnZlciwgZm9yIHdyaXRhYmxlIGRhdGEsIHNvbWUg SU5WQUxJRF9EQVRBIA0KICAgZXh0ZW50cyBtYXkgYmUgY29tbWl0dGVkIGFzIFJFQURfV1JJVEVf REFUQSBleHRlbnRzLCBzaWduaWZ5aW5nIHRoYXQgDQogICB0aGUgc3RvcmFnZSBhdCB0aGUgY29y cmVzcG9uZGluZyBzdG9yYWdlX29mZnNldCB2YWx1ZXMgaGFzIGJlZW4gDQogICBzdG9yZWQgaW50 byBhbmQgaXMgbm93IHRvIGJlIGNvbnNpZGVyZWQgYXMgdmFsaWQgZGF0YSB0byBiZSByZWFkLiAN CiAgIFJFQURfREFUQSBleHRlbnRzIGFyZSBub3QgY29tbWl0dGVkIHRvIHRoZSBzZXJ2ZXIuIEZv ciBleHRlbnRzIHRoYXQgDQogICB0aGUgY2xpZW50IHJlY2VpdmVzIHZpYSBMQVlPVVRHRVQgYXMg SU5WQUxJRF9EQVRBIGFuZCByZXR1cm5zIHZpYSANCiAgIExBWU9VVENPTU1JVCBhcyBSRUFEX1dS SVRFX0RBVEEsIHRoZSBzZXJ2ZXIgd2lsbCB1bmRlcnN0YW5kIHRoYXQgdGhlIA0KICAgUkVBRF9E QVRBIG1hcHBpbmcgZm9yIHRoYXQgZXh0ZW50IGlzIG5vIGxvbmdlciB2YWxpZCBvciBuZWNlc3Nh cnkgZm9yIA0KICAgdGhhdCBmaWxlLiANCgoyLjMuNS4gRXh0ZW50cyBhcmUgUGVybWlzc2lvbnMg DQoKICAgTGF5b3V0IGV4dGVudHMgcmV0dXJuZWQgdG8gcE5GUyBjbGllbnRzIGdyYW50IHBlcm1p c3Npb24gdG8gcmVhZCBvciANCiAgIHdyaXRlOyBSRUFEX0RBVEEgYW5kIE5PTkVfREFUQSBhcmUg cmVhZC1vbmx5IChOT05FX0RBVEEgcmVhZHMgYXMgDQogICB6ZXJvZXMpLCBSRUFEX1dSSVRFX0RB VEEgYW5kIElOVkFMSURfREFUQSBhcmUgcmVhZC93cml0ZSwgDQogICAoSU5WQUxJRF9EQVRBIHJl YWRzIGFzIHplcm9zLCBhbnkgd3JpdGUgY29udmVydHMgaXQgdG8gDQogICBSRUFEX1dSSVRFX0RB VEEpLiAgVGhpcyBpcyB0aGUgb25seSBjbGllbnQgbWVhbnMgb2Ygb2J0YWluaW5nIA0KICAgcGVy bWlzc2lvbiB0byBwZXJmb3JtIGRpcmVjdCBJL08gdG8gc3RvcmFnZSBkZXZpY2VzOyBhIHBORlMg Y2xpZW50IA0KICAgTVVTVCBOT1QgcGVyZm9ybSBkaXJlY3QgSS9PIG9wZXJhdGlvbnMgdGhhdCBh cmUgbm90IHBlcm1pdHRlZCBieSBhbiANCiAgIGV4dGVudCBoZWxkIGJ5IHRoZSBjbGllbnQuICBD bGllbnQgYWRoZXJlbmNlIHRvIHRoaXMgcnVsZSBwbGFjZXMgdGhlIA0KICAgcE5GUyBzZXJ2ZXIg aW4gY29udHJvbCBvZiBwb3RlbnRpYWxseSBjb25mbGljdGluZyBzdG9yYWdlIGRldmljZSANCiAg IG9wZXJhdGlvbnMsIGVuYWJsaW5nIHRoZSBzZXJ2ZXIgdG8gZGV0ZXJtaW5lIHdoYXQgZG9lcyBj b25mbGljdCBhbmQgDQogICBob3cgdG8gYXZvaWQgY29uZmxpY3RzIGJ5IGdyYW50aW5nIGFuZCBy ZWNhbGxpbmcgZXh0ZW50cyB0by9mcm9tIA0KICAgY2xpZW50cy4gICANCgogICBCbG9jay92b2x1 bWUgY2xhc3Mgc3RvcmFnZSBkZXZpY2VzIGFyZSBub3QgcmVxdWlyZWQgdG8gcGVyZm9ybSByZWFk IA0KICAgYW5kIHdyaXRlIG9wZXJhdGlvbnMgYXRvbWljYWxseS4gIE92ZXJsYXBwaW5nIGNvbmN1 cnJlbnQgcmVhZCBhbmQgDQogICB3cml0ZSBvcGVyYXRpb25zIHRvIHRoZSBzYW1lIGRhdGEgbWF5 IGNhdXNlIHRoZSByZWFkIHRvIHJldHVybiBhIA0KICAgbWl4dHVyZSBvZiBiZWZvcmUtd3JpdGUg YW5kIGFmdGVyLXdyaXRlIGRhdGEuICBPdmVybGFwcGluZyB3cml0ZSANCiAgIG9wZXJhdGlvbnMg Y2FuIGJlIHdvcnNlLCBhcyB0aGUgcmVzdWx0IGNvdWxkIGJlIGEgbWl4dHVyZSBvZiBkYXRhIA0K ICAgZnJvbSB0aGUgdHdvIHdyaXRlIG9wZXJhdGlvbnM7IGRhdGEgY29ycnVwdGlvbiBjYW4gb2Nj dXIgaWYgdGhlIA0KICAgdW5kZXJseWluZyBzdG9yYWdlIGlzIHN0cmlwZWQgYW5kIHRoZSBvcGVy YXRpb25zIGNvbXBsZXRlIGluIA0KICAgZGlmZmVyZW50IG9yZGVycyBvbiBkaWZmZXJlbnQgc3Ry aXBlcy4gIEEgcE5GUyBzZXJ2ZXIgY2FuIGF2b2lkIHRoZXNlIA0KICAgY29uZmxpY3RzIGJ5IGlt cGxlbWVudGluZyBhIHNpbmdsZSB3cml0ZXIgWE9SIG11bHRpcGxlIHJlYWRlcnMgDQogICBjb25j dXJyZW5jeSBjb250cm9sIHBvbGljeSB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBjbGllbnRzIHdo byB3aXNoIA0KICAgdG8gYWNjZXNzIHRoZSBzYW1lIGRhdGEuICBUaGlzIHBvbGljeSBTSE9VTEQg YmUgaW1wbGVtZW50ZWQgd2hlbiANCiAgIHN0b3JhZ2UgZGV2aWNlcyBkbyBub3QgcHJvdmlkZSBh dG9taWNpdHkgZm9yIGNvbmN1cnJlbnQgcmVhZC93cml0ZSANCiAgIGFuZCB3cml0ZS93cml0ZSBv cGVyYXRpb25zIHRvIHRoZSBzYW1lIGRhdGEuIA0KCiAgIElmIGEgY2xpZW50IG1ha2VzIGEgbGF5 b3V0IHJlcXVlc3QgdGhhdCBjb25mbGljdHMgd2l0aCBhbiBleGlzdGluZyANCiAgIGxheW91dCBk ZWxlZ2F0aW9uLCB0aGUgcmVxdWVzdCB3aWxsIGJlIHJlamVjdGVkIHdpdGggdGhlIGVycm9yIA0K ICAgTkZTNEVSUl9MQVlPVVRUUllMQVRFUi4gIFRoaXMgY2xpZW50IGlzIHRoZW4gZXhwZWN0ZWQg dG8gcmV0cnkgdGhlIA0KIA0KIA0KQmxhY2sgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDIwMDcgICAgICAgICAgICAgICAgICBbUGFnZSAxNF0gDQogICAgDA0KCgoKCgoKSW50ZXJu ZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1h cmNoIDIwMDcgDQogICAgDQoKICAgcmVxdWVzdCBhZnRlciBhIHNob3J0IGludGVydmFsLiAgRHVy aW5nIHRoaXMgaW50ZXJ2YWwgdGhlIHNlcnZlciANCiAgIFNIT1VMRCByZWNhbGwgdGhlIGNvbmZs aWN0aW5nIHBvcnRpb24gb2YgdGhlIGxheW91dCBkZWxlZ2F0aW9uIGZyb20gDQogICB0aGUgY2xp ZW50IHRoYXQgY3VycmVudGx5IGhvbGRzIGl0LiAgVGhpcyByZWplY3QtYW5kLXJldHJ5IGFwcHJv YWNoIA0KICAgZG9lcyBub3QgcHJldmVudCBjbGllbnQgc3RhcnZhdGlvbiB3aGVuIHRoZXJlIGlz IGNvbnRlbnRpb24gZm9yIHRoZSANCiAgIGxheW91dCBvZiBhIHBhcnRpY3VsYXIgZmlsZS4gIEZv ciB0aGlzIHJlYXNvbiBhIHBORlMgc2VydmVyIFNIT1VMRCANCiAgIGltcGxlbWVudCBhIG1lY2hh bmlzbSB0byBwcmV2ZW50IHN0YXJ2YXRpb24uICBPbmUgcG9zc2liaWxpdHkgaXMgdGhhdCANCiAg IHRoZSBzZXJ2ZXIgY2FuIG1haW50YWluIGEgcXVldWUgb2YgcmVqZWN0ZWQgbGF5b3V0IHJlcXVl c3RzLiAgRWFjaCANCiAgIG5ldyBsYXlvdXQgcmVxdWVzdCBjYW4gYmUgY2hlY2tlZCB0byBzZWUg aWYgaXQgY29uZmxpY3RzIHdpdGggYSANCiAgIHByZXZpb3VzIHJlamVjdGVkIHJlcXVlc3QsIGFu ZCBpZiBzbywgdGhlIG5ld2VyIHJlcXVlc3QgY2FuIGJlIA0KICAgcmVqZWN0ZWQuIE9uY2UgdGhl IG9yaWdpbmFsIHJlcXVlc3RpbmcgY2xpZW50IHJldHJpZXMgaXRzIHJlcXVlc3QsIA0KICAgaXRz IGVudHJ5IGluIHRoZSByZWplY3RlZCByZXF1ZXN0IHF1ZXVlIGNhbiBiZSBjbGVhcmVkLCBvciB0 aGUgZW50cnkgDQogICBpbiB0aGUgcmVqZWN0ZWQgcmVxdWVzdCBxdWV1ZSBjYW4gYmUgcmVtb3Zl ZCB3aGVuIGl0IHJlYWNoZXMgYSANCiAgIGNlcnRhaW4gYWdlLiANCgogICBORlN2NCBzdXBwb3J0 cyBtYW5kYXRvcnkgbG9ja3MgYW5kIHNoYXJlIHJlc2VydmF0aW9ucy4gIFRoZXNlIGFyZSANCiAg IG1lY2hhbmlzbXMgdGhhdCBjbGllbnRzIGNhbiB1c2UgdG8gcmVzdHJpY3QgdGhlIHNldCBvZiBJ L08gb3BlcmF0aW9ucyANCiAgIHRoYXQgYXJlIHBlcm1pc3NpYmxlIHRvIG90aGVyIGNsaWVudHMu ICBTaW5jZSBhbGwgSS9PIG9wZXJhdGlvbnMgDQogICB1bHRpbWF0ZWx5IGFycml2ZSBhdCB0aGUg TkZTdjQgc2VydmVyIGZvciBwcm9jZXNzaW5nLCB0aGUgc2VydmVyIGlzIA0KICAgaW4gYSBwb3Np dGlvbiB0byBlbmZvcmNlIHRoZXNlIHJlc3RyaWN0aW9ucy4gIEhvd2V2ZXIsIHdpdGggcE5GUyAN CiAgIGxheW91dCBkZWxlZ2F0aW9ucywgSS9PcyB3aWxsIGJlIGlzc3VlZCBmcm9tIHRoZSBjbGll bnRzIHRoYXQgaG9sZCANCiAgIHRoZSBkZWxlZ2F0aW9ucyBkaXJlY3RseSB0byB0aGUgc3RvcmFn ZSBkZXZpY2VzIHRoYXQgaG9zdCB0aGUgZGF0YS4gIA0KICAgVGhlc2UgZGV2aWNlcyBoYXZlIG5v IGtub3dsZWRnZSBvZiBmaWxlcywgbWFuZGF0b3J5IGxvY2tzLCBvciBzaGFyZSANCiAgIHJlc2Vy dmF0aW9ucywgYW5kIGFyZSBub3QgaW4gYSBwb3NpdGlvbiB0byBlbmZvcmNlIHN1Y2ggcmVzdHJp Y3Rpb25zLiAgDQogICBGb3IgdGhpcyByZWFzb24gdGhlIE5GU3Y0IHNlcnZlciBNVVNUIE5PVCBn cmFudCBsYXlvdXQgZGVsZWdhdGlvbnMgDQogICB0aGF0IGNvbmZsaWN0IHdpdGggbWFuZGF0b3J5 IGxvY2tzIG9yIHNoYXJlIHJlc2VydmF0aW9ucy4gIEZ1cnRoZXIsIA0KICAgaWYgYSBjb25mbGlj dGluZyBtYW5kYXRvcnkgbG9jayByZXF1ZXN0IG9yIGEgY29uZmxpY3Rpbmcgb3BlbiByZXF1ZXN0 IA0KICAgYXJyaXZlcyBhdCB0aGUgc2VydmVyLCB0aGUgc2VydmVyIE1VU1QgcmVjYWxsIHRoZSBw YXJ0IG9mIHRoZSBsYXlvdXQgDQogICBkZWxlZ2F0aW9uIGluIGNvbmZsaWN0IHdpdGggdGhlIHJl cXVlc3QgYmVmb3JlIGdyYW50aW5nIHRoZSByZXF1ZXN0LiANCgoyLjMuNi4gRW5kLW9mLWZpbGUg UHJvY2Vzc2luZyANCgogICBUaGUgZW5kLW9mLWZpbGUgbG9jYXRpb24gY2FuIGJlIGNoYW5nZWQg aW4gdHdvIHdheXM6IGltcGxpY2l0bHkgYXMgDQogICB0aGUgcmVzdWx0IG9mIGEgV1JJVEUgb3Ig TEFZT1VUQ09NTUlUIGJleW9uZCB0aGUgY3VycmVudCBlbmQtb2YtZmlsZSwgDQogICBvciBleHBs aWNpdGx5IGFzIHRoZSByZXN1bHQgb2YgYSBTRVRBVFRSIHJlcXVlc3QuICBUeXBpY2FsbHksIHdo ZW4gYSANCiAgIGZpbGUgaXMgdHJ1bmNhdGVkIGJ5IGFuIE5GU3Y0IGNsaWVudCB2aWEgdGhlIFNF VEFUVFIgY2FsbCwgdGhlIHNlcnZlciANCiAgIGZyZWVzIGFueSBkaXNrIGJsb2NrcyBiZWxvbmdp bmcgdG8gdGhlIGZpbGUgd2hpY2ggYXJlIGJleW9uZCB0aGUgbmV3IA0KICAgZW5kLW9mLWZpbGUg b2N0ZXQsIGFuZCBtYXkgd3JpdGUgemVyb3MgdG8gdGhlIHBvcnRpb24gb2YgdGhlIG5ldyBlbmQt DQogICBvZi1maWxlIGJsb2NrIGJleW9uZCB0aGUgbmV3IGVuZC1vZi1maWxlIG9jdGV0LiAgVGhl c2UgYWN0aW9ucyByZW5kZXIgDQogICBhbnkgcE5GUyBsYXlvdXRzIHdoaWNoIHJlZmVyIHRvIHRo ZSBibG9ja3MgdGhhdCBhcmUgZnJlZWQgb3Igd3JpdHRlbiANCiAgIHNlbWFudGljYWxseSBpbnZh bGlkLiAgVGhlcmVmb3JlLCB0aGUgc2VydmVyIE1VU1QgcmVjYWxsIGZyb20gY2xpZW50cyANCiAg IHRoZSBwb3J0aW9ucyBvZiBhbnkgcE5GUyBsYXlvdXRzIHdoaWNoIHJlZmVyIHRvIGJsb2NrcyB0 aGF0IHdpbGwgYmUgDQogICBmcmVlZCBvciB3cml0dGVuIGJ5IHRoZSBzZXJ2ZXIgYmVmb3JlIHBy b2Nlc3NpbmcgdGhlIHRydW5jYXRlIA0KICAgcmVxdWVzdC4gVGhlc2UgcmVjYWxscyBtYXkgdGFr ZSB0aW1lIHRvIGNvbXBsZXRlOyBhcyBleHBsYWluZWQgaW4gDQogICBbTkZTdjQuMV0sIGlmIHRo ZSBzZXJ2ZXIgY2Fubm90IHJlc3BvbmQgdG8gdGhlIGNsaWVudCBTRVRBVFRSIHJlcXVlc3QgDQog ICBpbiBhIHJlYXNvbmFibGUgYW1vdW50IG9mIHRpbWUsIGl0IFNIT1VMRCByZXBseSB0byB0aGUg Y2xpZW50IHdpdGggDQogICB0aGUgZXJyb3IgTkZTNEVSUl9ERUxBWS4gDQoKIA0KIA0KQmxhY2sg ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICBb UGFnZSAxNV0gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2Nr L1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgQmxvY2tz IGluIHRoZSBJTlZBTElEX0RBVEEgc3RhdGUgd2hpY2ggbGllIGJleW9uZCB0aGUgbmV3IGVuZC1v Zi1maWxlIA0KICAgYmxvY2sgcHJlc2VudCBhIHNwZWNpYWwgY2FzZS4gIFRoZSBzZXJ2ZXIgaGFz IHJlc2VydmVkIHRoZXNlIGJsb2NrcyANCiAgIGZvciB1c2UgYnkgYSBwTkZTIGNsaWVudCB3aXRo IGEgd3JpdGFibGUgbGF5b3V0IGZvciB0aGUgZmlsZSwgYnV0IHRoZSANCiAgIGNsaWVudCBoYXMg eWV0IHRvIGNvbW1pdCB0aGUgYmxvY2tzLCBhbmQgdGhleSBhcmUgbm90IHlldCBhIHBhcnQgb2Yg DQogICB0aGUgZmlsZSBtYXBwaW5nIG9uIGRpc2suICBUaGUgc2VydmVyIE1BWSBmcmVlIHRoZXNl IGJsb2NrcyB3aGlsZSANCiAgIHByb2Nlc3NpbmcgdGhlIFNFVEFUVFIgcmVxdWVzdC4gIElmIHNv LCB0aGUgc2VydmVyIE1VU1QgcmVjYWxsIGFueSANCiAgIGxheW91dHMgZnJvbSBwTkZTIGNsaWVu dHMgd2hpY2ggcmVmZXIgdG8gdGhlIGJsb2NrcyBiZWZvcmUgcHJvY2Vzc2luZyANCiAgIHRoZSB0 cnVuY2F0ZS4gIElmIHRoZSBzZXJ2ZXIgZG9lcyBub3QgZnJlZSB0aGUgSU5WQUxJRF9EQVRBIGJs b2NrcyANCiAgIHdoaWxlIHByb2Nlc3NpbmcgdGhlIFNFVEFUVFIgcmVxdWVzdCwgaXQgbmVlZCBu b3QgcmVjYWxsIGxheW91dHMgDQogICB3aGljaCByZWZlciBvbmx5IHRvIHRoZSBJTlZBTElEIERB VEEgYmxvY2tzLiANCgogICBXaGVuIGEgZmlsZSBpcyBleHRlbmRlZCBpbXBsaWNpdGx5IGJ5IGEg V1JJVEUgb3IgTEFZT1VUQ09NTUlUIGJleW9uZCANCiAgIHRoZSBjdXJyZW50IGVuZC1vZi1maWxl LCBvciBleHRlbmRlZCBleHBsaWNpdGx5IGJ5IGEgU0VUQVRUUiByZXF1ZXN0LCANCiAgIHRoZSBz ZXJ2ZXIgbmVlZCBub3QgcmVjYWxsIGFueSBwb3J0aW9ucyBvZiBhbnkgcE5GUyBsYXlvdXRzLiAN CgoyLjMuNy4gQ2xpZW50IEZlbmNpbmcgDQoKICAgVGhlIHBORlMgYmxvY2sgcHJvdG9jb2wgbXVz dCBoYW5kbGUgc2l0dWF0aW9ucyBpbiB3aGljaCBhIHN5c3RlbSANCiAgIGZhaWx1cmUsIHR5cGlj YWxseSBhIG5ldHdvcmsgY29ubmVjdGl2aXR5IGlzc3VlLCByZXF1aXJlcyB0aGUgc2VydmVyIA0K ICAgdG8gdW5pbGF0ZXJhbGx5IHJldm9rZSBleHRlbnRzIGZyb20gb25lIGNsaWVudCBpbiBvcmRl ciB0byB0cmFuc2ZlciANCiAgIHRoZSBleHRlbnRzIHRvIGFub3RoZXIgY2xpZW50LiAgVGhlIHBO RlMgc2VydmVyIGltcGxlbWVudGF0aW9uIE1VU1QgDQogICBlbnN1cmUgdGhhdCB3aGVuIHJlc291 cmNlcyBhcmUgdHJhbnNmZXJyZWQgdG8gYW5vdGhlciBjbGllbnQsIHRoZXkgDQogICBhcmUgbm90 IHVzZWQgYnkgdGhlIGNsaWVudCBvcmlnaW5hbGx5IG93bmluZyB0aGVtLCBhbmQgdGhpcyBtdXN0 IGJlIA0KICAgZW5zdXJlZCBhZ2FpbnN0IGFueSBwb3NzaWJsZSBjb21iaW5hdGlvbiBvZiBwYXJ0 aXRpb25zIGFuZCBkZWxheXMgDQogICBhbW9uZyBhbGwgb2YgdGhlIHBhcnRpY2lwYW50cyB0byB0 aGUgcHJvdG9jb2wgKHNlcnZlciwgc3RvcmFnZSBhbmQgDQogICBjbGllbnQpLiAgU2V2ZXJhbCBh cHByb2FjaGVzIHRvIGd1YXJhbnRlZWluZyB0aGlzIGlzb2xhdGlvbiBhcmUgDQogICBwb3NzaWJs ZSBhbmQgYXJlIGRpc2N1c3NlZCBiZWxvdy4gDQoKICAgT25lIHNlcnZlciBiYXNlZCBpbXBsZW1l bnRhdGlvbiBjaG9pY2UgZm9yIGZlbmNpbmcgaXMgdG8gdXNlIHRoZSANCiAgIFNUT01JVEggKFNo b290IFRoZSBPdGhlciBNYWNoaW5lIEluIFRoZSBIZWFkKSBwcm90b2NvbCwgaS5lLiwgdHVybiAN CiAgIG9mZiB0aGUgcG93ZXIgdG8gdGhlIGNsaWVudCBtYWNoaW5lIHRoYXQgbmVlZHMgdG8gYmUg aXNvbGF0ZWQuICBUaGlzIA0KICAgaXMgcG9zc2libGUgaWYgdGhlIHNlcnZlciBoYXMgYWNjZXNz IHRvIGVpdGhlciBhbiBJUE1JIGludGVyZmFjZSB0byANCiAgIHBvd2VyIGN5Y2xlIHRoZSBjbGll bnQsIG9yIGFuIGFsdGVybmF0ZSBtZXRob2Qgb2YgdHVybmluZyBvZmYgcG93ZXIgDQogICB0byBh IG5vbi1jb21tdW5pY2F0aXZlIGNsaWVudC4gIFRoZSBjbGllbnQgU0hPVUxEIGJlIGtlcHQgcG93 ZXJlZCBvZmYgDQogICBmb3IgYXQgbGVhc3QgdGhlIGR1cmF0aW9uIG9mIHRoZSBzZXJ2ZXIgbGVh c2UgdGltZSwgYXMgaXQgaXMgDQogICBwb3NzaWJsZSwgYWx0aG91Z2ggdW50eXBpY2FsLCB0aGF0 IHRoZSBjbGllbnQgY2FjaGVzIHRoZSBsYXlvdXQgDQogICBpbmZvcm1hdGlvbiBvbiBwZXJzaXN0 ZW50IHN0b3JhZ2UuICBUaGlzIGFwcHJvYWNoIGNhbiBpbiBzb21lIA0KICAgaW5zdGFuY2VzIGd1 YXJhbnRlZSB0aGF0IHRoZSByb2d1ZSBjbGllbnQgbm8gbG9uZ2VyIGlzIGNhcGFibGUgb2YgDQog ICBhY2Nlc3NpbmcgdGhlIHN0b3JhZ2UuICBIb3dldmVyLCBpbiBvdGhlciBzaXR1YXRpb25zLCBm b3IgZXhhbXBsZSANCiAgIGxhY2sgb2YgVENQL0lQIGFjY2VzcyB0byB0aGUgY2xpZW50J3MgSVBN SSBuZXR3b3JrIGFkZHJlc3MsIHRoaXMgDQogICBhcHByb2FjaCBjYW5ub3QgZ3VhcmFudGVlIGFu eXRoaW5nLiAgIA0KCiAgIEFub3RoZXIgaW1wbGVtZW50YXRpb24gY2hvaWNlIGZvciBmZW5jaW5n IHRoZSBibG9jayBjbGllbnQgZnJvbSB0aGUgDQogICBibG9jayBzdG9yYWdlIGlzIHRoZSB1c2Ug b2YgTFVOIChMb2dpY2FsIFVuaXQgTnVtYmVyKSBtYXNraW5nIG9yIA0KICAgbWFwcGluZyBhdCB0 aGUgc3RvcmFnZSBzeXN0ZW1zIG9yIHN0b3JhZ2UgYXJlYSBuZXR3b3JrIHRvIGRpc2FibGUgDQog ICBhY2Nlc3MgYnkgdGhlIGNsaWVudCB0byBiZSBpc29sYXRlZC4gIEluIGNvbnRyYXN0IHRvIHRo ZSBTVE9NSVRIIA0KICAgYXBwcm9hY2gsIHRoaXMgcmVxdWlyZXMgc2VydmVyIGFjY2VzcyB0byBh IG1hbmFnZW1lbnQgaW50ZXJmYWNlIGZvciANCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdIA0KICAgIAwN CgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0ICAg ICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIHRoZSBzdG9yYWdlIHN5c3RlbSBhbmQg YXV0aG9yaXphdGlvbiB0byBwZXJmb3JtIExVTiBtYXNraW5nIGFuZCANCiAgIG1hbmFnZW1lbnQg b3BlcmF0aW9ucy4gIEZvciBleGFtcGxlLCBTTUktUyBbU01JU10gcHJvdmlkZXMgYSBtZWFucyB0 byANCiAgIGRpc2NvdmVyIGFuZCBtYXNrIExVTnMsIGluY2x1ZGluZyBhIG1lYW5zIG9mIGFzc29j aWF0aW5nIGNsaWVudHMgd2l0aCANCiAgIHRoZSBuZWNlc3NhcnkgV29ybGQgV2lkZSBOYW1lcyBv ciBJbml0aWF0b3IgbmFtZXMgdG8gYmUgbWFza2VkLiANCgogICBJbiB0aGUgYWJzZW5jZSBvZiBz dXBwb3J0IGZvciBvdGhlciBtZWNoYW5pc21zLCB0aGUgc2VydmVyIE1VU1QgDQogICBjaG9vc2Ug dG8gcmVseSBvbiB0aGUgY2xpZW50cyB0byBpbXBsZW1lbnQgYSB0aW1lZCBsZWFzZSBJL08gZmVu Y2luZyANCiAgIG1lY2hhbmlzbS4gIEJlY2F1c2UgY2xpZW50cyBkbyBub3Qga25vdyBpZiB0aGUg c2VydmVyIGlzIHVzaW5nIA0KICAgU1RPTUlUSCBvciBMVU4gbWFza2luZy4gaW4gYWxsIGNhc2Vz IHRoZSBjbGllbnQgTVVTVCBpbXBsZW1lbnQgdGltZWQgDQogICBsZWFzZSBmZW5jaW5nLiAgSW4g dGltZWQgbGVhc2UgZmVuY2luZyB3ZSBkZWZpbmUgdHdvIHRpbWUgcGVyaW9kcywgDQogICB0aGUg Zmlyc3QsICJsZWFzZV90aW1lIiBpcyB0aGUgbGVuZ3RoIG9mIGEgbGVhc2UgYXMgZGVmaW5lZCBi eSB0aGUgDQogICBzZXJ2ZXIncyBsZWFzZV90aW1lIGF0dHJpYnV0ZSAoc2VlIFNlY3Rpb24gNS40 IG9mIFtORlNWNC4xXSksIGFuZCB0aGUgDQogICBzZWNvbmQsICJtYXhpbXVtX2lvX3RpbWUiIGlz IHRoZSBtYXhpbXVtIHRpbWUgaXQgY2FuIHRha2UgZm9yIGEgDQogICBjbGllbnQgSS9PIHRvIHRo ZSBzdG9yYWdlIHN5c3RlbSB0byBlaXRoZXIgY29tcGxldGUgb3IgZmFpbDsgdGhpcyANCiAgIHZh bHVlIGlzIG9mdGVuIDMwIHNlY29uZHMgb3IgNjAgc2Vjb25kcywgYnV0IG1heSBiZSBsb25nZXIg aW4gc29tZSANCiAgIGVudmlyb25tZW50cy4gIElmIHRoZSBtYXhpbXVtIGNsaWVudCBJL08gdGlt ZSBjYW5ub3QgYmUgYm91bmRlZCwgdGhpcyANCiAgIHRpbWVkIGxlYXNlIG1lY2hhbmlzbSBNVVNU IE5PVCBiZSB1c2VkLiAgVGhlIGNsaWVudCBjYW4gdXNlIEdFVEFUVFIgDQogICB0byBxdWVyeSB0 aGUgc2VydmVyJ3MgZGVmYXVsdCBzZXR0aW5nIG9mICJtYXhpbXVtX2lvX3RpbWUiLiAgVGhlIA0K ICAgc2VydmVyIG11c3QgcmVzcG9uZCB3aXRoIHRoZSBtYXhpbXVtIEkvTyB0aW1lIGluIHNlY29u ZHMuICBJZiB0aGUgDQogICBjbGllbnQncyBtYXhpbXVtIEkvTyB0aW1lIGlzIGdyZWF0ZXIgdGhh biB0aGUgc2VydmVyJ3MgZGVmYXVsdCwgdGhlbiANCiAgIHRoZSBjbGllbnQgTVVTVCB1c2UgU0VU QVRUUiB0byBpbmZvcm0gdGhlIHNlcnZlciBvZiBpdHMgbWF4aW11bV9JL08gDQogICB0aW1lLiAg VXNpbmcgdGhlc2UgdHdvIHRpbWUgc3BhbiB2YWx1ZXMsIHdlIHNwZWNpZnkgdGhlIGJlaGF2aW9y IG9mIA0KICAgdGhlIGNsaWVudCBhbmQgc2VydmVyIGFzIGZvbGxvd3MuIA0KCiAgIFdoZW4gYSBj bGllbnQgcmVjZWl2ZXMgbGF5b3V0IGluZm9ybWF0aW9uIHZpYSBhIExBWU9VVEdFVCBvcGVyYXRp b24sIA0KICAgdGhvc2UgbGF5b3V0cyBhcmUgdmFsaWQgZm9yIGF0IG1vc3QgImxlYXNlX3RpbWUi IHNlY29uZHMgZnJvbSB3aGVuIA0KICAgdGhlIHNlcnZlciBncmFudGVkIHRoZW0uICBBIGxheW91 dCBpcyByZW5ld2VkIGJ5IGFueSBzdWNjZXNzZnVsIA0KICAgU0VRVUVVTkNFIG9wZXJhdGlvbiwg b3Igd2hlbmV2ZXIgYSBuZXcgc3RhdGVpZCBpcyBjcmVhdGVkIG9yIHVwZGF0ZWQgDQogICAoc2Vl IHRoZSBzZWN0aW9uICJMZWFzZSBSZW5ld2FsIiBvZiBbTkZTVjQuMV0pLiAgSWYgdGhlIGxheW91 dCBsZWFzZSANCiAgIGlzIG5vdCByZW5ld2VkIHByaW9yIHRvIGV4cGlyYXRpb24sIHRoZSBjbGll bnQgTVVTVCBjZWFzZSB0byB1c2UgdGhlIA0KICAgbGF5b3V0IGFmdGVyICJsZWFzZV90aW1lIiBz ZWNvbmRzIGZyb20gd2hlbiBpdCBlaXRoZXIgc2VudCB0aGUgDQogICBvcmlnaW5hbCBMQVlPVVRH RVQgY29tbWFuZCwgb3Igc2VudCB0aGUgbGFzdCBvcGVyYXRpb24gcmVuZXdpbmcgdGhlIA0KICAg bGVhc2UuICBJbiBvdGhlciB3b3JkcywgdGhlIGNsaWVudCBtYXkgbm90IGlzc3VlIGFueSBJL08g dG8gYmxvY2tzIA0KICAgc3BlY2lmaWVkIGJ5IGFuIGV4cGlyZWQgbGF5b3V0LiAgSW4gdGhlIHBy ZXNlbmNlIG9mIGxhcmdlIA0KICAgY29tbXVuaWNhdGlvbiBkZWxheXMgYmV0d2VlbiB0aGUgY2xp ZW50IGFuZCBzZXJ2ZXIgaXQgaXMgZXZlbiANCiAgIHBvc3NpYmxlIGZvciB0aGUgbGVhc2UgdG8g ZXhwaXJlIHByaW9yIHRvIHRoZSBzZXJ2ZXIgcmVzcG9uc2UgDQogICBhcnJpdmluZyBhdCB0aGUg Y2xpZW50LiAgSW4gc3VjaCBhIHNpdHVhdGlvbiB0aGUgY2xpZW50IE1VU1QgTk9UIHVzZSANCiAg IHRoZSBleHBpcmVkIGxheW91dHMsIGFuZCBTSE9VTEQgcmV2ZXJ0IHRvIHVzaW5nIHN0YW5kYXJk IE5GU3Y0MSBSRUFEIA0KICAgYW5kIFdSSVRFIG9wZXJhdGlvbnMuICBGdXJ0aGVybW9yZSwgdGhl IGNsaWVudCBtdXN0IGJlIGNvbmZpZ3VyZWQgDQogICBzdWNoIHRoYXQgSS9PIG9wZXJhdGlvbnMg Y29tcGxldGUgd2l0aGluIHRoZSAibWF4aW11bV9pb190aW1lIiBldmVuIA0KICAgaW4gdGhlIHBy ZXNlbmNlIG9mIG11bHRpcGF0aGluZyBkcml2ZXJzIHRoYXQgd2lsbCByZXRyeSBJL09zIHZpYSAN CiAgIG11bHRpcGxlIHBhdGhzLiAgSWYgYSBjbGllbnQgY2Fubm90IGd1YXJhbnRlZSBhIGJvdW5k ZWQgbWF4aW11bSBJL08gDQogICB0aW1lLCBpdCBNVVNUIE5PVCB1c2UgcE5GUy4gDQoKICAgQXMg c3RhdGVkIGluIHRoZSBzZWN0aW9uICJEZWFsaW5nIHdpdGggTGVhc2UgRXhwaXJhdGlvbiBvbiB0 aGUgDQogICBDbGllbnQiIG9mIFtORlNWNC4xXSwgaWYgYW55IFNFUVVFTkNFIG9wZXJhdGlvbiBp cyBzdWNjZXNzZnVsLCBidXQgDQogICBzcl9zdGF0dXNfZmxhZyBoYXMgU0VRNF9TVEFUVVNfRVhQ SVJFRF9BTExfU1RBVEVfUkVWT0tFRCwgDQogDQogDQpCbGFjayAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDE3XSANCiAgICAMDQoK CgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2svVm9sdW1lIExheW91dCAgICAg ICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICBTRVE0X1NUQVRVU19FWFBJUkVEX1NPTUVf U1RBVEVfUkVWT0tFRCwgb3IgDQogICBTRVE0X1NUQVRVU19BRE1JTl9TVEFURV9SRVZPS0VEIHNl dCwgdGhlIGNsaWVudCBNVVNUIGltbWVkaWF0ZWx5IA0KICAgY2Vhc2UgdG8gdXNlIGFsbCBsYXlv dXRzIGFuZCBkZXZpY2UgaWQgdG8gZGV2aWNlIGFkZHJlc3MgbWFwcGluZ3MgDQogICBhc3NvY2lh dGVkIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgc2VydmVyLiANCgogICBJbiB0aGUgYWJzZW5jZSBv ZiBrbm93biB0d28gd2F5IGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCANCiAg IHRoZSBzZXJ2ZXIgb24gdGhlIGZvcmUgY2hhbm5lbCwgdGhlIHNlcnZlciBtdXN0IHdhaXQgZm9y IGF0IGxlYXN0IHRoZSANCiAgIHRpbWUgcGVyaW9kICJsZWFzZV90aW1lIiBwbHVzICJtYXhpbXVt X2lvX3RpbWUiIGJlZm9yZSB0cmFuc2ZlcnJpbmcgDQogICBsYXlvdXRzIGZyb20gdGhlIG9yaWdp bmFsIGNsaWVudCB0byBhbnkgb3RoZXIgY2xpZW50LiAgVGhlIHNlcnZlciwgDQogICBsaWtlIHRo ZSBjbGllbnQsIG11c3QgdGFrZSBhIGNvbnNlcnZhdGl2ZSBhcHByb2FjaCwgYW5kIHN0YXJ0IHRo ZSANCiAgIGxlYXNlIGV4cGlyYXRpb24gdGltZXIgZnJvbSB0aGUgdGltZSB0aGF0IGl0IHJlY2Vp dmVkIHRoZSBvcGVyYXRpb24gDQogICB3aGljaCBsYXN0IHJlbmV3ZWQgdGhlIGxlYXNlLiANCgoy LjQuIENyYXNoIFJlY292ZXJ5IElzc3VlcyANCgogICBXaGVuIHRoZSBzZXJ2ZXIgY3Jhc2hlcyB3 aGlsZSB0aGUgY2xpZW50IGhvbGRzIGEgd3JpdGFibGUgbGF5b3V0LCBhbmQgDQogICB0aGUgY2xp ZW50IGhhcyB3cml0dGVuIGRhdGEgdG8gYmxvY2tzIGNvdmVyZWQgYnkgdGhlIGxheW91dCwgYW5k IHRoZSANCiAgIGJsb2NrcyBhcmUgc3RpbGwgaW4gdGhlIElOVkFMSURfREFUQSBzdGF0ZSwgdGhl IGNsaWVudCBoYXMgdHdvIA0KICAgb3B0aW9ucyBmb3IgcmVjb3ZlcnkuICBJZiB0aGUgZGF0YSB0 aGF0IGhhcyBiZWVuIHdyaXR0ZW4gdG8gdGhlc2UgDQogICBibG9ja3MgaXMgc3RpbGwgY2FjaGVk IGJ5IHRoZSBjbGllbnQsIHRoZSBjbGllbnQgY2FuIHNpbXBseSByZS13cml0ZSANCiAgIHRoZSBk YXRhIHZpYSBORlN2NCwgb25jZSB0aGUgc2VydmVyIGhhcyBjb21lIGJhY2sgb25saW5lLiAgSG93 ZXZlciwgDQogICBpZiB0aGUgZGF0YSBpcyBubyBsb25nZXIgaW4gdGhlIGNsaWVudCdzIGNhY2hl LCB0aGUgY2xpZW50IE1VU1QgTk9UIA0KICAgYXR0ZW1wdCB0byBzb3VyY2UgdGhlIGRhdGEgZnJv bSB0aGUgZGF0YSBzZXJ2ZXJzLiAgSW5zdGVhZCwgaXQgc2hvdWxkIA0KICAgYXR0ZW1wdCB0byBj b21taXQgdGhlIGJsb2NrcyBpbiBxdWVzdGlvbiB0byB0aGUgc2VydmVyIGR1cmluZyB0aGUgDQog ICBzZXJ2ZXIncyByZWNvdmVyeSBncmFjZSBwZXJpb2QsIGJ5IHNlbmRpbmcgYSBMQVlPVVRDT01N SVQgd2l0aCB0aGUgDQogICAibG9jYV9yZWNsYWltIiBmbGFnIHNldCB0byB0cnVlLiBUaGlzIHBy b2Nlc3MgaXMgZGVzY3JpYmVkIGluIGRldGFpbCANCiAgIGluIFtORlN2NC4xXSBzZWN0aW9uIDE4 LjQyLjQuIA0KCjIuNS4gUmVjYWxsaW5nIHJlc291cmNlczogQ0JfUkVDQUxMX0FOWSANCgogICBU aGUgc2VydmVyIG1heSBkZWNpZGUgdGhhdCBpdCBjYW5ub3QgaG9sZCBhbGwgb2YgdGhlIHN0YXRl IGZvciANCiAgIGxheW91dHMgd2l0aG91dCBydW5uaW5nIG91dCBvZiByZXNvdXJjZXMuIEluIHN1 Y2ggYSBjYXNlLCBpdCBpcyBmcmVlIA0KICAgdG8gcmVjYWxsIGluZGl2aWR1YWwgbGF5b3V0cyB1 c2luZyBDQl9MQVlPVVRSRUNBTEwgdG8gcmVkdWNlIHRoZSANCiAgIGxvYWQsIG9yIGl0IG1heSBj aG9vc2UgdG8gcmVxdWVzdCB0aGF0IHRoZSBjbGllbnQgcmV0dXJuIGFueSBsYXlvdXQuIA0KCiAg IEZvciB0aGUgYmxvY2sgbGF5b3V0IHdlIGRlZmluZSB0aGUgZm9sbG93aW5nIGJpdCANCgogICBj b25zdCBSQ0E0X0JMS19MQVlPVVRfUkVDQUxMX0FOWV9MQVlPVVRTID0gNCANCgogICBXaGVuIHRo ZSBzZXJ2ZXIgc2VuZHMgYSBDQl9SRUNBTExfQU5ZIHJlcXVlc3QgdG8gYSBjbGllbnQgc3BlY2lm eWluZyANCiAgIHRoZSBSQ0E0X0JMS19MQVlPVVRfUkVDQUxMX0FOWV9MQVlPVVRTIGJpdCBpbiBj cmFhX3R5cGVfbWFzaywgdGhlIA0KICAgY2xpZW50IHNob3VsZCBpbW1lZGlhdGVseSByZXNwb25k IHdpdGggTkZTNF9PSywgYW5kIHRoZW4gDQogICBhc3luY2hyb25vdXNseSByZXR1cm4gY29tcGxl dGUgZmlsZSBsYXlvdXRzIHVudGlsIHRoZSBudW1iZXIgb2YgZmlsZXMgDQogICB3aXRoIGxheW91 dHMgY2FjaGVkIG9uIHRoZSBjbGllbnQgaXMgbGVzcyB0aGUgY3JhYV9vYmplY3RfdG9fa2VlcC4g DQoKICAgVGhlIGJsb2NrIGxheW91dCBkb2VzIG5vdCBjdXJyZW50bHkgdXNlIGJpdHMgNSwgNiBv ciA3LiAgSWYgYW55IG9mIA0KICAgdGhlc2UgYml0cyBhcmUgc2V0LCB0aGUgY2xpZW50IHNob3Vs ZCByZXR1cm4gTkZTNEVSUl9JTlZBTC4gDQogDQogDQpCbGFjayAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDE4XSANCiAgICAMDQoK CgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2svVm9sdW1lIExheW91dCAgICAg ICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgoyLjYuIFRyYW5zaWVudCBhbmQgUGVybWFuZW50 IEVycm9ycyANCgogICBUaGUgc2VydmVyIG1heSByZXNwb25kIHRvIExBWU9VVEdFVCB3aXRoIGEg dmFyaWV0eSBvZiBlcnJvciBzdGF0dXNlcy4gDQogICBUaGVzZSBlcnJvcnMgY2FuIGNvbnZleSB0 cmFuc2llbnQgY29uZGl0aW9ucyBvciBtb3JlIHBlcm1hbmVudCANCiAgIGNvbmRpdGlvbnMgdGhh dCBhcmUgdW5saWtlbHkgdG8gYmUgcmVzb2x2ZWQgc29vbi4gDQoKICAgVGhlIHRyYW5zaWVudCBl cnJvcnMsIE5GUzRFUlJfUkVDQUxMQ09ORkxJQ1QgYW5kIE5GUzRFUlJfVFJZTEFURVIgYXJlIA0K ICAgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBzZXJ2ZXIgY2Fubm90IGltbWVkaWF0ZWx5IGdy YW50IHRoZSBsYXlvdXQgDQogICB0byB0aGUgY2xpZW50LiAgSW4gdGhlIGZvcm1lciBjYXNlIHRo aXMgaXMgYmVjYXVzZSB0aGUgc2VydmVyIGhhcyANCiAgIHJlY2VudGx5IGlzc3VlZCBhIENCX0xB WU9VVFJFQ0FMTCB0byB0aGUgcmVxdWVzdGluZyBjbGllbnQsIHdoZXJlYXMgDQogICBpbiB0aGUg Y2FzZSBvZiBORlM0RVJSX1RSWUxBVEVSLCB0aGUgc2VydmVyIGNhbm5vdCBncmFudCB0aGUgcmVx dWVzdCANCiAgIHBvc3NpYmx5IGR1ZSB0byBzaGFyaW5nIGNvbmZsaWN0cyB3aXRoIG90aGVyIGNs aWVudHMuICBJbiBlaXRoZXIgDQogICBjYXNlLCBhIHJlYXNvbmFibGUgYXBwcm9hY2ggZm9yIHRo ZSBjbGllbnQgaXMgdG8gd2FpdCBzZXZlcmFsIA0KICAgbWlsbGlzZWNvbmRzIGFuZCByZXRyeSB0 aGUgcmVxdWVzdC4gIFRoZSBjbGllbnQgU0hPVUxEIHRyYWNrIHRoZSANCiAgIG51bWJlciBvZiBy ZXRyaWVzLCBhbmQgaWYgZm9yd2FyZCBwcm9ncmVzcyBpcyBub3QgbWFkZSwgdGhlIGNsaWVudCAN CiAgIFNIT1VMRCBzZW5kIHRoZSBSRUFEIG9yIFdSSVRFIG9wZXJhdGlvbiBkaXJlY3RseSB0byB0 aGUgc2VydmVyLiANCgogICBUaGUgZXJyb3IgTkZTNEVSUl9MQVlPVVRVTkFWQUlMQUJMRSBtYXkg YmUgcmV0dXJuZWQgYnkgdGhlIHNlcnZlciBpZiANCiAgIGxheW91dHMgYXJlIG5vdCBzdXBwb3J0 ZWQgZm9yIHRoZSByZXF1ZXN0ZWQgZmlsZSBvciBpdHMgY29udGFpbmluZyANCiAgIGZpbGUgc3lz dGVtLiAgVGhlIHNlcnZlciBtYXkgYWxzbyByZXR1cm4gdGhpcyBlcnJvciBjb2RlIGlmIHRoZSAN CiAgIHNlcnZlciBpcyB0aGUgcHJvZ3Jlc3Mgb2YgbWlncmF0aW5nIHRoZSBmaWxlIGZyb20gc2Vj b25kYXJ5IHN0b3JhZ2UsIA0KICAgb3IgZm9yIGFueSBvdGhlciByZWFzb24gd2hpY2ggY2F1c2Vz IHRoZSBzZXJ2ZXIgdG8gYmUgdW5hYmxlIHRvIA0KICAgc3VwcGx5IHRoZSBsYXlvdXQuICBBcyBh IHJlc3VsdCBvZiByZWNlaXZpbmcgDQogICBORlM0RVJSX0xBWU9VVFVOQVZBSUxBQkxFLCB0aGUg Y2xpZW50IFNIT1VMRCBzZW5kIGZ1dHVyZSBSRUFEIGFuZCANCiAgIFdSSVRFIHJlcXVlc3RzIGRp cmVjdGx5IHRvIHRoZSBzZXJ2ZXIuICBJdCBpcyBleHBlY3RlZCB0aGF0IGEgY2xpZW50IA0KICAg d2lsbCBub3QgY2FjaGUgdGhlIGZpbGUncyBsYXlvdXR1bmF2YWlsYWJsZSBzdGF0ZSBmb3JldmVy LCBwYXJ0aWN1bGFyIA0KICAgaWYgdGhlIGZpbGUgaXMgY2xvc2VkLCBhbmQgdGh1cyBldmVudHVh bGx5LCB0aGUgY2xpZW50IE1BWSByZWlzc3VlIGEgDQogICBMQVlPVVRHRVQgb3BlcmF0aW9uLiAN CgozLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCgogICBUeXBpY2FsbHksIFNBTiBkaXNrIGFy cmF5cyBhbmQgU0FOIHByb3RvY29scyBwcm92aWRlIGFjY2VzcyBjb250cm9sIA0KICAgbWVjaGFu aXNtcyAoYWNjZXNzLWxvZ2ljcywgbHVuIG1hc2tpbmcsIGV0Yy4pIHdoaWNoIG9wZXJhdGUgYXQg dGhlIA0KICAgZ3JhbnVsYXJpdHkgb2YgaW5kaXZpZHVhbCBob3N0cy4gIFRoZSBmdW5jdGlvbmFs aXR5IHByb3ZpZGVkIGJ5IHN1Y2ggDQogICBtZWNoYW5pc21zIG1ha2VzIGl0IHBvc3NpYmxlIGZv ciB0aGUgc2VydmVyIHRvICJmZW5jZSIgaW5kaXZpZHVhbCANCiAgIGNsaWVudCBtYWNoaW5lcyBm cm9tIGNlcnRhaW4gcGh5c2ljYWwgZGlza3MtLS10aGF0IGlzIHRvIHNheSwgdG8gDQogICBwcmV2 ZW50IGluZGl2aWR1YWwgY2xpZW50IG1hY2hpbmVzIGZyb20gcmVhZGluZyBvciB3cml0aW5nIHRv IGNlcnRhaW4gDQogICBwaHlzaWNhbCBkaXNrcy4gIEZpbmVyLWdyYWluZWQgYWNjZXNzIGNvbnRy b2wgbWV0aG9kcyBhcmUgbm90IA0KICAgZ2VuZXJhbGx5IGF2YWlsYWJsZS4gIEZvciB0aGlzIHJl YXNvbiwgY2VydGFpbiBzZWN1cml0eSANCiAgIHJlc3BvbnNpYmlsaXRpZXMgYXJlIGRlbGVnYXRl ZCB0byBwTkZTIGNsaWVudHMgZm9yIGJsb2NrL3ZvbHVtZSANCiAgIGxheW91dHMuICBCbG9jay92 b2x1bWUgc3RvcmFnZSBzeXN0ZW1zIGdlbmVyYWxseSBjb250cm9sIGFjY2VzcyBhdCBhIA0KICAg dm9sdW1lIGdyYW51bGFyaXR5LCBhbmQgaGVuY2UgcE5GUyBjbGllbnRzIGhhdmUgdG8gYmUgdHJ1 c3RlZCB0byBvbmx5IA0KICAgcGVyZm9ybSBhY2Nlc3NlcyBhbGxvd2VkIGJ5IHRoZSBsYXlvdXQg ZXh0ZW50cyB0aGV5IGN1cnJlbnRseSBob2xkIA0KICAgKGUuZy4sIGFuZCBub3QgYWNjZXNzIHN0 b3JhZ2UgZm9yIGZpbGVzIG9uIHdoaWNoIGEgbGF5b3V0IGV4dGVudCBpcyANCiAgIG5vdCBoZWxk KS4gIEluIGdlbmVyYWwsIHRoZSBzZXJ2ZXIgd2lsbCBub3QgYmUgYWJsZSB0byBwcmV2ZW50IGEg DQogICBjbGllbnQgd2hpY2ggaG9sZHMgYSBsYXlvdXQgZm9yIGEgZmlsZSBmcm9tIGFjY2Vzc2lu ZyBwYXJ0cyBvZiB0aGUgDQogICBwaHlzaWNhbCBkaXNrIG5vdCBjb3ZlcmVkIGJ5IHRoZSBsYXlv dXQuICBTaW1pbGFybHksIHRoZSBzZXJ2ZXIgd2lsbCANCiANCiANCkJsYWNrICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTldIA0K ICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5 b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIG5vdCBiZSBhYmxlIHRvIHBy ZXZlbnQgYSBjbGllbnQgZnJvbSBhY2Nlc3NpbmcgYmxvY2tzIGNvdmVyZWQgYnkgYSANCiAgIGxh eW91dCB0aGF0IGl0IGhhcyBhbHJlYWR5IHJldHVybmVkLiAgVGhpcyBibG9jay1iYXNlZCBsZXZl bCBvZiANCiAgIHByb3RlY3Rpb24gbXVzdCBiZSBwcm92aWRlZCBieSB0aGUgY2xpZW50IHNvZnR3 YXJlLiANCgogICBBbiBhbHRlcm5hdGl2ZSBtZXRob2Qgb2YgYmxvY2svdm9sdW1lIHByb3RvY29s IHVzZSBpcyBmb3IgdGhlIHN0b3JhZ2UgDQogICBkZXZpY2VzIHRvIGV4cG9ydCB2aXJ0dWFsaXpl ZCBibG9jayBhZGRyZXNzZXMsIHdoaWNoIGRvIHJlZmxlY3QgdGhlIA0KICAgZmlsZXMgdG8gd2hp Y2ggYmxvY2tzIGJlbG9uZy4gIFRoZXNlIHZpcnR1YWwgYmxvY2sgYWRkcmVzc2VzIGFyZSANCiAg IGV4cG9ydGVkIHRvIHBORlMgY2xpZW50cyB2aWEgbGF5b3V0cy4gIFRoaXMgYWxsb3dzIHRoZSBz dG9yYWdlIGRldmljZSANCiAgIHRvIG1ha2UgYXBwcm9wcmlhdGUgYWNjZXNzIGNoZWNrcywgd2hp bGUgbWFwcGluZyB2aXJ0dWFsIGJsb2NrIA0KICAgYWRkcmVzc2VzIHRvIHBoeXNpY2FsIGJsb2Nr IGFkZHJlc3Nlcy4gIEluIGVudmlyb25tZW50cyB3aGVyZSB0aGUgDQogICBzZWN1cml0eSByZXF1 aXJlbWVudHMgYXJlIHN1Y2ggdGhhdCBjbGllbnQtc2lkZSBwcm90ZWN0aW9uIGZyb20gDQogICBh Y2Nlc3MgdG8gc3RvcmFnZSBvdXRzaWRlIG9mIHRoZSBsYXlvdXQgaXMgbm90IHN1ZmZpY2llbnQg cE5GUyANCiAgIGJsb2NrL3ZvbHVtZSBzdG9yYWdlIGxheW91dHMgZm9yIHBORlMgU0hPVUxEIE5P VCBiZSB1c2VkLCB1bmxlc3MgdGhlIA0KICAgc3RvcmFnZSBkZXZpY2UgaXMgYWJsZSB0byBpbXBs ZW1lbnQgdGhlIGFwcHJvcHJpYXRlIGFjY2VzcyBjaGVja3MsIA0KICAgdmlhIHVzZSBvZiB2aXJ0 dWFsaXplZCBibG9jayBhZGRyZXNzZXMsIG9yIG90aGVyIG1lYW5zLiANCgogICBUaGlzIGFsc28g aGFzIGltcGxpY2F0aW9ucyBmb3Igc29tZSBORlN2NCBmdW5jdGlvbmFsaXR5IG91dHNpZGUgcE5G Uy4gIA0KICAgRm9yIGluc3RhbmNlLCBpZiBhIGZpbGUgaXMgY292ZXJlZCBieSBhIG1hbmRhdG9y eSByZWFkLW9ubHkgbG9jaywgdGhlIA0KICAgc2VydmVyIGNhbiBlbnN1cmUgdGhhdCBvbmx5IHJl YWRhYmxlIGxheW91dHMgZm9yIHRoZSBmaWxlIGFyZSBncmFudGVkIA0KICAgdG8gcE5GUyBjbGll bnRzLiAgSG93ZXZlciwgaXQgaXMgdXAgdG8gZWFjaCBwTkZTIGNsaWVudCB0byBlbnN1cmUgDQog ICB0aGF0IHRoZSByZWFkYWJsZSBsYXlvdXQgaXMgdXNlZCBvbmx5IHRvIHNlcnZpY2UgcmVhZCBy ZXF1ZXN0cywgYW5kIA0KICAgbm90IHRvIGFsbG93IHdyaXRlcyB0byB0aGUgZXhpc3RpbmcgcGFy dHMgb2YgdGhlIGZpbGUuICBTaW5jZSANCiAgIGJsb2NrL3ZvbHVtZSBzdG9yYWdlIHN5c3RlbXMg YXJlIGdlbmVyYWxseSBub3QgY2FwYWJsZSBvZiBlbmZvcmNpbmcgDQogICBzdWNoIGZpbGUtYmFz ZWQgc2VjdXJpdHksIGluIGVudmlyb25tZW50cyB3aGVyZSBwTkZTIGNsaWVudHMgY2Fubm90IA0K ICAgYmUgdHJ1c3RlZCB0byBlbmZvcmNlIHN1Y2ggcG9saWNpZXMsIHBORlMgYmxvY2svdm9sdW1l IHN0b3JhZ2UgDQogICBsYXlvdXRzIFNIT1VMRCBOT1QgYmUgdXNlZC4gDQoKICAgQWNjZXNzIHRv IGJsb2NrL3ZvbHVtZSBzdG9yYWdlIGlzIGxvZ2ljYWxseSBhdCBhIGxvd2VyIGxheWVyIG9mIHRo ZSANCiAgIEkvTyBzdGFjayB0aGFuIE5GU3Y0LCBhbmQgaGVuY2UgTkZTdjQgc2VjdXJpdHkgaXMg bm90IGRpcmVjdGx5IA0KICAgYXBwbGljYWJsZSB0byBwcm90b2NvbHMgdGhhdCBhY2Nlc3Mgc3Vj aCBzdG9yYWdlIGRpcmVjdGx5LiAgRGVwZW5kaW5nIA0KICAgb24gdGhlIHByb3RvY29sLCBzb21l IG9mIHRoZSBzZWN1cml0eSBtZWNoYW5pc21zIHByb3ZpZGVkIGJ5IE5GU3Y0IA0KICAgKGUuZy4s IGVuY3J5cHRpb24sIGNyeXB0b2dyYXBoaWMgaW50ZWdyaXR5KSBtYXkgbm90IGJlIGF2YWlsYWJs ZSwgb3IgDQogICBtYXkgYmUgcHJvdmlkZWQgdmlhIGRpZmZlcmVudCBtZWFucy4gIEF0IG9uZSBl eHRyZW1lLCBwTkZTIHdpdGggDQogICBibG9jay92b2x1bWUgc3RvcmFnZSBjYW4gYmUgdXNlZCB3 aXRoIHN0b3JhZ2UgYWNjZXNzIHByb3RvY29scyAoZS5nLiwgDQogICBwYXJhbGxlbCBTQ1NJKSB0 aGF0IHByb3ZpZGUgZXNzZW50aWFsbHkgbm8gc2VjdXJpdHkgZnVuY3Rpb25hbGl0eS4gIA0KICAg QXQgdGhlIG90aGVyIGV4dHJlbWUsIHBORlMgbWF5IGJlIHVzZWQgd2l0aCBzdG9yYWdlIHByb3Rv Y29scyBzdWNoIGFzIA0KICAgaVNDU0kgdGhhdCBwcm92aWRlIHNpZ25pZmljYW50IGZ1bmN0aW9u YWxpdHkuICBJdCBpcyB0aGUgDQogICByZXNwb25zaWJpbGl0eSBvZiB0aG9zZSBhZG1pbmlzdGVy aW5nIGFuZCBkZXBsb3lpbmcgcE5GUyB3aXRoIGEgDQogICBibG9jay92b2x1bWUgc3RvcmFnZSBh Y2Nlc3MgcHJvdG9jb2wgdG8gZW5zdXJlIHRoYXQgYXBwcm9wcmlhdGUgDQogICBwcm90ZWN0aW9u IGlzIHByb3ZpZGVkIHRvIHRoYXQgcHJvdG9jb2wgKHBoeXNpY2FsIHNlY3VyaXR5IGlzIGEgDQog ICBjb21tb24gbWVhbnMgZm9yIHByb3RvY29scyBub3QgYmFzZWQgb24gSVApLiAgSW4gZW52aXJv bm1lbnRzIHdoZXJlIA0KICAgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBmb3IgdGhlIHN0b3Jh Z2UgcHJvdG9jb2wgY2Fubm90IGJlIG1ldCwgDQogICBwTkZTIGJsb2NrL3ZvbHVtZSBzdG9yYWdl IGxheW91dHMgU0hPVUxEIE5PVCBiZSB1c2VkLiANCgogICBXaGVuIHNlY3VyaXR5IGlzIGF2YWls YWJsZSBmb3IgYSBzdG9yYWdlIHByb3RvY29sLCBpdCBpcyBnZW5lcmFsbHkgYXQgDQogICBhIGRp ZmZlcmVudCBncmFudWxhcml0eSBhbmQgd2l0aCBhIGRpZmZlcmVudCBub3Rpb24gb2YgaWRlbnRp dHkgdGhhbiANCiAgIE5GU3Y0IChlLmcuLCBORlN2NCBjb250cm9scyB1c2VyIGFjY2VzcyB0byBm aWxlcywgaVNDU0kgY29udHJvbHMgDQogDQogDQpCbGFjayAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDIwXSANCiAgICAMDQoKCgoK CgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2svVm9sdW1lIExheW91dCAgICAgICAg ICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICBpbml0aWF0b3IgYWNjZXNzIHRvIHZvbHVtZXMp LiAgVGhlIHJlc3BvbnNpYmlsaXR5IGZvciBlbmZvcmNpbmcgDQogICBhcHByb3ByaWF0ZSBjb3Jy ZXNwb25kZW5jZXMgYmV0d2VlbiB0aGVzZSBzZWN1cml0eSBsYXllcnMgaXMgcGxhY2VkIA0KICAg dXBvbiB0aGUgcE5GUyBjbGllbnQuICBBcyB3aXRoIHRoZSBpc3N1ZXMgaW4gdGhlIGZpcnN0IHBh cmFncmFwaCBvZiANCiAgIHRoaXMgc2VjdGlvbiwgaW4gZW52aXJvbm1lbnRzIHdoZXJlIHRoZSBz ZWN1cml0eSByZXF1aXJlbWVudHMgYXJlIA0KICAgc3VjaCB0aGF0IGNsaWVudC1zaWRlIHByb3Rl Y3Rpb24gZnJvbSBhY2Nlc3MgdG8gc3RvcmFnZSBvdXRzaWRlIG9mIA0KICAgdGhlIGxheW91dCBp cyBub3Qgc3VmZmljaWVudCwgcE5GUyBibG9jay92b2x1bWUgc3RvcmFnZSBsYXlvdXRzICANCiAg IFNIT1VMRCBOT1QgYmUgdXNlZC4gDQoKNC4gQ29uY2x1c2lvbnMgDQoKICAgVGhpcyBkcmFmdCBz cGVjaWZpZXMgdGhlIGJsb2NrL3ZvbHVtZSBsYXlvdXQgdHlwZSBmb3IgcE5GUyBhbmQgDQogICBh c3NvY2lhdGVkIGZ1bmN0aW9uYWxpdHkuIA0KCjUuIElBTkEgQ29uc2lkZXJhdGlvbnMgDQoKICAg VGhlcmUgYXJlIG5vIElBTkEgY29uc2lkZXJhdGlvbnMgaW4gdGhpcyBkb2N1bWVudC4gIEFsbCBw TkZTIElBTkEgDQogICBDb25zaWRlcmF0aW9ucyBhcmUgY292ZXJlZCBpbiBbTkZTVjQuMV0uIA0K CjYuIFJldmlzaW9uIEhpc3RvcnkgDQoKICAgLTAwOiBJbml0aWFsIFZlcnNpb24gYXMgZHJhZnQt YmxhY2stcG5mcy1ibG9jay0wMCANCgogICAtMDE6IFJld29yayBkaXNjdXNzaW9uIG9mIGV4dGVu dHMgYXMgbG9ja3MgdG8gdGFsayBhYm91dCBleHRlbnRzIA0KICAgZ3JhbnRpbmcgYWNjZXNzIHBl cm1pc3Npb25zLiAgUmV3cml0ZSBvcGVyYXRpb24gb3JkZXJpbmcgc2VjdGlvbiB0byANCiAgIGRp c2N1c3MgZGVhZGxvY2tzIGFuZCByYWNlcyB0aGF0IGNhbiBjYXVzZSBwcm9ibGVtcy4gIEFkZCBu ZXcgc2VjdGlvbiANCiAgIG9uIHJlY2FsbCBjb21wbGV0aW9uLiAgQWRkIGNsaWVudCBjb3B5LW9u LXdyaXRlIGJhc2VkIG9uIHRleHQgZnJvbSANCiAgIENyYWlnIEV2ZXJoYXJ0LiANCgogICAtMDI6 IEZpeCBnbGl0Y2hlcyBpbiBleHRlbnQgc3RhdGUgZGVzY3JpcHRpb25zLiAgRGVzY3JpYmUgbW9z dCBpc3N1ZXMgDQogICBhcyBSRVNPTFZFRC4gIE1vc3Qgb2YgU2VjdGlvbiAzIGhhcyBiZWVuIGlu Y29ycG9yYXRlZCBpbnRvIHRoZSB0aGUgDQogICBtYWluIFBORkQgZHJhZnQsIGFkZCBOT1RFIHRv IHRoYXQgZWZmZWN0IGFuZCBzYXkgdGhhdCBpdCB3aWxsIGJlIA0KICAgZGVsZXRlZCBpbiB0aGUg bmV4dCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgKHdoaWNoIHNob3VsZCBiZSBhIGRyYWZ0LQ0KICAg aWV0Zi1uZnN2NCBkcmFmdCkuICBDbGVhbmluZyB1cCBhIG51bWJlciBvZiB0aGluZ3MgaGF2ZSBi ZWVuIGxlZnQgdG8gDQogICB0aGF0IGRyYWZ0IHJldmlzaW9uLCBpbmNsdWRpbmcgdGhlIGludGVy bG9ja3Mgd2l0aCB0aGUgdHlwZXMgaW4gdGhlIA0KICAgbWFpbiBwTkZTIGRyYWZ0LCBsYXlvdXQg c3RyaXBpbmcgc3VwcG9ydCwgYW5kIGZpbmlzaGluZyB0aGUgU2VjdXJpdHkgDQogICBDb25zaWRl cmF0aW9ucyBzZWN0aW9uLiANCgogICAtMDA6IE5ldyB2ZXJzaW9uIGFzIGRyYWZ0LWlldGYtbmZz djQtcG5mcy1ibG9jay4gIFJlbW92ZWQgcmVzb2x2ZWQgDQogICBvcGVyYXRpb25zIGlzc3VlcyAo U2VjdGlvbiAzKS4gIEFsaWduIHR5cGVzIHdpdGggbWFpbiBwTkZTIGRyYWZ0IA0KICAgKHdoaWNo IGlzIG5vdyBwYXJ0IG9mIHRoZSBORlN2NC4xIG1pbm9yIHZlcnNpb24gZHJhZnQpLCBhZGQgdm9s dW1lIA0KICAgc3RyaXBpbmcgYW5kIHNsaWNpbmcgc3VwcG9ydC4gIE5ldyBvcGVyYXRpb25zIGlz c3VlcyBhcmUgaW4gU2VjdGlvbiAzIA0KICAgLSB0aGUgbmVlZCBmb3IgYSAicmVjbGFpbSBiaXQi IGFuZCBFT0YgY29uY2VybnMgYXJlIHRoZSB0d28gbWFqb3IgDQogICBpc3N1ZXMuICBFeHRlbmRl ZCBhbmQgaW1wcm92ZWQgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24sIA0KICAg YnV0IGl0IHN0aWxsIG5lZWRzIHdvcmsuICBBZGRlZCAxLXNlbnRlbmNlIGNvbmNsdXNpb24gdGhh dCBhbHNvIHN0aWxsIA0KICAgbmVlZHMgd29yay4gDQoKCiANCiANCkJsYWNrICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMjFdIA0K ICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5 b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIC0wMTogQ2hhbmdlZCBkZWZp bml0aW9uIG9mIHBuZnNfYmxvY2tfZGV2aWNlYWRkcjQgdW5pb24gdG8gYWxsb3cgbW9yZSANCiAg IGNvbmNpc2UgcmVwcmVzZW50YXRpb24gb2YgYWdncmVnYXRlZCB2b2x1bWUgc3RydWN0dXJlcy4g IEZpeGVkIHR5cG9zIA0KICAgdG8gbWFrZSBib3RoIHBuZnNfYmxvY2tfbGF5b3V0dXBkYXRlIGFu ZCBwbmZzX2Jsb2NrX2xheW91dHJldHVybiANCiAgIHN0cnVjdHVyZXMgY29udGFpbiBleHRlbnQg bGlzdHMgaW5zdGVhZCBvZiBhIHNpbmdsZSBleHRlbnQuICBVcGRhdGVkIA0KICAgc2VjdGlvbiAy LjEuNiB0byByZW1vdmUgcmVmZXJlbmNlcyB0byBDQl9TSVpFQ0hBTkdFRC4gTW92ZWQgDQogICBk ZXNjcmlwdGlvbiBvZiByZWNvdmVyeSBmcm9tICJJc3N1ZXMiIHNlY3Rpb24gdG8gIkJsb2NrIExh eW91dCANCiAgIERlc2NyaXB0aW9uIiBzZWN0aW9uLiBSZW1vdmVkIHNlY3Rpb24gMy4yICJFbmQt b2YtZmlsZSBoYW5kbGluZyANCiAgIGlzc3VlcyIuICBNZXJnZWQgb2xkICJibG9jay92b2x1bWUg bGF5b3V0IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIiANCiAgIHNlY3Rpb24gZnJvbSBwcmV2aW91 cyB2ZXJzaW9uIG9mIFtORlN2NC4xXSB3aXRoIHNlY3Rpb24gNC4gIE1vdmVkIA0KICAgcGFyYWdy YXBoIG9uIGxpbmdlcmluZyB3cml0ZXMgdG8gdGhlIHNlY3Rpb24gd2hpY2ggZGVzY3JpYmVzIGxh eW91dCANCiAgIHJldHVybi4gIFJlbW92ZWQgSXNzdWVzIHNlY3Rpb24gKDMpIGFzIHRoZSByZW1h aW5pbmcgaXNzdWVzIGFyZSBhbGwgDQogICByZXNvbHZlZC4gDQoKICAgMDI6IENoYW5nZWQgcG5m c19kZXZpY2VhZGRyNCB0byBkZXZpY2VhZGRyNCB0byBtYXRjaCBbTkZTdjQuMV0uICANCiAgIFVw ZGF0ZWQgc2VjdGlvbiAyLjIuMiB0byBjbGFyaWZ5IHRoYXQgdGhlIGVzIGZpZWxkcyBtdXN0IGJl IA0KICAgUkVBRF9XUklURV9EQVRBIGluIHBuZnNfYmxvY2tfbGF5b3V0dXBkYXRlIHJlcXVlc3Rz LiAgVXBkYXRlZCBzZWN0aW9uIA0KICAgMi4yLjUgdG8gc3BlY2lmeSB0aGF0IGRhdGEgY29ycnVw dGlvbiBjYW4gb2NjdXI7IHRoYXQgcmVxdWVzdHMsIG5vdCANCiAgIHRoZSBjbGllbnQsIGFyZSBy ZWplY3RlZDsgdGhhdCBzZXJ2ZXIgIlNIT1VMRCIgcmVjYWxsIGNvbmZsaWN0aW5nIA0KICAgcG9y dGlvbnMgb2YgbGF5b3V0cy4gIENsYXJpZmllZCB0aGF0IHVuaWxhdGVyYWwgcmV2b2NhdGlvbiBt YXkgYWZmZWN0IA0KICAgbGF5b3V0cyBmcm9tIG90aGVyIGZpbGVzeXN0ZW1zLiAgQ2hhbmdlZCBz aWduYXR1cmUgb2Zmc2V0IHRvIGJlIGEgDQogICBzaWduZWQgcXVhbnRpdHkgdG8gYWxsb3cgZm9y IGxhYmVscyBhdCBhIGZpeGVkIGxvY2F0aW9uIGZyb20gdGhlIGVuZCANCiAgIG9mIGEgdm9sdW1l LiAgQ2hhbmdlZCBhbGwgZGF0YSBzdHJ1Y3R1cmVzIHRvIGhhdmUgc3VmZml4ICI0IiwgY2hhbmdl ZCANCiAgIGV4dGVudFN0YXRlNCB0byBwbmZzX2Jsb2NrX2V4dGVudF9zdGF0ZTQgYW5kIHNpZ0Nv bXBvbmVudCB0byANCiAgIHBuZnNfYmxvY2tfc2lnX2NvbXBvbmVudDQsIHRvIGNvbmZvcm0gdG8g W05GU3Y0LjFdLiANCgogICAwMzogTW92ZWQgc2VjdGlvbnMgR0VUREVWSUNFTElTVCBhbmQgR0VU REVWSUNFSU5GTyBlYXJsaWVyIGluIA0KICAgZG9jdW1lbnQgZm9yIGJldHRlciByZWFkYWJpbGl0 eS4gIEFkZGVkIHBuZnNfYmxvY2tfc2ltcGxlX3ZvbHVtZTQgDQogICBkYXRhIHN0cnVjdHVyZSwg YW5kIGFkZGVkIHZvbHVtZV9pZCBmaWVsZHMgdG8gYWxsIHBuZnNfYmxvY2sgdm9sdW1lIA0KICAg aW5mbyBkYXRhIHN0cnVjdHVyZXMuIA0KCiAgIDA0OiBBZGRlZCBpbmZvcm1hdGlvbiBhYm91dCBk ZXZpY2UgaWRzIHRvIGNsYXJpZnkgdGhlaXIgdXNhZ2UuICANCiAgIERlc2NyaWJlZCB3aGVyZSB0 aGUgcG5mc19ibG9ja19kZXZpY2VhZGRyNCBkYXRhIHN0cnVjdHVyZSBpcyBmb3VuZCB0byANCiAg IGJlIGFjY3VyYXRlIHdpdGggZHJhZnQtaWV0Zi1uZnN2NC1taW5vcnZlcnNpb24xLTE0LiAgVXBk YXRlZCANCiAgIHJlZmVyZW5jZXMgZnJvbSAtMDggdG8gLTE0LiAgUmVtb3ZlZCByb290X2lkIGZy b20gDQogICBwbmZzX2Jsb2NrX2RldmljZWFkZHI0LiAgQ2hhbmdlZCAnYnl0ZScgdG8gJ29jdGV0 Jy4gIENsYXJpZnkgdGhlIA0KICAgYmxvY2sgc2l6ZSBhbmQgc3RyaXBlIHNpemUgaW4gdm9sdW1l IGRhdGEgc3RydWN0dXJlcy4gIFJlbmFtZSANCiAgICd2b2x1bWUnIGFuZCAnaWQnIHRvIGJlICd2 b2xfaWQnIGNvbnNpc3RlbnRseS4gIEFkZGVkIHNlY3Rpb25zIG9uIA0KICAgQ0JfUkVDQUxMX0FO WSBhbmQgZmVuY2luZy4gDQoKNy4gQWNrbm93bGVkZ21lbnRzIA0KCiAgIFRoaXMgZHJhZnQgZHJh d3MgZXh0ZW5zaXZlbHkgb24gdGhlIGF1dGhvcnMnIGZhbWlsaWFyaXR5IHdpdGggdGhlIA0KICAg bWFwcGluZyBmdW5jdGlvbmFsaXR5IGFuZCBwcm90b2NvbCBpbiBFTUMncyBIaWdoUm9hZCBzeXN0 ZW0gDQogICBbSGlnaFJvYWRdLiAgVGhlIHByb3RvY29sIHVzZWQgYnkgSGlnaFJvYWQgaXMgY2Fs bGVkIEZNUCAoRmlsZSANCiAgIE1hcHBpbmcgUHJvdG9jb2wpOyBpdCBpcyBhbiBhZGQtb24gcHJv dG9jb2wgdGhhdCBydW5zIGluIHBhcmFsbGVsIA0KICAgd2l0aCBmaWxlc3lzdGVtIHByb3RvY29s cyBzdWNoIGFzIE5GU3YzIHRvIHByb3ZpZGUgcE5GUy1saWtlIA0KICAgZnVuY3Rpb25hbGl0eSBm b3IgYmxvY2svdm9sdW1lIHN0b3JhZ2UuICBXaGlsZSBkcmF3aW5nIG9uIEhpZ2hSb2FkIA0KIA0K IA0KQmxhY2sgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAg ICAgICAgICBbUGFnZSAyMl0gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBw TkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoK ICAgRk1QLCB0aGUgZGF0YSBzdHJ1Y3R1cmVzIGFuZCBmdW5jdGlvbmFsIGNvbnNpZGVyYXRpb25z IGluIHRoaXMgZHJhZnQgDQogICBkaWZmZXIgaW4gc2lnbmlmaWNhbnQgd2F5cywgYmFzZWQgb24g bGVzc29ucyBsZWFybmVkIGFuZCB0aGUgDQogICBvcHBvcnR1bml0eSB0byB0YWtlIGFkdmFudGFn ZSBvZiBORlN2NCBmZWF0dXJlcyBzdWNoIGFzIENPTVBPVU5EIA0KICAgb3BlcmF0aW9ucy4gIFRo ZSBkZXNpZ24gdG8gc3VwcG9ydCBwTkZTIGNsaWVudCBwYXJ0aWNpcGF0aW9uIGluIGNvcHktDQog ICBvbi13cml0ZSBpcyBiYXNlZCBvbiB0ZXh0IGFuZCBpZGVhcyBjb250cmlidXRlZCBieSBDcmFp ZyBFdmVyaGFydCANCiAgIChmb3JtZXJseSB3aXRoIElCTSkuIA0KCjguIFJlZmVyZW5jZXMgDQoK OC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyANCgogICBbUkZDMjExOV0gQnJhZG5lciwgUy4sICJL ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIA0KICAgICAgICAgICAgIFJlcXVp cmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuIA0KCiAgIFtORlNW NC4xXSBTaGVwbGVyLCBTLiwgRWlzbGVyLCBNLiwgYW5kIE5vdmVjaywgRC4gZWQuLCAiTkZTdjQg TWlub3IgDQogICAgICAgICAgICAgVmVyc2lvbiAxIiwgZHJhZnQtaWV0Zi1uZnN2NC1taW5vcnZl cnNpb24xLTE0LnR4dCwgSW50ZXJuZXQgDQogICAgICAgICAgICAgRHJhZnQsIEp1bHkgMjAwNy4g DQoKOC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIA0KCiAgIFtIaWdoUm9hZF0gRU1DIENvcnBv cmF0aW9uLCAiRU1DIENlbGVycmEgSGlnaFJvYWQiLCBFTUMgQzgxOS4xIHdoaXRlIA0KICAgICAg ICAgICAgICBwYXBlciwgYXZhaWxhYmxlIGF0OiANCiAgIGh0dHA6Ly93d3cuZW1jLmNvbS9wZGYv cHJvZHVjdHMvY2VsZXJyYV9maWxlX3NlcnZlci9IaWdoUm9hZF93cC5wZGYgDQogICAgICAgICAg ICAgIGxpbmsgY2hlY2tlZCAyOSBBdWd1c3QgMjAwNi4gICAgICAgDQoKICAgW1NNSVNdIFNOSUEs ICJTTklBIFN0b3JhZ2UgTWFuYWdlbWVudCBJbml0aWF0aXZlIFNwZWNpZmljYXRpb24iLCANCiAg ICAgICAgICAgIHZlcnNpb24gMS4wLjIsIGF2YWlsYWJsZSBhdDogDQogICBodHRwOi8vd3d3LnNu aWEub3JnL3NtaS90ZWNoX2FjdGl2aXRpZXMvc21pX3NwZWNfcHIvc3BlYy9TTUlTXzFfMF8yX2YN CiAgIGluYWwucGRmIA0KCkF1dGhvcidzIEFkZHJlc3NlcyANCgogICBEYXZpZCBMLiBCbGFjayAN CiAgIEVNQyBDb3Jwb3JhdGlvbiANCiAgIDE3NiBTb3V0aCBTdHJlZXQgDQogICBIb3BraW50b24s IE1BIDAxNzQ4IA0KICAgICAgIA0KICAgUGhvbmU6ICsxICg1MDgpIDI5My03OTUzIA0KICAgRW1h aWw6IGJsYWNrX2RhdmlkQGVtYy5jb20gDQogICAgDQoKCgoKCgoKIA0KIA0KQmxhY2sgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICBbUGFnZSAy M10gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVt ZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgU3RlcGhlbiBGcmlk ZWxsYSANCiAgIEVNQyBDb3Jwb3JhdGlvbiANCiAgIDIyOCBTb3V0aCBTdHJlZXQgDQogICBIb3Br aW50b24sIE1BICAwMTc0OCANCiAgICAgICANCiAgIFBob25lOiArMSAoNTA4KSAyNDktMzUyOCAN CiAgIEVtYWlsOiBmcmlkZWxsYV9zdGVwaGVuQGVtYy5jb20gDQogICAgDQogICBKYXNvbiBHbGFz Z293IA0KICAgRU1DIENvcnBvcmF0aW9uIA0KICAgMzIgQ29zbGluIERyaXZlIA0KICAgU291dGhi b3JvLCBNQSAgMDE3NzIgDQogICAgICAgDQogICBQaG9uZTogKzEgKDUwOCkgMzA1IDg4MzEgDQog ICBFbWFpbDogZ2xhc2dvd19qYXNvbkBlbWMuY29tIA0KICAgIA0KCkludGVsbGVjdHVhbCBQcm9w ZXJ0eSBTdGF0ZW1lbnQgDQoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5n IHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkgDQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkg UmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8gDQogICBwZXJ0 YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3Jp YmVkIGluIA0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNl bnNlIHVuZGVyIHN1Y2ggcmlnaHRzIA0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJs ZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIA0KICAgbWFkZSBhbnkgaW5kZXBl bmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uIA0K ICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1l bnRzIGNhbiBiZSANCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LiANCgogICBDb3BpZXMg b2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueSAN CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSBy ZXN1bHQgb2YgYW4gDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNl IG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YgDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0 cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcyANCiAgIHNwZWNpZmljYXRpb24gY2Fu IGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdCANCiAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiANCgogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRl cmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55IA0KICAgY29weXJpZ2h0 cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeSAN CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVk IHRvIGltcGxlbWVudCANCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5m b3JtYXRpb24gdG8gdGhlIElFVEYgYXQgaWV0Zi0NCiAgIGlwckBpZXRmLm9yZy4gDQoKRGlzY2xh aW1lciBvZiBWYWxpZGl0eSANCgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4gDQogICAiQVMgSVMiIGJhc2lzIGFu ZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMgDQog ICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZLCBUSEUg SUVURiBUUlVTVCBBTkQgDQogICBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBE SVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyANCiANCiANCkJsYWNrICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMjRdIA0K ICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5 b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIE9SIElNUExJRUQsIElOQ0xV RElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiANCiAg IFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBB TlkgSU1QTElFRCANCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiANCgpDb3B5cmlnaHQgU3RhdGVtZW50IA0KCiAgIENv cHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLiANCgogICBUaGlzIGRvY3VtZW50IGlz IHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyANCiAgIGNv bnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBh dXRob3JzIA0KICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuIA0KCkFja25vd2xlZGdtZW50IA0K CiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92 aWRlZCBieSB0aGUgDQogICBJbnRlcm5ldCBTb2NpZXR5LiANCgogDQoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3Vz dCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMjVdIA0KICAgIAw= ------_=_NextPart_001_01C8063C.1A2A45FB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 ------_=_NextPart_001_01C8063C.1A2A45FB-- From shutt@service-group.de Thu Oct 04 01:05:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdIuM-0000xU-Gn for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 01:05:58 -0400 Received: from [194.250.38.4] (helo=[83.197.153.107]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdIuH-0004Kz-03 for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 01:05:53 -0400 Received: from SL00001112 ([163.105.17.24] helo=SL00001112) by [83.197.153.107] ( sendmail 8.13.3/8.13.1) with esmtpa id 1todJq-000EHJ-EH for nfsv4-archive@lists.ietf.org; Thu, 4 Oct 2007 07:06:19 +0200 Message-ID: Date: Thu, 4 Oct 2007 07:05:53 +0200 From: "racquel shutt" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: eteredos Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea What's up nfsv4-archive Get your supply today before prices sky rocket racquel shutt http://elllison.com/ From nfsv4-bounces@ietf.org Thu Oct 04 07:36:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdOyn-0005Dk-UZ; Thu, 04 Oct 2007 07:34:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdOym-0005Bz-D8 for nfsv4@ietf.org; Thu, 04 Oct 2007 07:34:56 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdOyg-0003nN-5b for nfsv4@ietf.org; Thu, 04 Oct 2007 07:34:56 -0400 X-IronPort-AV: E=Sophos;i="4.21,229,1188802800"; d="scan'208";a="110736581" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 04 Oct 2007 04:34:37 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l94BYbj7024048; Thu, 4 Oct 2007 04:34:37 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 04:34:36 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 04:34:36 -0700 Received: from tmt.netapp.com ([10.30.32.49]) by exnane01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Oct 2007 07:34:35 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 04 Oct 2007 07:34:24 -0400 To: Glasgow_Jason@emc.com From: "Talpey, Thomas" Subject: Re: [nfsv4] Request for an additional recommended attribute In-Reply-To: <39CF2A4B63947142A66EAA65B2FDF2F005612D59@CORPUSMX40A.corp. emc.com> References: <39CF2A4B63947142A66EAA65B2FDF2F005612D59@CORPUSMX40A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 04 Oct 2007 11:34:35.0124 (UTC) FILETIME=[8A024340:01C8067A] X-Spam-Score: -2.2 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org It's not clear if this text is making a requirement that every NFSv4.1= server implement a bounded maximum I/O time, or if the client is able to request one. Also, it is not clear to me whether this time is global across all I/Os at the server, all I/Os for this clientid or sessionid, or whether it's= per-file. Can you clarify? If it's a server-global mandatory requirement, I have some strong concerns.=20 Is this really fencing btw? Usually I think of fencing as a way for a server to deny access to clients which fall out of a cluster. Tom. At 05:26 PM 10/3/2007, Glasgow_Jason@emc.com wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C80604.03F942D3" > >In describing how the pNFS block client will implement fencing, it became= necessary to define the maximum time that an I/O can be outstanding. The= client needs to communicate its value to the pNFS server. The most= appropriate means of doing so seems to be to provide a per server R/W= recommended attribute, which clients can write. >=20 >I propose updating section 5.6 "Recommended Attributes =96 Definitions"= with the following >=20 >maximum_io_time 74 uint32 R/W The default maximum time that a client > I/O to a data server can be active. > Clients may update this value. >=20 >=20 >=20 >This parameter is defined in the next version of the pNFS block layout spec= as follows: >=20 >-- >"maximum_io_time" is the maximum time it can take for a client I/O to the= storage system to either complete or fail; this value is often 30 seconds= or 60 seconds, but may be longer in some environments. . If the maximum= client I/O time cannot be bounded, this timed lease mechanism MUST NOT be= used. The client can use GETATTR to query the server's default setting of= "maximum_io_time". The server must respond with the maximum I/O time in= seconds. If the client's maximum I/O time is greater than the server's= default, then the client MUST use SETATTR to inform the server of its= maximum_I/O time. >-- >=20 >Are there comments on introducing this new attribute into the NFSv4 minor= version 1 spec? Is this a valid means of communicating a client specific= value to the server? >=20 >-Jason Glasgow >=20 >=20 >_______________________________________________ >nfsv4 mailing list >nfsv4@ietf.org >https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Oct 04 10:17:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRVT-0007XB-3Q; Thu, 04 Oct 2007 10:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRVS-0007Pr-9S for nfsv4@ietf.org; Thu, 04 Oct 2007 10:16:50 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdRVO-0002MP-LT for nfsv4@ietf.org; Thu, 04 Oct 2007 10:16:50 -0400 X-IronPort-AV: E=Sophos;i="4.21,230,1188802800"; d="scan'208";a="110771597" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 04 Oct 2007 07:16:30 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l94EGUUl016962; Thu, 4 Oct 2007 07:16:30 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 07:16:30 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 07:16:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Request for an additional recommended attribute Date: Thu, 4 Oct 2007 10:16:28 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Request for an additional recommended attribute Thread-Index: AcgGe+b8XF3yHcguTTqjxIrEh4Q01wAFD/Ug From: "Noveck, Dave" To: "Talpey, Thomas" , X-OriginalArrivalTime: 04 Oct 2007 14:16:30.0244 (UTC) FILETIME=[28ABEE40:01C80691] X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org My understanding is that this is to take the place of fencing, i.e. to provide to the protocol implementation time-based promises which can be relied upon to avoid a requirement for actual fencing. David Black's concern has been that requiring actual fencing support would limit the deployment of pnfs for blocks which limitation he believes would be a bad thing. -----Original Message----- From: Talpey, Thomas=20 Sent: Thursday, October 04, 2007 7:34 AM To: Glasgow_Jason@emc.com Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Request for an additional recommended attribute It's not clear if this text is making a requirement that every NFSv4.1 server implement a bounded maximum I/O time, or if the client is able to request one. Also, it is not clear to me whether this time is global across all I/Os at the server, all I/Os for this clientid or sessionid, or whether it's per-file. Can you clarify? If it's a server-global mandatory requirement, I have some strong concerns.=20 Is this really fencing btw? Usually I think of fencing as a way for a server to deny access to clients which fall out of a cluster. Tom. At 05:26 PM 10/3/2007, Glasgow_Jason@emc.com wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C80604.03F942D3" > >In describing how the pNFS block client will implement fencing, it became necessary to define the maximum time that an I/O can be outstanding. The client needs to communicate its value to the pNFS server. The most appropriate means of doing so seems to be to provide a per server R/W recommended attribute, which clients can write. >=20 >I propose updating section 5.6 "Recommended Attributes - Definitions" with the following >=20 >maximum_io_time 74 uint32 R/W The default maximum time that a client > I/O to a data server can be active. > Clients may update this value. >=20 >=20 >=20 >This parameter is defined in the next version of the pNFS block layout spec as follows: >=20 >-- >"maximum_io_time" is the maximum time it can take for a client I/O to the storage system to either complete or fail; this value is often 30 seconds or 60 seconds, but may be longer in some environments. . If the maximum client I/O time cannot be bounded, this timed lease mechanism MUST NOT be used. The client can use GETATTR to query the server's default setting of "maximum_io_time". The server must respond with the maximum I/O time in seconds. If the client's maximum I/O time is greater than the server's default, then the client MUST use SETATTR to inform the server of its maximum_I/O time. >-- >=20 >Are there comments on introducing this new attribute into the NFSv4 minor version 1 spec? Is this a valid means of communicating a client specific value to the server? >=20 >-Jason Glasgow >=20 >=20 >_______________________________________________ >nfsv4 mailing list >nfsv4@ietf.org >https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Oct 04 10:29:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRh8-0000Zw-Nh; Thu, 04 Oct 2007 10:28:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRh6-0000NP-VL for nfsv4@ietf.org; Thu, 04 Oct 2007 10:28:52 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdRgz-0002gz-EV for nfsv4@ietf.org; Thu, 04 Oct 2007 10:28:52 -0400 Received: by wx-out-0506.google.com with SMTP id s8so167963wxc for ; Thu, 04 Oct 2007 07:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; bh=ZssW++QdqzSlfG2Iism3+F6CHsaWe3rBBtvDe78k9ic=; b=ByStUmTsyRV5l1HNr33zJDnZ3zN8wjVJSn1HZFWn7g3NbPPj9HKwM6JjrVEQcp68VgI0dKhIvASKAI7AM75+sePz2zKKfZ5KrSjGdB0uWVdeVQma0vjKKpaAKUOCgxRu3qZedAoeu0YX53shVm+8wbkDFx83cmsX/fDaynjKso0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=X6U4gGhu0weHxmWkLD1CM1yAcHGxSa+7431JBzGZTWh1YbRzZsQb+BflXalQhSFaPxmZDeSs25Zc2Ok5Hhw/yZsMpgavgAAls1SHMvFuHu19DN9p8JVB0ktn/U4bA+HTBiWBl8UwcYh20dyBXyeDX40CDDXv2PkYGTdPyfR5jPA= Received: by 10.142.178.13 with SMTP id a13mr1740853wff.1191508103197; Thu, 04 Oct 2007 07:28:23 -0700 (PDT) Received: by 10.142.98.1 with HTTP; Thu, 4 Oct 2007 07:28:23 -0700 (PDT) Message-ID: <89c397150710040728h2b7a5df8ra93addb5d5d929ea@mail.gmail.com> Date: Thu, 4 Oct 2007 10:28:23 -0400 From: "William A. (Andy) Adamson" To: "Glasgow_Jason@emc.com" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_26103_14018844.1191508103194" X-Google-Sender-Auth: 7c272c3535fce54c X-Spam-Score: 0.0 (/) X-Scan-Signature: e2979bf969b930cb324a529c01a4e0b4 Cc: nfsv4@ietf.org Subject: [nfsv4] October 10 draft-ietf-nfsv4-pnfs-block-04 review telecon X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org ------=_Part_26103_14018844.1191508103194 Content-Type: multipart/alternative; boundary="----=_Part_26104_21678303.1191508103195" ------=_Part_26104_21678303.1191508103195 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We have scheduled time to review the latest pNFS block spec during the CITI October Bakeathon. For interested parties that cannot attend the Bakeathon meeting, David Black has set up this telecon: Wed, Oct 10 -- pNFS Block Specification Review: 1pm - 3pm EST Domestic Dial in # 877-928-7953 -- International Dial in # 1-210-814-2907 Participant Passcode 161636# -->Andy On 10/4/07, Glasgow_Jason@emc.com wrote: > > I submitted draft-ietf-nfsv4-pnfs-block-04. > > Please see summary of changes below. > > > > Jason > > > ------------------------------ > > *From:* Glasgow, Jason > *Sent:* Wednesday, October 03, 2007 11:52 PM > *To:* 'internet-drafts@ietf.org' > *Cc:* Glasgow, Jason; Black, David > *Subject:* draft-ietf-nfsv4-pnfs-block-04 > > > > Attached is an updated I-D, draft-ietf-nfsv4-pnfs-block-04.txt > > > > It updates the nfsv4 working group I-D, draft-ietf-nfsv4-pnfs-block-03.txt > > > > The new version has several editorial changes and clarifications as well > these technical changes: > > > > - Added Client Fencing section. > > > > - Added sections on CB_RECALL_ANY. > > > > - Added information about device ids to clarify their usage. > > > > - Described where the pnfs_block_deviceaddr4 data structure is found to > > be accurate with draft-ietf-nfsv4-minorversion1-14. > > > > - Updated references from -08 to -14. > > > > - Removed root_id from pnfs_block_deviceaddr4. > > > > - Changed 'byte' to 'octet'. > > > > - Clarify the block size and stripe size in volume data structures. > > > > - Rename 'volume' and 'id' to be 'vol_id' consistently. > > > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > > ------=_Part_26104_21678303.1191508103195 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We have scheduled time to review the latest pNFS block spec during the CITI October Bakeathon. For interested parties that cannot attend the Bakeathon meeting, David Black has set up this telecon:
 
Wed, Oct 10 -- pNFS Block Specification Review:

1pm - 3pm EST

Domestic Dial in # 877-928-7953 -- International Dial in # 1-210-814-2907

Participant Passcode 161636#

-->Andy


On 10/4/07, Glasgow_Jason@emc.com <Glasgow_Jason@emc.com> wrote:

I submitted draft-ietf-nfsv4-pnfs-block-04.

Please see summary of changes below.

 

Jason

 


From: Glasgow, Jason
Sent: Wednesday, October 03, 2007 11:52 PM
To: 'internet-drafts@ietf.org'
Cc: Glasgow, Jason; Black, David
Subject: draft-ietf-nfsv4-pnfs-block-04

 

Attached is an updated I-D, draft-ietf-nfsv4-pnfs-block-04.txt

 

It updates the nfsv4 working group I-D, draft-ietf-nfsv4-pnfs-block-03.txt

 

The new version has several editorial changes and clarifications as well these technical changes:

 

- Added Client Fencing section.

 

- Added sections on CB_RECALL_ANY.

 

- Added information about device ids to clarify their usage. 

 

-  Described where the pnfs_block_deviceaddr4 data structure is found to

   be accurate with draft-ietf-nfsv4-minorversion1-14.

 

-  Updated references from -08 to -14.

 

-  Removed root_id from pnfs_block_deviceaddr4.

 

-  Changed 'byte' to 'octet'.

 

-  Clarify the block size and stripe size in volume data structures. 

 

-  Rename 'volume' and 'id' to be 'vol_id' consistently.

 

 


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4



------=_Part_26104_21678303.1191508103195-- ------=_Part_26103_14018844.1191508103194 Content-Type: text/plain; name="draft-ietf-nfsv4-pnfs-block-04.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-nfsv4-pnfs-block-04.txt" X-Attachment-Id: f_f7dd3pzk DQoKCgoKCgogDQogDQpORlN2NCBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBEYXZpZCBMLiBCbGFjayANCkludGVybmV0IERyYWZ0ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVwaGVuIEZyaWRlbGxhIA0KRXhwaXJlczog QXByaWwgMjAwOCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEphc29uIEds YXNnb3cgDQpJbnRlbmRlZCBTdGF0dXM6IFByb3Bvc2VkIFN0YW5kYXJkICAgICAgICAgICAgICAg ICAgICAgIEVNQyBDb3Jwb3JhdGlvbiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAzLCAyMDA3IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgIHBORlMgQmxvY2svVm9sdW1lIExheW91 dCANCiAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1uZnN2NC1wbmZzLWJsb2NrLTA0LnR4 dCANCgoKU3RhdHVzIG9mIHRoaXMgTWVtbyANCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJu ZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCAgICAgICANCiAgIGFueSBhcHBs aWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyAg ICAgICANCiAgIGF3YXJlIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBv ZiB3aGljaCBoZSBvciBzaGUgICAgICAgDQogICBiZWNvbWVzIGF3YXJlIHdpbGwgYmUgZGlzY2xv c2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mICAgICAgIA0KICAgQkNQIDc5LiAN CgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l dCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgDQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4gDQoKICAg SW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzIA0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgDQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSANCiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgDQoKICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQgDQoKICAgVGhl IGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3Nl ZCBhdCANCiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCANCgogICBUaGlz IEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIGluIFNlcHRlbWJlciAyMDA3LiANCgpBYnN0cmFj dCANCgogICBQYXJhbGxlbCBORlMgKHBORlMpIGV4dGVuZHMgTkZTdjQgdG8gYWxsb3cgY2xpZW50 cyB0byBkaXJlY3RseSBhY2Nlc3MgDQogICBmaWxlIGRhdGEgb24gdGhlIHN0b3JhZ2UgdXNlZCBi eSB0aGUgTkZTdjQgc2VydmVyLiAgVGhpcyBhYmlsaXR5IHRvIA0KICAgYnlwYXNzIHRoZSBzZXJ2 ZXIgZm9yIGRhdGEgYWNjZXNzIGNhbiBpbmNyZWFzZSBib3RoIHBlcmZvcm1hbmNlIGFuZCANCiAg IHBhcmFsbGVsaXNtLCBidXQgcmVxdWlyZXMgYWRkaXRpb25hbCBjbGllbnQgZnVuY3Rpb25hbGl0 eSBmb3IgZGF0YSANCiAgIGFjY2Vzcywgc29tZSBvZiB3aGljaCBpcyBkZXBlbmRlbnQgb24gdGhl IGNsYXNzIG9mIHN0b3JhZ2UgdXNlZC4gIFRoZSANCiAgIG1haW4gcE5GUyBvcGVyYXRpb25zIGRy YWZ0IHNwZWNpZmllcyBzdG9yYWdlLWNsYXNzLWluZGVwZW5kZW50IA0KICAgZXh0ZW5zaW9ucyB0 byBORlM7IHRoaXMgZHJhZnQgc3BlY2lmaWVzIHRoZSBhZGRpdGlvbmFsIGV4dGVuc2lvbnMgDQoK IA0KIA0KIA0KQmxhY2sgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIwMDggICAg ICAgICAgICAgICAgICAgW1BhZ2UgMV0gDQogDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAg ICBwTkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAg DQoKICAgKHByaW1hcmlseSBkYXRhIHN0cnVjdHVyZXMpIGZvciB1c2Ugb2YgcE5GUyB3aXRoIGJs b2NrIGFuZCB2b2x1bWUgDQogICBiYXNlZCBzdG9yYWdlLiANCgpDb252ZW50aW9ucyB1c2VkIGlu IHRoaXMgZG9jdW1lbnQgDQoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCANCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5P VCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICAgZG9j dW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMtMjExOSBbUkZD MjExOV0uIA0KClRhYmxlIG9mIENvbnRlbnRzIA0KCiAgIDEuIEludHJvZHVjdGlvbi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMyANCiAgIDIuIEJsb2NrIExheW91 dCBEZXNjcmlwdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzIA0KICAgICAg Mi4xLiBCYWNrZ3JvdW5kIGFuZCBBcmNoaXRlY3R1cmUgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LiAzIA0KICAgICAgMi4yLiBHRVRERVZJQ0VMSVNUIGFuZCBHRVRERVZJQ0VJTkZPLi4uLi4uLi4u Li4uLi4uLi4uLi4uLiA0IA0KICAgICAgICAgMi4yLjEuIFZvbHVtZSBJZGVudGlmaWNhdGlvbi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDQgDQogICAgICAgICAyLjIuMi4gVm9sdW1lIFRvcG9s b2d5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gNSANCiAgICAgICAgIDIuMi4zLiBH RVRERVZJQ0VMSVNUIGFuZCBHRVRERVZJQ0VJTkZPIGRldmljZWlkNC4uLi4uLi4uLiA4IA0KICAg ICAgMi4zLiBEYXRhIFN0cnVjdHVyZXM6IEV4dGVudHMgYW5kIEV4dGVudCBMaXN0cy4uLi4uLi4u Li4uLi4gOSANCiAgICAgICAgIDIuMy4xLiBMYXlvdXQgUmVxdWVzdHMgYW5kIEV4dGVudCBMaXN0 cy4uLi4uLi4uLi4uLi4uLi4uMTEgDQogICAgICAgICAyLjMuMi4gTGF5b3V0IENvbW1pdHMgLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICAgICAgIDIuMy4zLiBMYXlvdXQg UmV0dXJucyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEyIA0KICAgICAgICAgMi4z LjQuIENsaWVudCBDb3B5LW9uLVdyaXRlIFByb2Nlc3NpbmcuLi4uLi4uLi4uLi4uLi4uLi4xMyAN CiAgICAgICAgIDIuMy41LiBFeHRlbnRzIGFyZSBQZXJtaXNzaW9ucy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xNCANCiAgICAgICAgIDIuMy42LiBFbmQtb2YtZmlsZSBQcm9jZXNzaW5nIC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xNSANCiAgICAgICAgIDIuMy43LiBDbGllbnQgRmVuY2luZyAu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2IA0KICAgICAgMi40LiBDcmFzaCBSZWNv dmVyeSBJc3N1ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTggDQogICAgICAyLjUu IFJlY2FsbGluZyByZXNvdXJjZXM6IENCX1JFQ0FMTF9BTlkgLi4uLi4uLi4uLi4uLi4uLi4uLjE4 IA0KICAgICAgMi42LiBUcmFuc2llbnQgYW5kIFBlcm1hbmVudCBFcnJvcnMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjE5IA0KICAgMy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xOSANCiAgIDQuIENvbmNsdXNpb25zLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMSANCiAgIDUuIElBTkEgQ29uc2lkZXJhdGlv bnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjEgDQogICA2LiBSZXZpc2lv biBIaXN0b3J5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIxIA0KICAg Ny4gQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjIyIA0KICAgOC4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjIzIA0KICAgICAgOC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMjMgDQogICAgICA4LjIuIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMyANCiAgIEF1dGhvcidzIEFkZHJlc3Nl cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMyANCiAgIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI0IA0K ICAgRGlzY2xhaW1lciBvZiBWYWxpZGl0eS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4yNCANCiAgIENvcHlyaWdodCBTdGF0ZW1lbnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMjUgDQogICBBY2tub3dsZWRnbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjUgDQogICAgDQoKCgoKIA0KIA0KQmxhY2sgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICAgW1BhZ2Ug Ml0gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVt ZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgIA0KMS4gSW50cm9k dWN0aW9uIA0KCiAgIEZpZ3VyZSAxIHNob3dzIHRoZSBvdmVyYWxsIGFyY2hpdGVjdHVyZSBvZiBh IHBORlMgc3lzdGVtOiANCgogICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgfCstLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0rIA0KICAgICAgIHx8Ky0tLS0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCANCiAgICAgICB8fHwgICAgICAg ICAgIHwgICAgICAgIE5GU3Y0ICsgcE5GUyAgICAgICAgICAgIHwgICAgICAgICAgIHwgDQogICAg ICAgK3x8ICBDbGllbnRzICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgU2Vy dmVyICB8IA0KICAgICAgICArfCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgfCANCiAgICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgDQogICAgICAgICAgICAgIHx8fCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rIA0KICAgICAgICAg ICAgICB8fHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAg ICAgICAgICAgICAgfHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgDQogICAgICAgICAgICAgIHx8fCAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rICAgICAg ICAgICAgICB8IA0KICAgICAgICAgICAgICB8fHwgICAgICAgICAgICAgICAgfCstLS0tLS0tLS0t LSsgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgfHwrLS0tLS0tLS0tLS0tLS0tLXx8Ky0t LS0tLS0tLS0tKyAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgIHwrLS0tLS0tLS0tLS0tLS0t LS18fHwgICAgICAgICAgIHwgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tK3x8ICBTdG9yYWdlICB8LS0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArfCAgU3lzdGVtcyAgfCANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyANCiAgICANCiAgICAgICAgICAgICAgICAgICAgICAg IEZpZ3VyZSAxIHBORlMgQXJjaGl0ZWN0dXJlIA0KCiAgIFRoZSBvdmVyYWxsIGFwcHJvYWNoIGlz IHRoYXQgcE5GUy1lbmhhbmNlZCBjbGllbnRzIG9idGFpbiBzdWZmaWNpZW50IA0KICAgaW5mb3Jt YXRpb24gZnJvbSB0aGUgc2VydmVyIHRvIGVuYWJsZSB0aGVtIHRvIGFjY2VzcyB0aGUgdW5kZXJs eWluZyANCiAgIHN0b3JhZ2UgKG9uIHRoZSBTdG9yYWdlIFN5c3RlbXMpIGRpcmVjdGx5LiAgU2Vl IHRoZSBwTkZTIHBvcnRpb24gb2YgDQogICBbTkZTVjQuMV0gZm9yIG1vcmUgZGV0YWlscy4gIFRo aXMgZHJhZnQgaXMgY29uY2VybmVkIHdpdGggYWNjZXNzIGZyb20gDQogICBwTkZTIGNsaWVudHMg dG8gU3RvcmFnZSBTeXN0ZW1zIG92ZXIgc3RvcmFnZSBwcm90b2NvbHMgYmFzZWQgb24gDQogICBi bG9ja3MgYW5kIHZvbHVtZXMsIHN1Y2ggYXMgdGhlIFNDU0kgcHJvdG9jb2wgZmFtaWx5IChlLmcu LCBwYXJhbGxlbCANCiAgIFNDU0ksIEZDUCBmb3IgRmlicmUgQ2hhbm5lbCwgaVNDU0ksIFNBUyku ICBUaGlzIGNsYXNzIG9mIHN0b3JhZ2UgaXMgDQogICByZWZlcnJlZCB0byBhcyBibG9jay92b2x1 bWUgc3RvcmFnZS4gIFdoaWxlIHRoZSBTZXJ2ZXIgdG8gU3RvcmFnZSANCiAgIFN5c3RlbSBwcm90 b2NvbCBpcyBub3Qgb2YgY29uY2VybiBmb3IgaW50ZXJvcGVyYWJpbGl0eSBoZXJlLCBpdCB3aWxs IA0KICAgdHlwaWNhbGx5IGFsc28gYmUgYSBibG9jay92b2x1bWUgcHJvdG9jb2wgd2hlbiBjbGll bnRzIHVzZSBibG9jay8gDQogICB2b2x1bWUgcHJvdG9jb2xzLiANCgoyLiBCbG9jayBMYXlvdXQg RGVzY3JpcHRpb24gDQoKMi4xLiBCYWNrZ3JvdW5kIGFuZCBBcmNoaXRlY3R1cmUgDQoKICAgVGhl IGZ1bmRhbWVudGFsIHN0b3JhZ2UgYWJzdHJhY3Rpb24gc3VwcG9ydGVkIGJ5IGJsb2NrL3ZvbHVt ZSBzdG9yYWdlIA0KICAgaXMgYSBzdG9yYWdlIHZvbHVtZSBjb25zaXN0aW5nIG9mIGEgc2VxdWVu dGlhbCBzZXJpZXMgb2YgZml4ZWQgc2l6ZSANCiAgIGJsb2Nrcy4gIFRoaXMgY2FuIGJlIHRob3Vn aHQgb2YgYXMgYSBsb2dpY2FsIGRpc2s7IGl0IG1heSBiZSByZWFsaXplZCANCiAgIGJ5IHRoZSBT dG9yYWdlIFN5c3RlbSBhcyBhIHBoeXNpY2FsIGRpc2ssIGEgcG9ydGlvbiBvZiBhIHBoeXNpY2Fs IA0KICAgZGlzayBvciBzb21ldGhpbmcgbW9yZSBjb21wbGV4IChlLmcuLCBjb25jYXRlbmF0aW9u LCBzdHJpcGluZywgUkFJRCwgDQoKIA0KIA0KQmxhY2sgICAgICAgICAgICAgICAgICAgIEV4cGly ZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQogICAgDA0KCgoKCgoK SW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAg ICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgYW5kIGNvbWJpbmF0aW9ucyB0aGVyZW9mKSBpbnZv bHZpbmcgbXVsdGlwbGUgcGh5c2ljYWwgZGlza3Mgb3IgDQogICBwb3J0aW9ucyB0aGVyZW9mLiAN CgogICBBIHBORlMgbGF5b3V0IGZvciB0aGlzIGJsb2NrL3ZvbHVtZSBjbGFzcyBvZiBzdG9yYWdl IGlzIHJlc3BvbnNpYmxlIA0KICAgZm9yIG1hcHBpbmcgZnJvbSBhbiBORlMgZmlsZSAob3IgcG9y dGlvbiBvZiBhIGZpbGUpIHRvIHRoZSBibG9ja3Mgb2YgDQogICBzdG9yYWdlIHZvbHVtZXMgdGhh dCBjb250YWluIHRoZSBmaWxlLiAgVGhlIGJsb2NrcyBhcmUgZXhwcmVzc2VkIGFzIA0KICAgZXh0 ZW50cyB3aXRoIDY0IGJpdCBvZmZzZXRzIGFuZCBsZW5ndGhzIHVzaW5nIHRoZSBleGlzdGluZyBO RlN2NCANCiAgIG9mZnNldDQgYW5kIGxlbmd0aDQgdHlwZXMuICBDbGllbnRzIG11c3QgYmUgYWJs ZSB0byBwZXJmb3JtIEkvTyB0byANCiAgIHRoZSBibG9jayBleHRlbnRzIHdpdGhvdXQgYWZmZWN0 aW5nIGFkZGl0aW9uYWwgYXJlYXMgb2Ygc3RvcmFnZSANCiAgIChlc3BlY2lhbGx5IGltcG9ydGFu dCBmb3Igd3JpdGVzKSwgdGhlcmVmb3JlIGV4dGVudHMgTVVTVCBiZSBhbGlnbmVkIA0KICAgdG8g NTEyLW9jdGV0IGJvdW5kYXJpZXMsIGFuZCBTSE9VTEQgYmUgYWxpZ25lZCB0byB0aGUgYmxvY2sg c2l6ZSB1c2VkIA0KICAgYnkgdGhlIE5GU3Y0IHNlcnZlciBpbiBtYW5hZ2luZyB0aGUgYWN0dWFs IGZpbGVzeXN0ZW0gKDQga2lsb2J5dGVzIA0KICAgYW5kIDgga2lsb2J5dGVzIGFyZSBjb21tb24g YmxvY2sgc2l6ZXMpLiAgVGhpcyBibG9jayBzaXplIGlzIA0KICAgYXZhaWxhYmxlIGFzIHRoZSBO RlN2NC4xIGxheW91dF9ibGtzaXplIGF0dHJpYnV0ZS4gW05GU1Y0LjFdIA0KCiAgIFRoZSBwTkZT IG9wZXJhdGlvbiBmb3IgcmVxdWVzdGluZyBhIGxheW91dCAoTEFZT1VUR0VUKSBpbmNsdWRlcyB0 aGUgDQogICAibGF5b3V0aW9tb2RlNCBsb2dhX2lvbW9kZSIgYXJndW1lbnQgd2hpY2ggaW5kaWNh dGVzIHdoZXRoZXIgdGhlIA0KICAgcmVxdWVzdGVkIGxheW91dCBpcyBmb3IgcmVhZC1vbmx5IHVz ZSBvciByZWFkLXdyaXRlIHVzZS4gIEEgcmVhZC1vbmx5IA0KICAgbGF5b3V0IG1heSBjb250YWlu IGhvbGVzIHRoYXQgYXJlIHJlYWQgYXMgemVybywgd2hlcmVhcyBhIHJlYWQtd3JpdGUgDQogICBs YXlvdXQgd2lsbCBjb250YWluIGFsbG9jYXRlZCwgYnV0IHVuLWluaXRpYWxpemVkIHN0b3JhZ2Ug aW4gdGhvc2UgDQogICBob2xlcyAocmVhZCBhcyB6ZXJvLCBjYW4gYmUgd3JpdHRlbiBieSBjbGll bnQpLiAgVGhpcyBkcmFmdCBhbHNvIA0KICAgc3VwcG9ydHMgY2xpZW50IHBhcnRpY2lwYXRpb24g aW4gY29weSBvbiB3cml0ZSBieSBwcm92aWRpbmcgYm90aCANCiAgIHJlYWQtb25seSBhbmQgdW4t aW5pdGlhbGl6ZWQgc3RvcmFnZSBmb3IgdGhlIHNhbWUgcmFuZ2UgaW4gYSBsYXlvdXQuICANCiAg IFJlYWRzIGFyZSBpbml0aWFsbHkgcGVyZm9ybWVkIG9uIHRoZSByZWFkLW9ubHkgc3RvcmFnZSwg d2l0aCB3cml0ZXMgDQogICBnb2luZyB0byB0aGUgdW4taW5pdGlhbGl6ZWQgc3RvcmFnZS4gIEFm dGVyIHRoZSBmaXJzdCB3cml0ZSB0aGF0IA0KICAgaW5pdGlhbGl6ZXMgdGhlIHVuLWluaXRpYWxp emVkIHN0b3JhZ2UsIGFsbCByZWFkcyBhcmUgcGVyZm9ybWVkIHRvIA0KICAgdGhhdCBub3ctaW5p dGlhbGl6ZWQgd3JpdGVhYmxlIHN0b3JhZ2UsIGFuZCB0aGUgY29ycmVzcG9uZGluZyByZWFkLQ0K ICAgb25seSBzdG9yYWdlIGlzIG5vIGxvbmdlciB1c2VkLiANCgoyLjIuIEdFVERFVklDRUxJU1Qg YW5kIEdFVERFVklDRUlORk8gDQoKMi4yLjEuIFZvbHVtZSBJZGVudGlmaWNhdGlvbiANCgogICBT dG9yYWdlIFN5c3RlbXMgc3VjaCBhcyBzdG9yYWdlIGFycmF5cyBjYW4gaGF2ZSBtdWx0aXBsZSBw aHlzaWNhbCANCiAgIG5ldHdvcmsgcG9ydHMgdGhhdCBuZWVkIG5vdCBiZSBjb25uZWN0ZWQgdG8g YSBjb21tb24gbmV0d29yaywgDQogICByZXN1bHRpbmcgaW4gYSBwTkZTIGNsaWVudCBoYXZpbmcg c2ltdWx0YW5lb3VzIG11bHRpcGF0aCBhY2Nlc3MgdG8gDQogICB0aGUgc2FtZSBzdG9yYWdlIHZv bHVtZXMgdmlhIGRpZmZlcmVudCBwb3J0cyBvbiBkaWZmZXJlbnQgbmV0d29ya3MuICANCiAgIFRo ZSBuZXR3b3JrcyBtYXkgbm90IGV2ZW4gYmUgdGhlIHNhbWUgdGVjaG5vbG9neSAtIGZvciBleGFt cGxlLCANCiAgIGFjY2VzcyB0byB0aGUgc2FtZSB2b2x1bWUgdmlhIGJvdGggaVNDU0kgYW5kIEZp YnJlIENoYW5uZWwgaXMgDQogICBwb3NzaWJsZSwgaGVuY2UgbmV0d29yayBhZGRyZXNzIGFyZSBk aWZmaWN1bHQgdG8gdXNlIGZvciB2b2x1bWUgDQogICBpZGVudGlmaWNhdGlvbi4gIEZvciB0aGlz IHJlYXNvbiwgdGhpcyBwTkZTIGJsb2NrIGxheW91dCBpZGVudGlmaWVzIA0KICAgc3RvcmFnZSB2 b2x1bWVzIGJ5IGNvbnRlbnQsIGZvciBleGFtcGxlIHByb3ZpZGluZyB0aGUgbWVhbnMgdG8gbWF0 Y2ggDQogICAodW5pcXVlIHBvcnRpb25zIG9mKSBsYWJlbHMgdXNlZCBieSB2b2x1bWUgbWFuYWdl cnMuICBBbnkgYmxvY2sgcE5GUyANCiAgIHN5c3RlbSB1c2luZyB0aGlzIGxheW91dCBNVVNUIHN1 cHBvcnQgYSBtZWFucyBvZiBjb250ZW50LWJhc2VkIHVuaXF1ZSANCiAgIHZvbHVtZSBpZGVudGlm aWNhdGlvbiB0aGF0IGNhbiBiZSBlbXBsb3llZCB2aWEgdGhlIGRhdGEgc3RydWN0dXJlIA0KICAg Z2l2ZW4gaGVyZS4gDQoKIA0KIA0KQmxhY2sgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDIwMDcgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQogICAgDA0KCgoKCgoKSW50ZXJu ZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1h cmNoIDIwMDcgDQogICAgDQoKICAgc3RydWN0IHBuZnNfYmxvY2tfc2lnX2NvbXBvbmVudDQgeyAg LyogIGRpc2sgc2lnbmF0dXJlIGNvbXBvbmVudCAqLyANCgogICAgICBvZmZzZXQ0IHNpZ19vZmZz ZXQ7ICAgICAgICAvKiBvY3RldCBvZmZzZXQgb2YgY29tcG9uZW50IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgd2l0aGluIHNpZ25hdHVyZSBibG9jayAqLyANCgogICAgICBv cGFxdWUgIGNvbnRlbnRzPD47ICAgICAgICAvKiBjb250ZW50cyBvZiB0aGlzIGNvbXBvbmVudCBv ZiB0aGUgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaWduYXR1cmUgKHRo aXMgaXMgb3BhcXVlKSAqLyANCgogICB9OyANCgogICBOb3RlIHRoYXQgdGhlIG9wYXF1ZSAiY29u dGVudHMiIGZpZWxkIGluIHRoZSANCiAgICJwbmZzX2Jsb2NrX3NpZ19jb21wb25lbnQ0IiBzdHJ1 Y3R1cmUgTVVTVCBOT1QgYmUgaW50ZXJwcmV0ZWQgYXMgYSANCiAgIHplcm8tdGVybWluYXRlZCBz dHJpbmcsIGFzIGl0IG1heSBjb250YWluIGVtYmVkZGVkIHplcm8tdmFsdWVkIA0KICAgb2N0ZXRz LiAgVGhlcmUgYXJlIG5vIHJlc3RyaWN0aW9ucyBvbiBhbGlnbm1lbnQgKGUuZy4sIG5laXRoZXIg DQogICBzaWdfb2Zmc2V0IG5vciB0aGUgbGVuZ3RoIGFyZSByZXF1aXJlZCB0byBiZSBtdWx0aXBs ZXMgb2YgNCkuICBUaGUgDQogICBzaWdfb2Zmc2V0IHJlcHJlc2VudHMgYW4gb2Zmc2V0IGZyb20g dGhlIHN0YXJ0IG9mIGEgc2lnbmF0dXJlIGJsb2NrIA0KICAgKGRlZmluZWQgYmVsb3cpLiANCgog ICBUaGUgcE5GUyBjbGllbnQgYmxvY2sgbGF5b3V0IGRyaXZlciB1c2VzIHRoaXMgdm9sdW1lIGlk ZW50aWZpY2F0aW9uIA0KICAgdG8gbWFwIHBuZnNfYmxvY2tfdm9sdW1lX3R5cGU0IFZPTFVNRV9T SU1QTEUgZGV2aWNlaWQ0cyB0byBpdHMgbG9jYWwgDQogICB2aWV3IG9mIGEgTFVOLiANCgoyLjIu Mi4gVm9sdW1lIFRvcG9sb2d5IA0KCiAgIFRoZSBwTkZTIGJsb2NrIHNlcnZlciB2b2x1bWUgdG9w b2xvZ3kgaXMgZXhwcmVzc2VkIGFzIGFuIGFyYml0cmFyeSANCiAgIGNvbWJpbmF0aW9uIG9mIGJh c2Ugdm9sdW1lIHR5cGVzIGVudW1lcmF0ZWQgaW4gdGhlIGZvbGxvd2luZyBkYXRhIA0KICAgc3Ry dWN0dXJlcy4gDQoKICAgZW51bSBwbmZzX2Jsb2NrX3ZvbHVtZV90eXBlNCB7IA0KCiAgICAgIFZP TFVNRV9TSU1QTEUgPSAwLCAgICAgIC8qIHZvbHVtZSBtYXBzIHRvIGEgc2luZ2xlIExVICovIA0K CiAgICAgIFZPTFVNRV9TTElDRSAgPSAxLCAgICAgIC8qIHZvbHVtZSBpcyBhIHNsaWNlIG9mIGFu b3RoZXIgdm9sdW1lICovIA0KCiAgICAgIFZPTFVNRV9DT05DQVQgPSAyLCAgICAgIC8qIHZvbHVt ZSBpcyBhIGNvbmNhdGVuYXRpb24gb2YgbXVsdGlwbGUgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB2b2x1bWVzICovIA0KCiAgICAgIFZPTFVNRV9TVFJJUEUgPSAzICAgICAgIC8q IHZvbHVtZSBpcyBzdHJpcGVkIGFjcm9zcyBtdWx0aXBsZSANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHZvbHVtZXMgKi8gDQoKICAgfTsgDQoKICAgc3RydWN0IHBuZnNfYmxvY2tf c2ltcGxlX3ZvbHVtZV9pbmZvNCB7IA0KCiAgICAgIGRldmljZWlkNCAgICAgICAgIHZvbF9pZDsg ICAgIC8qIHRoaXMgdm9sdW1lIGlkICovIA0KCiAgICAgIGludDY0X3QgICAgICAgICAgIHNpZ19v ZmZzZXQ7ICAgIC8qIG9mZnNldCBpbiA1MTIgb2N0ZXQgYmxvY2tzICANCiANCiANCkJsYWNrICAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgIFtQ YWdlIDVdIA0KICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9W b2x1bWUgTGF5b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZyb20gc3RhcnQgb2Ygdm9sdW1lIGlmIHBvc2l0 aXZlIA0KCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZyb20gZW5kIG9m IHZvbHVtZSBpZiBuZWdhdGl2ZSANCgogICAgICBwbmZzX2Jsb2NrX3NpZ19jb21wb25lbnQ0ICBk czxNQVhfU0lHX0NPTVA+OyAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAvKiBkaXNrIHNpZ25hdHVyZSAqLyANCgogICB9OyAN CgogICAgDQoKICAgc3RydWN0IHBuZnNfYmxvY2tfc2xpY2Vfdm9sdW1lX2luZm80IHsgDQoKICAg ICAgZGV2aWNlaWQ0ICAgICAgICB2b2xfaWQ7ICAvKiB0aGlzIHZvbHVtZSBpZCAqLyANCgogICAg ICBvZmZzZXQ0ICAgICAgICAgIHN0YXJ0OyAgIC8qIG9mZnNldCBvZiB0aGUgc3RhcnQgb2YgdGhl IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2xpY2UgaW4gNTEyIG9jdGV0 IGJsb2NrcyAqLyANCgogICAgICBsZW5ndGg0ICAgICAgICAgIGxlbmd0aDsgIC8qIGxlbmd0aCBv ZiBzbGljZSBpbiA1MTIgb2N0ZXQgYmxvY2tzIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKi8gDQoKICAgICAgZGV2aWNlaWQ0ICAgICAgICB2b2x1bWU7ICAvKiB2b2x1bWUg d2hpY2ggaXMgc2xpY2VkICovIA0KCiAgIH07IA0KCiAgICANCgogICBzdHJ1Y3QgcG5mc19ibG9j a19jb25jYXRfdm9sdW1lX2luZm80IHsgDQoKICAgICAgZGV2aWNlaWQ0ICAgICAgICAgdm9sX2lk OyAgICAgLyogdGhpcyB2b2x1bWUgaWQgKi8gDQoKICAgICAgZGV2aWNlaWQ0ICAgICAgICAgdm9s dW1lczw+OyAgLyogdm9sdW1lcyB3aGljaCBhcmUgY29uY2F0ZW5hdGVkICovIA0KCiAgIH07IA0K CiAgICANCgogICBzdHJ1Y3QgcG5mc19ibG9ja19zdHJpcGVfdm9sdW1lX2luZm80IHsgDQoKICAg ICAgZGV2aWNlaWQ0ICAgICAgICAgdm9sX2lkOyAgICAgICAgLyogdGhpcyB2b2x1bWUgaWQgKi8g DQoKICAgICAgbGVuZ3RoNCAgICAgICAgICAgc3RyaXBlX3VuaXQ7ICAgLyogc2l6ZSBvZiBzdHJp cGUgaW4gNTEyIG9jdGVjdCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYmxvY2tzICovIA0KCiAgICAgIGRldmljZWlkNCAgICAgICAgIHZvbHVtZXM8PjsgICAgIC8q IHZvbHVtZXMgd2hpY2ggYXJlIHN0cmlwZWQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFjcm9zcyAtLSBNVVNUIGJlIHNhbWUgc2l6ZSAqLyANCgogDQogDQpCbGFj ayAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAg ICBbUGFnZSA2XSANCiAgICAMDQoKCgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxv Y2svVm9sdW1lIExheW91dCAgICAgICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICB9OyAN CgogICAgDQoKICAgdW5pb24gcG5mc19ibG9ja192b2x1bWU0IHN3aXRjaCAocG5mc19ibG9ja192 b2x1bWVfdHlwZTQgdHlwZSkgeyANCgogICAgICAgICBjYXNlIFZPTFVNRV9TSU1QTEU6IA0KCiAg ICAgICAgICAgICAgIHBuZnNfYmxvY2tfc2ltcGxlX3ZvbHVtZV9pbmZvNCBzaW1wbGVfaW5mbzsg DQoKICAgICAgICAgY2FzZSBWT0xVTUVfU0xJQ0U6IA0KCiAgICAgICAgICAgICAgIHBuZnNfYmxv Y2tfc2xpY2Vfdm9sdW1lX2luZm80IHNsaWNlX2luZm87IA0KCiAgICAgICAgIGNhc2UgVk9MVU1F X0NPTkNBVDogDQoKICAgICAgICAgICAgICAgcG5mc19ibG9ja19jb25jYXRfdm9sdW1lX2luZm80 IGNvbmNhdF9pbmZvOyANCgogICAgICAgICBjYXNlIFZPTFVNRV9TVFJJUEU6IA0KCiAgICAgICAg ICAgICAgIHBuZnNfYmxvY2tfc3RyaXBlX3ZvbHVtZV9pbmZvNCBzdHJpcGVfaW5mbzsgDQoKICAg fTsgDQoKICAgIA0KCiAgIHN0cnVjdCBwbmZzX2Jsb2NrX2RldmljZWFkZHI0IHsgDQoKICAgICAg cG5mc19ibG9ja192b2x1bWU0ICAgdm9sdW1lczw+OyAgLyogYXJyYXkgb2Ygdm9sdW1lcyAqLyAN CgogICB9OyANCgogICAgDQoKICAgVGhlICJwbmZzX2Jsb2NrX2RldmljZWFkZHI0IiBkYXRhIHN0 cnVjdHVyZSBpcyBhIHN0cnVjdHVyZSB0aGF0IA0KICAgYWxsb3dzIGFyYml0cmFyaWx5IGNvbXBs ZXggbmVzdGVkIHZvbHVtZSBzdHJ1Y3R1cmVzIHRvIGJlIGVuY29kZWQuICANCiAgIFRoZSB0eXBl cyBvZiBhZ2dyZWdhdGlvbnMgdGhhdCBhcmUgYWxsb3dlZCBhcmUgc3RyaXBlcywgDQogICBjb25j YXRlbmF0aW9ucywgYW5kIHNsaWNlcy4gTm90ZSB0aGF0IHRoZSB2b2x1bWUgdG9wb2xvZ3kgZXhw cmVzc2VkIA0KICAgaW4gdGhlIHBuZnNfYmxvY2tfZGV2aWNlYWRkcjQgZGF0YSBzdHJ1Y3R1cmUg d2lsbCBhbHdheXMgcmVzb2x2ZSB0byBhIA0KICAgc2V0IG9mIHBuZnNfYmxvY2tfdm9sdW1lX3R5 cGU0IFZPTFVNRV9TSU1QTEUuICBUaGUgYXJyYXkgb2Ygdm9sdW1lcyANCiAgIGlzIG9yZGVyZWQg c3VjaCB0aGF0IHRoZSByb290IHZvbHVtZSBpcyB0aGUgbGFzdCBlbGVtZW50IG9mIHRoZSANCiAg IGFycmF5LiAgQ29uY2F0LCBzbGljZSBhbmQgc3RyaXBlIHZvbHVtZXMgTVVTVCByZWZlciB0byB2 b2x1bWVzIA0KICAgZGVmaW5lZCBieSBsb3dlciBpbmRleGVkIGVsZW1lbnRzIG9mIHRoZSBhcnJh eS4gDQoKICAgVGhlICJwbmZzX2Jsb2NrX2RldmljZV9hZGRyNCIgZGF0YSBzdHJ1Y3R1cmUgaXMg cmV0dXJuZWQgYnkgdGhlIA0KICAgc2VydmVyIGFzIHRoZSBzdG9yYWdlLXByb3RvY29sLXNwZWNp ZmljIG9wYXF1ZSBmaWVsZCBkYV9hZGRyX2JvZHkgaW4gDQogICB0aGUgImRldmljZV9hZGRyNCIg c3RydWN0dXJlIGJ5IHN1Y2Nlc3NmdWwgR0VUREVWSUNFTElTVCBhbmQgDQogDQogDQpCbGFjayAg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgICBb UGFnZSA3XSANCiAgICAMDQoKCgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2sv Vm9sdW1lIExheW91dCAgICAgICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICBHRVRERVZJ Q0VJTkZPIG9wZXJhdGlvbnMuIFtORlNWNC4xXS4gIFR5cGljYWxseSB0aGUgc2VydmVyIGluIA0K ICAgcmVzcG9uc2UgdG8gYSBHRVRERVZJQ0VMSVNUIHJlcXVlc3Qgd2lsbCByZXR1cm4gYSBzaW5n bGUgDQogICAiZGV2bGlzdF9pdGVtNCIgaW4gdGhlIGdkbHJfZGV2aW5mb19saXN0IGFycmF5LiAg VGhpcyBpcyBiZWNhdXNlIHRoZSANCiAgICJvcGFxdWUgZGFfYWRkcl9ib2R5IiBmaWVsZCBpbnNp ZGUgdGhlICJkZXZpY2VfYWRkcjQiIGVuY29kZXMgdGhlIA0KICAgZW50aXJlIHZvbHVtZSBoaWVy YXJjaHkuICBJbiB0aGUgY2FzZSBvZiBjb3B5LW9uLXdyaXRlIGZpbGUgc3lzdGVtcywgDQogICB0 aGUgImdkbHJfZGV2aW5mb19saXN0IiBhcnJheSB3aWxsIGNvbnRhaW4gdHdvIGRldmljZXNfaXRl bTRzLCBvbmUgDQogICBkZXNjcmliaW5nIHRoZSByZWFkLW9ubHkgdm9sdW1lIGhpZXJhcmNoeSwg YW5kIG9uZSBkZXNjcmliaW5nIHRoZSANCiAgIHdyaXRhYmxlIHZvbHVtZSBoaWVyYXJjaHkuIA0K CiAgIEFzIG5vdGVkIGFib3ZlLCBhbGwgZGV2aWNlX2FkZHI0IHN0cnVjdHVyZXMgZXZlbnR1YWxs eSByZXNvbHZlIHRvIGEgDQogICBzZXQgb2Ygdm9sdW1lcyBvZiB0eXBlICJwbmZzX2Jsb2NrX3Zv bHVtZV90eXBlNCBWT0xVTUVfU0lNUExFIiAgVGhlc2UgDQogICB2b2x1bWVzIGFyZSBlYWNoIHVu aXF1ZWx5IGlkZW50aWZpZWQgYnkgYSBzZXQgb2Ygc2lnbmF0dXJlIGNvbXBvbmVudHMgDQogICBs b2NhdGVkIHdpdGhpbiByZXNwZWN0aXZlIHNpZ25hdHVyZSBibG9ja3MuICBFYWNoIFZPTFVNRV9T SU1QTEUgDQogICB2b2x1bWUgc3BlY2lmaWVzIHRoZSBsb2NhdGlvbiBvZiBpdHMgc2lnbmF0dXJl IGJsb2NrIGluIHRlcm1zIG9mIDUxMiANCiAgIG9jdGV0IGJsb2Nrcy4gIFRoZSAiaW50NjRfdCBz aWdfb2Zmc2V0IiBpcyBhIHNpZ25lZCBxdWFudGl0eSB3aGljaCANCiAgIHdoZW4gcG9zaXRpdmUg cmVwcmVzZW50cyBhbiBvZmZzZXQgZnJvbSB0aGUgc3RhcnQgb2YgdGhlIHZvbHVtZSwgYW5kIA0K ICAgd2hlbiBuZWdhdGl2ZSByZXByZXNlbnRzIGFuIG9mZnNldCBmcm9tIHRoZSBlbmQgb2YgdGhl IHZvbHVtZS4gDQoKICAgTmVnYXRpdmUgb2Zmc2V0cyBhcmUgcGVybWl0dGVkIGluIG9yZGVyIHRv IHNpbXBsaWZ5IHRoZSBjbGllbnQgDQogICBpbXBsZW1lbnRhdGlvbiBvbiBzeXN0ZW1zIHdoZXJl IHRoZSBkZXZpY2UgbGFiZWwgaXMgZm91bmQgYXQgYSBmaXhlZCANCiAgIG9mZnNldCBmcm9tIHRo ZSBlbmQgb2YgdGhlIHZvbHVtZS4gSWYgdGhlIHNlcnZlciB1c2VzIG5lZ2F0aXZlIA0KICAgb2Zm c2V0cyB0byBkZXNjcmliZSB0aGUgc2lnbmF0dXJlLCB0aGVuIHRoZSBjbGllbnQgYW5kIHNlcnZl ciBNVVNUIA0KICAgTk9UIHNlZSBkaWZmZXJlbnQgdm9sdW1lIHNpemVzLiAgTmVnYXRpdmUgb2Zm c2V0cyBTSE9VTEQgTk9UIGJlIHVzZWQgDQogICBpbiBzeXN0ZW1zIHRoYXQgZHluYW1pY2FsbHkg cmVzaXplIHZvbHVtZXMgdW5sZXNzIGNhcmUgaXMgdGFrZW4gdG8gDQogICBlbnN1cmUgdGhhdCB0 aGUgZGV2aWNlIGxhYmVsIGlzIGFsd2F5cyBwcmVzZW50IGF0IHRoZSBvZmZzZXQgZnJvbSB0aGUg DQogICBlbmQgb2YgdGhlIHZvbHVtZSBhcyBzZWVuIGJ5IHRoZSBjbGllbnRzLiANCgoyLjIuMy4g R0VUREVWSUNFTElTVCBhbmQgR0VUREVWSUNFSU5GTyBkZXZpY2VpZDQgDQoKICAgVGhlICJkZXZp Y2VpZDQgZGxpX2lkIiByZXR1cm5lZCBpbiB0aGUgZGV2bGlzdF9pdGVtNCBvZiBhIHN1Y2Nlc3Nm dWwgDQogICBHRVRERVZJQ0VMSVNUIG9wZXJhdGlvbiBpcyBhIHNob3J0aGFuZCBpZCB1c2VkIHRv IHJlZmVyZW5jZSB0aGUgd2hvbGUgDQogICB2b2x1bWUgdG9wb2xvZ3kuIERlY29kaW5nIHRoZSAi cG5mc19ibG9ja19kZXZpY2VhZGRyNCIgcmVzdWx0cyBpbiBhIA0KICAgZmxhdCBvcmRlcmluZyBv ZiA1MTIgb2N0ZXQgZGF0YSBibG9ja3MgbWFwcGVkIHRvIFZPTFVNRV9TSU1QTEUgDQogICBkZXZp Y2VpZDRzLiBDb21iaW5lZCB3aXRoIHRoZSBkZXZpY2VpZDQgbWFwcGluZyB0byBhIGNsaWVudCBM VU4gDQogICBkZXNjcmliZWQgaW4gMi4yLjEgVm9sdW1lIElkZW50aWZpY2F0aW9uLCBhIGxvZ2lj YWwgdm9sdW1lIG9mZnNldCAgDQogICBjYW4gYmUgbWFwcGVkIHRvIGEgNTEyIGJsb2NrIG9uIGEg cE5GUyBjbGllbnQgTFVOLiBbTkZTVjQuMV0gIFdpdGggDQogICB0aGUgZXhjZXB0aW9uIG9mIHRo ZSByb290IHZvbHVtZSBpZCwgdGhlIGRldmljZSBpZHMgcmV0dXJuZWQgaW4gdGhlIA0KICAgdm9s dW1lcyBhcnJheSBvZiBhIHBuZnNfYmxvY2tfZGV2aWNlYWRkcjQgZGF0YSBzdHJ1Y3R1cmUgc2hv dWxkIG5vdCANCiAgIGJlIHBhc3NlZCBhcyBhcmd1bWVudHMgaW4gYSBHRVRERVZJQ0VJTkZPIHJl cXVlc3QuICBUaGVzZSBub24tcm9vdCANCiAgIHZvbHVtZSBkZXZpY2UgaWRzIGFyZSBuZXZlciBy ZXR1cm5lZCBieSBMQVlPVVRHRVQgaW4gdGhlIA0KICAgInBuZnNfYmxvY2tfbGF5b3V0NCB2b2xf aWQiIGZpZWxkLiAgSWYgYSBub24tcm9vdCBkZXZpY2UgaWQgaXMgcGFzc2VkIA0KICAgYXMgYW4g YXJndW1lbnQgaW4gYSBHRVRERVZJQ0VJTkZPIHJlcXVlc3QsIHRoZSBzZXJ2ZXIgU0hPVUxEIHJl dHVybiANCiAgIE5GUzRFUlJfSU5WQUwuIA0KCgoKCiANCiANCkJsYWNrICAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdIA0KICAg IAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0 ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCjIuMy4gRGF0YSBTdHJ1Y3R1cmVzOiBF eHRlbnRzIGFuZCBFeHRlbnQgTGlzdHMgDQoKICAgQSBwTkZTIGJsb2NrIGxheW91dCBpcyBhIGxp c3Qgb2YgZXh0ZW50cyB3aXRoaW4gYSBmbGF0IGFycmF5IG9mIDUxMi0NCiAgIG9jdGV0IGRhdGEg YmxvY2tzIGluIGEgbG9naWNhbCB2b2x1bWUuICBUaGUgZGV0YWlscyBvZiB0aGUgdm9sdW1lIA0K ICAgdG9wb2xvZ3kgY2FuIGJlIGRldGVybWluZWQgYnkgdXNpbmcgdGhlIEdFVERFVklDRUlORk8g b3IgDQogICBHRVRERVZJQ0VMSVNUIG9wZXJhdGlvbiAoc2VlIGRpc2N1c3Npb24gb2Ygdm9sdW1l IGlkZW50aWZpY2F0aW9uLCANCiAgIHNlY3Rpb24gMi4yIGFib3ZlKS4gIFRoZSBibG9jayBsYXlv dXQgZGVzY3JpYmVzIHRoZSBpbmRpdmlkdWFsIGJsb2NrIA0KICAgZXh0ZW50cyBvbiB0aGUgdm9s dW1lIHRoYXQgbWFrZSB1cCB0aGUgZmlsZS4gIFRoZSBvZmZzZXRzIGFuZCBsZW5ndGggDQogICBj b250YWluZWQgaW4gYW4gZXh0ZW50IGFyZSBzcGVjaWZpZWQgaW4gdW5pdHMgb2Ygb2N0ZXRzLiAN CgogICBlbnVtIHBuZnNfYmxvY2tfZXh0ZW50X3N0YXRlNCB7IA0KCiAgICAgUkVBRF9XUklURV9E QVRBICA9IDAsIC8qIHRoZSBkYXRhIGxvY2F0ZWQgYnkgdGhpcyBleHRlbnQgaXMgdmFsaWQgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgcmVhZGluZyBhbmQgd3JpdGluZy4gKi8g DQoKICAgICBSRUFEX0RBVEEgPSAxLCAgICAgICAgLyogdGhlIGRhdGEgbG9jYXRlZCBieSB0aGlz IGV4dGVudCBpcyB2YWxpZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciByZWFk aW5nIG9ubHk7IGl0IG1heSBub3QgYmUgd3JpdHRlbi4gDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAqLyANCgogICAgIElOVkFMSURfREFUQSA9IDIsICAgICAvKiB0aGUgbG9jYXRpb24g aXMgdmFsaWQ7IHRoZSBkYXRhIGlzIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW52 YWxpZC4gSXQgaXMgYSBuZXdseSAocHJlLSkgYWxsb2NhdGVkIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgZXh0ZW50LiBUaGVyZSBpcyBwaHlzaWNhbCBzcGFjZSBvbiB0aGUgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB2b2x1bWUuICovIA0KCiAgICAgTk9ORV9EQVRBID0g MyAgICAgICAgIC8qIHRoZSBsb2NhdGlvbiBpcyBpbnZhbGlkLiBJdCBpcyBhIGhvbGUgaW4gDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZmlsZS4gVGhlcmUgaXMgbm8gcGh5c2lj YWwgc3BhY2Ugb24gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdm9sdW1lLiAq LyANCgogICB9OyANCgogICBzdHJ1Y3QgcG5mc19ibG9ja19leHRlbnQ0IHsgDQoKICAgICBvZmZz ZXQ0ICAgICAgICAgZmlsZV9vZmZzZXQ7ICAgICAvKiB0aGUgc3RhcnRpbmcgb2N0ZXQgb2Zmc2V0 IGluIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZmlsZSAq LyANCgogICAgIGxlbmd0aDQgICAgICAgICBleHRlbnRfbGVuZ3RoOyAgIC8qIHRoZSBzaXplIGlu IG9jdGV0cyBvZiB0aGUgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGV4dGVudCAqLyANCgogICAgIG9mZnNldDQgICAgICAgICBzdG9yYWdlX29mZnNldDsgIC8qIHRo ZSBzdGFydGluZyBvY3RldCBvZmZzZXQgaW4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRoZSB2b2x1bWUgKi8gDQoKICAgICBwbmZzX2Jsb2NrX2V4dGVudF9zdGF0 ZTQgZXM7ICAgICAvKiB0aGUgc3RhdGUgb2YgdGhpcyBleHRlbnQgKi8gDQoKICAgfTsgDQoKICAg IA0KCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAg ICAgICAgICAgICAgICAgIFtQYWdlIDldIA0KICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAg ICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0K ICAgIA0KCiAgIHN0cnVjdCBwbmZzX2Jsb2NrX2xheW91dDQgeyANCgogICAgICBkZXZpY2VpZDQg ICAgICAgICAgdm9sX2lkOyAgICAgICAvKiBpZCBvZiBsb2dpY2FsIHZvbHVtZSBvbiB3aGljaCAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmlsZSBpcyBzdG9yZWQu ICovIA0KCiAgICAgIHBuZnNfYmxvY2tfZXh0ZW50NCBleHRlbnRzPD47ICAgIC8qIGV4dGVudHMg d2hpY2ggbWFrZSB1cCB0aGlzIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBsYXlvdXQuICovIA0KCiAgIH07IA0KCiAgIFRoZSBibG9jayBsYXlvdXQgY29uc2lzdHMg b2YgYSBkZXZpY2VpZDQsIHNob3J0aGFuZCBmb3IgdGhlIHdob2xlIA0KICAgdG9wb2xvZ3kgb2Yg dGhlIGxvZ2ljYWwgdm9sdW1lIG9uIHdoaWNoIHRoZSBmaWxlIGlzIHN0b3JlZCwgZm9sbG93ZWQg DQogICBieSBhIGxpc3Qgb2YgZXh0ZW50cyB3aGljaCBtYXAgdGhlIGxvZ2ljYWwgcmVnaW9ucyBv ZiB0aGUgZmlsZSB0byANCiAgIHBoeXNpY2FsIGxvY2F0aW9ucyBvbiB0aGUgdm9sdW1lLiAgVGhl ICJzdG9yYWdlIG9mZnNldCIgZmllbGQgd2l0aGluIA0KICAgZWFjaCBleHRlbnQgaWRlbnRpZmll cyBhIGxvY2F0aW9uIG9uIHRoZSBsb2dpY2FsIHZvbHVtZSBkZXNjcmliZWQgYnkgDQogICB0aGUg InZvbHVtZSIgZmllbGQgaW4gdGhlIGxheW91dC4gIFRoZSBjbGllbnQgaXMgcmVzcG9uc2libGUg Zm9yIA0KICAgdHJhbnNsYXRpbmcgdGhpcyBsb2dpY2FsIG9mZnNldCBpbnRvIGFuIG9mZnNldCBv biB0aGUgYXBwcm9wcmlhdGUgDQogICB1bmRlcmx5aW5nIFNBTiBsb2dpY2FsIHVuaXQuICAgIA0K CiAgIEVhY2ggZXh0ZW50IG1hcHMgYSBsb2dpY2FsIHJlZ2lvbiBvZiB0aGUgZmlsZSBvbnRvIGEg cG9ydGlvbiBvZiB0aGUgDQogICBzcGVjaWZpZWQgbG9naWNhbCB2b2x1bWUuICBUaGUgZmlsZV9v ZmZzZXQsIGV4dGVudF9sZW5ndGgsIGFuZCBlcyANCiAgIGZpZWxkcyBmb3IgYW4gZXh0ZW50IHJl dHVybmVkIGZyb20gdGhlIHNlcnZlciBhcmUgYWx3YXlzIHZhbGlkLiBUaGUgDQogICBpbnRlcnBy ZXRhdGlvbiBvZiB0aGUgc3RvcmFnZV9vZmZzZXQgZmllbGQgZGVwZW5kcyBvbiB0aGUgdmFsdWUg b2YgZXMgDQogICBhcyBmb2xsb3dzIChpbiBpbmNyZWFzaW5nIG9yZGVyKTogIA0KCiAgIG8gIFJF QURfV1JJVEVfREFUQSBtZWFucyB0aGF0IHN0b3JhZ2Vfb2Zmc2V0IGlzIHZhbGlkLCBhbmQgcG9p bnRzIHRvIA0KICAgICAgdmFsaWQvaW5pdGlhbGl6ZWQgZGF0YSB0aGF0IGNhbiBiZSByZWFkIGFu ZCB3cml0dGVuLiANCgogICBvICBSRUFEX0RBVEEgbWVhbnMgdGhhdCBzdG9yYWdlX29mZnNldCBp cyB2YWxpZCBhbmQgcG9pbnRzIHRvIHZhbGlkLyANCiAgICAgIGluaXRpYWxpemVkIGRhdGEgd2hp Y2ggY2FuIG9ubHkgYmUgcmVhZC4gIFdyaXRlIG9wZXJhdGlvbnMgYXJlIA0KICAgICAgcHJvaGli aXRlZDsgdGhlIGNsaWVudCBtYXkgbmVlZCB0byByZXF1ZXN0IGEgcmVhZC13cml0ZSBsYXlvdXQu IA0KCiAgIG8gIElOVkFMSURfREFUQSBtZWFucyB0aGF0IHN0b3JhZ2Vfb2Zmc2V0IGlzIHZhbGlk LCBidXQgcG9pbnRzIHRvIA0KICAgICAgaW52YWxpZCB1bi1pbml0aWFsaXplZCBkYXRhLiBUaGlz IGRhdGEgbXVzdCBub3QgYmUgcGh5c2ljYWxseSByZWFkIA0KICAgICAgZnJvbSB0aGUgZGlzayB1 bnRpbCBpdCBoYXMgYmVlbiBpbml0aWFsaXplZC4gIEEgcmVhZCByZXF1ZXN0IGZvciANCiAgICAg IGFuIElOVkFMSURfREFUQSBleHRlbnQgbXVzdCBmaWxsIHRoZSB1c2VyIGJ1ZmZlciB3aXRoIHpl cm9zLiBXcml0ZSANCiAgICAgIHJlcXVlc3RzIG11c3Qgd3JpdGUgd2hvbGUgc2VydmVyLXNpemVk IGJsb2NrcyB0byB0aGUgZGlzazsgb2N0ZXRzIA0KICAgICAgbm90IGluaXRpYWxpemVkIGJ5IHRo ZSB1c2VyIG11c3QgYmUgc2V0IHRvIHplcm8uICBBbnkgd3JpdGUgdG8gDQogICAgICBzdG9yYWdl IGluIGFuIElOVkFMSURfREFUQSBleHRlbnQgY2hhbmdlcyB0aGUgd3JpdHRlbiBwb3J0aW9uIG9m IA0KICAgICAgdGhlIGV4dGVudCB0byBSRUFEX1dSSVRFX0RBVEE7IHRoZSBwTkZTIGNsaWVudCBp cyByZXNwb25zaWJsZSBmb3IgDQogICAgICByZXBvcnRpbmcgdGhpcyBjaGFuZ2UgdmlhIExBWU9V VENPTU1JVC4gDQoKICAgbyAgTk9ORV9EQVRBIG1lYW5zIHRoYXQgc3RvcmFnZV9vZmZzZXQgaXMg bm90IHZhbGlkLCBhbmQgdGhpcyBleHRlbnQgDQogICAgICBtYXkgbm90IGJlIHVzZWQgdG8gc2F0 aXNmeSB3cml0ZSByZXF1ZXN0cy4gUmVhZCByZXF1ZXN0cyBtYXkgYmUgDQogICAgICBzYXRpc2Zp ZWQgYnkgemVyby1maWxsaW5nIGFzIGZvciBJTlZBTElEX0RBVEEuIE5PTkVfREFUQSBleHRlbnRz IA0KICAgICAgbWF5IGJlIHJldHVybmVkIGJ5IHJlcXVlc3RzIGZvciByZWFkYWJsZSBleHRlbnRz OyB0aGV5IGFyZSBuZXZlciANCiAgICAgIHJldHVybmVkIGlmIHRoZSByZXF1ZXN0IHdhcyBmb3Ig YSB3cml0ZWFibGUgZXh0ZW50LiANCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdIA0KICAgIAwNCgoKCgoK CkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0ICAgICAgICAg ICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIEFuIGV4dGVudCBsaXN0IGxpc3RzIGFsbCByZWxl dmFudCBleHRlbnRzIGluIGluY3JlYXNpbmcgb3JkZXIgb2YgdGhlIA0KICAgZmlsZV9vZmZzZXQg b2YgZWFjaCBleHRlbnQ7IGFueSB0aWVzIGFyZSBicm9rZW4gYnkgaW5jcmVhc2luZyBvcmRlciAN CiAgIG9mIHRoZSBleHRlbnQgc3RhdGUgKGVzKS4gDQoKMi4zLjEuIExheW91dCBSZXF1ZXN0cyBh bmQgRXh0ZW50IExpc3RzIA0KCiAgIEVhY2ggcmVxdWVzdCBmb3IgYSBsYXlvdXQgc3BlY2lmaWVz IGF0IGxlYXN0IHRocmVlIHBhcmFtZXRlcnM6IGZpbGUgDQogICBvZmZzZXQsIGRlc2lyZWQgc2l6 ZSwgYW5kIG1pbmltdW0gc2l6ZS4gIElmIHRoZSBzdGF0dXMgb2YgYSByZXF1ZXN0IA0KICAgaW5k aWNhdGVzIHN1Y2Nlc3MsIHRoZSBleHRlbnQgbGlzdCByZXR1cm5lZCBtdXN0IG1lZXQgdGhlIGZv bGxvd2luZyANCiAgIGNyaXRlcmlhOiAgDQoKICAgbyAgQSByZXF1ZXN0IGZvciBhIHJlYWRhYmxl IChidXQgbm90IHdyaXRlYWJsZSkgbGF5b3V0IHJldHVybnMgb25seSANCiAgICAgIFJFQURfREFU QSBvciBOT05FX0RBVEEgZXh0ZW50cyAoYnV0IG5vdCBJTlZBTElEX0RBVEEgb3IgDQogICAgICBS RUFEX1dSSVRFX0RBVEEgZXh0ZW50cykuIA0KCiAgIG8gIEEgcmVxdWVzdCBmb3IgYSB3cml0ZWFi bGUgbGF5b3V0IHJldHVybnMgUkVBRF9XUklURV9EQVRBIG9yIA0KICAgICAgSU5WQUxJRF9EQVRB IGV4dGVudHMgKGJ1dCBub3QgTk9ORV9EQVRBIGV4dGVudHMpLiAgSXQgbWF5IGFsc28gDQogICAg ICByZXR1cm4gUkVBRF9EQVRBIGV4dGVudHMgb25seSB3aGVuIHRoZSBvZmZzZXQgcmFuZ2VzIGlu IHRob3NlIA0KICAgICAgZXh0ZW50cyBhcmUgYWxzbyBjb3ZlcmVkIGJ5IElOVkFMSURfREFUQSBl eHRlbnRzIHRvIHBlcm1pdCB3cml0ZXMuICANCgogICBvICBUaGUgZmlyc3QgZXh0ZW50IGluIHRo ZSBsaXN0IE1VU1QgY29udGFpbiB0aGUgc3RhcnRpbmcgb2Zmc2V0LiANCgogICBvICBUaGUgdG90 YWwgc2l6ZSBvZiBleHRlbnRzIGluIHRoZSBleHRlbnQgbGlzdCBNVVNUIGNvdmVyIGF0IGxlYXN0 IA0KICAgICAgdGhlIG1pbmltdW0gc2l6ZSBhbmQgbm8gbW9yZSB0aGFuIHRoZSBkZXNpcmVkIHNp emUuICBPbmUgZXhjZXB0aW9uIA0KICAgICAgaXMgYWxsb3dlZDogdGhlIHRvdGFsIHNpemUgTUFZ IGJlIHNtYWxsZXIgaWYgb25seSByZWFkYWJsZSBleHRlbnRzIA0KICAgICAgd2VyZSByZXF1ZXN0 ZWQgYW5kIEVPRiBpcyBlbmNvdW50ZXJlZC4gDQoKICAgbyAgRXh0ZW50cyBpbiB0aGUgZXh0ZW50 IGxpc3QgTVVTVCBiZSBsb2dpY2FsbHkgY29udGlndW91cyBmb3IgYSANCiAgICAgIHJlYWQtb25s eSBsYXlvdXQuICBGb3IgYSByZWFkLXdyaXRlIGxheW91dCwgdGhlIHNldCBvZiB3cml0YWJsZSAN CiAgICAgIGV4dGVudHMgKGkuZS4sIGV4Y2x1ZGluZyBSRUFEX0RBVEEgZXh0ZW50cykgTVVTVCBi ZSBsb2dpY2FsbHkgDQogICAgICBjb250aWd1b3VzLiAgRXZlcnkgUkVBRF9EQVRBIGV4dGVudCBp biBhIHJlYWQtd3JpdGUgbGF5b3V0IE1VU1QgYmUgDQogICAgICBjb3ZlcmVkIGJ5IGFuIElOVkFM SURfREFUQSBleHRlbnQuICBUaGlzIG92ZXJsYXAgb2YgUkVBRF9EQVRBIGFuZCANCiAgICAgIElO VkFMSURfREFUQSBleHRlbnRzIGlzIHRoZSBvbmx5IHBlcm1pdHRlZCBleHRlbnQgb3ZlcmxhcC4g DQoKICAgbyAgRXh0ZW50cyBNVVNUIGJlIG9yZGVyZWQgaW4gdGhlIGxpc3QgYnkgc3RhcnRpbmcg b2Zmc2V0LCB3aXRoIA0KICAgICAgUkVBRF9EQVRBIGV4dGVudHMgcHJlY2VkaW5nIElOVkFMSURf REFUQSBleHRlbnRzIGluIHRoZSBjYXNlIG9mIA0KICAgICAgZXF1YWwgZmlsZV9vZmZzZXRzLiAN CgoyLjMuMi4gTGF5b3V0IENvbW1pdHMgDQoKICAgc3RydWN0IHBuZnNfYmxvY2tfbGF5b3V0dXBk YXRlNCB7IA0KCiAgICAgIHBuZnNfYmxvY2tfZXh0ZW50NCBjb21taXRfbGlzdDw+Oy8qIGxpc3Qg b2YgZXh0ZW50cyB0byB3aGljaCBub3cgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbnRhaW4gdmFsaWQgZGF0YS4gKi8gDQoKCgogDQogDQpCbGFjayAgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDEx XSANCiAgICAMDQoKCgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2svVm9sdW1l IExheW91dCAgICAgICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICAgICAgICBib29sICAg ICAgICAgICAgICAgbWFrZV92ZXJzaW9uOyAvKiBjbGllbnQgcmVxdWVzdHMgc2VydmVyIHRvDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3JlYXRlIGNvcHktb24t d3JpdGUgaW1hZ2Ugb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB0aGlzIGZpbGUuICovIA0KCiAgIH07IA0KCiAgIFRoZSAicG5mc19ibG9ja19sYXlvdXR1cGRh dGU0IiBzdHJ1Y3R1cmUgaXMgdXNlZCBieSB0aGUgY2xpZW50IGFzIHRoZSANCiAgIGJsb2NrLXBy b3RvY29sIHNwZWNpZmljIGFyZ3VtZW50IGluIGEgTEFZT1VUQ09NTUlUIG9wZXJhdGlvbi4gIFRo ZSANCiAgICJjb21taXRfbGlzdCIgZmllbGQgaXMgYW4gZXh0ZW50IGxpc3QgY292ZXJpbmcgcmVn aW9ucyBvZiB0aGUgZmlsZSANCiAgIGxheW91dCB0aGF0IHdlcmUgcHJldmlvdXNseSBpbiB0aGUg SU5WQUxJRF9EQVRBIHN0YXRlLCBidXQgaGF2ZSBiZWVuIA0KICAgd3JpdHRlbiBieSB0aGUgY2xp ZW50IGFuZCBzaG91bGQgbm93IGJlIGNvbnNpZGVyZWQgaW4gdGhlIA0KICAgUkVBRF9XUklURV9E QVRBIHN0YXRlLiAgVGhlIGVzIGZpZWxkIG9mIGVhY2ggZXh0ZW50IGluIHRoZSANCiAgIGNvbW1p dF9saXN0IE1VU1QgYmUgc2V0IHRvIFJFQURfV1JJVEVfREFUQS4gIEltcGxlbWVudGVycyBzaG91 bGQgYmUgDQogICBhd2FyZSB0aGF0IGEgc2VydmVyIG1heSBiZSB1bmFibGUgdG8gY29tbWl0IHJl Z2lvbnMgYXQgYSBncmFudWxhcml0eSANCiAgIHNtYWxsZXIgdGhhbiBhIGZpbGUtc3lzdGVtIGJs b2NrICh0eXBpY2FsbHkgNEtCIG9yIDhLQikuICBBcyBub3RlZCANCiAgIGFib3ZlLCB0aGUgYmxv Y2stc2l6ZSB0aGF0IHRoZSBzZXJ2ZXIgdXNlcyBpcyBhdmFpbGFibGUgYXMgYW4gTkZTdjQgDQog ICBhdHRyaWJ1dGUsIGFuZCBhbnkgZXh0ZW50cyBpbmNsdWRlZCBpbiB0aGUgImNvbW1pdF9saXN0 IiBNVVNUIGJlIA0KICAgYWxpZ25lZCB0byB0aGlzIGdyYW51bGFyaXR5IGFuZCBoYXZlIGEgc2l6 ZSB0aGF0IGlzIGEgbXVsdGlwbGUgb2YgDQogICB0aGlzIGdyYW51bGFyaXR5LiAgSWYgdGhlIGNs aWVudCBiZWxpZXZlcyB0aGF0IGl0cyBhY3Rpb25zIGhhdmUgbW92ZWQgDQogICB0aGUgZW5kLW9m LWZpbGUgaW50byB0aGUgbWlkZGxlIG9mIGEgYmxvY2sgYmVpbmcgY29tbWl0dGVkLCB0aGUgDQog ICBjbGllbnQgTVVTVCB3cml0ZSB6ZXJvZXMgZnJvbSB0aGUgZW5kLW9mLWZpbGUgdG8gdGhlIGVu ZCBvZiB0aGF0IA0KICAgYmxvY2sgYmVmb3JlIGNvbW1pdHRpbmcgdGhlIGJsb2NrLiAgRmFpbHVy ZSB0byBkbyBzbyBtYXkgcmVzdWx0IGluIA0KICAganVuayAodW5pbml0aWFsaXplZCBkYXRhKSBh cHBlYXJpbmcgaW4gdGhhdCBhcmVhIGlmIHRoZSBmaWxlIGlzIA0KICAgc3Vic2VxdWVudGx5IGV4 dGVuZGVkIGJ5IG1vdmluZyB0aGUgZW5kLW9mLWZpbGUuIA0KCiAgIFRoZSAibWFrZV92ZXJzaW9u IiBmaWVsZCBvZiB0aGUgc3RydWN0dXJlIGlzIGEgZmxhZyB0aGF0IHRoZSBjbGllbnQgDQogICBt YXkgc2V0IHRvIHJlcXVlc3QgdGhhdCB0aGUgc2VydmVyIGNyZWF0ZSBhIGNvcHktb24td3JpdGUg aW1hZ2Ugb2YgDQogICB0aGUgZmlsZSAocE5GUyBjbGllbnRzIG1heSBiZSBpbnZvbHZlZCBpbiB0 aGlzIG9wZXJhdGlvbiAtIHNlZSANCiAgIHNlY3Rpb24gMi4yLjQsIGJlbG93KS4gIEluIGFudGlj aXBhdGlvbiBvZiB0aGlzIG9wZXJhdGlvbiB0aGUgY2xpZW50IA0KICAgd2hpY2ggc2V0cyB0aGUg Im1ha2VfdmVyc2lvbiIgZmxhZyBpbiB0aGUgTEFZT1VUQ09NTUlUIG9wZXJhdGlvbiANCiAgIHNo b3VsZCBpbW1lZGlhdGVseSBtYXJrIGFsbCBleHRlbnRzIGluIHRoZSBsYXlvdXQgdGhhdCBpcyBw b3NzZXNzZXMgDQogICBhcyBzdGF0ZSBSRUFEX0RBVEEuICBGdXR1cmUgd3JpdGVzIHRvIHRoZSBm aWxlIHJlcXVpcmUgYSBuZXcgDQogICBMQVlPVVRHRVQgb3BlcmF0aW9uIHRvIHRoZSBzZXJ2ZXIg d2l0aCBhbiAiaW9tb2RlIiBzZXQgdG8gDQogICBMQVlPVVRJT01PREVfUlcuIA0KCjIuMy4zLiBM YXlvdXQgUmV0dXJucyANCgogICBzdHJ1Y3QgcG5mc19ibG9ja19sYXlvdXRyZXR1cm40IHsgDQoK ICAgICAgcG5mc19ibG9ja19leHRlbnQ0IHJlbF9saXN0PD47ICAgLyogbGlzdCBvZiBleHRlbnRz IHRoZSBjbGllbnQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdp bGwgbm8gbG9uZ2VyIHVzZS4gKi8gDQoKICAgfTsgDQoKICAgVGhlICJyZWxfbGlzdCIgZmllbGQg aXMgYW4gZXh0ZW50IGxpc3QgY292ZXJpbmcgcmVnaW9ucyBvZiB0aGUgZmlsZSANCiAgIGxheW91 dCB0aGF0IGFyZSBubyBsb25nZXIgbmVlZGVkIGJ5IHRoZSBjbGllbnQuICBJbmNsdWRpbmcgZXh0 ZW50cyBpbiANCiAgIHRoZSAicmVsX2xpc3QiIGZvciBhIExBWU9VVFJFVFVSTiBvcGVyYXRpb24g cmVwcmVzZW50cyBhbiBleHBsaWNpdCANCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdIA0KICAgIAwNCgoK CgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0ICAgICAg ICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIHJlbGVhc2Ugb2YgcmVzb3VyY2VzIGJ5IHRo ZSBjbGllbnQsIHVzdWFsbHkgZG9uZSBmb3IgdGhlIHB1cnBvc2Ugb2YgDQogICBhdm9pZGluZyB1 bm5lY2Vzc2FyeSBDQl9MQVlPVVRSRUNBTEwgb3BlcmF0aW9ucyBpbiB0aGUgZnV0dXJlLiANCgog ICBOb3RlIHRoYXQgdGhlIGJsb2NrL3ZvbHVtZSBsYXlvdXQgc3VwcG9ydHMgdW5pbGF0ZXJhbCBs YXlvdXQgDQogICByZXZvY2F0aW9uLiBXaGVuIGEgbGF5b3V0IGlzIHVuaWxhdGVyYWxseSByZXZv a2VkIGJ5IHRoZSBzZXJ2ZXIsIA0KICAgdXN1YWxseSBkdWUgdG8gdGhlIGNsaWVudCdzIGxlYXNl IHRpbWVyIGV4cGlyaW5nIG9yIHRoZSBjbGllbnQgDQogICBmYWlsaW5nIHRvIHJldHVybiBhIGxh eW91dCBpbiBhIHRpbWVseSBtYW5uZXIsIGl0IGlzIGltcG9ydGFudCBmb3IgDQogICB0aGUgc2Fr ZSBvZiBjb3JyZWN0bmVzcyB0aGF0IGFueSBpbi1mbGlnaHQgSS9PcyB0aGF0IHRoZSBjbGllbnQg DQogICBpc3N1ZWQgYmVmb3JlIHRoZSBsYXlvdXQgd2FzIHJldm9rZWQgYXJlIHJlamVjdGVkIGF0 IHRoZSBzdG9yYWdlLiAgDQogICBGb3IgdGhlIGJsb2NrL3ZvbHVtZSBwcm90b2NvbCwgdGhpcyBp cyBwb3NzaWJsZSBieSBmZW5jaW5nIGEgY2xpZW50IA0KICAgd2l0aCBhbiBleHBpcmVkIGxheW91 dCB0aW1lciBmcm9tIHRoZSBwaHlzaWNhbCBzdG9yYWdlLiAgTm90ZSwgDQogICBob3dldmVyLCB0 aGF0IHRoZSBncmFudWxhcml0eSBvZiB0aGlzIG9wZXJhdGlvbiBjYW4gb25seSBiZSBhdCB0aGUg DQogICBob3N0L2xvZ2ljYWwtdW5pdCBsZXZlbC4gIFRodXMsIGlmIG9uZSBvZiBhIGNsaWVudCdz IGxheW91dHMgaXMgDQogICB1bmlsYXRlcmFsbHkgcmV2b2tlZCBieSB0aGUgc2VydmVyLCBpdCB3 aWxsIGVmZmVjdGl2ZWx5IHJlbmRlciANCiAgIHVzZWxlc3MgKmFsbCogb2YgdGhlIGNsaWVudCdz IGxheW91dHMgZm9yIGZpbGVzIGxvY2F0ZWQgb24gdGhlIA0KICAgc3RvcmFnZSB1bml0cyBjb21w cmlzaW5nIHRoZSBsb2dpY2FsIHZvbHVtZS4gIFRoaXMgbWF5IHJlbmRlciB1c2VsZXNzIA0KICAg dGhlIGNsaWVudCdzIGxheW91dHMgZm9yIGZpbGVzIGluIG90aGVyIGZpbGVzeXN0ZW1zLiANCgoy LjMuNC4gQ2xpZW50IENvcHktb24tV3JpdGUgUHJvY2Vzc2luZyANCgogICBEaXN0aW5ndWlzaGlu ZyB0aGUgUkVBRF9XUklURV9EQVRBIGFuZCBSRUFEX0RBVEEgZXh0ZW50IHR5cGVzIGluIA0KICAg Y29tYmluYXRpb24gd2l0aCB0aGUgYWxsb3dlZCBvdmVybGFwIG9mIFJFQURfREFUQSBleHRlbnRz IHdpdGggDQogICBJTlZBTElEX0RBVEEgZXh0ZW50cyBhbGxvd3MgY29weS1vbi13cml0ZSBwcm9j ZXNzaW5nIHRvIGJlIGRvbmUgYnkgDQogICBwTkZTIGNsaWVudHMuIEluIGNsYXNzaWMgTkZTLCB0 aGlzIG9wZXJhdGlvbiB3b3VsZCBiZSBkb25lIGJ5IHRoZSANCiAgIHNlcnZlci4gIFNpbmNlIHBO RlMgZW5hYmxlcyBjbGllbnRzIHRvIGRvIGRpcmVjdCBibG9jayBhY2Nlc3MsIGl0IGlzIA0KICAg dXNlZnVsIGZvciBjbGllbnRzIHRvIHBhcnRpY2lwYXRlIGluIGNvcHktb24td3JpdGUgb3BlcmF0 aW9ucy4gIEFsbCANCiAgIGJsb2NrL3ZvbHVtZSBwTkZTIGNsaWVudHMgTVVTVCBzdXBwb3J0IHRo aXMgY29weS1vbi13cml0ZSBwcm9jZXNzaW5nLiANCgogICBXaGVuIGEgY2xpZW50IHdpc2hlcyB0 byB3cml0ZSBkYXRhIGNvdmVyZWQgYnkgYSBSRUFEX0RBVEEgZXh0ZW50LCBpdCANCiAgIE1VU1Qg aGF2ZSByZXF1ZXN0ZWQgYSB3cml0YWJsZSBsYXlvdXQgZnJvbSB0aGUgc2VydmVyOyB0aGF0IGxh eW91dCANCiAgIHdpbGwgY29udGFpbiBJTlZBTElEX0RBVEEgZXh0ZW50cyB0byBjb3ZlciBhbGwg dGhlIGRhdGEgcmFuZ2VzIG9mIA0KICAgdGhhdCBsYXlvdXQncyBSRUFEX0RBVEEgZXh0ZW50cy4g TW9yZSBwcmVjaXNlbHksIGZvciBhbnkgZmlsZV9vZmZzZXQgDQogICByYW5nZSBjb3ZlcmVkIGJ5 IG9uZSBvciBtb3JlIFJFQURfREFUQSBleHRlbnRzIGluIGEgd3JpdGFibGUgbGF5b3V0LCANCiAg IHRoZSBzZXJ2ZXIgTVVTVCBpbmNsdWRlIG9uZSBvciBtb3JlIElOVkFMSURfREFUQSBleHRlbnRz IGluIHRoZSANCiAgIGxheW91dCB0aGF0IGNvdmVyIHRoZSBzYW1lIGZpbGVfb2Zmc2V0IHJhbmdl LiBXaGVuIHBlcmZvcm1pbmcgYSB3cml0ZSANCiAgIHRvIHN1Y2ggYW4gYXJlYSBvZiBhIGxheW91 dCwgdGhlIGNsaWVudCBNVVNUIGVmZmVjdGl2ZWx5IGNvcHkgdGhlIA0KICAgZGF0YSBmcm9tIHRo ZSBSRUFEX0RBVEEgZXh0ZW50IGZvciBhbnkgcGFydGlhbCBibG9ja3Mgb2YgZmlsZV9vZmZzZXQg DQogICBhbmQgcmFuZ2UsIG1lcmdlIGluIHRoZSBjaGFuZ2VzIHRvIGJlIHdyaXR0ZW4sIGFuZCB3 cml0ZSB0aGUgcmVzdWx0IA0KICAgdG8gdGhlIElOVkFMSURfREFUQSBleHRlbnQgZm9yIHRoZSBi bG9ja3MgZm9yIHRoYXQgZmlsZV9vZmZzZXQgYW5kIA0KICAgcmFuZ2UuIFRoYXQgaXMsIGlmIGVu dGlyZSBibG9ja3Mgb2YgZGF0YSBhcmUgdG8gYmUgb3ZlcndyaXR0ZW4gYnkgYW4gDQogICBvcGVy YXRpb24sIHRoZSBjb3JyZXNwb25kaW5nIFJFQURfREFUQSBibG9ja3MgbmVlZCBub3QgYmUgZmV0 Y2hlZCwgDQogICBidXQgYW55IHBhcnRpYWwtYmxvY2sgd3JpdGVzIG11c3QgYmUgbWVyZ2VkIHdp dGggZGF0YSBmZXRjaGVkIHZpYSANCiAgIFJFQURfREFUQSBleHRlbnRzIGJlZm9yZSBzdG9yaW5n IHRoZSByZXN1bHQgdmlhIElOVkFMSURfREFUQSBleHRlbnRzLiAgDQogICBGb3IgdGhlIHB1cnBv c2VzIG9mIHRoaXMgZGlzY3Vzc2lvbiwgImVudGlyZSBibG9ja3MiIGFuZCAicGFydGlhbCANCiAg IGJsb2NrcyIgcmVmZXIgdG8gdGhlIHNlcnZlcidzIGZpbGUtc3lzdGVtIGJsb2NrIHNpemUuICBT dG9yaW5nIG9mIA0KICAgZGF0YSBpbiBhbiBJTlZBTElEX0RBVEEgZXh0ZW50IGNvbnZlcnRzIHRo ZSB3cml0dGVuIHBvcnRpb24gb2YgdGhlIA0KICAgSU5WQUxJRF9EQVRBIGV4dGVudCB0byBhIFJF QURfV1JJVEVfREFUQSBleHRlbnQ7IGFsbCBzdWJzZXF1ZW50IHJlYWRzIA0KIA0KIA0KQmxhY2sg ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICBb UGFnZSAxM10gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2Nr L1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgTVVTVCBi ZSBwZXJmb3JtZWQgZnJvbSB0aGlzIGV4dGVudDsgdGhlIGNvcnJlc3BvbmRpbmcgcG9ydGlvbiBv ZiB0aGUgDQogICBSRUFEX0RBVEEgZXh0ZW50IE1VU1QgTk9UIGJlIHVzZWQgYWZ0ZXIgc3Rvcmlu ZyBkYXRhIGluIGFuIA0KICAgSU5WQUxJRF9EQVRBIGV4dGVudC4gDQoKICAgSW4gdGhlIExBWU9V VENPTU1JVCBvcGVyYXRpb24gdGhhdCBub3JtYWxseSBzZW5kcyB1cGRhdGVkIGxheW91dCANCiAg IGluZm9ybWF0aW9uIGJhY2sgdG8gdGhlIHNlcnZlciwgZm9yIHdyaXRhYmxlIGRhdGEsIHNvbWUg SU5WQUxJRF9EQVRBIA0KICAgZXh0ZW50cyBtYXkgYmUgY29tbWl0dGVkIGFzIFJFQURfV1JJVEVf REFUQSBleHRlbnRzLCBzaWduaWZ5aW5nIHRoYXQgDQogICB0aGUgc3RvcmFnZSBhdCB0aGUgY29y cmVzcG9uZGluZyBzdG9yYWdlX29mZnNldCB2YWx1ZXMgaGFzIGJlZW4gDQogICBzdG9yZWQgaW50 byBhbmQgaXMgbm93IHRvIGJlIGNvbnNpZGVyZWQgYXMgdmFsaWQgZGF0YSB0byBiZSByZWFkLiAN CiAgIFJFQURfREFUQSBleHRlbnRzIGFyZSBub3QgY29tbWl0dGVkIHRvIHRoZSBzZXJ2ZXIuIEZv ciBleHRlbnRzIHRoYXQgDQogICB0aGUgY2xpZW50IHJlY2VpdmVzIHZpYSBMQVlPVVRHRVQgYXMg SU5WQUxJRF9EQVRBIGFuZCByZXR1cm5zIHZpYSANCiAgIExBWU9VVENPTU1JVCBhcyBSRUFEX1dS SVRFX0RBVEEsIHRoZSBzZXJ2ZXIgd2lsbCB1bmRlcnN0YW5kIHRoYXQgdGhlIA0KICAgUkVBRF9E QVRBIG1hcHBpbmcgZm9yIHRoYXQgZXh0ZW50IGlzIG5vIGxvbmdlciB2YWxpZCBvciBuZWNlc3Nh cnkgZm9yIA0KICAgdGhhdCBmaWxlLiANCgoyLjMuNS4gRXh0ZW50cyBhcmUgUGVybWlzc2lvbnMg DQoKICAgTGF5b3V0IGV4dGVudHMgcmV0dXJuZWQgdG8gcE5GUyBjbGllbnRzIGdyYW50IHBlcm1p c3Npb24gdG8gcmVhZCBvciANCiAgIHdyaXRlOyBSRUFEX0RBVEEgYW5kIE5PTkVfREFUQSBhcmUg cmVhZC1vbmx5IChOT05FX0RBVEEgcmVhZHMgYXMgDQogICB6ZXJvZXMpLCBSRUFEX1dSSVRFX0RB VEEgYW5kIElOVkFMSURfREFUQSBhcmUgcmVhZC93cml0ZSwgDQogICAoSU5WQUxJRF9EQVRBIHJl YWRzIGFzIHplcm9zLCBhbnkgd3JpdGUgY29udmVydHMgaXQgdG8gDQogICBSRUFEX1dSSVRFX0RB VEEpLiAgVGhpcyBpcyB0aGUgb25seSBjbGllbnQgbWVhbnMgb2Ygb2J0YWluaW5nIA0KICAgcGVy bWlzc2lvbiB0byBwZXJmb3JtIGRpcmVjdCBJL08gdG8gc3RvcmFnZSBkZXZpY2VzOyBhIHBORlMg Y2xpZW50IA0KICAgTVVTVCBOT1QgcGVyZm9ybSBkaXJlY3QgSS9PIG9wZXJhdGlvbnMgdGhhdCBh cmUgbm90IHBlcm1pdHRlZCBieSBhbiANCiAgIGV4dGVudCBoZWxkIGJ5IHRoZSBjbGllbnQuICBD bGllbnQgYWRoZXJlbmNlIHRvIHRoaXMgcnVsZSBwbGFjZXMgdGhlIA0KICAgcE5GUyBzZXJ2ZXIg aW4gY29udHJvbCBvZiBwb3RlbnRpYWxseSBjb25mbGljdGluZyBzdG9yYWdlIGRldmljZSANCiAg IG9wZXJhdGlvbnMsIGVuYWJsaW5nIHRoZSBzZXJ2ZXIgdG8gZGV0ZXJtaW5lIHdoYXQgZG9lcyBj b25mbGljdCBhbmQgDQogICBob3cgdG8gYXZvaWQgY29uZmxpY3RzIGJ5IGdyYW50aW5nIGFuZCBy ZWNhbGxpbmcgZXh0ZW50cyB0by9mcm9tIA0KICAgY2xpZW50cy4gICANCgogICBCbG9jay92b2x1 bWUgY2xhc3Mgc3RvcmFnZSBkZXZpY2VzIGFyZSBub3QgcmVxdWlyZWQgdG8gcGVyZm9ybSByZWFk IA0KICAgYW5kIHdyaXRlIG9wZXJhdGlvbnMgYXRvbWljYWxseS4gIE92ZXJsYXBwaW5nIGNvbmN1 cnJlbnQgcmVhZCBhbmQgDQogICB3cml0ZSBvcGVyYXRpb25zIHRvIHRoZSBzYW1lIGRhdGEgbWF5 IGNhdXNlIHRoZSByZWFkIHRvIHJldHVybiBhIA0KICAgbWl4dHVyZSBvZiBiZWZvcmUtd3JpdGUg YW5kIGFmdGVyLXdyaXRlIGRhdGEuICBPdmVybGFwcGluZyB3cml0ZSANCiAgIG9wZXJhdGlvbnMg Y2FuIGJlIHdvcnNlLCBhcyB0aGUgcmVzdWx0IGNvdWxkIGJlIGEgbWl4dHVyZSBvZiBkYXRhIA0K ICAgZnJvbSB0aGUgdHdvIHdyaXRlIG9wZXJhdGlvbnM7IGRhdGEgY29ycnVwdGlvbiBjYW4gb2Nj dXIgaWYgdGhlIA0KICAgdW5kZXJseWluZyBzdG9yYWdlIGlzIHN0cmlwZWQgYW5kIHRoZSBvcGVy YXRpb25zIGNvbXBsZXRlIGluIA0KICAgZGlmZmVyZW50IG9yZGVycyBvbiBkaWZmZXJlbnQgc3Ry aXBlcy4gIEEgcE5GUyBzZXJ2ZXIgY2FuIGF2b2lkIHRoZXNlIA0KICAgY29uZmxpY3RzIGJ5IGlt cGxlbWVudGluZyBhIHNpbmdsZSB3cml0ZXIgWE9SIG11bHRpcGxlIHJlYWRlcnMgDQogICBjb25j dXJyZW5jeSBjb250cm9sIHBvbGljeSB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBjbGllbnRzIHdo byB3aXNoIA0KICAgdG8gYWNjZXNzIHRoZSBzYW1lIGRhdGEuICBUaGlzIHBvbGljeSBTSE9VTEQg YmUgaW1wbGVtZW50ZWQgd2hlbiANCiAgIHN0b3JhZ2UgZGV2aWNlcyBkbyBub3QgcHJvdmlkZSBh dG9taWNpdHkgZm9yIGNvbmN1cnJlbnQgcmVhZC93cml0ZSANCiAgIGFuZCB3cml0ZS93cml0ZSBv cGVyYXRpb25zIHRvIHRoZSBzYW1lIGRhdGEuIA0KCiAgIElmIGEgY2xpZW50IG1ha2VzIGEgbGF5 b3V0IHJlcXVlc3QgdGhhdCBjb25mbGljdHMgd2l0aCBhbiBleGlzdGluZyANCiAgIGxheW91dCBk ZWxlZ2F0aW9uLCB0aGUgcmVxdWVzdCB3aWxsIGJlIHJlamVjdGVkIHdpdGggdGhlIGVycm9yIA0K ICAgTkZTNEVSUl9MQVlPVVRUUllMQVRFUi4gIFRoaXMgY2xpZW50IGlzIHRoZW4gZXhwZWN0ZWQg dG8gcmV0cnkgdGhlIA0KIA0KIA0KQmxhY2sgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDIwMDcgICAgICAgICAgICAgICAgICBbUGFnZSAxNF0gDQogICAgDA0KCgoKCgoKSW50ZXJu ZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1h cmNoIDIwMDcgDQogICAgDQoKICAgcmVxdWVzdCBhZnRlciBhIHNob3J0IGludGVydmFsLiAgRHVy aW5nIHRoaXMgaW50ZXJ2YWwgdGhlIHNlcnZlciANCiAgIFNIT1VMRCByZWNhbGwgdGhlIGNvbmZs aWN0aW5nIHBvcnRpb24gb2YgdGhlIGxheW91dCBkZWxlZ2F0aW9uIGZyb20gDQogICB0aGUgY2xp ZW50IHRoYXQgY3VycmVudGx5IGhvbGRzIGl0LiAgVGhpcyByZWplY3QtYW5kLXJldHJ5IGFwcHJv YWNoIA0KICAgZG9lcyBub3QgcHJldmVudCBjbGllbnQgc3RhcnZhdGlvbiB3aGVuIHRoZXJlIGlz IGNvbnRlbnRpb24gZm9yIHRoZSANCiAgIGxheW91dCBvZiBhIHBhcnRpY3VsYXIgZmlsZS4gIEZv ciB0aGlzIHJlYXNvbiBhIHBORlMgc2VydmVyIFNIT1VMRCANCiAgIGltcGxlbWVudCBhIG1lY2hh bmlzbSB0byBwcmV2ZW50IHN0YXJ2YXRpb24uICBPbmUgcG9zc2liaWxpdHkgaXMgdGhhdCANCiAg IHRoZSBzZXJ2ZXIgY2FuIG1haW50YWluIGEgcXVldWUgb2YgcmVqZWN0ZWQgbGF5b3V0IHJlcXVl c3RzLiAgRWFjaCANCiAgIG5ldyBsYXlvdXQgcmVxdWVzdCBjYW4gYmUgY2hlY2tlZCB0byBzZWUg aWYgaXQgY29uZmxpY3RzIHdpdGggYSANCiAgIHByZXZpb3VzIHJlamVjdGVkIHJlcXVlc3QsIGFu ZCBpZiBzbywgdGhlIG5ld2VyIHJlcXVlc3QgY2FuIGJlIA0KICAgcmVqZWN0ZWQuIE9uY2UgdGhl IG9yaWdpbmFsIHJlcXVlc3RpbmcgY2xpZW50IHJldHJpZXMgaXRzIHJlcXVlc3QsIA0KICAgaXRz IGVudHJ5IGluIHRoZSByZWplY3RlZCByZXF1ZXN0IHF1ZXVlIGNhbiBiZSBjbGVhcmVkLCBvciB0 aGUgZW50cnkgDQogICBpbiB0aGUgcmVqZWN0ZWQgcmVxdWVzdCBxdWV1ZSBjYW4gYmUgcmVtb3Zl ZCB3aGVuIGl0IHJlYWNoZXMgYSANCiAgIGNlcnRhaW4gYWdlLiANCgogICBORlN2NCBzdXBwb3J0 cyBtYW5kYXRvcnkgbG9ja3MgYW5kIHNoYXJlIHJlc2VydmF0aW9ucy4gIFRoZXNlIGFyZSANCiAg IG1lY2hhbmlzbXMgdGhhdCBjbGllbnRzIGNhbiB1c2UgdG8gcmVzdHJpY3QgdGhlIHNldCBvZiBJ L08gb3BlcmF0aW9ucyANCiAgIHRoYXQgYXJlIHBlcm1pc3NpYmxlIHRvIG90aGVyIGNsaWVudHMu ICBTaW5jZSBhbGwgSS9PIG9wZXJhdGlvbnMgDQogICB1bHRpbWF0ZWx5IGFycml2ZSBhdCB0aGUg TkZTdjQgc2VydmVyIGZvciBwcm9jZXNzaW5nLCB0aGUgc2VydmVyIGlzIA0KICAgaW4gYSBwb3Np dGlvbiB0byBlbmZvcmNlIHRoZXNlIHJlc3RyaWN0aW9ucy4gIEhvd2V2ZXIsIHdpdGggcE5GUyAN CiAgIGxheW91dCBkZWxlZ2F0aW9ucywgSS9PcyB3aWxsIGJlIGlzc3VlZCBmcm9tIHRoZSBjbGll bnRzIHRoYXQgaG9sZCANCiAgIHRoZSBkZWxlZ2F0aW9ucyBkaXJlY3RseSB0byB0aGUgc3RvcmFn ZSBkZXZpY2VzIHRoYXQgaG9zdCB0aGUgZGF0YS4gIA0KICAgVGhlc2UgZGV2aWNlcyBoYXZlIG5v IGtub3dsZWRnZSBvZiBmaWxlcywgbWFuZGF0b3J5IGxvY2tzLCBvciBzaGFyZSANCiAgIHJlc2Vy dmF0aW9ucywgYW5kIGFyZSBub3QgaW4gYSBwb3NpdGlvbiB0byBlbmZvcmNlIHN1Y2ggcmVzdHJp Y3Rpb25zLiAgDQogICBGb3IgdGhpcyByZWFzb24gdGhlIE5GU3Y0IHNlcnZlciBNVVNUIE5PVCBn cmFudCBsYXlvdXQgZGVsZWdhdGlvbnMgDQogICB0aGF0IGNvbmZsaWN0IHdpdGggbWFuZGF0b3J5 IGxvY2tzIG9yIHNoYXJlIHJlc2VydmF0aW9ucy4gIEZ1cnRoZXIsIA0KICAgaWYgYSBjb25mbGlj dGluZyBtYW5kYXRvcnkgbG9jayByZXF1ZXN0IG9yIGEgY29uZmxpY3Rpbmcgb3BlbiByZXF1ZXN0 IA0KICAgYXJyaXZlcyBhdCB0aGUgc2VydmVyLCB0aGUgc2VydmVyIE1VU1QgcmVjYWxsIHRoZSBw YXJ0IG9mIHRoZSBsYXlvdXQgDQogICBkZWxlZ2F0aW9uIGluIGNvbmZsaWN0IHdpdGggdGhlIHJl cXVlc3QgYmVmb3JlIGdyYW50aW5nIHRoZSByZXF1ZXN0LiANCgoyLjMuNi4gRW5kLW9mLWZpbGUg UHJvY2Vzc2luZyANCgogICBUaGUgZW5kLW9mLWZpbGUgbG9jYXRpb24gY2FuIGJlIGNoYW5nZWQg aW4gdHdvIHdheXM6IGltcGxpY2l0bHkgYXMgDQogICB0aGUgcmVzdWx0IG9mIGEgV1JJVEUgb3Ig TEFZT1VUQ09NTUlUIGJleW9uZCB0aGUgY3VycmVudCBlbmQtb2YtZmlsZSwgDQogICBvciBleHBs aWNpdGx5IGFzIHRoZSByZXN1bHQgb2YgYSBTRVRBVFRSIHJlcXVlc3QuICBUeXBpY2FsbHksIHdo ZW4gYSANCiAgIGZpbGUgaXMgdHJ1bmNhdGVkIGJ5IGFuIE5GU3Y0IGNsaWVudCB2aWEgdGhlIFNF VEFUVFIgY2FsbCwgdGhlIHNlcnZlciANCiAgIGZyZWVzIGFueSBkaXNrIGJsb2NrcyBiZWxvbmdp bmcgdG8gdGhlIGZpbGUgd2hpY2ggYXJlIGJleW9uZCB0aGUgbmV3IA0KICAgZW5kLW9mLWZpbGUg b2N0ZXQsIGFuZCBtYXkgd3JpdGUgemVyb3MgdG8gdGhlIHBvcnRpb24gb2YgdGhlIG5ldyBlbmQt DQogICBvZi1maWxlIGJsb2NrIGJleW9uZCB0aGUgbmV3IGVuZC1vZi1maWxlIG9jdGV0LiAgVGhl c2UgYWN0aW9ucyByZW5kZXIgDQogICBhbnkgcE5GUyBsYXlvdXRzIHdoaWNoIHJlZmVyIHRvIHRo ZSBibG9ja3MgdGhhdCBhcmUgZnJlZWQgb3Igd3JpdHRlbiANCiAgIHNlbWFudGljYWxseSBpbnZh bGlkLiAgVGhlcmVmb3JlLCB0aGUgc2VydmVyIE1VU1QgcmVjYWxsIGZyb20gY2xpZW50cyANCiAg IHRoZSBwb3J0aW9ucyBvZiBhbnkgcE5GUyBsYXlvdXRzIHdoaWNoIHJlZmVyIHRvIGJsb2NrcyB0 aGF0IHdpbGwgYmUgDQogICBmcmVlZCBvciB3cml0dGVuIGJ5IHRoZSBzZXJ2ZXIgYmVmb3JlIHBy b2Nlc3NpbmcgdGhlIHRydW5jYXRlIA0KICAgcmVxdWVzdC4gVGhlc2UgcmVjYWxscyBtYXkgdGFr ZSB0aW1lIHRvIGNvbXBsZXRlOyBhcyBleHBsYWluZWQgaW4gDQogICBbTkZTdjQuMV0sIGlmIHRo ZSBzZXJ2ZXIgY2Fubm90IHJlc3BvbmQgdG8gdGhlIGNsaWVudCBTRVRBVFRSIHJlcXVlc3QgDQog ICBpbiBhIHJlYXNvbmFibGUgYW1vdW50IG9mIHRpbWUsIGl0IFNIT1VMRCByZXBseSB0byB0aGUg Y2xpZW50IHdpdGggDQogICB0aGUgZXJyb3IgTkZTNEVSUl9ERUxBWS4gDQoKIA0KIA0KQmxhY2sg ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICBb UGFnZSAxNV0gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2Nr L1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgQmxvY2tz IGluIHRoZSBJTlZBTElEX0RBVEEgc3RhdGUgd2hpY2ggbGllIGJleW9uZCB0aGUgbmV3IGVuZC1v Zi1maWxlIA0KICAgYmxvY2sgcHJlc2VudCBhIHNwZWNpYWwgY2FzZS4gIFRoZSBzZXJ2ZXIgaGFz IHJlc2VydmVkIHRoZXNlIGJsb2NrcyANCiAgIGZvciB1c2UgYnkgYSBwTkZTIGNsaWVudCB3aXRo IGEgd3JpdGFibGUgbGF5b3V0IGZvciB0aGUgZmlsZSwgYnV0IHRoZSANCiAgIGNsaWVudCBoYXMg eWV0IHRvIGNvbW1pdCB0aGUgYmxvY2tzLCBhbmQgdGhleSBhcmUgbm90IHlldCBhIHBhcnQgb2Yg DQogICB0aGUgZmlsZSBtYXBwaW5nIG9uIGRpc2suICBUaGUgc2VydmVyIE1BWSBmcmVlIHRoZXNl IGJsb2NrcyB3aGlsZSANCiAgIHByb2Nlc3NpbmcgdGhlIFNFVEFUVFIgcmVxdWVzdC4gIElmIHNv LCB0aGUgc2VydmVyIE1VU1QgcmVjYWxsIGFueSANCiAgIGxheW91dHMgZnJvbSBwTkZTIGNsaWVu dHMgd2hpY2ggcmVmZXIgdG8gdGhlIGJsb2NrcyBiZWZvcmUgcHJvY2Vzc2luZyANCiAgIHRoZSB0 cnVuY2F0ZS4gIElmIHRoZSBzZXJ2ZXIgZG9lcyBub3QgZnJlZSB0aGUgSU5WQUxJRF9EQVRBIGJs b2NrcyANCiAgIHdoaWxlIHByb2Nlc3NpbmcgdGhlIFNFVEFUVFIgcmVxdWVzdCwgaXQgbmVlZCBu b3QgcmVjYWxsIGxheW91dHMgDQogICB3aGljaCByZWZlciBvbmx5IHRvIHRoZSBJTlZBTElEIERB VEEgYmxvY2tzLiANCgogICBXaGVuIGEgZmlsZSBpcyBleHRlbmRlZCBpbXBsaWNpdGx5IGJ5IGEg V1JJVEUgb3IgTEFZT1VUQ09NTUlUIGJleW9uZCANCiAgIHRoZSBjdXJyZW50IGVuZC1vZi1maWxl LCBvciBleHRlbmRlZCBleHBsaWNpdGx5IGJ5IGEgU0VUQVRUUiByZXF1ZXN0LCANCiAgIHRoZSBz ZXJ2ZXIgbmVlZCBub3QgcmVjYWxsIGFueSBwb3J0aW9ucyBvZiBhbnkgcE5GUyBsYXlvdXRzLiAN CgoyLjMuNy4gQ2xpZW50IEZlbmNpbmcgDQoKICAgVGhlIHBORlMgYmxvY2sgcHJvdG9jb2wgbXVz dCBoYW5kbGUgc2l0dWF0aW9ucyBpbiB3aGljaCBhIHN5c3RlbSANCiAgIGZhaWx1cmUsIHR5cGlj YWxseSBhIG5ldHdvcmsgY29ubmVjdGl2aXR5IGlzc3VlLCByZXF1aXJlcyB0aGUgc2VydmVyIA0K ICAgdG8gdW5pbGF0ZXJhbGx5IHJldm9rZSBleHRlbnRzIGZyb20gb25lIGNsaWVudCBpbiBvcmRl ciB0byB0cmFuc2ZlciANCiAgIHRoZSBleHRlbnRzIHRvIGFub3RoZXIgY2xpZW50LiAgVGhlIHBO RlMgc2VydmVyIGltcGxlbWVudGF0aW9uIE1VU1QgDQogICBlbnN1cmUgdGhhdCB3aGVuIHJlc291 cmNlcyBhcmUgdHJhbnNmZXJyZWQgdG8gYW5vdGhlciBjbGllbnQsIHRoZXkgDQogICBhcmUgbm90 IHVzZWQgYnkgdGhlIGNsaWVudCBvcmlnaW5hbGx5IG93bmluZyB0aGVtLCBhbmQgdGhpcyBtdXN0 IGJlIA0KICAgZW5zdXJlZCBhZ2FpbnN0IGFueSBwb3NzaWJsZSBjb21iaW5hdGlvbiBvZiBwYXJ0 aXRpb25zIGFuZCBkZWxheXMgDQogICBhbW9uZyBhbGwgb2YgdGhlIHBhcnRpY2lwYW50cyB0byB0 aGUgcHJvdG9jb2wgKHNlcnZlciwgc3RvcmFnZSBhbmQgDQogICBjbGllbnQpLiAgU2V2ZXJhbCBh cHByb2FjaGVzIHRvIGd1YXJhbnRlZWluZyB0aGlzIGlzb2xhdGlvbiBhcmUgDQogICBwb3NzaWJs ZSBhbmQgYXJlIGRpc2N1c3NlZCBiZWxvdy4gDQoKICAgT25lIHNlcnZlciBiYXNlZCBpbXBsZW1l bnRhdGlvbiBjaG9pY2UgZm9yIGZlbmNpbmcgaXMgdG8gdXNlIHRoZSANCiAgIFNUT01JVEggKFNo b290IFRoZSBPdGhlciBNYWNoaW5lIEluIFRoZSBIZWFkKSBwcm90b2NvbCwgaS5lLiwgdHVybiAN CiAgIG9mZiB0aGUgcG93ZXIgdG8gdGhlIGNsaWVudCBtYWNoaW5lIHRoYXQgbmVlZHMgdG8gYmUg aXNvbGF0ZWQuICBUaGlzIA0KICAgaXMgcG9zc2libGUgaWYgdGhlIHNlcnZlciBoYXMgYWNjZXNz IHRvIGVpdGhlciBhbiBJUE1JIGludGVyZmFjZSB0byANCiAgIHBvd2VyIGN5Y2xlIHRoZSBjbGll bnQsIG9yIGFuIGFsdGVybmF0ZSBtZXRob2Qgb2YgdHVybmluZyBvZmYgcG93ZXIgDQogICB0byBh IG5vbi1jb21tdW5pY2F0aXZlIGNsaWVudC4gIFRoZSBjbGllbnQgU0hPVUxEIGJlIGtlcHQgcG93 ZXJlZCBvZmYgDQogICBmb3IgYXQgbGVhc3QgdGhlIGR1cmF0aW9uIG9mIHRoZSBzZXJ2ZXIgbGVh c2UgdGltZSwgYXMgaXQgaXMgDQogICBwb3NzaWJsZSwgYWx0aG91Z2ggdW50eXBpY2FsLCB0aGF0 IHRoZSBjbGllbnQgY2FjaGVzIHRoZSBsYXlvdXQgDQogICBpbmZvcm1hdGlvbiBvbiBwZXJzaXN0 ZW50IHN0b3JhZ2UuICBUaGlzIGFwcHJvYWNoIGNhbiBpbiBzb21lIA0KICAgaW5zdGFuY2VzIGd1 YXJhbnRlZSB0aGF0IHRoZSByb2d1ZSBjbGllbnQgbm8gbG9uZ2VyIGlzIGNhcGFibGUgb2YgDQog ICBhY2Nlc3NpbmcgdGhlIHN0b3JhZ2UuICBIb3dldmVyLCBpbiBvdGhlciBzaXR1YXRpb25zLCBm b3IgZXhhbXBsZSANCiAgIGxhY2sgb2YgVENQL0lQIGFjY2VzcyB0byB0aGUgY2xpZW50J3MgSVBN SSBuZXR3b3JrIGFkZHJlc3MsIHRoaXMgDQogICBhcHByb2FjaCBjYW5ub3QgZ3VhcmFudGVlIGFu eXRoaW5nLiAgIA0KCiAgIEFub3RoZXIgaW1wbGVtZW50YXRpb24gY2hvaWNlIGZvciBmZW5jaW5n IHRoZSBibG9jayBjbGllbnQgZnJvbSB0aGUgDQogICBibG9jayBzdG9yYWdlIGlzIHRoZSB1c2Ug b2YgTFVOIChMb2dpY2FsIFVuaXQgTnVtYmVyKSBtYXNraW5nIG9yIA0KICAgbWFwcGluZyBhdCB0 aGUgc3RvcmFnZSBzeXN0ZW1zIG9yIHN0b3JhZ2UgYXJlYSBuZXR3b3JrIHRvIGRpc2FibGUgDQog ICBhY2Nlc3MgYnkgdGhlIGNsaWVudCB0byBiZSBpc29sYXRlZC4gIEluIGNvbnRyYXN0IHRvIHRo ZSBTVE9NSVRIIA0KICAgYXBwcm9hY2gsIHRoaXMgcmVxdWlyZXMgc2VydmVyIGFjY2VzcyB0byBh IG1hbmFnZW1lbnQgaW50ZXJmYWNlIGZvciANCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdIA0KICAgIAwN CgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5b3V0ICAg ICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIHRoZSBzdG9yYWdlIHN5c3RlbSBhbmQg YXV0aG9yaXphdGlvbiB0byBwZXJmb3JtIExVTiBtYXNraW5nIGFuZCANCiAgIG1hbmFnZW1lbnQg b3BlcmF0aW9ucy4gIEZvciBleGFtcGxlLCBTTUktUyBbU01JU10gcHJvdmlkZXMgYSBtZWFucyB0 byANCiAgIGRpc2NvdmVyIGFuZCBtYXNrIExVTnMsIGluY2x1ZGluZyBhIG1lYW5zIG9mIGFzc29j aWF0aW5nIGNsaWVudHMgd2l0aCANCiAgIHRoZSBuZWNlc3NhcnkgV29ybGQgV2lkZSBOYW1lcyBv ciBJbml0aWF0b3IgbmFtZXMgdG8gYmUgbWFza2VkLiANCgogICBJbiB0aGUgYWJzZW5jZSBvZiBz dXBwb3J0IGZvciBvdGhlciBtZWNoYW5pc21zLCB0aGUgc2VydmVyIE1VU1QgDQogICBjaG9vc2Ug dG8gcmVseSBvbiB0aGUgY2xpZW50cyB0byBpbXBsZW1lbnQgYSB0aW1lZCBsZWFzZSBJL08gZmVu Y2luZyANCiAgIG1lY2hhbmlzbS4gIEJlY2F1c2UgY2xpZW50cyBkbyBub3Qga25vdyBpZiB0aGUg c2VydmVyIGlzIHVzaW5nIA0KICAgU1RPTUlUSCBvciBMVU4gbWFza2luZy4gaW4gYWxsIGNhc2Vz IHRoZSBjbGllbnQgTVVTVCBpbXBsZW1lbnQgdGltZWQgDQogICBsZWFzZSBmZW5jaW5nLiAgSW4g dGltZWQgbGVhc2UgZmVuY2luZyB3ZSBkZWZpbmUgdHdvIHRpbWUgcGVyaW9kcywgDQogICB0aGUg Zmlyc3QsICJsZWFzZV90aW1lIiBpcyB0aGUgbGVuZ3RoIG9mIGEgbGVhc2UgYXMgZGVmaW5lZCBi eSB0aGUgDQogICBzZXJ2ZXIncyBsZWFzZV90aW1lIGF0dHJpYnV0ZSAoc2VlIFNlY3Rpb24gNS40 IG9mIFtORlNWNC4xXSksIGFuZCB0aGUgDQogICBzZWNvbmQsICJtYXhpbXVtX2lvX3RpbWUiIGlz IHRoZSBtYXhpbXVtIHRpbWUgaXQgY2FuIHRha2UgZm9yIGEgDQogICBjbGllbnQgSS9PIHRvIHRo ZSBzdG9yYWdlIHN5c3RlbSB0byBlaXRoZXIgY29tcGxldGUgb3IgZmFpbDsgdGhpcyANCiAgIHZh bHVlIGlzIG9mdGVuIDMwIHNlY29uZHMgb3IgNjAgc2Vjb25kcywgYnV0IG1heSBiZSBsb25nZXIg aW4gc29tZSANCiAgIGVudmlyb25tZW50cy4gIElmIHRoZSBtYXhpbXVtIGNsaWVudCBJL08gdGlt ZSBjYW5ub3QgYmUgYm91bmRlZCwgdGhpcyANCiAgIHRpbWVkIGxlYXNlIG1lY2hhbmlzbSBNVVNU IE5PVCBiZSB1c2VkLiAgVGhlIGNsaWVudCBjYW4gdXNlIEdFVEFUVFIgDQogICB0byBxdWVyeSB0 aGUgc2VydmVyJ3MgZGVmYXVsdCBzZXR0aW5nIG9mICJtYXhpbXVtX2lvX3RpbWUiLiAgVGhlIA0K ICAgc2VydmVyIG11c3QgcmVzcG9uZCB3aXRoIHRoZSBtYXhpbXVtIEkvTyB0aW1lIGluIHNlY29u ZHMuICBJZiB0aGUgDQogICBjbGllbnQncyBtYXhpbXVtIEkvTyB0aW1lIGlzIGdyZWF0ZXIgdGhh biB0aGUgc2VydmVyJ3MgZGVmYXVsdCwgdGhlbiANCiAgIHRoZSBjbGllbnQgTVVTVCB1c2UgU0VU QVRUUiB0byBpbmZvcm0gdGhlIHNlcnZlciBvZiBpdHMgbWF4aW11bV9JL08gDQogICB0aW1lLiAg VXNpbmcgdGhlc2UgdHdvIHRpbWUgc3BhbiB2YWx1ZXMsIHdlIHNwZWNpZnkgdGhlIGJlaGF2aW9y IG9mIA0KICAgdGhlIGNsaWVudCBhbmQgc2VydmVyIGFzIGZvbGxvd3MuIA0KCiAgIFdoZW4gYSBj bGllbnQgcmVjZWl2ZXMgbGF5b3V0IGluZm9ybWF0aW9uIHZpYSBhIExBWU9VVEdFVCBvcGVyYXRp b24sIA0KICAgdGhvc2UgbGF5b3V0cyBhcmUgdmFsaWQgZm9yIGF0IG1vc3QgImxlYXNlX3RpbWUi IHNlY29uZHMgZnJvbSB3aGVuIA0KICAgdGhlIHNlcnZlciBncmFudGVkIHRoZW0uICBBIGxheW91 dCBpcyByZW5ld2VkIGJ5IGFueSBzdWNjZXNzZnVsIA0KICAgU0VRVUVVTkNFIG9wZXJhdGlvbiwg b3Igd2hlbmV2ZXIgYSBuZXcgc3RhdGVpZCBpcyBjcmVhdGVkIG9yIHVwZGF0ZWQgDQogICAoc2Vl IHRoZSBzZWN0aW9uICJMZWFzZSBSZW5ld2FsIiBvZiBbTkZTVjQuMV0pLiAgSWYgdGhlIGxheW91 dCBsZWFzZSANCiAgIGlzIG5vdCByZW5ld2VkIHByaW9yIHRvIGV4cGlyYXRpb24sIHRoZSBjbGll bnQgTVVTVCBjZWFzZSB0byB1c2UgdGhlIA0KICAgbGF5b3V0IGFmdGVyICJsZWFzZV90aW1lIiBz ZWNvbmRzIGZyb20gd2hlbiBpdCBlaXRoZXIgc2VudCB0aGUgDQogICBvcmlnaW5hbCBMQVlPVVRH RVQgY29tbWFuZCwgb3Igc2VudCB0aGUgbGFzdCBvcGVyYXRpb24gcmVuZXdpbmcgdGhlIA0KICAg bGVhc2UuICBJbiBvdGhlciB3b3JkcywgdGhlIGNsaWVudCBtYXkgbm90IGlzc3VlIGFueSBJL08g dG8gYmxvY2tzIA0KICAgc3BlY2lmaWVkIGJ5IGFuIGV4cGlyZWQgbGF5b3V0LiAgSW4gdGhlIHBy ZXNlbmNlIG9mIGxhcmdlIA0KICAgY29tbXVuaWNhdGlvbiBkZWxheXMgYmV0d2VlbiB0aGUgY2xp ZW50IGFuZCBzZXJ2ZXIgaXQgaXMgZXZlbiANCiAgIHBvc3NpYmxlIGZvciB0aGUgbGVhc2UgdG8g ZXhwaXJlIHByaW9yIHRvIHRoZSBzZXJ2ZXIgcmVzcG9uc2UgDQogICBhcnJpdmluZyBhdCB0aGUg Y2xpZW50LiAgSW4gc3VjaCBhIHNpdHVhdGlvbiB0aGUgY2xpZW50IE1VU1QgTk9UIHVzZSANCiAg IHRoZSBleHBpcmVkIGxheW91dHMsIGFuZCBTSE9VTEQgcmV2ZXJ0IHRvIHVzaW5nIHN0YW5kYXJk IE5GU3Y0MSBSRUFEIA0KICAgYW5kIFdSSVRFIG9wZXJhdGlvbnMuICBGdXJ0aGVybW9yZSwgdGhl IGNsaWVudCBtdXN0IGJlIGNvbmZpZ3VyZWQgDQogICBzdWNoIHRoYXQgSS9PIG9wZXJhdGlvbnMg Y29tcGxldGUgd2l0aGluIHRoZSAibWF4aW11bV9pb190aW1lIiBldmVuIA0KICAgaW4gdGhlIHBy ZXNlbmNlIG9mIG11bHRpcGF0aGluZyBkcml2ZXJzIHRoYXQgd2lsbCByZXRyeSBJL09zIHZpYSAN CiAgIG11bHRpcGxlIHBhdGhzLiAgSWYgYSBjbGllbnQgY2Fubm90IGd1YXJhbnRlZSBhIGJvdW5k ZWQgbWF4aW11bSBJL08gDQogICB0aW1lLCBpdCBNVVNUIE5PVCB1c2UgcE5GUy4gDQoKICAgQXMg c3RhdGVkIGluIHRoZSBzZWN0aW9uICJEZWFsaW5nIHdpdGggTGVhc2UgRXhwaXJhdGlvbiBvbiB0 aGUgDQogICBDbGllbnQiIG9mIFtORlNWNC4xXSwgaWYgYW55IFNFUVVFTkNFIG9wZXJhdGlvbiBp cyBzdWNjZXNzZnVsLCBidXQgDQogICBzcl9zdGF0dXNfZmxhZyBoYXMgU0VRNF9TVEFUVVNfRVhQ SVJFRF9BTExfU1RBVEVfUkVWT0tFRCwgDQogDQogDQpCbGFjayAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDE3XSANCiAgICAMDQoK CgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2svVm9sdW1lIExheW91dCAgICAg ICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICBTRVE0X1NUQVRVU19FWFBJUkVEX1NPTUVf U1RBVEVfUkVWT0tFRCwgb3IgDQogICBTRVE0X1NUQVRVU19BRE1JTl9TVEFURV9SRVZPS0VEIHNl dCwgdGhlIGNsaWVudCBNVVNUIGltbWVkaWF0ZWx5IA0KICAgY2Vhc2UgdG8gdXNlIGFsbCBsYXlv dXRzIGFuZCBkZXZpY2UgaWQgdG8gZGV2aWNlIGFkZHJlc3MgbWFwcGluZ3MgDQogICBhc3NvY2lh dGVkIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgc2VydmVyLiANCgogICBJbiB0aGUgYWJzZW5jZSBv ZiBrbm93biB0d28gd2F5IGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCANCiAg IHRoZSBzZXJ2ZXIgb24gdGhlIGZvcmUgY2hhbm5lbCwgdGhlIHNlcnZlciBtdXN0IHdhaXQgZm9y IGF0IGxlYXN0IHRoZSANCiAgIHRpbWUgcGVyaW9kICJsZWFzZV90aW1lIiBwbHVzICJtYXhpbXVt X2lvX3RpbWUiIGJlZm9yZSB0cmFuc2ZlcnJpbmcgDQogICBsYXlvdXRzIGZyb20gdGhlIG9yaWdp bmFsIGNsaWVudCB0byBhbnkgb3RoZXIgY2xpZW50LiAgVGhlIHNlcnZlciwgDQogICBsaWtlIHRo ZSBjbGllbnQsIG11c3QgdGFrZSBhIGNvbnNlcnZhdGl2ZSBhcHByb2FjaCwgYW5kIHN0YXJ0IHRo ZSANCiAgIGxlYXNlIGV4cGlyYXRpb24gdGltZXIgZnJvbSB0aGUgdGltZSB0aGF0IGl0IHJlY2Vp dmVkIHRoZSBvcGVyYXRpb24gDQogICB3aGljaCBsYXN0IHJlbmV3ZWQgdGhlIGxlYXNlLiANCgoy LjQuIENyYXNoIFJlY292ZXJ5IElzc3VlcyANCgogICBXaGVuIHRoZSBzZXJ2ZXIgY3Jhc2hlcyB3 aGlsZSB0aGUgY2xpZW50IGhvbGRzIGEgd3JpdGFibGUgbGF5b3V0LCBhbmQgDQogICB0aGUgY2xp ZW50IGhhcyB3cml0dGVuIGRhdGEgdG8gYmxvY2tzIGNvdmVyZWQgYnkgdGhlIGxheW91dCwgYW5k IHRoZSANCiAgIGJsb2NrcyBhcmUgc3RpbGwgaW4gdGhlIElOVkFMSURfREFUQSBzdGF0ZSwgdGhl IGNsaWVudCBoYXMgdHdvIA0KICAgb3B0aW9ucyBmb3IgcmVjb3ZlcnkuICBJZiB0aGUgZGF0YSB0 aGF0IGhhcyBiZWVuIHdyaXR0ZW4gdG8gdGhlc2UgDQogICBibG9ja3MgaXMgc3RpbGwgY2FjaGVk IGJ5IHRoZSBjbGllbnQsIHRoZSBjbGllbnQgY2FuIHNpbXBseSByZS13cml0ZSANCiAgIHRoZSBk YXRhIHZpYSBORlN2NCwgb25jZSB0aGUgc2VydmVyIGhhcyBjb21lIGJhY2sgb25saW5lLiAgSG93 ZXZlciwgDQogICBpZiB0aGUgZGF0YSBpcyBubyBsb25nZXIgaW4gdGhlIGNsaWVudCdzIGNhY2hl LCB0aGUgY2xpZW50IE1VU1QgTk9UIA0KICAgYXR0ZW1wdCB0byBzb3VyY2UgdGhlIGRhdGEgZnJv bSB0aGUgZGF0YSBzZXJ2ZXJzLiAgSW5zdGVhZCwgaXQgc2hvdWxkIA0KICAgYXR0ZW1wdCB0byBj b21taXQgdGhlIGJsb2NrcyBpbiBxdWVzdGlvbiB0byB0aGUgc2VydmVyIGR1cmluZyB0aGUgDQog ICBzZXJ2ZXIncyByZWNvdmVyeSBncmFjZSBwZXJpb2QsIGJ5IHNlbmRpbmcgYSBMQVlPVVRDT01N SVQgd2l0aCB0aGUgDQogICAibG9jYV9yZWNsYWltIiBmbGFnIHNldCB0byB0cnVlLiBUaGlzIHBy b2Nlc3MgaXMgZGVzY3JpYmVkIGluIGRldGFpbCANCiAgIGluIFtORlN2NC4xXSBzZWN0aW9uIDE4 LjQyLjQuIA0KCjIuNS4gUmVjYWxsaW5nIHJlc291cmNlczogQ0JfUkVDQUxMX0FOWSANCgogICBU aGUgc2VydmVyIG1heSBkZWNpZGUgdGhhdCBpdCBjYW5ub3QgaG9sZCBhbGwgb2YgdGhlIHN0YXRl IGZvciANCiAgIGxheW91dHMgd2l0aG91dCBydW5uaW5nIG91dCBvZiByZXNvdXJjZXMuIEluIHN1 Y2ggYSBjYXNlLCBpdCBpcyBmcmVlIA0KICAgdG8gcmVjYWxsIGluZGl2aWR1YWwgbGF5b3V0cyB1 c2luZyBDQl9MQVlPVVRSRUNBTEwgdG8gcmVkdWNlIHRoZSANCiAgIGxvYWQsIG9yIGl0IG1heSBj aG9vc2UgdG8gcmVxdWVzdCB0aGF0IHRoZSBjbGllbnQgcmV0dXJuIGFueSBsYXlvdXQuIA0KCiAg IEZvciB0aGUgYmxvY2sgbGF5b3V0IHdlIGRlZmluZSB0aGUgZm9sbG93aW5nIGJpdCANCgogICBj b25zdCBSQ0E0X0JMS19MQVlPVVRfUkVDQUxMX0FOWV9MQVlPVVRTID0gNCANCgogICBXaGVuIHRo ZSBzZXJ2ZXIgc2VuZHMgYSBDQl9SRUNBTExfQU5ZIHJlcXVlc3QgdG8gYSBjbGllbnQgc3BlY2lm eWluZyANCiAgIHRoZSBSQ0E0X0JMS19MQVlPVVRfUkVDQUxMX0FOWV9MQVlPVVRTIGJpdCBpbiBj cmFhX3R5cGVfbWFzaywgdGhlIA0KICAgY2xpZW50IHNob3VsZCBpbW1lZGlhdGVseSByZXNwb25k IHdpdGggTkZTNF9PSywgYW5kIHRoZW4gDQogICBhc3luY2hyb25vdXNseSByZXR1cm4gY29tcGxl dGUgZmlsZSBsYXlvdXRzIHVudGlsIHRoZSBudW1iZXIgb2YgZmlsZXMgDQogICB3aXRoIGxheW91 dHMgY2FjaGVkIG9uIHRoZSBjbGllbnQgaXMgbGVzcyB0aGUgY3JhYV9vYmplY3RfdG9fa2VlcC4g DQoKICAgVGhlIGJsb2NrIGxheW91dCBkb2VzIG5vdCBjdXJyZW50bHkgdXNlIGJpdHMgNSwgNiBv ciA3LiAgSWYgYW55IG9mIA0KICAgdGhlc2UgYml0cyBhcmUgc2V0LCB0aGUgY2xpZW50IHNob3Vs ZCByZXR1cm4gTkZTNEVSUl9JTlZBTC4gDQogDQogDQpCbGFjayAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDE4XSANCiAgICAMDQoK CgoKCgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2svVm9sdW1lIExheW91dCAgICAg ICAgICAgICAgTWFyY2ggMjAwNyANCiAgICANCgoyLjYuIFRyYW5zaWVudCBhbmQgUGVybWFuZW50 IEVycm9ycyANCgogICBUaGUgc2VydmVyIG1heSByZXNwb25kIHRvIExBWU9VVEdFVCB3aXRoIGEg dmFyaWV0eSBvZiBlcnJvciBzdGF0dXNlcy4gDQogICBUaGVzZSBlcnJvcnMgY2FuIGNvbnZleSB0 cmFuc2llbnQgY29uZGl0aW9ucyBvciBtb3JlIHBlcm1hbmVudCANCiAgIGNvbmRpdGlvbnMgdGhh dCBhcmUgdW5saWtlbHkgdG8gYmUgcmVzb2x2ZWQgc29vbi4gDQoKICAgVGhlIHRyYW5zaWVudCBl cnJvcnMsIE5GUzRFUlJfUkVDQUxMQ09ORkxJQ1QgYW5kIE5GUzRFUlJfVFJZTEFURVIgYXJlIA0K ICAgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBzZXJ2ZXIgY2Fubm90IGltbWVkaWF0ZWx5IGdy YW50IHRoZSBsYXlvdXQgDQogICB0byB0aGUgY2xpZW50LiAgSW4gdGhlIGZvcm1lciBjYXNlIHRo aXMgaXMgYmVjYXVzZSB0aGUgc2VydmVyIGhhcyANCiAgIHJlY2VudGx5IGlzc3VlZCBhIENCX0xB WU9VVFJFQ0FMTCB0byB0aGUgcmVxdWVzdGluZyBjbGllbnQsIHdoZXJlYXMgDQogICBpbiB0aGUg Y2FzZSBvZiBORlM0RVJSX1RSWUxBVEVSLCB0aGUgc2VydmVyIGNhbm5vdCBncmFudCB0aGUgcmVx dWVzdCANCiAgIHBvc3NpYmx5IGR1ZSB0byBzaGFyaW5nIGNvbmZsaWN0cyB3aXRoIG90aGVyIGNs aWVudHMuICBJbiBlaXRoZXIgDQogICBjYXNlLCBhIHJlYXNvbmFibGUgYXBwcm9hY2ggZm9yIHRo ZSBjbGllbnQgaXMgdG8gd2FpdCBzZXZlcmFsIA0KICAgbWlsbGlzZWNvbmRzIGFuZCByZXRyeSB0 aGUgcmVxdWVzdC4gIFRoZSBjbGllbnQgU0hPVUxEIHRyYWNrIHRoZSANCiAgIG51bWJlciBvZiBy ZXRyaWVzLCBhbmQgaWYgZm9yd2FyZCBwcm9ncmVzcyBpcyBub3QgbWFkZSwgdGhlIGNsaWVudCAN CiAgIFNIT1VMRCBzZW5kIHRoZSBSRUFEIG9yIFdSSVRFIG9wZXJhdGlvbiBkaXJlY3RseSB0byB0 aGUgc2VydmVyLiANCgogICBUaGUgZXJyb3IgTkZTNEVSUl9MQVlPVVRVTkFWQUlMQUJMRSBtYXkg YmUgcmV0dXJuZWQgYnkgdGhlIHNlcnZlciBpZiANCiAgIGxheW91dHMgYXJlIG5vdCBzdXBwb3J0 ZWQgZm9yIHRoZSByZXF1ZXN0ZWQgZmlsZSBvciBpdHMgY29udGFpbmluZyANCiAgIGZpbGUgc3lz dGVtLiAgVGhlIHNlcnZlciBtYXkgYWxzbyByZXR1cm4gdGhpcyBlcnJvciBjb2RlIGlmIHRoZSAN CiAgIHNlcnZlciBpcyB0aGUgcHJvZ3Jlc3Mgb2YgbWlncmF0aW5nIHRoZSBmaWxlIGZyb20gc2Vj b25kYXJ5IHN0b3JhZ2UsIA0KICAgb3IgZm9yIGFueSBvdGhlciByZWFzb24gd2hpY2ggY2F1c2Vz IHRoZSBzZXJ2ZXIgdG8gYmUgdW5hYmxlIHRvIA0KICAgc3VwcGx5IHRoZSBsYXlvdXQuICBBcyBh IHJlc3VsdCBvZiByZWNlaXZpbmcgDQogICBORlM0RVJSX0xBWU9VVFVOQVZBSUxBQkxFLCB0aGUg Y2xpZW50IFNIT1VMRCBzZW5kIGZ1dHVyZSBSRUFEIGFuZCANCiAgIFdSSVRFIHJlcXVlc3RzIGRp cmVjdGx5IHRvIHRoZSBzZXJ2ZXIuICBJdCBpcyBleHBlY3RlZCB0aGF0IGEgY2xpZW50IA0KICAg d2lsbCBub3QgY2FjaGUgdGhlIGZpbGUncyBsYXlvdXR1bmF2YWlsYWJsZSBzdGF0ZSBmb3JldmVy LCBwYXJ0aWN1bGFyIA0KICAgaWYgdGhlIGZpbGUgaXMgY2xvc2VkLCBhbmQgdGh1cyBldmVudHVh bGx5LCB0aGUgY2xpZW50IE1BWSByZWlzc3VlIGEgDQogICBMQVlPVVRHRVQgb3BlcmF0aW9uLiAN CgozLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCgogICBUeXBpY2FsbHksIFNBTiBkaXNrIGFy cmF5cyBhbmQgU0FOIHByb3RvY29scyBwcm92aWRlIGFjY2VzcyBjb250cm9sIA0KICAgbWVjaGFu aXNtcyAoYWNjZXNzLWxvZ2ljcywgbHVuIG1hc2tpbmcsIGV0Yy4pIHdoaWNoIG9wZXJhdGUgYXQg dGhlIA0KICAgZ3JhbnVsYXJpdHkgb2YgaW5kaXZpZHVhbCBob3N0cy4gIFRoZSBmdW5jdGlvbmFs aXR5IHByb3ZpZGVkIGJ5IHN1Y2ggDQogICBtZWNoYW5pc21zIG1ha2VzIGl0IHBvc3NpYmxlIGZv ciB0aGUgc2VydmVyIHRvICJmZW5jZSIgaW5kaXZpZHVhbCANCiAgIGNsaWVudCBtYWNoaW5lcyBm cm9tIGNlcnRhaW4gcGh5c2ljYWwgZGlza3MtLS10aGF0IGlzIHRvIHNheSwgdG8gDQogICBwcmV2 ZW50IGluZGl2aWR1YWwgY2xpZW50IG1hY2hpbmVzIGZyb20gcmVhZGluZyBvciB3cml0aW5nIHRv IGNlcnRhaW4gDQogICBwaHlzaWNhbCBkaXNrcy4gIEZpbmVyLWdyYWluZWQgYWNjZXNzIGNvbnRy b2wgbWV0aG9kcyBhcmUgbm90IA0KICAgZ2VuZXJhbGx5IGF2YWlsYWJsZS4gIEZvciB0aGlzIHJl YXNvbiwgY2VydGFpbiBzZWN1cml0eSANCiAgIHJlc3BvbnNpYmlsaXRpZXMgYXJlIGRlbGVnYXRl ZCB0byBwTkZTIGNsaWVudHMgZm9yIGJsb2NrL3ZvbHVtZSANCiAgIGxheW91dHMuICBCbG9jay92 b2x1bWUgc3RvcmFnZSBzeXN0ZW1zIGdlbmVyYWxseSBjb250cm9sIGFjY2VzcyBhdCBhIA0KICAg dm9sdW1lIGdyYW51bGFyaXR5LCBhbmQgaGVuY2UgcE5GUyBjbGllbnRzIGhhdmUgdG8gYmUgdHJ1 c3RlZCB0byBvbmx5IA0KICAgcGVyZm9ybSBhY2Nlc3NlcyBhbGxvd2VkIGJ5IHRoZSBsYXlvdXQg ZXh0ZW50cyB0aGV5IGN1cnJlbnRseSBob2xkIA0KICAgKGUuZy4sIGFuZCBub3QgYWNjZXNzIHN0 b3JhZ2UgZm9yIGZpbGVzIG9uIHdoaWNoIGEgbGF5b3V0IGV4dGVudCBpcyANCiAgIG5vdCBoZWxk KS4gIEluIGdlbmVyYWwsIHRoZSBzZXJ2ZXIgd2lsbCBub3QgYmUgYWJsZSB0byBwcmV2ZW50IGEg DQogICBjbGllbnQgd2hpY2ggaG9sZHMgYSBsYXlvdXQgZm9yIGEgZmlsZSBmcm9tIGFjY2Vzc2lu ZyBwYXJ0cyBvZiB0aGUgDQogICBwaHlzaWNhbCBkaXNrIG5vdCBjb3ZlcmVkIGJ5IHRoZSBsYXlv dXQuICBTaW1pbGFybHksIHRoZSBzZXJ2ZXIgd2lsbCANCiANCiANCkJsYWNrICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTldIA0K ICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5 b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIG5vdCBiZSBhYmxlIHRvIHBy ZXZlbnQgYSBjbGllbnQgZnJvbSBhY2Nlc3NpbmcgYmxvY2tzIGNvdmVyZWQgYnkgYSANCiAgIGxh eW91dCB0aGF0IGl0IGhhcyBhbHJlYWR5IHJldHVybmVkLiAgVGhpcyBibG9jay1iYXNlZCBsZXZl bCBvZiANCiAgIHByb3RlY3Rpb24gbXVzdCBiZSBwcm92aWRlZCBieSB0aGUgY2xpZW50IHNvZnR3 YXJlLiANCgogICBBbiBhbHRlcm5hdGl2ZSBtZXRob2Qgb2YgYmxvY2svdm9sdW1lIHByb3RvY29s IHVzZSBpcyBmb3IgdGhlIHN0b3JhZ2UgDQogICBkZXZpY2VzIHRvIGV4cG9ydCB2aXJ0dWFsaXpl ZCBibG9jayBhZGRyZXNzZXMsIHdoaWNoIGRvIHJlZmxlY3QgdGhlIA0KICAgZmlsZXMgdG8gd2hp Y2ggYmxvY2tzIGJlbG9uZy4gIFRoZXNlIHZpcnR1YWwgYmxvY2sgYWRkcmVzc2VzIGFyZSANCiAg IGV4cG9ydGVkIHRvIHBORlMgY2xpZW50cyB2aWEgbGF5b3V0cy4gIFRoaXMgYWxsb3dzIHRoZSBz dG9yYWdlIGRldmljZSANCiAgIHRvIG1ha2UgYXBwcm9wcmlhdGUgYWNjZXNzIGNoZWNrcywgd2hp bGUgbWFwcGluZyB2aXJ0dWFsIGJsb2NrIA0KICAgYWRkcmVzc2VzIHRvIHBoeXNpY2FsIGJsb2Nr IGFkZHJlc3Nlcy4gIEluIGVudmlyb25tZW50cyB3aGVyZSB0aGUgDQogICBzZWN1cml0eSByZXF1 aXJlbWVudHMgYXJlIHN1Y2ggdGhhdCBjbGllbnQtc2lkZSBwcm90ZWN0aW9uIGZyb20gDQogICBh Y2Nlc3MgdG8gc3RvcmFnZSBvdXRzaWRlIG9mIHRoZSBsYXlvdXQgaXMgbm90IHN1ZmZpY2llbnQg cE5GUyANCiAgIGJsb2NrL3ZvbHVtZSBzdG9yYWdlIGxheW91dHMgZm9yIHBORlMgU0hPVUxEIE5P VCBiZSB1c2VkLCB1bmxlc3MgdGhlIA0KICAgc3RvcmFnZSBkZXZpY2UgaXMgYWJsZSB0byBpbXBs ZW1lbnQgdGhlIGFwcHJvcHJpYXRlIGFjY2VzcyBjaGVja3MsIA0KICAgdmlhIHVzZSBvZiB2aXJ0 dWFsaXplZCBibG9jayBhZGRyZXNzZXMsIG9yIG90aGVyIG1lYW5zLiANCgogICBUaGlzIGFsc28g aGFzIGltcGxpY2F0aW9ucyBmb3Igc29tZSBORlN2NCBmdW5jdGlvbmFsaXR5IG91dHNpZGUgcE5G Uy4gIA0KICAgRm9yIGluc3RhbmNlLCBpZiBhIGZpbGUgaXMgY292ZXJlZCBieSBhIG1hbmRhdG9y eSByZWFkLW9ubHkgbG9jaywgdGhlIA0KICAgc2VydmVyIGNhbiBlbnN1cmUgdGhhdCBvbmx5IHJl YWRhYmxlIGxheW91dHMgZm9yIHRoZSBmaWxlIGFyZSBncmFudGVkIA0KICAgdG8gcE5GUyBjbGll bnRzLiAgSG93ZXZlciwgaXQgaXMgdXAgdG8gZWFjaCBwTkZTIGNsaWVudCB0byBlbnN1cmUgDQog ICB0aGF0IHRoZSByZWFkYWJsZSBsYXlvdXQgaXMgdXNlZCBvbmx5IHRvIHNlcnZpY2UgcmVhZCBy ZXF1ZXN0cywgYW5kIA0KICAgbm90IHRvIGFsbG93IHdyaXRlcyB0byB0aGUgZXhpc3RpbmcgcGFy dHMgb2YgdGhlIGZpbGUuICBTaW5jZSANCiAgIGJsb2NrL3ZvbHVtZSBzdG9yYWdlIHN5c3RlbXMg YXJlIGdlbmVyYWxseSBub3QgY2FwYWJsZSBvZiBlbmZvcmNpbmcgDQogICBzdWNoIGZpbGUtYmFz ZWQgc2VjdXJpdHksIGluIGVudmlyb25tZW50cyB3aGVyZSBwTkZTIGNsaWVudHMgY2Fubm90IA0K ICAgYmUgdHJ1c3RlZCB0byBlbmZvcmNlIHN1Y2ggcG9saWNpZXMsIHBORlMgYmxvY2svdm9sdW1l IHN0b3JhZ2UgDQogICBsYXlvdXRzIFNIT1VMRCBOT1QgYmUgdXNlZC4gDQoKICAgQWNjZXNzIHRv IGJsb2NrL3ZvbHVtZSBzdG9yYWdlIGlzIGxvZ2ljYWxseSBhdCBhIGxvd2VyIGxheWVyIG9mIHRo ZSANCiAgIEkvTyBzdGFjayB0aGFuIE5GU3Y0LCBhbmQgaGVuY2UgTkZTdjQgc2VjdXJpdHkgaXMg bm90IGRpcmVjdGx5IA0KICAgYXBwbGljYWJsZSB0byBwcm90b2NvbHMgdGhhdCBhY2Nlc3Mgc3Vj aCBzdG9yYWdlIGRpcmVjdGx5LiAgRGVwZW5kaW5nIA0KICAgb24gdGhlIHByb3RvY29sLCBzb21l IG9mIHRoZSBzZWN1cml0eSBtZWNoYW5pc21zIHByb3ZpZGVkIGJ5IE5GU3Y0IA0KICAgKGUuZy4s IGVuY3J5cHRpb24sIGNyeXB0b2dyYXBoaWMgaW50ZWdyaXR5KSBtYXkgbm90IGJlIGF2YWlsYWJs ZSwgb3IgDQogICBtYXkgYmUgcHJvdmlkZWQgdmlhIGRpZmZlcmVudCBtZWFucy4gIEF0IG9uZSBl eHRyZW1lLCBwTkZTIHdpdGggDQogICBibG9jay92b2x1bWUgc3RvcmFnZSBjYW4gYmUgdXNlZCB3 aXRoIHN0b3JhZ2UgYWNjZXNzIHByb3RvY29scyAoZS5nLiwgDQogICBwYXJhbGxlbCBTQ1NJKSB0 aGF0IHByb3ZpZGUgZXNzZW50aWFsbHkgbm8gc2VjdXJpdHkgZnVuY3Rpb25hbGl0eS4gIA0KICAg QXQgdGhlIG90aGVyIGV4dHJlbWUsIHBORlMgbWF5IGJlIHVzZWQgd2l0aCBzdG9yYWdlIHByb3Rv Y29scyBzdWNoIGFzIA0KICAgaVNDU0kgdGhhdCBwcm92aWRlIHNpZ25pZmljYW50IGZ1bmN0aW9u YWxpdHkuICBJdCBpcyB0aGUgDQogICByZXNwb25zaWJpbGl0eSBvZiB0aG9zZSBhZG1pbmlzdGVy aW5nIGFuZCBkZXBsb3lpbmcgcE5GUyB3aXRoIGEgDQogICBibG9jay92b2x1bWUgc3RvcmFnZSBh Y2Nlc3MgcHJvdG9jb2wgdG8gZW5zdXJlIHRoYXQgYXBwcm9wcmlhdGUgDQogICBwcm90ZWN0aW9u IGlzIHByb3ZpZGVkIHRvIHRoYXQgcHJvdG9jb2wgKHBoeXNpY2FsIHNlY3VyaXR5IGlzIGEgDQog ICBjb21tb24gbWVhbnMgZm9yIHByb3RvY29scyBub3QgYmFzZWQgb24gSVApLiAgSW4gZW52aXJv bm1lbnRzIHdoZXJlIA0KICAgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBmb3IgdGhlIHN0b3Jh Z2UgcHJvdG9jb2wgY2Fubm90IGJlIG1ldCwgDQogICBwTkZTIGJsb2NrL3ZvbHVtZSBzdG9yYWdl IGxheW91dHMgU0hPVUxEIE5PVCBiZSB1c2VkLiANCgogICBXaGVuIHNlY3VyaXR5IGlzIGF2YWls YWJsZSBmb3IgYSBzdG9yYWdlIHByb3RvY29sLCBpdCBpcyBnZW5lcmFsbHkgYXQgDQogICBhIGRp ZmZlcmVudCBncmFudWxhcml0eSBhbmQgd2l0aCBhIGRpZmZlcmVudCBub3Rpb24gb2YgaWRlbnRp dHkgdGhhbiANCiAgIE5GU3Y0IChlLmcuLCBORlN2NCBjb250cm9scyB1c2VyIGFjY2VzcyB0byBm aWxlcywgaVNDU0kgY29udHJvbHMgDQogDQogDQpCbGFjayAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDIwXSANCiAgICAMDQoKCgoK CgpJbnRlcm5ldC1EcmFmdCAgICAgICAgIHBORlMgQmxvY2svVm9sdW1lIExheW91dCAgICAgICAg ICAgICAgTWFyY2ggMjAwNyANCiAgICANCgogICBpbml0aWF0b3IgYWNjZXNzIHRvIHZvbHVtZXMp LiAgVGhlIHJlc3BvbnNpYmlsaXR5IGZvciBlbmZvcmNpbmcgDQogICBhcHByb3ByaWF0ZSBjb3Jy ZXNwb25kZW5jZXMgYmV0d2VlbiB0aGVzZSBzZWN1cml0eSBsYXllcnMgaXMgcGxhY2VkIA0KICAg dXBvbiB0aGUgcE5GUyBjbGllbnQuICBBcyB3aXRoIHRoZSBpc3N1ZXMgaW4gdGhlIGZpcnN0IHBh cmFncmFwaCBvZiANCiAgIHRoaXMgc2VjdGlvbiwgaW4gZW52aXJvbm1lbnRzIHdoZXJlIHRoZSBz ZWN1cml0eSByZXF1aXJlbWVudHMgYXJlIA0KICAgc3VjaCB0aGF0IGNsaWVudC1zaWRlIHByb3Rl Y3Rpb24gZnJvbSBhY2Nlc3MgdG8gc3RvcmFnZSBvdXRzaWRlIG9mIA0KICAgdGhlIGxheW91dCBp cyBub3Qgc3VmZmljaWVudCwgcE5GUyBibG9jay92b2x1bWUgc3RvcmFnZSBsYXlvdXRzICANCiAg IFNIT1VMRCBOT1QgYmUgdXNlZC4gDQoKNC4gQ29uY2x1c2lvbnMgDQoKICAgVGhpcyBkcmFmdCBz cGVjaWZpZXMgdGhlIGJsb2NrL3ZvbHVtZSBsYXlvdXQgdHlwZSBmb3IgcE5GUyBhbmQgDQogICBh c3NvY2lhdGVkIGZ1bmN0aW9uYWxpdHkuIA0KCjUuIElBTkEgQ29uc2lkZXJhdGlvbnMgDQoKICAg VGhlcmUgYXJlIG5vIElBTkEgY29uc2lkZXJhdGlvbnMgaW4gdGhpcyBkb2N1bWVudC4gIEFsbCBw TkZTIElBTkEgDQogICBDb25zaWRlcmF0aW9ucyBhcmUgY292ZXJlZCBpbiBbTkZTVjQuMV0uIA0K CjYuIFJldmlzaW9uIEhpc3RvcnkgDQoKICAgLTAwOiBJbml0aWFsIFZlcnNpb24gYXMgZHJhZnQt YmxhY2stcG5mcy1ibG9jay0wMCANCgogICAtMDE6IFJld29yayBkaXNjdXNzaW9uIG9mIGV4dGVu dHMgYXMgbG9ja3MgdG8gdGFsayBhYm91dCBleHRlbnRzIA0KICAgZ3JhbnRpbmcgYWNjZXNzIHBl cm1pc3Npb25zLiAgUmV3cml0ZSBvcGVyYXRpb24gb3JkZXJpbmcgc2VjdGlvbiB0byANCiAgIGRp c2N1c3MgZGVhZGxvY2tzIGFuZCByYWNlcyB0aGF0IGNhbiBjYXVzZSBwcm9ibGVtcy4gIEFkZCBu ZXcgc2VjdGlvbiANCiAgIG9uIHJlY2FsbCBjb21wbGV0aW9uLiAgQWRkIGNsaWVudCBjb3B5LW9u LXdyaXRlIGJhc2VkIG9uIHRleHQgZnJvbSANCiAgIENyYWlnIEV2ZXJoYXJ0LiANCgogICAtMDI6 IEZpeCBnbGl0Y2hlcyBpbiBleHRlbnQgc3RhdGUgZGVzY3JpcHRpb25zLiAgRGVzY3JpYmUgbW9z dCBpc3N1ZXMgDQogICBhcyBSRVNPTFZFRC4gIE1vc3Qgb2YgU2VjdGlvbiAzIGhhcyBiZWVuIGlu Y29ycG9yYXRlZCBpbnRvIHRoZSB0aGUgDQogICBtYWluIFBORkQgZHJhZnQsIGFkZCBOT1RFIHRv IHRoYXQgZWZmZWN0IGFuZCBzYXkgdGhhdCBpdCB3aWxsIGJlIA0KICAgZGVsZXRlZCBpbiB0aGUg bmV4dCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgKHdoaWNoIHNob3VsZCBiZSBhIGRyYWZ0LQ0KICAg aWV0Zi1uZnN2NCBkcmFmdCkuICBDbGVhbmluZyB1cCBhIG51bWJlciBvZiB0aGluZ3MgaGF2ZSBi ZWVuIGxlZnQgdG8gDQogICB0aGF0IGRyYWZ0IHJldmlzaW9uLCBpbmNsdWRpbmcgdGhlIGludGVy bG9ja3Mgd2l0aCB0aGUgdHlwZXMgaW4gdGhlIA0KICAgbWFpbiBwTkZTIGRyYWZ0LCBsYXlvdXQg c3RyaXBpbmcgc3VwcG9ydCwgYW5kIGZpbmlzaGluZyB0aGUgU2VjdXJpdHkgDQogICBDb25zaWRl cmF0aW9ucyBzZWN0aW9uLiANCgogICAtMDA6IE5ldyB2ZXJzaW9uIGFzIGRyYWZ0LWlldGYtbmZz djQtcG5mcy1ibG9jay4gIFJlbW92ZWQgcmVzb2x2ZWQgDQogICBvcGVyYXRpb25zIGlzc3VlcyAo U2VjdGlvbiAzKS4gIEFsaWduIHR5cGVzIHdpdGggbWFpbiBwTkZTIGRyYWZ0IA0KICAgKHdoaWNo IGlzIG5vdyBwYXJ0IG9mIHRoZSBORlN2NC4xIG1pbm9yIHZlcnNpb24gZHJhZnQpLCBhZGQgdm9s dW1lIA0KICAgc3RyaXBpbmcgYW5kIHNsaWNpbmcgc3VwcG9ydC4gIE5ldyBvcGVyYXRpb25zIGlz c3VlcyBhcmUgaW4gU2VjdGlvbiAzIA0KICAgLSB0aGUgbmVlZCBmb3IgYSAicmVjbGFpbSBiaXQi IGFuZCBFT0YgY29uY2VybnMgYXJlIHRoZSB0d28gbWFqb3IgDQogICBpc3N1ZXMuICBFeHRlbmRl ZCBhbmQgaW1wcm92ZWQgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24sIA0KICAg YnV0IGl0IHN0aWxsIG5lZWRzIHdvcmsuICBBZGRlZCAxLXNlbnRlbmNlIGNvbmNsdXNpb24gdGhh dCBhbHNvIHN0aWxsIA0KICAgbmVlZHMgd29yay4gDQoKCiANCiANCkJsYWNrICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMjFdIA0K ICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5 b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIC0wMTogQ2hhbmdlZCBkZWZp bml0aW9uIG9mIHBuZnNfYmxvY2tfZGV2aWNlYWRkcjQgdW5pb24gdG8gYWxsb3cgbW9yZSANCiAg IGNvbmNpc2UgcmVwcmVzZW50YXRpb24gb2YgYWdncmVnYXRlZCB2b2x1bWUgc3RydWN0dXJlcy4g IEZpeGVkIHR5cG9zIA0KICAgdG8gbWFrZSBib3RoIHBuZnNfYmxvY2tfbGF5b3V0dXBkYXRlIGFu ZCBwbmZzX2Jsb2NrX2xheW91dHJldHVybiANCiAgIHN0cnVjdHVyZXMgY29udGFpbiBleHRlbnQg bGlzdHMgaW5zdGVhZCBvZiBhIHNpbmdsZSBleHRlbnQuICBVcGRhdGVkIA0KICAgc2VjdGlvbiAy LjEuNiB0byByZW1vdmUgcmVmZXJlbmNlcyB0byBDQl9TSVpFQ0hBTkdFRC4gTW92ZWQgDQogICBk ZXNjcmlwdGlvbiBvZiByZWNvdmVyeSBmcm9tICJJc3N1ZXMiIHNlY3Rpb24gdG8gIkJsb2NrIExh eW91dCANCiAgIERlc2NyaXB0aW9uIiBzZWN0aW9uLiBSZW1vdmVkIHNlY3Rpb24gMy4yICJFbmQt b2YtZmlsZSBoYW5kbGluZyANCiAgIGlzc3VlcyIuICBNZXJnZWQgb2xkICJibG9jay92b2x1bWUg bGF5b3V0IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIiANCiAgIHNlY3Rpb24gZnJvbSBwcmV2aW91 cyB2ZXJzaW9uIG9mIFtORlN2NC4xXSB3aXRoIHNlY3Rpb24gNC4gIE1vdmVkIA0KICAgcGFyYWdy YXBoIG9uIGxpbmdlcmluZyB3cml0ZXMgdG8gdGhlIHNlY3Rpb24gd2hpY2ggZGVzY3JpYmVzIGxh eW91dCANCiAgIHJldHVybi4gIFJlbW92ZWQgSXNzdWVzIHNlY3Rpb24gKDMpIGFzIHRoZSByZW1h aW5pbmcgaXNzdWVzIGFyZSBhbGwgDQogICByZXNvbHZlZC4gDQoKICAgMDI6IENoYW5nZWQgcG5m c19kZXZpY2VhZGRyNCB0byBkZXZpY2VhZGRyNCB0byBtYXRjaCBbTkZTdjQuMV0uICANCiAgIFVw ZGF0ZWQgc2VjdGlvbiAyLjIuMiB0byBjbGFyaWZ5IHRoYXQgdGhlIGVzIGZpZWxkcyBtdXN0IGJl IA0KICAgUkVBRF9XUklURV9EQVRBIGluIHBuZnNfYmxvY2tfbGF5b3V0dXBkYXRlIHJlcXVlc3Rz LiAgVXBkYXRlZCBzZWN0aW9uIA0KICAgMi4yLjUgdG8gc3BlY2lmeSB0aGF0IGRhdGEgY29ycnVw dGlvbiBjYW4gb2NjdXI7IHRoYXQgcmVxdWVzdHMsIG5vdCANCiAgIHRoZSBjbGllbnQsIGFyZSBy ZWplY3RlZDsgdGhhdCBzZXJ2ZXIgIlNIT1VMRCIgcmVjYWxsIGNvbmZsaWN0aW5nIA0KICAgcG9y dGlvbnMgb2YgbGF5b3V0cy4gIENsYXJpZmllZCB0aGF0IHVuaWxhdGVyYWwgcmV2b2NhdGlvbiBt YXkgYWZmZWN0IA0KICAgbGF5b3V0cyBmcm9tIG90aGVyIGZpbGVzeXN0ZW1zLiAgQ2hhbmdlZCBz aWduYXR1cmUgb2Zmc2V0IHRvIGJlIGEgDQogICBzaWduZWQgcXVhbnRpdHkgdG8gYWxsb3cgZm9y IGxhYmVscyBhdCBhIGZpeGVkIGxvY2F0aW9uIGZyb20gdGhlIGVuZCANCiAgIG9mIGEgdm9sdW1l LiAgQ2hhbmdlZCBhbGwgZGF0YSBzdHJ1Y3R1cmVzIHRvIGhhdmUgc3VmZml4ICI0IiwgY2hhbmdl ZCANCiAgIGV4dGVudFN0YXRlNCB0byBwbmZzX2Jsb2NrX2V4dGVudF9zdGF0ZTQgYW5kIHNpZ0Nv bXBvbmVudCB0byANCiAgIHBuZnNfYmxvY2tfc2lnX2NvbXBvbmVudDQsIHRvIGNvbmZvcm0gdG8g W05GU3Y0LjFdLiANCgogICAwMzogTW92ZWQgc2VjdGlvbnMgR0VUREVWSUNFTElTVCBhbmQgR0VU REVWSUNFSU5GTyBlYXJsaWVyIGluIA0KICAgZG9jdW1lbnQgZm9yIGJldHRlciByZWFkYWJpbGl0 eS4gIEFkZGVkIHBuZnNfYmxvY2tfc2ltcGxlX3ZvbHVtZTQgDQogICBkYXRhIHN0cnVjdHVyZSwg YW5kIGFkZGVkIHZvbHVtZV9pZCBmaWVsZHMgdG8gYWxsIHBuZnNfYmxvY2sgdm9sdW1lIA0KICAg aW5mbyBkYXRhIHN0cnVjdHVyZXMuIA0KCiAgIDA0OiBBZGRlZCBpbmZvcm1hdGlvbiBhYm91dCBk ZXZpY2UgaWRzIHRvIGNsYXJpZnkgdGhlaXIgdXNhZ2UuICANCiAgIERlc2NyaWJlZCB3aGVyZSB0 aGUgcG5mc19ibG9ja19kZXZpY2VhZGRyNCBkYXRhIHN0cnVjdHVyZSBpcyBmb3VuZCB0byANCiAg IGJlIGFjY3VyYXRlIHdpdGggZHJhZnQtaWV0Zi1uZnN2NC1taW5vcnZlcnNpb24xLTE0LiAgVXBk YXRlZCANCiAgIHJlZmVyZW5jZXMgZnJvbSAtMDggdG8gLTE0LiAgUmVtb3ZlZCByb290X2lkIGZy b20gDQogICBwbmZzX2Jsb2NrX2RldmljZWFkZHI0LiAgQ2hhbmdlZCAnYnl0ZScgdG8gJ29jdGV0 Jy4gIENsYXJpZnkgdGhlIA0KICAgYmxvY2sgc2l6ZSBhbmQgc3RyaXBlIHNpemUgaW4gdm9sdW1l IGRhdGEgc3RydWN0dXJlcy4gIFJlbmFtZSANCiAgICd2b2x1bWUnIGFuZCAnaWQnIHRvIGJlICd2 b2xfaWQnIGNvbnNpc3RlbnRseS4gIEFkZGVkIHNlY3Rpb25zIG9uIA0KICAgQ0JfUkVDQUxMX0FO WSBhbmQgZmVuY2luZy4gDQoKNy4gQWNrbm93bGVkZ21lbnRzIA0KCiAgIFRoaXMgZHJhZnQgZHJh d3MgZXh0ZW5zaXZlbHkgb24gdGhlIGF1dGhvcnMnIGZhbWlsaWFyaXR5IHdpdGggdGhlIA0KICAg bWFwcGluZyBmdW5jdGlvbmFsaXR5IGFuZCBwcm90b2NvbCBpbiBFTUMncyBIaWdoUm9hZCBzeXN0 ZW0gDQogICBbSGlnaFJvYWRdLiAgVGhlIHByb3RvY29sIHVzZWQgYnkgSGlnaFJvYWQgaXMgY2Fs bGVkIEZNUCAoRmlsZSANCiAgIE1hcHBpbmcgUHJvdG9jb2wpOyBpdCBpcyBhbiBhZGQtb24gcHJv dG9jb2wgdGhhdCBydW5zIGluIHBhcmFsbGVsIA0KICAgd2l0aCBmaWxlc3lzdGVtIHByb3RvY29s cyBzdWNoIGFzIE5GU3YzIHRvIHByb3ZpZGUgcE5GUy1saWtlIA0KICAgZnVuY3Rpb25hbGl0eSBm b3IgYmxvY2svdm9sdW1lIHN0b3JhZ2UuICBXaGlsZSBkcmF3aW5nIG9uIEhpZ2hSb2FkIA0KIA0K IA0KQmxhY2sgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAg ICAgICAgICBbUGFnZSAyMl0gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBw TkZTIEJsb2NrL1ZvbHVtZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoK ICAgRk1QLCB0aGUgZGF0YSBzdHJ1Y3R1cmVzIGFuZCBmdW5jdGlvbmFsIGNvbnNpZGVyYXRpb25z IGluIHRoaXMgZHJhZnQgDQogICBkaWZmZXIgaW4gc2lnbmlmaWNhbnQgd2F5cywgYmFzZWQgb24g bGVzc29ucyBsZWFybmVkIGFuZCB0aGUgDQogICBvcHBvcnR1bml0eSB0byB0YWtlIGFkdmFudGFn ZSBvZiBORlN2NCBmZWF0dXJlcyBzdWNoIGFzIENPTVBPVU5EIA0KICAgb3BlcmF0aW9ucy4gIFRo ZSBkZXNpZ24gdG8gc3VwcG9ydCBwTkZTIGNsaWVudCBwYXJ0aWNpcGF0aW9uIGluIGNvcHktDQog ICBvbi13cml0ZSBpcyBiYXNlZCBvbiB0ZXh0IGFuZCBpZGVhcyBjb250cmlidXRlZCBieSBDcmFp ZyBFdmVyaGFydCANCiAgIChmb3JtZXJseSB3aXRoIElCTSkuIA0KCjguIFJlZmVyZW5jZXMgDQoK OC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyANCgogICBbUkZDMjExOV0gQnJhZG5lciwgUy4sICJL ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIA0KICAgICAgICAgICAgIFJlcXVp cmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuIA0KCiAgIFtORlNW NC4xXSBTaGVwbGVyLCBTLiwgRWlzbGVyLCBNLiwgYW5kIE5vdmVjaywgRC4gZWQuLCAiTkZTdjQg TWlub3IgDQogICAgICAgICAgICAgVmVyc2lvbiAxIiwgZHJhZnQtaWV0Zi1uZnN2NC1taW5vcnZl cnNpb24xLTE0LnR4dCwgSW50ZXJuZXQgDQogICAgICAgICAgICAgRHJhZnQsIEp1bHkgMjAwNy4g DQoKOC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIA0KCiAgIFtIaWdoUm9hZF0gRU1DIENvcnBv cmF0aW9uLCAiRU1DIENlbGVycmEgSGlnaFJvYWQiLCBFTUMgQzgxOS4xIHdoaXRlIA0KICAgICAg ICAgICAgICBwYXBlciwgYXZhaWxhYmxlIGF0OiANCiAgIGh0dHA6Ly93d3cuZW1jLmNvbS9wZGYv cHJvZHVjdHMvY2VsZXJyYV9maWxlX3NlcnZlci9IaWdoUm9hZF93cC5wZGYgDQogICAgICAgICAg ICAgIGxpbmsgY2hlY2tlZCAyOSBBdWd1c3QgMjAwNi4gICAgICAgDQoKICAgW1NNSVNdIFNOSUEs ICJTTklBIFN0b3JhZ2UgTWFuYWdlbWVudCBJbml0aWF0aXZlIFNwZWNpZmljYXRpb24iLCANCiAg ICAgICAgICAgIHZlcnNpb24gMS4wLjIsIGF2YWlsYWJsZSBhdDogDQogICBodHRwOi8vd3d3LnNu aWEub3JnL3NtaS90ZWNoX2FjdGl2aXRpZXMvc21pX3NwZWNfcHIvc3BlYy9TTUlTXzFfMF8yX2YN CiAgIGluYWwucGRmIA0KCkF1dGhvcidzIEFkZHJlc3NlcyANCgogICBEYXZpZCBMLiBCbGFjayAN CiAgIEVNQyBDb3Jwb3JhdGlvbiANCiAgIDE3NiBTb3V0aCBTdHJlZXQgDQogICBIb3BraW50b24s IE1BIDAxNzQ4IA0KICAgICAgIA0KICAgUGhvbmU6ICsxICg1MDgpIDI5My03OTUzIA0KICAgRW1h aWw6IGJsYWNrX2RhdmlkQGVtYy5jb20gDQogICAgDQoKCgoKCgoKIA0KIA0KQmxhY2sgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDcgICAgICAgICAgICAgICAgICBbUGFnZSAy M10gDQogICAgDA0KCgoKCgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICBwTkZTIEJsb2NrL1ZvbHVt ZSBMYXlvdXQgICAgICAgICAgICAgIE1hcmNoIDIwMDcgDQogICAgDQoKICAgU3RlcGhlbiBGcmlk ZWxsYSANCiAgIEVNQyBDb3Jwb3JhdGlvbiANCiAgIDIyOCBTb3V0aCBTdHJlZXQgDQogICBIb3Br aW50b24sIE1BICAwMTc0OCANCiAgICAgICANCiAgIFBob25lOiArMSAoNTA4KSAyNDktMzUyOCAN CiAgIEVtYWlsOiBmcmlkZWxsYV9zdGVwaGVuQGVtYy5jb20gDQogICAgDQogICBKYXNvbiBHbGFz Z293IA0KICAgRU1DIENvcnBvcmF0aW9uIA0KICAgMzIgQ29zbGluIERyaXZlIA0KICAgU291dGhi b3JvLCBNQSAgMDE3NzIgDQogICAgICAgDQogICBQaG9uZTogKzEgKDUwOCkgMzA1IDg4MzEgDQog ICBFbWFpbDogZ2xhc2dvd19qYXNvbkBlbWMuY29tIA0KICAgIA0KCkludGVsbGVjdHVhbCBQcm9w ZXJ0eSBTdGF0ZW1lbnQgDQoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5n IHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkgDQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkg UmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8gDQogICBwZXJ0 YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3Jp YmVkIGluIA0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNl bnNlIHVuZGVyIHN1Y2ggcmlnaHRzIA0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJs ZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIA0KICAgbWFkZSBhbnkgaW5kZXBl bmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uIA0K ICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1l bnRzIGNhbiBiZSANCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LiANCgogICBDb3BpZXMg b2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueSAN CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSBy ZXN1bHQgb2YgYW4gDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNl IG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YgDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0 cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcyANCiAgIHNwZWNpZmljYXRpb24gY2Fu IGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdCANCiAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiANCgogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRl cmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55IA0KICAgY29weXJpZ2h0 cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeSAN CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVk IHRvIGltcGxlbWVudCANCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5m b3JtYXRpb24gdG8gdGhlIElFVEYgYXQgaWV0Zi0NCiAgIGlwckBpZXRmLm9yZy4gDQoKRGlzY2xh aW1lciBvZiBWYWxpZGl0eSANCgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4gDQogICAiQVMgSVMiIGJhc2lzIGFu ZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMgDQog ICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZLCBUSEUg SUVURiBUUlVTVCBBTkQgDQogICBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBE SVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyANCiANCiANCkJsYWNrICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMjRdIA0K ICAgIAwNCgoKCgoKCkludGVybmV0LURyYWZ0ICAgICAgICAgcE5GUyBCbG9jay9Wb2x1bWUgTGF5 b3V0ICAgICAgICAgICAgICBNYXJjaCAyMDA3IA0KICAgIA0KCiAgIE9SIElNUExJRUQsIElOQ0xV RElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiANCiAg IFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBB TlkgSU1QTElFRCANCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiANCgpDb3B5cmlnaHQgU3RhdGVtZW50IA0KCiAgIENv cHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLiANCgogICBUaGlzIGRvY3VtZW50IGlz IHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyANCiAgIGNv bnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBh dXRob3JzIA0KICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuIA0KCkFja25vd2xlZGdtZW50IA0K CiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92 aWRlZCBieSB0aGUgDQogICBJbnRlcm5ldCBTb2NpZXR5LiANCgogDQoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCiANCiANCkJsYWNrICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3Vz dCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgMjVdIA0KICAgIAw= ------=_Part_26103_14018844.1191508103194 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 ------=_Part_26103_14018844.1191508103194-- From nfsv4-bounces@ietf.org Thu Oct 04 11:24:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSXf-0005gl-Dk; Thu, 04 Oct 2007 11:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSXe-0005f9-GD for nfsv4@ietf.org; Thu, 04 Oct 2007 11:23:10 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdSXa-0004uU-5S for nfsv4@ietf.org; Thu, 04 Oct 2007 11:23:10 -0400 X-IronPort-AV: E=Sophos;i="4.21,230,1188802800"; d="scan'208";a="110790475" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 04 Oct 2007 08:23:00 -0700 Received: from sacexrs01.hq.netapp.com (sacexrs01.hq.netapp.com [10.99.190.105]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l94FMx8l005087; Thu, 4 Oct 2007 08:23:00 -0700 (PDT) Received: from RTPEXMV01.hq.netapp.com ([10.100.157.176]) by sacexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 08:22:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Request for an additional recommended attribute Date: Thu, 4 Oct 2007 11:22:57 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Request for an additional recommended attribute Thread-Index: AcgGe+b8XF3yHcguTTqjxIrEh4Q01wAFD/UgAAKH/ZA= References: From: "Everhart, Craig" To: "Noveck, Dave" , "Talpey, Thomas" , X-OriginalArrivalTime: 04 Oct 2007 15:22:59.0785 (UTC) FILETIME=[729F9390:01C8069A] X-Spam-Score: -4.0 (----) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org How is it that the client will know this and the server will not, anyway? Is there something that puts the client in the driver's seat here, or might it be the case that the server will know and will need to tell the client? Craig=20 > -----Original Message----- > From: Noveck, Dave=20 > Sent: Thursday, October 04, 2007 10:16 AM > To: Talpey, Thomas; Glasgow_Jason@emc.com > Cc: nfsv4@ietf.org > Subject: RE: [nfsv4] Request for an additional recommended attribute >=20 > My understanding is that this is to take the place of=20 > fencing, i.e. to provide to the protocol implementation=20 > time-based promises which can be relied upon to avoid a=20 > requirement for actual fencing. David Black's concern has=20 > been that requiring actual fencing support would limit the=20 > deployment of pnfs for blocks which limitation he believes=20 > would be a bad thing. >=20 > -----Original Message----- > From: Talpey, Thomas > Sent: Thursday, October 04, 2007 7:34 AM > To: Glasgow_Jason@emc.com > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Request for an additional recommended attribute >=20 >=20 > It's not clear if this text is making a requirement that every NFSv4.1 > server > implement a bounded maximum I/O time, or if the client is able to > request > one. Also, it is not clear to me whether this time is global=20 > across all > I/Os > at the server, all I/Os for this clientid or sessionid, or=20 > whether it's > per-file. >=20 > Can you clarify? If it's a server-global mandatory requirement, I have > some > strong concerns.=20 >=20 > Is this really fencing btw? Usually I think of fencing as a way for a > server > to deny access to clients which fall out of a cluster. >=20 > Tom. >=20 > At 05:26 PM 10/3/2007, Glasgow_Jason@emc.com wrote: > >Content-class: urn:content-classes:message > >Content-Type: multipart/alternative; > > boundary=3D"----_=3D_NextPart_001_01C80604.03F942D3" > > > >In describing how the pNFS block client will implement fencing, it > became necessary to define the maximum time that an I/O can be > outstanding. The client needs to communicate its value to the pNFS > server. The most appropriate means of doing so seems to be=20 > to provide a > per server R/W recommended attribute, which clients can write. > >=20 > >I propose updating section 5.6 "Recommended Attributes - Definitions" > with the following > >=20 > >maximum_io_time 74 uint32 R/W The default maximum time that a > client > > I/O to a data server can=20 > be active. > > Clients may update this value. > >=20 > >=20 > >=20 > >This parameter is defined in the next version of the pNFS=20 > block layout > spec as follows: > >=20 > >-- > >"maximum_io_time" is the maximum time it can take for a client I/O to > the storage system to either complete or fail; this value is often 30 > seconds or 60 seconds, but may be longer in some=20 > environments. . If the > maximum client I/O time cannot be bounded, this timed lease mechanism > MUST NOT be used. The client can use GETATTR to query the server's > default setting of "maximum_io_time". The server must=20 > respond with the > maximum I/O time in seconds. If the client's maximum I/O time is > greater than the server's default, then the client MUST use SETATTR to > inform the server of its maximum_I/O time. > >-- > >=20 > >Are there comments on introducing this new attribute into the NFSv4 > minor version 1 spec? Is this a valid means of communicating a client > specific value to the server? > >=20 > >-Jason Glasgow > >=20 > >=20 > >_______________________________________________ > >nfsv4 mailing list > >nfsv4@ietf.org > >https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Penn@mail.hearty.com Thu Oct 04 11:36:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSkS-0007B6-J9 for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 11:36:24 -0400 Received: from [80.180.2.117] (helo=[79.11.64.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdSkG-0003aE-Pc for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 11:36:13 -0400 Received: by 10.136.100.77 with SMTP id JVwXTcPNvZjnm; Thu, 4 Oct 2007 17:36:12 +0200 (GMT) Received: by 192.168.186.175 with SMTP id rypaOeWSWKkjot.8547393642808; Thu, 4 Oct 2007 17:36:10 +0200 (GMT) Message-ID: <000b01c8069c$47f60730$b6400b4f@benq8jgxh2maui> From: "freddie Penn" To: Subject: fassha"l Date: Thu, 4 Oct 2007 17:36:07 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C806AD.0B7ED730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C806AD.0B7ED730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://ebiotrae.com/ Evening nfsv4-archive This product is soooooooooo amazing.. get it today freddie Penn ------=_NextPart_000_0004_01C806AD.0B7ED730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://ebiotrae.com/
Evening nfsv4-archive
This product is soooooooooo amazing.. get it = today
freddie Penn
------=_NextPart_000_0004_01C806AD.0B7ED730-- From MichelegretaMobley@howstuffworks.com Thu Oct 04 12:15:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdTMC-00017D-SJ for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 12:15:24 -0400 Received: from [190.80.185.222] (helo=elohim16004c84.gateway.2wire.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdTMC-00054k-Iy for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 12:15:24 -0400 Received: from falmouth by howstuffworks.com with SMTP id ssyNEUoKrT for ; Thu, 4 Oct 2007 12:09:22 -0100 From: "Danielle Gibbons" To: Subject: Win $$$ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Visit and start seeing the dollars coming. We know how to treat our players - how about a $2400 welcome bonmus when you join? We know how to treat our players - how about a $2400 welcome bonmus when you join? Your own privater Vegas! http://trynetgambling.net/ From nfsv4-bounces@ietf.org Thu Oct 04 14:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVnq-0005AT-JS; Thu, 04 Oct 2007 14:52:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVnp-00059D-Iy for nfsv4@ietf.org; Thu, 04 Oct 2007 14:52:05 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdVno-0001pe-TF for nfsv4@ietf.org; Thu, 04 Oct 2007 14:52:05 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l94Iq0af003847; Thu, 4 Oct 2007 14:52:01 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l94IpxC0015272; Thu, 4 Oct 2007 14:51:59 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 14:51:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Request for an additional recommended attribute Date: Thu, 4 Oct 2007 14:51:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Request for an additional recommended attribute thread-index: AcgGe+b8XF3yHcguTTqjxIrEh4Q01wAFD/UgAAKC5sA= References: To: , X-OriginalArrivalTime: 04 Oct 2007 18:51:58.0783 (UTC) FILETIME=[A472D4F0:01C806B7] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Dave and Tom, > My understanding is that this is to take the place of fencing, i.e. to > provide to the protocol implementation time-based promises which can be > relied upon to avoid a requirement for actual fencing. David Black's > concern has been that requiring actual fencing support would limit the > deployment of pnfs for blocks which limitation he believes would be a > bad thing. Yes, it's in support of that mechanism - the basic idea is that the client stops using a layout when the client's leases expire (the actual timing is somewhat subtler due to client-server communication latency). The server needs to know how much longer it has to wait for client I/Os in flight before it can safely take back resources. The details are in the latest (just posted) version of the block layout draft. > It's not clear if this text is making a requirement that every NFSv4.1 server > implement a bounded maximum I/O time, or if the client is able to request > one. It's neither, this is the client telling the server what the max I/O time is for client I/O done against pNFS block layouts. Support for it would only be required if the pNFS block layout is supported (although I'd have no problem if other layouts found this useful). > Also, it is not clear to me whether this time is global across all I/Os > at the server, all I/Os for this clientid or sessionid, or whether it's per-file. Per-clientid. The maximum I/O time for a client I/O may depend on the client's I/O stack, so it's better to have the client tell the server than have the server guess (although 60 seconds will usually be a good guess). This is also the answer to Craig's question - the client knows the client's I/O stack significantly better than the server does, especially if the client and server aren't running the same OS. Forcing the client to tell the server is also a way to (try to) catch clients that may be in unbounded I/O territory and keep them from using the block layout. I'm not sure whether this aspect is important in practice (it may turn out to be a blame-redirection mechanism rather than a damage-prevention mechanism). In the reverse direction, allowing clients with lower I/O bounds to speed up failure processing is useful. > Can you clarify? If it's a server-global mandatory requirement, I have some > strong concerns.=20 It's only for clients and servers that implement the pNFS block layout, unless some other layout would find this useful. > Is this really fencing btw? Usually I think of fencing as a way for a > server to deny access to clients which fall out of a cluster. Dave Noveck's language at the start of this message is a better description - in essence, for the block layout, we're prepared to trust a client to fence itself if it's lost communication with the server for long enough to lose its leases. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Oct 04 14:57:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVtP-0005lK-7V; Thu, 04 Oct 2007 14:57:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVtN-0005km-Mk for nfsv4@ietf.org; Thu, 04 Oct 2007 14:57:49 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdVtJ-0003jp-HD for nfsv4@ietf.org; Thu, 04 Oct 2007 14:57:49 -0400 X-IronPort-AV: E=Sophos;i="4.21,231,1188802800"; d="scan'208";a="110855475" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 04 Oct 2007 11:57:19 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l94IvHpV008570; Thu, 4 Oct 2007 11:57:19 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 11:57:19 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 11:57:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Request for an additional recommended attribute Date: Thu, 4 Oct 2007 14:57:17 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Request for an additional recommended attribute Thread-Index: AcgGe+b8XF3yHcguTTqjxIrEh4Q01wAFD/UgAAKC5sAAB3ctAA== From: "Noveck, Dave" To: , "Talpey, Thomas" X-OriginalArrivalTime: 04 Oct 2007 18:57:19.0119 (UTC) FILETIME=[636239F0:01C806B8] X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > telling the server what the max I/O time > is for client I/O done against pNFS block layouts "telling" doesn't really cover it. It is making a promise or contract, and the correctness of the protocol will depend on that promise being honored. This is not informative in the normal sense.=20 -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Thursday, October 04, 2007 2:52 PM To: Noveck, Dave; Talpey, Thomas Cc: nfsv4@ietf.org Subject: RE: [nfsv4] Request for an additional recommended attribute Dave and Tom, > My understanding is that this is to take the place of fencing, i.e. to > provide to the protocol implementation time-based promises which can be > relied upon to avoid a requirement for actual fencing. David Black's > concern has been that requiring actual fencing support would limit the > deployment of pnfs for blocks which limitation he believes would be a > bad thing. Yes, it's in support of that mechanism - the basic idea is that the client stops using a layout when the client's leases expire (the actual timing is somewhat subtler due to client-server communication latency). The server needs to know how much longer it has to wait for client I/Os in flight before it can safely take back resources. The details are in the latest (just posted) version of the block layout draft. > It's not clear if this text is making a requirement that every NFSv4.1 server > implement a bounded maximum I/O time, or if the client is able to request > one. It's neither, this is the client telling the server what the max I/O time is for client I/O done against pNFS block layouts. Support for it would only be required if the pNFS block layout is supported (although I'd have no problem if other layouts found this useful). > Also, it is not clear to me whether this time is global across all I/Os > at the server, all I/Os for this clientid or sessionid, or whether it's per-file. Per-clientid. The maximum I/O time for a client I/O may depend on the client's I/O stack, so it's better to have the client tell the server than have the server guess (although 60 seconds will usually be a good guess). This is also the answer to Craig's question - the client knows the client's I/O stack significantly better than the server does, especially if the client and server aren't running the same OS. Forcing the client to tell the server is also a way to (try to) catch clients that may be in unbounded I/O territory and keep them from using the block layout. I'm not sure whether this aspect is important in practice (it may turn out to be a blame-redirection mechanism rather than a damage-prevention mechanism). In the reverse direction, allowing clients with lower I/O bounds to speed up failure processing is useful. > Can you clarify? If it's a server-global mandatory requirement, I have some > strong concerns.=20 It's only for clients and servers that implement the pNFS block layout, unless some other layout would find this useful. > Is this really fencing btw? Usually I think of fencing as a way for a > server to deny access to clients which fall out of a cluster. Dave Noveck's language at the start of this message is a better description - in essence, for the block layout, we're prepared to trust a client to fence itself if it's lost communication with the server for long enough to lose its leases. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From LouisacorporaMoreland@lyricsfreak.com Thu Oct 04 17:45:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdYVg-0001nE-Kf for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 17:45:32 -0400 Received: from pool-141-153-180-100.mad.east.verizon.net ([141.153.180.100] helo=user5ad4f1af13.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdYVg-0000vj-CZ for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 17:45:32 -0400 Received: from slimy by lyricsfreak.com with SMTP id HHrN8k7oHK for ; Thu, 4 Oct 2007 17:37:47 +0500 From: "Annabelle Kimble" To: Subject: If you're in the US or anywhere else, join your new casino paradise. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Come see what it means to be a VIP. USA players too! Download and GO! Play your favorite games and get $2400 welcome bonus. Your own privater Vegas! http://trynetgambling.net/ From nfsv4-bounces@ietf.org Thu Oct 04 18:16:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdYyS-0006Lg-0D; Thu, 04 Oct 2007 18:15:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdYyO-0006F0-TD; Thu, 04 Oct 2007 18:15:12 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdYyO-0002Br-GK; Thu, 04 Oct 2007 18:15:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2AAEC175DD; Thu, 4 Oct 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IdYyD-0000yT-Kx; Thu, 04 Oct 2007 18:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 04 Oct 2007 18:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nfsv4@ietf.org Subject: [nfsv4] I-D ACTION:draft-ietf-nfsv4-pnfs-block-04.txt X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : pNFS Block/Volume Layout Author(s) : D. Black, et al. Filename : draft-ietf-nfsv4-pnfs-block-04.txt Pages : 25 Date : 2007-10-4 Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations draft specifies storage-class-independent extensions to NFS; this draft specifies the additional extensions (primarily data structures) for use of pNFS with block and volume based storage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-pnfs-block-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-pnfs-block-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-pnfs-block-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-4170226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-pnfs-block-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-pnfs-block-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-4170226.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --NextPart-- From bildas_Fortelka@outofhand.com Thu Oct 04 18:57:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZdj-00040o-Qi for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 18:57:55 -0400 Received: from node-5079.tor.pppoe.execulink.com ([67.158.67.216]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdZdh-0003YL-EG for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 18:57:53 -0400 Received: from christopher ([118.146.36.189]:22947 "EHLO christopher" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [67.158.67.216] with ESMTP id S22NWVTGHIJZYLTI (ORCPT ); Thu, 4 Oct 2007 18:57:57 -0400 Message-ID: <6D42E1A1.FB0C09DB@outofhand.com> Date: Thu, 4 Oct 2007 18:57:32 -0400 From: "bildas Fortelka" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: 1poleved Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good evening nfsv4-archive A slightly soft erection is not only troublesome to you, but it's less visually exciting and less stimulating to your partner bildas Fortelka http://smandalist.com/ From TonyattributiveGraham@people.com Thu Oct 04 20:20:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idavs-00067D-Vv for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 20:20:45 -0400 Received: from 36-90-246-201.adsl.terra.cl ([201.246.90.36] helo=ciber05) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Idavs-0006I3-IV for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 20:20:44 -0400 Received: from freak by people.com with SMTP id 7YpEUtBFFN for ; Thu, 4 Oct 2007 20:20:26 +0400 From: "Tony Cole" To: Subject: Our casino is for everyone who likes to win! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Win $$$ instead of throwing it all away at other casinos. When YOU WIN, we win! Play your favorite games from the comfort of your home, USA players ARE included! After thatit's only fun and winning. http://vegasgamecity.net/ From nfsv4-bounces@ietf.org Thu Oct 04 21:32:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idc1q-0005IR-Iq; Thu, 04 Oct 2007 21:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idc1p-0004zn-HW for nfsv4@ietf.org; Thu, 04 Oct 2007 21:30:57 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idc1a-0001KA-GE for nfsv4@ietf.org; Thu, 04 Oct 2007 21:30:48 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l951UHI4010771; Thu, 4 Oct 2007 21:30:17 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l951U6rN005166; Thu, 4 Oct 2007 21:30:15 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 21:30:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Request for an additional recommended attribute Date: Thu, 4 Oct 2007 21:29:55 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Request for an additional recommended attribute thread-index: AcgGe+b8XF3yHcguTTqjxIrEh4Q01wAFD/UgAAKC5sAAB3ctAAANxiGw References: To: X-OriginalArrivalTime: 05 Oct 2007 01:30:07.0093 (UTC) FILETIME=[42FDAA50:01C806EF] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -4.0 (----) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I agree - it's clearly a promise. --David=20 > -----Original Message----- > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com]=20 > Sent: Thursday, October 04, 2007 2:57 PM > To: Black, David; Talpey, Thomas > Cc: nfsv4@ietf.org > Subject: RE: [nfsv4] Request for an additional recommended attribute >=20 > > telling the server what the max I/O time > > is for client I/O done against pNFS block layouts >=20 > "telling" doesn't really cover it. >=20 > It is making a promise or contract, and the correctness of the protocol > will depend on that promise being honored. This is not informative in > the normal sense.=20 >=20 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: Thursday, October 04, 2007 2:52 PM > To: Noveck, Dave; Talpey, Thomas > Cc: nfsv4@ietf.org > Subject: RE: [nfsv4] Request for an additional recommended attribute >=20 >=20 > Dave and Tom, >=20 > > My understanding is that this is to take the place of=20 > fencing, i.e. to > > provide to the protocol implementation time-based promises which can > be > > relied upon to avoid a requirement for actual fencing. =20 > David Black's > > concern has been that requiring actual fencing support=20 > would limit the > > deployment of pnfs for blocks which limitation he believes=20 > would be a > > bad thing. >=20 > Yes, it's in support of that mechanism - the basic idea is that the > client > stops using a layout when the client's leases expire (the=20 > actual timing > is > somewhat subtler due to client-server communication latency). The > server > needs to know how much longer it has to wait for client I/Os in flight > before it can safely take back resources. The details are in=20 > the latest > (just posted) version of the block layout draft. >=20 > > It's not clear if this text is making a requirement that=20 > every NFSv4.1 > server > > implement a bounded maximum I/O time, or if the client is able to > request > > one. >=20 > It's neither, this is the client telling the server what the max I/O > time > is for client I/O done against pNFS block layouts. Support=20 > for it would > only be required if the pNFS block layout is supported (although I'd > have > no problem if other layouts found this useful). >=20 > > Also, it is not clear to me whether this time is global across all > I/Os > > at the server, all I/Os for this clientid or sessionid, or whether > it's per-file. >=20 > Per-clientid. The maximum I/O time for a client I/O may depend on the > client's I/O stack, so it's better to have the client tell the server > than > have the server guess (although 60 seconds will usually be a good > guess). > This is also the answer to Craig's question - the client knows the > client's > I/O stack significantly better than the server does, especially if the > client and server aren't running the same OS. >=20 > Forcing the client to tell the server is also a way to (try to) catch > clients that may be in unbounded I/O territory and keep them=20 > from using > the block layout. I'm not sure whether this aspect is important in > practice (it may turn out to be a blame-redirection mechanism rather > than a damage-prevention mechanism). In the reverse=20 > direction, allowing > clients with lower I/O bounds to speed up failure processing=20 > is useful. >=20 > > Can you clarify? If it's a server-global mandatory=20 > requirement, I have > some > > strong concerns.=20 >=20 > It's only for clients and servers that implement the pNFS=20 > block layout, > unless some other layout would find this useful. >=20 > > Is this really fencing btw? Usually I think of fencing as a=20 > way for a > > server to deny access to clients which fall out of a cluster. >=20 > Dave Noveck's language at the start of this message is a better > description > - in essence, for the block layout, we're prepared to trust a=20 > client to > fence itself if it's lost communication with the server for=20 > long enough > to lose its leases. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From BrendanacknowledgeNash@washingtonpost.com Thu Oct 04 23:27:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IddqJ-0002wY-B5 for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 23:27:11 -0400 Received: from adsl-243-195-180.cae.bellsouth.net ([74.243.195.180] helo=homec45698874e.launchmodem.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IddqI-0004an-66 for nfsv4-archive@lists.ietf.org; Thu, 04 Oct 2007 23:27:11 -0400 Received: from birefringent by washingtonpost.com with SMTP id w46KvNpalX for ; Thu, 4 Oct 2007 23:26:06 +0500 From: "Dominick Mckenzie" To: Subject: Huge progressive jackpots, slots, multi-hand, and single-hand blackjack. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.9 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Win $$$ instead of throwing it all away at other casinos. Download our casino in 20 seconds to get $2400 richer when you join. $2400 welcome bonus will be deposited in your new casino account! Our casino is for you and everyone else who likes to win! http://vegasgamecity.net/ From marti@alexcardona.com Fri Oct 05 08:42:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdmVr-0003SL-Ga for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 08:42:39 -0400 Received: from [151.56.64.253] (helo=[151.56.64.253]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdmVn-00031T-8O for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 08:42:35 -0400 Received: from witem520565-w0v ([108.125.175.144]:23209 "EHLO witem520565-w0v" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [151.56.64.253] with ESMTP id S22KQUKTSLNVWVJD (ORCPT ); Fri, 5 Oct 2007 14:43:07 +0200 Message-ID: <000a01c8074d$33b16880$fd403897@witem520565w0v> From: "Luke marti" To: Subject: tuusinri Date: Fri, 5 Oct 2007 14:42:34 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C8075D.F73A3880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C8075D.F73A3880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://skishames.com/ Wassup nfsv4-archive Increased confidence when making love =3D better sex Luke marti ------=_NextPart_000_0005_01C8075D.F73A3880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://skishames.com/
Wassup nfsv4-archive
Increased confidence when making love =3D = better sex
Luke marti
------=_NextPart_000_0005_01C8075D.F73A3880-- From srinivasaRansome@finefacet.com Fri Oct 05 13:11:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idqhl-0006na-75 for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 13:11:13 -0400 Received: from host107-3-dynamic.18-79-r.retail.telecomitalia.it ([79.18.3.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idqhf-0004f9-SM for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 13:11:13 -0400 Received: from nome_pc by finefacet.com with ASMTP id 1650F15A for ; Fri, 5 Oct 2007 19:11:34 +0200 Received: from nome_pc ([198.106.161.46]) by finefacet.com with ESMTP id 069BFCDB4D0A for ; Fri, 5 Oct 2007 19:11:34 +0200 Message-ID: <000301c80772$b335c1d0$6b03124f@nomepc> From: "srinivasa Ransome" To: nfsv4-archive@lists.ietf.org Subject: dlis}g}l Date: Fri, 5 Oct 2007 19:10:59 +0200 Message-ID: <000301c80772$b335c1d0$6b03124f@nomepc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Yo nfsv4-archive I have been using manster for 2 months and I have gained a 1/2 inch in girth and 1/4 inch in length srinivasa Ransome http://startrave.com/ From TheodoreexpellableDunn@orgonics.com Fri Oct 05 13:13:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqkH-0001Bz-TW for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 13:13:49 -0400 Received: from eu85-87-67-75.clientes.euskaltel.es ([85.87.67.75] helo=.euskaltel.es) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdqkH-00045P-JG for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 13:13:49 -0400 Received: from appendage by orgonics.com with SMTP id bLWFszeIRS for ; Fri, 5 Oct 2007 19:13:17 -0100 From: "Theodore Nichols" To: Subject: Relax and have fun with poker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de USA players too! Download and GO! Come find out. We're serious about fun. Play your favorite games and get $2400 welcome bonus. http://trynetgambling.net/ From nfsv4-bounces@ietf.org Fri Oct 05 14:06:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdrYW-0005oz-2B; Fri, 05 Oct 2007 14:05:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdrYU-0005ka-Tv for nfsv4@ietf.org; Fri, 05 Oct 2007 14:05:42 -0400 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdrYO-00074V-NP for nfsv4@ietf.org; Fri, 05 Oct 2007 14:05:42 -0400 Received: by an-out-0708.google.com with SMTP id c17so99101anc for ; Fri, 05 Oct 2007 11:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=38aFd20PmZfvgEZQcGnBY9GzV6Wdzmm0j1tL6ntYbTs=; b=K2wVVZ2F0AuDQ81mRY02cdDzHX3/04uQzf+GMmkx2klbNeKu/+RJvtzXpFsFcjianIR+8o0TJF1OESbhpeIF7N8R8RqMclyB3phClJwcHx+GLWP9WGJeL6EFHaBB2UzYuGU6lw3KSSnA1jBC5JuEHE2mpMc4FUKLN5i5+ycaBm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=X4BfF71nOggorSOhWUT6YPa/qyw8R0Kpe/vhj5+udyL3ZvU/279Mht4BjBSvc8Y1SyxMMval2TfvkfKKnzfqRsl5UUE77QyoP6huC3pRn3CYn3WBsPh/ziuj3LwiFK9rJYWf6LyVBZAthWrtEDkrsakmH0AeyTQpQQ3uWV9rB3g= Received: by 10.142.239.11 with SMTP id m11mr2736568wfh.1191607522302; Fri, 05 Oct 2007 11:05:22 -0700 (PDT) Received: by 10.142.98.1 with HTTP; Fri, 5 Oct 2007 11:05:22 -0700 (PDT) Message-ID: <89c397150710051105w32e05cd4v9083627449eb025d@mail.gmail.com> Date: Fri, 5 Oct 2007 14:05:22 -0400 From: "William A. (Andy) Adamson" To: "Marc Eshel" Subject: Re: [nfsv4] NFSv4.1 draft 14 available at www.nfsv4-editor.org In-Reply-To: MIME-Version: 1.0 References: <58F1CB97-3058-4CF4-A872-79FE5EFAB76B@sun.com> X-Google-Sender-Auth: 4d35b154b94ac3b2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Spencer Shepler , NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0186334451==" Errors-To: nfsv4-bounces@ietf.org --===============0186334451== Content-Type: multipart/alternative; boundary="----=_Part_33647_19829758.1191607522285" ------=_Part_33647_19829758.1191607522285 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The nfsv4_1_file_layout4 does not declare a list, and so only one is able to be put in the loc_body field. % %/* Encoded in the loc_body field of type layout_content4: */ struct nfsv4_1_file_layout4 { deviceid4 nfl_deviceid; nfl_util4 nfl_util; uint32_t nfl_first_stripe_index; nfs_fh4 nfl_fh_list<>; }; We need to add something like the following to be encoded in the loc_body field of type layout_content4 struct nfsv4_1_file_layout_list4 { struct nfs4_1_file_layout4 layout_list<>; } -->Andy On 9/25/07, Marc Eshel wrote: > > It looks like layoutreturn4 is still missing in the draft14, but it is in > the .x file. > > union layoutreturn4 switch(layoutreturn_type4 lr_returntype) { > case LAYOUTRETURN4_FILE: > layoutreturn_file4 lr_layout; > default: > void; > }; > > > > > Spencer Shepler > 09/25/2007 06:03 AM > > To > NFSv4 > cc > > Subject > [nfsv4] NFSv4.1 draft 14 available at www.nfsv4-editor.org > > > > > > > > Latest html, diff, and line numbered draft can be found here: > > http://www.nfsv4-editor.org/drafts/drafts.html > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > ------=_Part_33647_19829758.1191607522285 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The nfsv4_1_file_layout4 does not declare a list, and so only one is able to be put in the loc_body field.


%
%/* Encoded in the loc_body field of type layout_content4: */
struct nfsv4_1_file_layout4 {
         deviceid4      nfl_deviceid;
         nfl_util4      nfl_util;
         uint32_t       nfl_first_stripe_index;
         nfs_fh4        nfl_fh_list<>;
};


We need to add something like the following to be encoded in the loc_body field of type layout_content4

 struct nfsv4_1_file_layout_list4 {
         struct nfs4_1_file_layout4  layout_list<>; 
}

-->Andy

On 9/25/07, Marc Eshel <eshel@almaden.ibm.com> wrote:
It looks like layoutreturn4 is still missing in the draft14, but it is in
the .x file.

union layoutreturn4 switch(layoutreturn_type4 lr_returntype) {
                 case LAYOUTRETURN4_FILE:
                                 layoutreturn_file4 lr_layout;
                 default:
                                 void;
};




Spencer Shepler <Spencer.Shepler@Sun.COM>
09/25/2007 06:03 AM

To
NFSv4 <nfsv4@ietf.org >
cc

Subject
[nfsv4] NFSv4.1 draft 14 available at www.nfsv4-editor.org







Latest html, diff, and line numbered draft can be found here:

http://www.nfsv4-editor.org/drafts/drafts.html

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4



_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


------=_Part_33647_19829758.1191607522285-- --===============0186334451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============0186334451==-- From Nikola-Oxner@mkhandel.de Fri Oct 05 16:13:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdtXq-0000NP-Ho for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 16:13:10 -0400 Received: from [201.250.113.98] (helo=[201.250.113.98]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdtXi-0002nt-Hh for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 16:13:03 -0400 Received: from seba-b71ae7bfe8 by mkhandel.de with ASMTP id 1D1686E9 for ; Fri, 5 Oct 2007 17:13:42 -0300 Received: from seba-b71ae7bfe8 ([145.154.188.140]) by mkhandel.de with ESMTP id 2D38013F79D1 for ; Fri, 5 Oct 2007 17:13:42 -0300 Message-ID: <000801c8078c$239f7dd0$6271fac9@sebab71ae7bfe8> From: "Nikola Oxner" To: Subject: limonaad Date: Fri, 5 Oct 2007 17:13:05 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C80772.FE5245D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.1 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0005_01C80772.FE5245D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://stasuzuki.com/ Morning nfsv4-archive A slightly soft erection is not only troublesome to you, but it's less = visually exciting and less stimulating to your partner Nikola Oxner ------=_NextPart_000_0005_01C80772.FE5245D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://stasuzuki.com/
Morning nfsv4-archive
A slightly soft erection is not only = troublesome to you,=20 but it's less visually exciting and less stimulating to your = partner
Nikola Oxner
------=_NextPart_000_0005_01C80772.FE5245D0-- From DelmerpurlLe@flickr.com Fri Oct 05 16:41:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdtzS-0000I9-AT for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 16:41:42 -0400 Received: from c-76-118-165-114.hsd1.ma.comcast.net ([76.118.165.114] helo=dczkps81.hsd1.ma.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IdtzR-0003ey-CQ for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 16:41:42 -0400 Received: from idiosyncratic by flickr.com with SMTP id a9pkC6BDdw for ; Fri, 5 Oct 2007 16:17:43 +0600 From: "Jonah Head" To: Subject: Relax and have fun with progressive video slots Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Visit and start seeing the dollars coming. If you're in the US or anywhere else, join your new casino paradise. We have it all! USA players too! Download and GO! http://citycasino4u.net/ From PengCheng354@mail.csps.ylc.edu.tw Fri Oct 05 17:33:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdunJ-00083o-7d for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 17:33:13 -0400 Received: from [77.204.157.46] (helo=[77.204.158.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdunI-00059A-GG for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 17:33:13 -0400 Received: from maison-krmiblza by mail.csps.ylc.edu.tw with ASMTP id F524E0FE for ; Fri, 5 Oct 2007 23:34:09 +0200 Received: from maison-krmiblza ([155.130.192.151]) by mail.csps.ylc.edu.tw with ESMTP id B64FE30A5825 for ; Fri, 5 Oct 2007 23:34:09 +0200 Message-ID: <000901c80797$6be9ce00$139ecc4d@maisonkrmiblza> From: "PengCheng kirch" To: Subject: tuontira Date: Fri, 5 Oct 2007 23:33:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C807A8.2F729E00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.7 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C807A8.2F729E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.siybreeze.com/ Yo man nfsv4-archive You get astonishingly fast penis enlargement results PengCheng kirch ------=_NextPart_000_0008_01C807A8.2F729E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.siybreeze.com/
Yo man nfsv4-archive
You get astonishingly fast penis enlargement = results
PengCheng kirch
------=_NextPart_000_0008_01C807A8.2F729E00-- From FreemangerundRosario@gasupreme.us Fri Oct 05 18:48:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idvxk-0006Ai-6C for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 18:48:04 -0400 Received: from 215-183-126-200.fibertel.com.ar ([200.126.183.215] helo=lopezc8597bc5a) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Idvxj-0007jz-No for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 18:48:04 -0400 Received: from posseman by gasupreme.us with SMTP id ZiIo2SQjKv for ; Fri, 5 Oct 2007 19:47:41 -0100 From: "Kennith Hinton" To: Subject: Get $2400 you download our casino. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Players from the United States and around the world! Play your favorite games from the comfort of your home, USA players ARE included! Download our casino in 20 seconds to get $2400 richer when you join. Get your bonus and walk the red carpet to winnings and fun. http://bigcasinopoint.com/ From Ruiqiang.Manochehri@naturalmentecongelados.com Fri Oct 05 19:23:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwWJ-0000QY-9T for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 19:23:47 -0400 Received: from host81-158-127-21.range81-158.btcentralplus.com ([81.158.127.21] helo=[81.129.221.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdwWD-0000aj-IS for nfsv4-archive@lists.ietf.org; Fri, 05 Oct 2007 19:23:41 -0400 Received: from your-447023ae6b ([175.181.41.181] helo=your-447023ae6b) by [81.129.221.120] ( sendmail 8.13.3/8.13.1) with esmtpa id 1MYgNL-000QAR-mh for nfsv4-archive@lists.ietf.org; Sat, 6 Oct 2007 00:24:00 +0100 Message-ID: <000301c807a6$c4f36470$78dd8151@your447023ae6b> From: "Ruiqiang Manochehri" To: Subject: utledu Date: Sat, 6 Oct 2007 00:23:43 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C807AF.26B7CC70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0003_01C807AF.26B7CC70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.staqrkist.com/ Wazzup nfsv4-archive I have been using manster for 2 months and I have gained a 1/2 inch in = girth and 1/4 inch in length Ruiqiang Manochehri ------=_NextPart_000_0003_01C807AF.26B7CC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.staqrkist.com/
Wazzup nfsv4-archive
I have been using manster for 2 months and I = have gained=20 a 1/2 inch in girth and 1/4 inch in length
Ruiqiang Manochehri
------=_NextPart_000_0003_01C807AF.26B7CC70-- From banksjcdao@cbacc.org Sat Oct 06 11:55:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeC0F-0008UF-R0 for nfsv4-archive@lists.ietf.org; Sat, 06 Oct 2007 11:55:43 -0400 Received: from host-84-221-102-111.cust-adsl.tiscali.it ([84.221.102.111] helo=[84.221.70.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeC04-00012g-TM for nfsv4-archive@lists.ietf.org; Sat, 06 Oct 2007 11:55:33 -0400 Received: from ufftec ([124.149.145.71] helo=ufftec) by [84.221.102.253] ( sendmail 8.13.3/8.13.1) with esmtpa id 1AwfUT-000GPM-lR for nfsv4-archive@lists.ietf.org; Sat, 6 Oct 2007 17:55:43 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 6 Oct 2007 17:55:21 +0200 To: nfsv4-archive@lists.ietf.org From: "Jered banks" Subject: skrownor Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.8 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good morning nfsv4-archive Ladies, here is the ultimate gift for your men, used by p0rnstarrs worldwide Jered banks http://www.missburke.com/ From lynnanne_bleeker@atleticacasper.com.br Sat Oct 06 15:00:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeEtJ-0002w1-FY for nfsv4-archive@lists.ietf.org; Sat, 06 Oct 2007 15:00:45 -0400 Received: from adsl-40-189.38-151.net24.it ([151.38.189.40] helo=[151.37.95.231]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeEtG-0004ys-PZ for nfsv4-archive@lists.ietf.org; Sat, 06 Oct 2007 15:00:43 -0400 Received: from xyz-700f0cdf0ce ([139.107.64.8] helo=xyz-700f0cdf0ce) by [151.37.95.231] ( sendmail 8.13.3/8.13.1) with esmtpa id 1rkqFT-000RWV-ie for nfsv4-archive@lists.ietf.org; Sat, 6 Oct 2007 21:01:04 +0200 Message-ID: Date: Sat, 6 Oct 2007 21:00:29 +0200 From: "lynnanne bleeker" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: etutitsn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Wazzup nfsv4-archive Adding inches to your cock.. lynnanne bleeker http://misohahne.com/ From JSteven@CMS-AUSTRALIA.COM.AU Sat Oct 06 22:56:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeMJv-0007ht-0q for nfsv4-archive@lists.ietf.org; Sat, 06 Oct 2007 22:56:43 -0400 Received: from ppp-106-79.21-151.libero.it ([151.21.79.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeMJj-0007Fl-Il for nfsv4-archive@lists.ietf.org; Sat, 06 Oct 2007 22:56:38 -0400 Received: from your-a47779be2c ([168.149.196.85] helo=your-a47779be2c) by [151.21.79.106] ( sendmail 8.13.3/8.13.1) with esmtpa id 1RXGUI-000XRV-EF for nfsv4-archive@lists.ietf.org; Sun, 7 Oct 2007 04:56:50 +0200 Message-ID: <000a01c8088d$a52b04d0$6a4f1597@youra47779be2c> From: "JSteven Mosberian" To: Subject: ocrekauq Date: Sun, 7 Oct 2007 04:56:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C8089E.68B3D4D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C8089E.68B3D4D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.mxrjeans.com/ Hi nfsv4-archive You should see me now, i am sooooo confident with the ladies. JSteven Mosberian ------=_NextPart_000_0008_01C8089E.68B3D4D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.mxrjeans.com/
Hi nfsv4-archive
You should see me now, i am sooooo confident = with the ladies.
JSteven Mosberian
------=_NextPart_000_0008_01C8089E.68B3D4D0-- From Essibos@thebestinrehab.com Sat Oct 06 23:16:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeMce-0001CY-D9 for nfsv4-archive@lists.ietf.org; Sat, 06 Oct 2007 23:16:04 -0400 Received: from [196.15.51.14] (helo=[212.116.219.46]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeMcd-0000sK-GU for nfsv4-archive@lists.ietf.org; Sat, 06 Oct 2007 23:16:04 -0400 Received: from multimedia ([172.188.1.51]:30124 "EHLO multimedia" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [212.116.219.46] with ESMTP id S22JRNTLUUZIVKXF (ORCPT ); Sun, 7 Oct 2007 06:16:14 +0300 Message-ID: <000901c80890$64006740$2edb74d4@multimedia> From: "Essi bos" To: Subject: eralac Date: Sun, 7 Oct 2007 06:16:02 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C808A9.894D9F40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0004_01C808A9.894D9F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://munetsex.com/ Wassup nfsv4-archive myspace recommends this website for all MEN looking to get 2-3" bigger = cock Essi bos ------=_NextPart_000_0004_01C808A9.894D9F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://munetsex.com/
Wassup nfsv4-archive
myspace recommends this website for all MEN = looking to=20 get 2-3" bigger cock
Essi bos
------=_NextPart_000_0004_01C808A9.894D9F40-- From Mladymyr@art-de.de Sun Oct 07 14:04:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeaTz-0001U6-Jk for nfsv4-archive@lists.ietf.org; Sun, 07 Oct 2007 14:04:03 -0400 Received: from p5088fbed.dip.t-dialin.net ([80.136.251.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeaTu-00082K-MM for nfsv4-archive@lists.ietf.org; Sun, 07 Oct 2007 14:03:59 -0400 Received: by 10.44.22.60 with SMTP id loWNMUqgUfGQG; Sun, 7 Oct 2007 20:04:03 +0200 (GMT) Received: by 192.168.232.63 with SMTP id XASEjnyCWLMBUw.6959338399633; Sun, 7 Oct 2007 20:04:01 +0200 (GMT) Message-ID: <000701c8090c$6ea936a0$edfb8850@dannycomp> From: "Ries Mlady" To: Subject: kessanbi Date: Sun, 7 Oct 2007 20:03:58 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C8091D.323206A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0003_01C8091D.323206A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.porterro.com/ Good evening nfsv4-archive life is short, dont have a small cock all your life Ries Mlady ------=_NextPart_000_0003_01C8091D.323206A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.porterro.com/
Good evening nfsv4-archive
life is short, dont have a small cock all your = life
Ries Mlady
------=_NextPart_000_0003_01C8091D.323206A0-- From Abhishek336@digitally-drunken.de Mon Oct 08 00:14:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iek0f-00016r-Nf for nfsv4-archive@lists.ietf.org; Mon, 08 Oct 2007 00:14:25 -0400 Received: from fibereach.fttp.xmission.com ([207.135.146.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iek0V-0001Ny-GD for nfsv4-archive@lists.ietf.org; Mon, 08 Oct 2007 00:14:21 -0400 Received: by 10.234.116.6 with SMTP id WyUDKVaMpSDcJ; Sun, 7 Oct 2007 22:16:01 -0600 (GMT) Received: by 192.168.121.68 with SMTP id LIASUocmjJKytS.2756550666194; Sun, 7 Oct 2007 22:15:59 -0600 (GMT) Message-ID: <000901c80961$ec63cba0$309287cf@kitchen> From: "Abhishek Konttila" To: Subject: llesegnu Date: Sun, 7 Oct 2007 22:15:56 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8092F.A1C95BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.4 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C8092F.A1C95BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://pjidji.com/ How it is going nfsv4-archive I was looking for a method to improve my size. By size, I mean overall = length and width of my penis Abhishek Konttila ------=_NextPart_000_0007_01C8092F.A1C95BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://pjidji.com/
How it is going nfsv4-archive
I was looking for a method to improve my size. = By size,=20 I mean overall length and width of my penis
Abhishek Konttila
------=_NextPart_000_0007_01C8092F.A1C95BA0-- From Elly-Groosman@volker-schwarz.de Mon Oct 08 03:56:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IenTK-0002Iq-3w for nfsv4-archive@lists.ietf.org; Mon, 08 Oct 2007 03:56:14 -0400 Received: from [131.114.111.250] (helo=[131.114.111.250]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IenTJ-0005FV-L5 for nfsv4-archive@lists.ietf.org; Mon, 08 Oct 2007 03:56:14 -0400 Received: from ATENEO-197 ([130.182.71.182] helo=ATENEO-197) by [131.114.111.250] ( sendmail 8.13.3/8.13.1) with esmtpa id 1OUMaJ-000GZY-bO for nfsv4-archive@lists.ietf.org; Mon, 8 Oct 2007 09:57:01 +0200 Message-ID: <000801c80980$bbad2690$fa6f7283@ATENEO197> From: "Elly Groosman" To: Subject: oplehood Date: Mon, 8 Oct 2007 09:56:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C80991.7F35F690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0006_01C80991.7F35F690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.ppmbiz.com/ Morning nfsv4-archive I fill her whole mouth now Elly Groosman ------=_NextPart_000_0006_01C80991.7F35F690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.ppmbiz.com/
Morning nfsv4-archive
I fill her whole mouth now
Elly Groosman
------=_NextPart_000_0006_01C80991.7F35F690-- From esaufaisal5@ajatus.org Mon Oct 08 09:39:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IespX-0000aC-A2 for nfsv4-archive@lists.ietf.org; Mon, 08 Oct 2007 09:39:31 -0400 Received: from bth53.neoplus.adsl.tpnet.pl ([83.29.153.53] helo=83.29.153.53) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IespN-0007ey-PR for nfsv4-archive@lists.ietf.org; Mon, 08 Oct 2007 09:39:26 -0400 Received: from [83.29.153.53] by ruaawnu.ajatus.org; Mon, 08 Oct 2007 13:38:33 +0000 Message-ID: <000501c809b0$06aba826$77f8c5aa@aawnuqx> From: "Marina Webber" To: "Deandre Coley" Subject: Fw: Thanks, we are accepting your application Date: Mon, 08 Oct 2007 11:51:11 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C809B0.06A890B6" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.6 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C809B0.06A890B6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and require IMMEDIATE cash to spend ANY = way you like or wish Extra money to give your company a boost or need A = low interest loan - NO STRINGS ATTACHED, here is best deal we can offer = you THIS EVENING (hurry, this lot will expire TODAY):   $34,000+ loan   Hurry, when best deal is gone, it is gone. Simply Call Us Free on=20 877-292-6896 ------=_NextPart_000_0002_01C809B0.06A890B6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you have your own business and = require IMMEDIATE cash to spend ANY way you like or wish Extra money to = give your company a boost or need A low interest loan - NO STRINGS = ATTACHED, here is best deal we can offer you THIS EVENING (hurry, this = lot will expire TODAY):
=20
 
$34,000+ loan
 
Hurry, when best deal is gone, it is = gone. Simply Call Us Free on 877-292-6896
------=_NextPart_000_0002_01C809B0.06A890B6-- From nfsv4-bounces@ietf.org Mon Oct 08 10:20:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetRu-0006bJ-Gv; Mon, 08 Oct 2007 10:19:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetRr-0004J1-53 for nfsv4@ietf.org; Mon, 08 Oct 2007 10:19:07 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IetRa-0001yQ-Mj for nfsv4@ietf.org; Mon, 08 Oct 2007 10:18:51 -0400 Received: from bfields by fieldses.org with local (Exim 4.67) (envelope-from ) id 1IetRZ-0001SR-Ra for nfsv4@ietf.org; Mon, 08 Oct 2007 10:18:49 -0400 Date: Mon, 8 Oct 2007 10:18:49 -0400 To: nfsv4@ietf.org Subject: Re: [nfsv4] [PATCH] spec nits Message-ID: <20071008141849.GA2902@fieldses.org> References: <20070828193828.GF3764@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070828193828.GF3764@fieldses.org> User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Tue, Aug 28, 2007 at 03:38:28PM -0400, J. Bruce Fields wrote: > These are just attempts to fix grammar problems, cut a few unnecessary > words, and clarify slightly here or there. Also some minor > inconsistencies in terminology--describing posix/fcntl locks as > "octet-range" seems a little pedantic, especially since "byte-range" > seems to be the already-established usage, and ditto for "server > reinitialization" vs. "server reboot"--but if I chose wrong then I could > submit a patch to correct either one in the other direction. > > There's (hopefully) no change in meaning anywhere. (Though there were > one or two places--such as in the definition of "Server" in 1.5--where I > wasn't completely sure I understood the original.) > > I can also send this as separate patches with comments on each if > preferred. Some of this got fixed in -14. Thanks! Some of it (e.g. the "octet-range" byte language) still seems to be there. I don't think there were objections to this last time around, so here's an update to apply against -14. --b. diff --git a/nfsv41_middle_core_infrastructure.xml b/nfsv41_middle_core_infrastructure.xml index ce6425e..297f8eb 100755 --- a/nfsv41_middle_core_infrastructure.xml +++ b/nfsv41_middle_core_infrastructure.xml @@ -655,7 +655,7 @@
- The Server Owner is somewhat similar to a Client Owner + The Server Owner is similar to a Client Owner (), but unlike the Client Owner, there is no shorthand serverid. The Server Owner is defined in the following structure: @@ -671,7 +671,7 @@ struct server_owner4 { - The Server Owner is returned in the results of + The Server Owner is returned from EXCHANGE_ID. When the so_major_id fields are the same in two EXCHANGE_ID results, the connections each EXCHANGE_ID are sent over can be assumed to address the same Server @@ -740,9 +740,8 @@ struct server_owner4 { general, the client will not have to use either operation except during initial communication with the server or when the client crosses security policy boundaries at - the server. It is possible that the server's policies - change during the client's interaction therefore - forcing the client to negotiate a new security tuple. + the server. But the server's policies may also change at any + time and force the client to negotiate a new security tuple. Where the use of different security tuples would affect @@ -1147,16 +1146,17 @@ struct server_owner4 { Principals with appropriate access rights can modify the - authorization on a file object via the SETATTR () operation. Four attributes - that affect access rights are: mode, owner, owner_group, and - acl. See . + authorization on a file object via the SETATTR () operation. Attributes + that affect access rights include: mode, owner, owner_group, acl + dacl, and sacl. See .
NFSv4.1 provides auditing on a per file object - basis, via the ACL attribute as described in . + basis, via the acl and sacl attributes as described in . It is outside the scope of this specification to specify audit log formats or management policies. @@ -1165,7 +1165,7 @@ struct server_owner4 {
NFSv4.1 provides alarm control on a per file object - basis, via the ACL attribute as described in . + basis, via the acl and sacl attributes as described in . Alarms may serve as the basis for intrusion detection. It is outside the scope of this specification to specify heuristics for detecting intrusion via alarms. @@ -1396,8 +1396,8 @@ struct server_owner4 { state may be accessed using any of the sessions associated with that client's client ID, when connections are associated with those sessions. When - no connections are associated for any of the sessions - associated with the client ID for an extended time + no connections are associated with any of a client ID's + sessions for an extended time, such objects as locks, opens, delegations, layouts, etc. are subject to expiration. The session serves as an object representing a means of access by a client to @@ -1472,8 +1472,8 @@ struct server_owner4 { Each client ID () can have - zero or more active sessions. A client ID, and a session - associated with it are required to perform file access in + zero or more active sessions. A client ID and associated + session are required to perform file access in NFSv4.1. Each time a session is used (whether by a client sending a request to the server, or the client replying to a callback request from the server), the state leased @@ -1483,7 +1483,7 @@ struct server_owner4 { State such as share reservations, locks, delegations, and layouts () is tied to - the client ID. Client state is not tied to the sessions of the client ID. + the client ID. Client state is not tied to any individual session. Successive state changing operations from a given state owner MAY go over different sessions, provided the session is associated with the same client ID. A callback @@ -1504,7 +1504,7 @@ struct server_owner4 {
A channel is not a connection. A channel represents the - direction ONC RPC requests are sent to. + direction ONC RPC requests are sent. Each session has one or two channels: the fore channel and the backchannel. @@ -1583,7 +1583,7 @@ struct server_owner4 { - It is permissible for a connection of type of + It is permissible for a connection of one type of transport to be associated with the fore channel, and a connection of a different type to be associated with the backchannel. diff --git a/nfsv41_middle_introduction.xml b/nfsv41_middle_introduction.xml index e790215..5c90d66 100755 --- a/nfsv41_middle_introduction.xml +++ b/nfsv41_middle_introduction.xml @@ -288,7 +288,7 @@
- As mentioned previously, NFS v4.1, is a single protocol which + As mentioned previously, NFS v4.1 is a single protocol which includes locking facilities. These locking facilities include support for many types of locks including a number of sorts of recallable locks. Recallable locks such as @@ -298,6 +298,10 @@ via a callback request. The assurances provided by delegations allow more extensive caching to be done safely when circumstances allow it. + + + The types of locks are: + Share reservations as established by OPEN operations. @@ -306,18 +310,18 @@ Byte-range locks. - File delegations which are recallable locks that assure + File delegations, which are recallable locks that assure the holder that inconsistent opens and file changes cannot occur so long as the delegation is held. - Directory delegations which are recallable delegations + Directory delegations, which are recallable locks that assure the holder that inconsistent directory modifications cannot occur so long as the delegation is held. - Layouts which are recallable objects that assure the + Layouts, which are recallable objects that assure the holder that direct access to the file data may be performed directly by the client and that no change to the data's location inconsistent with that access @@ -330,7 +334,7 @@ single client-wide lease. All requests made on sessions associated with the client renew that lease. When leases are not promptly renewed locks are subject to revocation. - In the event of server re-initialization, clients have the + In the event of server reboot, clients have the opportunity to safely reclaim their locks within a special grace period. @@ -345,8 +349,8 @@ The "client" is the entity that accesses the NFS server's resources. The client may be an application which contains the logic to access the NFS server directly. The client - may also be the traditional operating system client remote - file system services for a set of applications. + may also be the traditional operating system client that + provides remote file system services for a set of applications. A client is uniquely identified by a Client Owner. @@ -385,8 +389,8 @@ state about variable length leases across server failures. - The term "lock" is used to refer to record (octet-range) - locks, share reservations, delegations or layouts unless + The term "lock" is used to refer to record (byte-range) + locks, share reservations, delegations, or layouts unless specifically stated otherwise. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Sprollkcolr@gay-power.de Tue Oct 09 04:32:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfAVa-0000AL-FK for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 04:32:06 -0400 Received: from cpc1-barn8-0-0-cust359.brnt.cable.ntl.com ([81.97.177.104]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfAVI-0001Cy-DK for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 04:31:48 -0400 Received: by 10.221.180.214 with SMTP id nVOdSYovAPQwN; Tue, 9 Oct 2007 11:31:51 +0300 (GMT) Received: by 192.168.104.42 with SMTP id ECUnkzbDYbNghi.0901523533220; Tue, 9 Oct 2007 11:31:49 +0300 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 9 Oct 2007 11:31:46 +0300 To: nfsv4-archive@lists.ietf.org From: "kirril Sproll" Subject: deliatev Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Evening nfsv4-archive tired of being just mr average to the ladies? kirril Sproll http://www.nietien.com/ From stevo.Levitan@newwebgen.com Tue Oct 09 04:48:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfAl3-0004r8-VT for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 04:48:05 -0400 Received: from [24.205.203.12] (helo=[24.205.203.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfAl3-0001eW-If for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 04:48:05 -0400 Received: by 10.198.40.143 with SMTP id jvIVmLAAJYttl; Tue, 9 Oct 2007 01:48:12 -0700 (GMT) Received: by 192.168.63.36 with SMTP id jFmhMpQNYzleRX.2516850960394; Tue, 9 Oct 2007 01:48:10 -0700 (GMT) Message-ID: <000b01c80a51$1d3f3710$0ccbcd18@mcneil> From: "stevo Levitan" To: Subject: mentendr Date: Tue, 9 Oct 2007 01:48:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C80A16.70E05F10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.1 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0009_01C80A16.70E05F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.njbookbar.com/ Morning nfsv4-archive WOW! EXCLUSIVE herbal pills that will ENLARGE your cock stevo Levitan ------=_NextPart_000_0009_01C80A16.70E05F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.njbookbar.com/
Morning nfsv4-archive
WOW! EXCLUSIVE herbal pills that will ENLARGE = your cock
stevo Levitan
------=_NextPart_000_0009_01C80A16.70E05F10-- From bonnie9shahrokh@acegroup.cc Tue Oct 09 11:05:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGee-0002Wz-37 for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 11:05:52 -0400 Received: from [87.251.136.8] (helo=87.251.136.8) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGec-0002SQ-Mx for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 11:05:52 -0400 Received: from [87.251.136.8] by tvcvl.acegroup.cc; Tue, 09 Oct 2007 15:05:36 +0000 Message-ID: <000801c80a85$05b50393$f73c29b4@ltbsv> From: "Marian Garland" To: "Martina Simmons" Subject: Thanks, we are ready to lend some cash regardless of Credit Date: Tue, 09 Oct 2007 13:18:14 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C80A85.05AF668E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.7 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C80A85.05AF668E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and want IMMEDIATE cash to spend ANY way = you like or need Extra money to give your business a boost or want A low = interest loan - NO STRINGS ATTACHED, here is the deal we can offer you = TONIGHT (hurry, this tender will expire TONIGHT):   $57,000+ loan   Hurry, when the deal is gone, it is gone. Simply Call Us Free on=20 877-292-6896 ------=_NextPart_000_0005_01C80A85.05AF668E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you have your own business and want = IMMEDIATE cash to spend ANY way you like or need Extra money to give = your business a boost or want A low interest loan - NO STRINGS ATTACHED, = here is the deal we can offer you TONIGHT (hurry, this tender will = expire TONIGHT):
=20
 
$57,000+ loan
 
Hurry, when the deal is gone, it is = gone. Simply Call Us Free on 877-292-6896
------=_NextPart_000_0005_01C80A85.05AF668E-- From balakris7jonell0@Web.de Tue Oct 09 13:24:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfIp7-0005Rd-0v for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 13:24:49 -0400 Received: from cir80.neoplus.adsl.tpnet.pl ([83.31.41.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfIp5-0008WV-Qy for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 13:24:48 -0400 Received: from [83.31.41.80] by fxuoxv.Web.de; Tue, 09 Oct 2007 17:24:44 +0000 Message-ID: <000701c80a99$041108dd$6080029d@uoxvnb> From: "Donnell Cantrell" To: "Carmen Daugherty" Subject: Fwd: Thank you, we are ready to give a loan Date: Tue, 09 Oct 2007 15:37:21 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C80A99.040B6334" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.5 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C80A99.040B6334 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and require IMMEDIATE money to spend ANY = way you like or wish Extra money to give your business a boost or need A = low interest loan - NO STRINGS ATTACHED, here is our best deal we can = offer you THIS NIGHT (hurry, this offer will expire THIS NIGHT):   $34,000+ loan   Hurry, when our best deal is gone, it is gone. Simply Call Us Free on=20 877-292-6896 ------=_NextPart_000_0004_01C80A99.040B6334 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you have your own business and = require IMMEDIATE money to spend ANY way you like or wish Extra money to = give your business a boost or need A low interest loan - NO STRINGS = ATTACHED, here is our best deal we can offer you THIS NIGHT (hurry, this = offer will expire THIS NIGHT):
=20
 
$34,000+ loan
 
Hurry, when our best deal is gone, it = is gone. Simply Call Us Free on 877-292-6896
------=_NextPart_000_0004_01C80A99.040B6334-- From JOmarieMargileth@holik.tk Tue Oct 09 16:30:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLjD-0007fW-5r for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 16:30:55 -0400 Received: from chello087207169089.chello.pl ([87.207.169.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfLj8-0002g4-BG for nfsv4-archive@lists.ietf.org; Tue, 09 Oct 2007 16:30:55 -0400 Received: by 10.201.28.23 with SMTP id EgQwsaFaAymTP; Tue, 9 Oct 2007 22:28:36 +0200 (GMT) Received: by 192.168.6.63 with SMTP id KKYuexuRscbLUV.6326802586656; Tue, 9 Oct 2007 22:28:34 +0200 (GMT) Message-ID: <6BF996B2.01A7D08B@holik.tk> Date: Tue, 9 Oct 2007 22:28:31 +0200 From: "JOmarie Margileth" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: nostak Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Good evening nfsv4-archive wow, its so much bigger now JOmarie Margileth http://www.recifessex.com/ From nfsv4-bounces@ietf.org Wed Oct 10 01:05:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTjR-0008Nq-Fm; Wed, 10 Oct 2007 01:03:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTjP-0008Jn-IR for nfsv4@ietf.org; Wed, 10 Oct 2007 01:03:39 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfTjO-0001n8-9S for nfsv4@ietf.org; Wed, 10 Oct 2007 01:03:39 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9A53bmP000004 for ; Wed, 10 Oct 2007 05:03:37 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPO00G01JD5BZ00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 09 Oct 2007 23:03:37 -0600 (MDT) Received: from [192.168.0.6] ([129.150.32.141]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPO00CCKJDH9M10@mail-amer.sun.com>; Tue, 09 Oct 2007 23:03:18 -0600 (MDT) Date: Wed, 10 Oct 2007 00:03:29 -0500 From: Spencer Shepler Subject: Re: [nfsv4] [PATCH] spec nits In-reply-to: <20071008141849.GA2902@fieldses.org> To: "J. Bruce Fields" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20070828193828.GF3764@fieldses.org> <20071008141849.GA2902@fieldses.org> X-Spam-Score: -1.0 (-) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Bruce, These changes have been integrated. Spencer On Oct 8, 2007, at 9:18 AM, J. Bruce Fields wrote: > On Tue, Aug 28, 2007 at 03:38:28PM -0400, J. Bruce Fields wrote: >> These are just attempts to fix grammar problems, cut a few >> unnecessary >> words, and clarify slightly here or there. Also some minor >> inconsistencies in terminology--describing posix/fcntl locks as >> "octet-range" seems a little pedantic, especially since "byte-range" >> seems to be the already-established usage, and ditto for "server >> reinitialization" vs. "server reboot"--but if I chose wrong then I >> could >> submit a patch to correct either one in the other direction. >> >> There's (hopefully) no change in meaning anywhere. (Though there >> were >> one or two places--such as in the definition of "Server" in 1.5-- >> where I >> wasn't completely sure I understood the original.) >> >> I can also send this as separate patches with comments on each if >> preferred. > > Some of this got fixed in -14. Thanks! Some of it (e.g. the > "octet-range" byte language) still seems to be there. I don't think > there were objections to this last time around, so here's an update to > apply against -14. > > --b. > > > diff --git a/nfsv41_middle_core_infrastructure.xml b/ > nfsv41_middle_core_infrastructure.xml > index ce6425e..297f8eb 100755 > --- a/nfsv41_middle_core_infrastructure.xml > +++ b/nfsv41_middle_core_infrastructure.xml > @@ -655,7 +655,7 @@ >
>
> > - The Server Owner is somewhat similar to a Client Owner > + The Server Owner is similar to a Client Owner > (), but unlike the > Client Owner, there is no shorthand serverid. > The Server Owner is defined in the following structure: > @@ -671,7 +671,7 @@ struct server_owner4 { > > > > - The Server Owner is returned in the results of > + The Server Owner is returned from > EXCHANGE_ID. When the so_major_id fields are the same in > two EXCHANGE_ID results, the connections each EXCHANGE_ID > are sent over can be assumed to address the same Server > @@ -740,9 +740,8 @@ struct server_owner4 { > general, the client will not have to use either > operation except during initial communication with the > server or when the client crosses security policy boundaries at > - the server. It is possible that the server's policies > - change during the client's interaction therefore > - forcing the client to negotiate a new security tuple. > + the server. But the server's policies may also change at any > + time and force the client to negotiate a new security tuple. > > > Where the use of different security tuples would affect > @@ -1147,16 +1146,17 @@ struct server_owner4 { > > > Principals with appropriate access rights can modify the > - authorization on a file object via the SETATTR ( target="OP_SETATTR" />) operation. Four attributes > - that affect access rights are: mode, owner, owner_group, and > - acl. See . > + authorization on a file object via the SETATTR ( +target="OP_SETATTR" />) operation. Attributes > + that affect access rights include: mode, owner, owner_group, acl > + dacl, and sacl. See . > >
> >
> > NFSv4.1 provides auditing on a per file object > - basis, via the ACL attribute as described in target="acl" />. > + basis, via the acl and sacl attributes as described in target="acl" />. > It is outside the scope of this specification to specify > audit log formats or management policies. > > @@ -1165,7 +1165,7 @@ struct server_owner4 { >
> > NFSv4.1 provides alarm control on a per file object > - basis, via the ACL attribute as described in target="acl" />. > + basis, via the acl and sacl attributes as described in target="acl" />. > Alarms may serve as the basis for intrusion detection. > It is outside the scope of this specification to specify > heuristics for detecting intrusion via alarms. > @@ -1396,8 +1396,8 @@ struct server_owner4 { > state may be accessed using any of the sessions > associated with that client's client ID, when > connections are associated with those sessions. When > - no connections are associated for any of the sessions > - associated with the client ID for an extended time > + no connections are associated with any of a client ID's > + sessions for an extended time, > such objects as locks, opens, delegations, layouts, > etc. are subject to expiration. The session serves as > an object representing a means of access by a client to > @@ -1472,8 +1472,8 @@ struct server_owner4 { > > Each client ID > () can have > - zero or more active sessions. A client ID, and a session > - associated with it are required to perform file access in > + zero or more active sessions. A client ID and associated > + session are required to perform file access in > NFSv4.1. Each time a session is used (whether by a client > sending a request to the server, or the client replying > to a callback request from the server), the state leased > @@ -1483,7 +1483,7 @@ struct server_owner4 { > > State such as share reservations, locks, delegations, > and layouts () is tied to > - the client ID. Client state is not tied to the sessions of the > client ID. > + the client ID. Client state is not tied to any individual > session. > Successive state changing operations from a given state > owner MAY go over different sessions, provided the > session is associated with the same client ID. A callback > @@ -1504,7 +1504,7 @@ struct server_owner4 { >
> > A channel is not a connection. A channel represents the > - direction ONC RPC requests are sent to. > + direction ONC RPC requests are sent. > > > Each session has one or two channels: the fore channel and the > backchannel. > @@ -1583,7 +1583,7 @@ struct server_owner4 { > > > > - It is permissible for a connection of type of > + It is permissible for a connection of one type of > transport to be associated with the fore channel, > and a connection of a different type to be associated > with the backchannel. > diff --git a/nfsv41_middle_introduction.xml b/ > nfsv41_middle_introduction.xml > index e790215..5c90d66 100755 > --- a/nfsv41_middle_introduction.xml > +++ b/nfsv41_middle_introduction.xml > @@ -288,7 +288,7 @@ >
>
> > - As mentioned previously, NFS v4.1, is a single protocol which > + As mentioned previously, NFS v4.1 is a single protocol which > includes locking facilities. These locking facilities > include support for many types of locks including a number > of sorts of recallable locks. Recallable locks such as > @@ -298,6 +298,10 @@ > via a callback request. The assurances provided by > delegations allow more extensive caching to be done safely > when circumstances allow it. > + > + > + The types of locks are: > + > > > Share reservations as established by OPEN operations. > @@ -306,18 +310,18 @@ > Byte-range locks. > > > - File delegations which are recallable locks that assure > + File delegations, which are recallable locks that assure > the holder that inconsistent opens and file changes > cannot > occur so long as the delegation is held. > > > - Directory delegations which are recallable delegations > + Directory delegations, which are recallable locks > that assure the holder that inconsistent directory > modifications cannot occur so long as the delegation > is held. > > > - Layouts which are recallable objects that assure the > + Layouts, which are recallable objects that assure the > holder that direct access to the file data may be > performed directly by the client and that no change > to the data's location inconsistent with that access > @@ -330,7 +334,7 @@ > single client-wide lease. All requests made on sessions > associated with the client renew that lease. When leases > are not promptly renewed locks are subject to revocation. > - In the event of server re-initialization, clients have the > + In the event of server reboot, clients have the > opportunity to safely reclaim their locks within a special > grace period. > > @@ -345,8 +349,8 @@ > The "client" is the entity that accesses the NFS server's > resources. The client may be an application which contains > the logic to access the NFS server directly. The client > - may also be the traditional operating system client remote > - file system services for a set of applications. > + may also be the traditional operating system client that > + provides remote file system services for a set of > applications. > > A client is uniquely identified by a Client Owner. > > @@ -385,8 +389,8 @@ > state about variable length leases across server failures. > > > - The term "lock" is used to refer to record (octet-range) > - locks, share reservations, delegations or layouts unless > + The term "lock" is used to refer to record (byte-range) > + locks, share reservations, delegations, or layouts unless > specifically stated otherwise. > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From AprilcontraceptiveMoyer@interfax.ru Wed Oct 10 01:42:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfUKw-0003XZ-Vk for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 01:42:27 -0400 Received: from 24-107-226-122.dhcp.oxfr.ma.charter.com ([24.107.226.122] helo=yourfulkl1oh2q) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IfUKw-0007Fg-OM for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 01:42:26 -0400 Received: from paprika by interfax.ru with SMTP id Jn5gJB5rmF for ; Wed, 10 Oct 2007 01:41:23 +0500 From: "Eleanor Plummer" To: Subject: How about the best service around? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Players from the United States and around the world! We have it all! Get to know your new casino home! Play your favorite games from the comfort of your home, USA players ARE included! http://bigcasinoworld.net/ From Faisel@atochacap.com Wed Oct 10 03:34:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfW5q-000231-Jj for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 03:34:58 -0400 Received: from [60.52.55.242] (helo=52.60.in-addr.arpa.tm.net.my) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfW5k-0001Rv-Kr for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 03:34:53 -0400 Received: by 10.29.135.163 with SMTP id DXxyMUvTmuliF; Wed, 10 Oct 2007 15:34:58 +0800 (GMT) Received: by 192.168.90.205 with SMTP id ATKXYPGZvqYmbD.7090960562671; Wed, 10 Oct 2007 15:34:56 +0800 (GMT) Message-ID: <000601c80b10$0c4c04f0$f237343c@gabunganagenpen> From: "Faisel Mistry" To: Subject: lerab Date: Wed, 10 Oct 2007 15:34:53 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C80B53.1A6F44F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0008_01C80B53.1A6F44F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.radionecn.com/ Hi nfsv4-archive wow, its so much bigger now Faisel Mistry ------=_NextPart_000_0008_01C80B53.1A6F44F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.radionecn.com/
Hi nfsv4-archive
wow, its so much bigger now
Faisel Mistry
------=_NextPart_000_0008_01C80B53.1A6F44F0-- From ArthurbutyricStewart@smbc-comics.com Wed Oct 10 05:18:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfXhn-0003aN-3I for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 05:18:15 -0400 Received: from zue-tix-bbcs-dynip-169-145.vtx.ch ([83.228.169.145] helo=violonissimo) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IfXhj-0004lC-Im for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 05:18:12 -0400 Message-ID: <6f73f01c80b1e$78033660$6400a8c0@Violonissimo> From: "Carl Stewart" To: Subject: Fw: Thank you, we are accepting your loan request Date: Wed, 10 Oct 2007 11:17:52 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_6F73B_01C80B1E.78033660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.2 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_6F73B_01C80B1E.78033660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit does not matter to us! If you have your own business and wish IMMEDIATE cash to spend ANY way = you like or need Extra money to give the business a boost or need A low = interest loan - NO STRINGS ATTACHED, here is the deal we can offer you = NOW (hurry, this offer will expire TONIGHT): $37,000+ loan Hurry, when our best deal is gone, it is gone. Simply Call Us... Don't worry about approval, your your credit report will not disqualify = you! Call Us Free on 877-347-3607 ------=_NextPart_000_6F73B_01C80B1E.78033660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your your credit = report doesn't=20 matter to us!
=20
 
If you have your own = business and=20 want IMMEDIATE money to spend ANY way you like or wish Extra money to = give your=20 business a boost or wish A low interest loan - NO STRINGS ATTACHED, = here is=20 our deal we can offer you THIS EVENING (hurry, this tender will expire = THIS=20 NIGHT):
=20
 
$48,000+ = loan
 
Hurry, when best deal = is gone, it=20 is gone. Simply Call Us...
=20
 
Don't worry about = approval, your=20 credit history will not disqualify you!
=20
 
Call Us Free on=20 877-347-3607
------=_NextPart_000_6F73B_01C80B1E.78033660-- From ashfriend@win.tec.mn.us Wed Oct 10 09:29:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfbcZ-0003t1-Sa for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 09:29:07 -0400 Received: from chello062178091077.3.12.vie.surfer.at ([62.178.91.77]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfbcT-0003rg-46 for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 09:29:01 -0400 Received: from KIKI87 ([156.175.5.94]:29885 "EHLO KIKI87" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by chello062178091077.3.12.vie.surfer.at with ESMTP id S22GCVABICYSBBOZ (ORCPT ); Wed, 10 Oct 2007 15:29:04 +0200 Message-ID: <000d01c80b41$7e4af300$4d5bb23e@KIKI87> From: "ash friend" To: Subject: kobanash Date: Wed, 10 Oct 2007 15:28:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C80B52.41D3C300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0007_01C80B52.41D3C300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://rapuvendu.com/ Welcome nfsv4-archive proven to be safe and ver effective ash friend ------=_NextPart_000_0007_01C80B52.41D3C300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://rapuvendu.com/
Welcome nfsv4-archive
proven to be safe and ver = effective
ash friend
------=_NextPart_000_0007_01C80B52.41D3C300-- From wayen_panis@pesciro.com Wed Oct 10 10:15:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcLY-0005uU-UB for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 10:15:36 -0400 Received: from p5486dec9.dip.t-dialin.net ([84.134.222.201]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfcLT-00065d-Ue for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 10:15:32 -0400 Received: from comp ([125.100.138.151]:17484 "EHLO comp" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by p5486DEC9.dip.t-dialin.net with ESMTP id S22TRJLRXSKJBBOW (ORCPT ); Wed, 10 Oct 2007 16:15:51 +0200 Message-ID: <000701c80b48$095511a0$c9de8654@comp> From: "wayen panis" To: Subject: eluremol Date: Wed, 10 Oct 2007 16:15:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C80B58.CCDDE1A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ------=_NextPart_000_0005_01C80B58.CCDDE1A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.athenkia.com/ Nice to meet you nfsv4-archive YES you can turn your worm into a trouser snake safely, check it out wayen panis ------=_NextPart_000_0005_01C80B58.CCDDE1A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.athenkia.com/
Nice to meet you nfsv4-archive
YES you can turn your worm into a trouser = snake safely,=20 check it out
wayen panis
------=_NextPart_000_0005_01C80B58.CCDDE1A0-- From Croghankij@prace.co.uk Wed Oct 10 13:28:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IffLk-0003aG-11 for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 13:28:00 -0400 Received: from gqp58.internetdsl.tpnet.pl ([83.3.171.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IffLi-0001Pq-6l for nfsv4-archive@lists.ietf.org; Wed, 10 Oct 2007 13:27:59 -0400 Received: by 10.136.216.9 with SMTP id ydhyPQMZxaAsj; Wed, 10 Oct 2007 19:28:04 +0200 (GMT) Received: by 192.168.200.179 with SMTP id QclgkCTHEYrZfv.2549977927237; Wed, 10 Oct 2007 19:28:02 +0200 (GMT) Message-ID: <000d01c80b62$e74ef0b0$3aab0353@darenka> From: "khai Croghan" To: Subject: omicrist Date: Wed, 10 Oct 2007 19:27:59 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C80B73.AAD7C0B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0003_01C80B73.AAD7C0B0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://www.beajne.com/ Hello nfsv4-archive Do you want her to scream when you shove your mammoth cock in? khai Croghan ------=_NextPart_000_0003_01C80B73.AAD7C0B0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://www.beajne.com/
Hello nfsv4-archive
Do you want her to scream when you shove your = mammoth=20 cock in?
khai Croghan
------=_NextPart_000_0003_01C80B73.AAD7C0B0-- From Momrikooww@Vector-S.Com Thu Oct 11 04:30:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IftR9-0005Y1-QO for nfsv4-archive@lists.ietf.org; Thu, 11 Oct 2007 04:30:31 -0400 Received: from host249-1-dynamic.11-79-r.retail.telecomitalia.it ([79.11.1.249]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IftR6-0008Bq-5Z for nfsv4-archive@lists.ietf.org; Thu, 11 Oct 2007 04:30:28 -0400 Received: from patrizia ([108.175.56.139] helo=patrizia) by host249-1-dynamic.11-79-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1QfqPg-000AME-hi for nfsv4-archive@lists.ietf.org; Thu, 11 Oct 2007 10:29:04 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Oct 2007 10:28:42 +0200 To: nfsv4-archive@lists.ietf.org From: "Barney Momrik" Subject: renohcsd Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed How's tricks nfsv4-archive tired of pulling your pole? grow the natural way! Barney Momrik http://bodanika.com/ From ShermanportmanteauWebster@american.com Thu Oct 11 17:29:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig5ah-0002ri-N4 for nfsv4-archive@lists.ietf.org; Thu, 11 Oct 2007 17:29:11 -0400 Received: from [190.65.193.204] (helo=pc04) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ig5ae-0006ck-PL for nfsv4-archive@lists.ietf.org; Thu, 11 Oct 2007 17:29:11 -0400 Message-ID: <270401c80c4d$bdff0100$8601a8c0@pc04> From: "Benny Adkins" To: Subject: We offer business loans up to $1,000,000 Date: Thu, 11 Oct 2007 23:27:42 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2700_01C80C4D.BDFF0100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.9 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_2700_01C80C4D.BDFF0100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let us assist with the placement of working capital business loans for = small to medium sized businesses in all 50 states We've created an affordable, simple, and flexible approach to providing = working capital of $5,000 to $500,000 or more. No obligation application. No cost to apply. No closing costs. Poor = credit not a problem. Get approved in 48 hours! with a simple application process & quick = funding, Call Us Free on 877-347-3607 ------=_NextPart_000_2700_01C80C4D.BDFF0100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Let us assist with the placement of = working=20 capital business loans for small to medium sized businesses in all 50=20 states
 
We've created an affordable, simple, = and flexible=20 approach to providing working capital of $5,000 to $500,000 or=20 more.
=20
 
No obligation application. No cost = to apply. No=20 closing costs. Poor credit not a problem.
 
Get approved in 48 hours! with a = simple=20 application process & quick funding, Call Us Free on=20 877-347-3607
------=_NextPart_000_2700_01C80C4D.BDFF0100-- From nfsv4-bounces@ietf.org Thu Oct 11 18:38:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6eB-00070Y-LG; Thu, 11 Oct 2007 18:36:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6e8-0006u0-6K for nfsv4@ietf.org; Thu, 11 Oct 2007 18:36:48 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig6dy-0000sC-Og for nfsv4@ietf.org; Thu, 11 Oct 2007 18:36:46 -0400 Received: from bfields by fieldses.org with local (Exim 4.67) (envelope-from ) id 1Ig6dd-0003Hf-Bm; Thu, 11 Oct 2007 18:36:17 -0400 Date: Thu, 11 Oct 2007 18:36:17 -0400 To: Spencer Shepler Message-ID: <20071011223617.GG22823@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a3b79fd9d7bf2ef1762376a62c51ec4 Cc: nfsv4@ietf.org, Lisa Week Subject: [nfsv4] ACL section revisions X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org The following acl section revisions are leftover from the acl review. There's no substantive change to the ACL model, and nothing particularly contraversial--the goal is just to make the section easier to read, provide some better guidance here and there, and fix some minor bugs. I've also incorporated feedback from Sam, who reviewed this. (Thanks!) A summary: - Fix the DELETE/DELETE_CHILD algorithm to take into account traditional variations in the "sticky bit" behavior, and rewrite for conciseness. - Encourage more strongly that servers support the full ACL model instead of requiring client software to be aware of complex mapping. Provide some more guidance and an additional example. - Consistently use "nine low-order mode bits" rather than "bits that control permissions". - Fix an example in the "ACE Access Mask" section which suggests rejecting an acl in a case where it would be preferable to silently turn off allow bits. - Fix some ommissions from the "operations affected" lists: EXECUTE may affect any operation that takes a path (hence may require a lookup), and VERIFY, NVERIFY, and READDIR may be affected by READ_ATTRIBUTES. - miscellaneous copyediting: fix some typos, correct minor grammar and style problems, revise for conciseness, etc. On balance I'm removing language where possible (it's a long section) but only where I believe the result is text that is more helpful rather than less. (Gory details with detailed justifications for each change are available from git://linux-nfs.org/~bfields/nfsv41.git aclwork or by request--I could mail them out to the alias individually if preferred. Just let me know what you need.) --b. --- nfsv41_middle_fileattributes_acls.xml | 359 +++++++++++++-------------------- 1 files changed, 145 insertions(+), 214 deletions(-) diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml index 7ac7bd3..7ac55ab 100755 --- a/nfsv41_middle_fileattributes_acls.xml +++ b/nfsv41_middle_fileattributes_acls.xml @@ -15,7 +15,7 @@
- ACLs and modes represent two well established but different models + ACLs and modes represent two well established models for specifying permissions. This chapter specifies requirements that attempt to meet the following goals: @@ -51,7 +51,7 @@ Setting only the mode attribute should provide reasonable security. For example, setting a mode of 000 should be enough to ensure that future - opens for read or write by any principal should + opens for read or write by any principal fail, regardless of a previously existing or inherited ACL. @@ -66,27 +66,15 @@ implementations and discussions around them. - If a server supports ACL attributes (any of - "acl", "dacl" and - "sacl"), then at any time, the server can - provide the supported ACL attributes when - requested. The ACL attributes will describe all - permissions on the file object, except for the - three high-order bits of the mode attribute - (described in ). The ACL - attributes will not conflict with the mode - attribute, on servers that support the mode - attribute. Briefly, "will not conflict" - means that applying the algorithm in to the ACL yields the nine - low-order bits of the mode. See for exact requirements. - - - If a server supports the mode attribute, then at any time, - the server can provide a mode attribute when requested. - The mode attribute will not conflict with the ACL - attributes, on servers that support the ACL attributes. + On servers that support both the mode and the acl or + dacl attributes, the server must keep the two consistent + with each other. The value of the mode attribute (with + the exception of the three high order bits described in + ), must be determined entirely + by the value of the ACL, so that use of the mode is + never required for anything other than setting the + three high order bits. See + for exact requirements. When a mode attribute is set on an object, the ACL @@ -156,10 +144,26 @@ The NFS version 4 ACL model is quite rich. Some server platforms may provide access control functionality that goes beyond the UNIX-style mode attribute, but which is not as rich - as the NFS ACL model. So that users can take advantage of this - more limited functionality, the server may indicate that it - supports ACLs as long as it follows the guidelines for mapping - between its ACL model and the NFS version 4 ACL model. + as the NFS ACL model. So that users can take advantage of this + more limited functionality, the server may support the acl + attributes by mapping between its ACL model and the NFS version + 4 ACL model. Servers must ensure that the ACL they + actually store or enforce is at least as strict as the NFSv4 + ACL that was set. It is tempting to accomplish this by + rejecting any ACL that falls outside the small set that + can be represented accurately. However, such an approach + can render ACLs unusable without special client-side + knowledge of the server's mapping, which defeats the + purpose of having a common NFSv4 ACL protocol. + Therefore servers should accept every ACL that they can + without compromising security. To help accomplish this, + servers may make a special exception, in the case of + unsupported permission bits, to the rule that bits not + ALLOWED or DENIED by an ACL must be denied. For example, a + UNIX-style server might choose to silently allow read + attribute permissions even though an ACL does not explicitly + allow those permissions. (An ACL that explicitly denies + permission to read attributes should still be rejected.) The situation is complicated by the fact that a server @@ -216,9 +220,9 @@ ACE4_SYSTEM_AUDIT_ACE_TYPE AUDIT - LOG (system dependent) any access attempt to a file or - directory which uses any of the access methods - specified in acemask4. + LOG (in a system dependent way) any access attempt to + a file or directory which uses any of the access + methods specified in acemask4. ACE4_SYSTEM_ALARM_ACE_TYPE ALARM @@ -230,7 +234,7 @@ The "Abbreviation" column denotes how the types will be referred to throughout the rest of this - document. + chapter.
@@ -407,6 +411,10 @@ Operation(s) affected: READ OPEN + REMOVE + RENAME + LINK + CREATE Discussion: Permission to execute a file. @@ -450,6 +458,8 @@ ACE4_READ_ATTRIBUTES Operation(s) affected: GETATTR of file system object attributes + VERIFY + NVERIFY READDIR Discussion: The ability to read basic attributes (non-ACLs) of a file. @@ -548,76 +558,55 @@ and read. For example, suppose a server cannot distinguish overwriting data from appending new data, as described in the previous paragraph. - If a client submits an ACE where + If a client submits an ALLOW ACE where ACE4_APPEND_DATA is set but ACE4_WRITE_DATA is - not (or vice versa), the server should reject - the request with NFS4ERR_ATTRNOTSUPP. - Nonetheless, if the ACE has type DENY, the - server may silently turn on the other bit, so - that both ACE4_APPEND_DATA and ACE4_WRITE_DATA - are denied. + not (or vice versa), the server should either turn + off ACE4_APPEND DATA or reject the request with + NFS4ERR_ATTRNOTSUPP.
Two access mask bits govern the ability to delete a - file or directory object: ACE4_DELETE on the object - itself, and ACE4_DELETE_CHILD on the object's parent - directory. + directory entry: ACE4_DELETE on the object + itself (the "target"), and ACE4_DELETE_CHILD on + the containing directory (the "parent"). + + + + Many systems also take the "sticky bit" (MODE4_SVTX) + on a directory to allow unlink only to a user that + owns either the target or the parent; on some + such systems the decision also depends on + whether the target is writeable. - - Many systems also consult the "sticky bit" - (MODE4_SVTX) and write mode bit on the parent - directory when determining whether to allow a file to - be deleted. The mode bit for write corresponds to - ACE4_WRITE_DATA, which is the same physical bit as - ACE4_ADD_FILE. Therefore, ACE4_WRITE_DATA can come into - play when determining permission to delete. + + + Servers SHOULD allow unlink if either ACE4_DELETE + is permitted on the target, or ACE4_DELETE_CHILD is + permitted on the parent. (Note that this is + true even if the parent or target explicitly + denies one of these permissions.) - In the algorithm below, the strategy is that - ACE4_DELETE and ACE4_DELETE_CHILD take precedence over - the sticky bit, and the sticky bit takes precedence - over the "write" mode bits (reflected in - ACE4_ADD_FILE). + If the ACLs in question neither explicitly ALLOW + nor DENY either of the above, and if MODE4_SVTX is + not set on the parent, then the server SHOULD allow + the removal if and only if ACE4_ADD_FILE is permitted. + In the case where MODE4_SVTX is set, the server + may also require the remover to own either the parent + or the target, or may require the target to be + writeable. + - Server implementations SHOULD grant or deny permission - to delete based on the following algorithm. + This allows servers to support something close to + traditional unix-like semantics, with ACE4_ADD_FILE + taking the place of the write bit. -
- - if ACE4_TRAVERSE is denied by the parent directory ACL { - deny delete - } else if ACE4_DELETE is allowed by the target object ACL { - allow delete - } else if ACE4_DELETE_CHILD is allowed by the parent - directory ACL { - allow delete - } else if ACE4_DELETE_CHILD is denied by the - parent directory ACL { - deny delete - } else if ACE4_ADD_FILE is allowed by the parent directory ACL { - if MODE4_SVTX is set for the parent directory { - if the principal owns the parent directory OR - the principal owns the target object OR - ACE4_WRITE_DATA is allowed by the target - object ACL { - allow delete - } else { - deny delete - } - } else { - allow delete - } - } else { - deny delete - } - -
@@ -730,7 +719,7 @@ The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and ACE4_FAILED_ACCESS_ACE_FLAG - (FAILED) flag bits relate only to + (FAILED) flag bits may be set only on ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE (ALARM) ACE types. If during the processing of the @@ -757,14 +746,12 @@ The previously described processing - applies to that of the ACCESS operation as - well, the difference being that "success" - or "failure" does not mean whether ACCESS - returns NFS4_OK or not. Success means - whether ACCESS returns all requested and - supported bits. Failure means whether - ACCESS failed to return at least one - bit that was requested and supported. + applies to ACCESS operations even when + they return NFS4_OK. For the purposes of + AUDIT and ALARM, we consider an ACCESS + operation to be a "failure" if it fails + to return a bit that was requested and + supported. @@ -846,8 +833,8 @@ To avoid conflict, these special identifiers are - distinguish by an appended "@" and should appear in the - form "xxxx@" (note: no domain name after the "@"). For + distinguished by an appended "@" and should appear in the + form "xxxx@" (with no domain name after the "@"). For example: ANONYMOUS@. @@ -1051,109 +1038,62 @@ The following method can be used to calculate the MODE4_R*, MODE4_W* and MODE4_X* bits of a mode attribute, based upon an ACL. - + + + + First, for each of the special identifiers ONWER@, GROUP@, and + EVERYONE@, evaluate the ACL in order, considering only ALLOW + and DENY ACEs for the identifier EVERYONE@ and for the + identifier under consideration. The result of the evaulation + will be an NFSv4 ACL mask showing exactly which bits are + permitted to that identifier. + + + + Then translate the calculated mask for OWNER@, GROUP@, and + EVERYONE@ into mode bits for, respectively, the user, group, + and other, as follows: + - To determine MODE4_ROTH, MODE4_WOTH, and MODE4_XOTH: - - - If the special identifier EVERYONE@ is granted - ACE4_READ_DATA, then - the bit MODE4_ROTH SHOULD be set. Otherwise, - MODE4_ROTH SHOULD NOT be set. - - - If the special identifier EVERYONE@ - is granted ACE4_WRITE_DATA or - ACE4_APPEND_DATA, then the bit - MODE4_WOTH SHOULD be set. Otherwise, - MODE4_WOTH SHOULD NOT be set. - - - If the special identifier EVERYONE@ - is granted ACE4_EXECUTE, then - the bit MODE4_XOTH SHOULD be set. Otherwise, - MODE4_XOTH SHOULD NOT be set. - - + Set the read bit (MODE4_RUSR, MODE4_RGRP, or + MODE4_ROTH) if and only if ACE4_READ_DATA is set in + the corresponding mask. + - To determine MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP, - note that the EVERYONE@ special identifier SHOULD be - taken into account. In other words, when determining - if the GROUP@ special identifier is granted a - permission, ACEs with the identifier EVERYONE@ should - take effect just as ACEs with the special identifier - GROUP@ would. - - - If the special identifier GROUP@ is granted - ACE4_READ_DATA, then the bit MODE4_RGRP SHOULD - be set. Otherwise, MODE4_RGRP SHOULD NOT be set. - - - If the special identifier GROUP@ is granted - ACE4_WRITE_DATA or ACE4_APPEND_DATA, then the - bit MODE4_WGRP SHOULD be set. Otherwise, - MODE4_WGRP SHOULD NOT be set. - - - If the special identifier GROUP@ is granted - ACE4_EXECUTE, then the bit MODE4_XGRP SHOULD - be set. Otherwise, MODE4_XGRP SHOULD NOT be - set. - - + Set the write bit (MODE4_WUSR, MODE4_WGRP, or + MODE4_WOTH) if and only if ACE4_WRITE_DATA and + ACE4_APPEND_DATA are both set in the corresponding + mask. + - To determine MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR, - note that the EVERYONE@ special identifier SHOULD be - taken into account. In other words, when determining - if the OWNER@ special identifier is granted a - permission, ACEs with the identifier EVERYONE@ should - take effect just as ACEs with the special identifer - OWNER@ would. - - - If the special identifier OWNER@ is granted - ACE4_READ_DATA, then the bit MODE4_RUSR SHOULD - be set. Otherwise, MODE4_RUSR SHOULD NOT be - set. - - - If the special identifier OWNER@ is granted - ACE4_WRITE_DATA or ACE4_APPEND_DATA, then the - bit MODE4_WUSR SHOULD be set. Otherwise, - MODE4_WUSR SHOULD NOT be set. - - - If the special identifier OWNER@ is granted - ACE4_EXECUTE, then the bit MODE4_XUSR SHOULD - be set. Otherwise, MODE4_XUSR SHOULD NOT be - set. - - + Set the execute bit (MODE4_XUSR, MODE4_XGRP, or + MODE4_XOTH), if and only if ACE4_EXECUTE is set in the + corresponding mask.
- The nine low-order mode bits (MODE4_R*, MODE4_W*, MODE4_X*) - correspond to ACE4_READ_DATA, - ACE4_WRITE_DATA/ACE4_APPEND_DATA, and ACE4_EXECUTE for - OWNER@, GROUP@, and EVERYONE@. On some implementations, - mode bits may represent a superset of these permissions, - e.g. if a specific user is granted ACE4_WRITE_DATA, then - MODE4_WGRP will be set, even though the file's owner_group - is not granted ACE4_WRITE_DATA. + Some server implementations also add bits permitted to + named users and groups to the group bits (MODE4_RGRP, + MODE4_WGRP, and MODE4_XGRP). + + + Implementations are discouraged from doing this, because + it has been found to cause confusion for users who see + members of a file's group denied access that the mode + bits appear to allow. (The presence of DENY ACEs may also + lead to such behavior, but DENY ACEs are expected to be + more rarely used.) - Server implementations are discouraged from doing this, as - experience has shown that this is confusing and annoying - to end users. The specifications above also discourage - this practice to enforce the semantic that setting the - mode attribute effectively specifies read, write, and - execute for owner, group, and other. + The same user confusion seen when fetching the mode also + results if setting the mode does not effectively control + permissions for the owner, group, and other users; this + motivates some of the requirements that follow.
@@ -1188,17 +1128,17 @@
- When any of the nine low-order mode permission bits + When any of the nine low-order mode bits are subject to change, either because the mode attribute was set or because the mode_set_masked attribute was set and the mask included one or more - bits from the low-order nine mode bits that control - permissions, and no ACL attribute is explicitly + bits from the nine low-order mode bits, + and no ACL attribute is explicitly set, the acl and dacl attributes must be modified - in accordance with the updated value of the - permissions bits within the mode. This must happen - even if the value of the permission bits within the - mode is the same after the mode is set as before. + in accordance with the updated value of those bits. + This must happen + even if the value of the low-order bits + is the same after the mode is set as before. Note that any AUDIT or ALARM ACEs (hence any ACEs in the @@ -1393,26 +1333,17 @@ from being affected by ACEs meant for non-directories. - If when a new directory is created and it inherits - ACEs from its parent, for each inheritable ACE - which affects the directory's permissions, a server - MAY create two ACEs on the directory being created; - one effective and one which is only inheritable - (i.e. has ACE4_INHERIT_ONLY_ACE flag set). In the - case of a dacl or sacl attribute, both of these - ACEs SHOULD have the ACE4_INHERITED_ACE flag set. - This gives the user and the server, in the cases - which it must mask certain permissions upon - creation, the ability to modify the effective - permissions without modifying the ACE which is to - be inherited to the new directory's children. - - - When a newly created object is created with attributes, - and those attributes contain an ACL attribute and/or a - mode attribute, the server MUST apply those attributes to - the newly created object, as described in . + When a new directory is created, the server MAY split + any inherited ACE which is both inheritable and effective + (in other words, which has neither ACE4_INHERIT_ONLY_ACE + nor ACE4_NO_PROPAGATE_INHERIT_ACE set), into two ACEs, + one with no inheritance flags, and one with + ACE4_INHERIT_ONLY_ACE set. (In the case of a dacl or + sacl attribute, both of those ACEs SHOULD also have the + ACE4_IHERITED_ACE flag set.) This makes it simpler to + modify the effective permissions on the directory + without modifying the ACE which is to be inherited to the + new directory's children.
----- End forwarded message ----- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From keqg@brandysgiftshop.com Thu Oct 11 22:51:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAcS-0008N8-8f for nfsv4-archive@lists.ietf.org; Thu, 11 Oct 2007 22:51:20 -0400 Received: from [125.235.226.64] (helo=dynamic-adsl-hni.vietel.com.vn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgAcL-0008OC-2Y for nfsv4-archive@lists.ietf.org; Thu, 11 Oct 2007 22:51:17 -0400 Received: from [125.235.226.64] by brandysgiftshop.com; Fri, 12 Oct 2007 09:49:43 +0700 From: "Weston Short" To: Subject: 1,200 trapped, 2,000 freed at mine Date: Fri, 12 Oct 2007 09:49:43 +0700 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000E_01C80C7A.8AB2B490" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6Q0ZICRTAMZVJDX49KT1BRU7TM2== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-ID: <01c80c7a$8ab2b490$40e2eb7d@keqg> X-Spam-Score: 3.0 (+++) X-Scan-Signature: a2c4a3535d1556ada67f8703d3d31591 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C80C7A.8AB2B490 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C80C7A.8AB2B490" ------=_NextPart_001_000F_01C80C7A.8AB2B490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit "It becomes a psychological phenomenon. Investors know that there are inherent risks in the market, but at the same time, they're rationalizing any bad news." "According to investigators, it appeared as though Ms. Gotbaum had possibly tried to manipulate the handcuffs from behind her to the front, got tangled up in the process, and they ended up around her neck area," he said. Allen said nobody realized the child had been abused. Finding Gotbaum "unconscious and not breathing," Hill said, officers performed CPR. CNN and other news organizations did so until the child was found, and De Meo asked media to stop showing the picture. Todd Allen, a Las Vegas resident, told CNN he once lived with the girl from the video and her mother. He said he recognizes his old apartment from scenes in the video. He said he knows the suspect because Allen's mother dated Stiles and the couple spent time together at Allen's apartment. Watch Allen describe Stiles and the girl » Stiles was a distant friend of the girl's family, De Meo said. Witnesses told police that Gotbaum was "yelling and screaming" and running through the terminal Friday. She was arrested for disorderly conduct. Someone close to Stiles told investigators Stiles is a "survivalist type" and always carries a weapon, Nye County District Attorney Bob Beckett said. While handcuffed, the New Yorker became "disruptive" and she was taken to a holding room, where she was left alone, Hill told CNN affiliate KTVK. A spokeswoman for the Maricopa County medical examiner said an autopsy would be conducted Monday morning. Investigators said officers went to check on her five to 10 minutes later. Police policy requires that be done every 15 minutes. Allen said he never witnessed Stiles physically assault anyone. "She's what you'd expect a little girl in elementary school to be like," he said. "You would never know something like that happened. Ever." "Sometime during the time she went into custody, she went into medical distress," he said. Authorities have identified Chester A. Stiles, 37, as the suspect in the tape. A resident of Pahrump, Nevada, he remains at-large, De Meo said. Pahrump is about 60 miles west of Las Vegas. Gotbaum was the mother of three young children and the daughter-in-law of longtime New York City Public Advocate Betsy Gotbaum. "The mother has cooperated with us," De Meo said. "We believe that the mother was not aware of anything that went on with this young girl. It was very sad for her to find this out." Betsy Gotbaum called Carol Ann Gotbaum "a wonderful, wonderful person" and a great mother. She said the family was dealing with the situation "the best way we can." (CNN) -- Darren Tuck, the man who gave police a tape depicting the rape of a 3-year-old girl, turned himself in Sunday to Nye County, Nevada, authorities. "But I have seen him verbally and mentally assault many people," Allen told CNN. "He's good with mind games. He's good at twisting people's realities and manipulating people." The Dow Jones industrial average added nearly 192 points to end at an all-time high of 14,087.55 points on Monday amid hopes that banks have put the worst of the recent 'credit crunch' behind them and expectations that the Federal Reserve will continue to cut interest rates. The tech-dominated Nasdaq also gained 1.5 percent for its highest close since February 2001 while the S&P 500 gained 1.3 percent. "You're seeing a continuation of the recent momentum," said Chris Johnson, CEO of Johnson Research Group. In Asia on Tuesday, Tokyo's Nikkei 225 gained 200 points to close up 1.19 percent at 17,047, its highest finish since August 9. Technology companies Sony (4.2 percent) and Canon (2.6 percent) and automakers Nissan (3 percent) were among the biggest gainers. "The Nikkei appears to be in a gradual uptrend now," Nobuyuki Nagamorim, a technical analyst at Unimat Yamamaru Securities, told The Associated Press. ------=_NextPart_001_000F_01C80C7A.8AB2B490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

"It becomes a psychological phenomenon. Investors know that there are= inherent risks in the market, but at the same time, they're rationalizin= g any bad news."


"According to investigators, it appeared as though Ms. Gotbaum had po= ssibly tried to manipulate the handcuffs from behind her to the front, go= t tangled up in the process, and they ended up around her neck area," he = said.


Allen said nobody realized the child had been abused.


Finding Gotbaum "unconscious and not breathing," Hill said, officers = performed CPR.


CNN and other news organizations did so until the child was found, an= d De Meo asked media to stop showing the picture.


Todd Allen, a Las Vegas resident, told CNN he once lived with the g= irl from the video and her mother. He said he recognizes his old apartmen= t from scenes in the video. He said he knows the suspect because Allen's = mother dated Stiles and the couple spent time together at Allen's apartme= nt. Watch Allen describe Stiles and the girl =BB


Stiles was a distant friend of the girl's family, De Meo said.

Witnesses told police that Gotbaum was "yelling and screaming" and ru= nning through the terminal Friday. She was arrested for disorderly conduc= t.


Someone close to Stiles told investigators Stiles is a "survivalist t= ype" and always carries a weapon, Nye County District Attorney Bob Becket= t said.


While handcuffed, the New Yorker became "disruptive" and she was take= n to a holding room, where she was left alone, Hill told CNN affiliate KT= VK.


A spokeswoman for the Maricopa County medical examiner said an autops= y would be conducted Monday morning.


Investigators said officers went to check on her five to 10 minutes l= ater. Police policy requires that be done every 15 minutes.


Al= len said he never witnessed Stiles physically assault anyone.


"She's what you'd expect a little girl in elementary school to be lik= e," he said. "You would never know something like that happened. Ever."

"Sometime during the time she went into custody, she went into medica= l distress," he said.


Authorities have identified Chester A. Stiles, 37, as the suspect in = the tape. A resident of Pahrump, Nevada, he remains at-large, De Meo sai= d. Pahrump is about 60 miles west of Las Vegas.


Gotbaum was the mother of three young children and the daughter-in-la= w of longtime New York City Public Advocate Betsy Gotbaum.


"The mother has cooperated with us," De Meo said. "We believe that th= e mother was not aware of anything that went on with this young girl. It = was very sad for her to find this out."


Betsy Gotbaum called Carol Ann Gotbaum "a wonderful, wonderful person= " and a great mother. She said the family was dealing with the situation = "the best way we can."


(CNN) -- Darren Tuck, the man who gave police a tape depicting th= e rape of a 3-year-old girl, turned himself in Sunday to Nye County, Neva= da, authorities.


"But I have seen him verbally and mentally assault many people," Alle= n told CNN. "He's good with mind games. He's good at twisting people's re= alities and manipulating people."


The Dow Jones industrial average added nearly 192 points to end at an= all-time high of 14,087.55 points on Monday amid hopes that banks have p= ut the worst of the recent 'credit crunch' behind them and expectations t= hat the Federal Reserve will continue to cut interest rates.


The tech-dominated Nasdaq also gained 1.5 percent for its highest clo= se since February 2001 while the S&P 500 gained 1.3 percent.


"You're seeing a continuation of the recent momentum," said Chris Joh= nson, CEO of Johnson Research Group.


In Asia on Tuesday, Tokyo's Nikkei 225 gained 200 points to close up = 1.19 percent at 17,047, its highest finish since August 9. Technology com= panies Sony (4.2 percent) and Canon (2.6 percent) and automakers Nissan (= 3 percent) were among the biggest gainers.


"The Nikkei appears to be in a gradual uptrend now," Nobuyuki Nagamor= im, a technical analyst at Unimat Yamamaru Securities, told The Associate= d Press.


------=_NextPart_001_000F_01C80C7A.8AB2B490-- ------=_NextPart_000_000E_01C80C7A.8AB2B490 Content-Type: image/gif; name="footer" Content-Disposition: attachment; filename="footer" Content-Transfer-Encoding: base64 Content-ID: <006901c80c7a$8ab2b490$40e2eb7d@504X3M> R0lGODlhigHWAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/ /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/ MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/ mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/ /5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAACKAdYA AAj/AP8J/KdtoEF/BhMqXPiv2raHECNW81dt4DSGGDMufKZKo8ePDLNp9FcQpEmF/hCWPAmSFCCW ClcyzOIHpkFqMg2+uugRoc2EPg3i+2nxH0+iDHMOvAfzIciUKY1CrFYRqVWk0/odNfoPYdCDW68u dCbWJDaWTLlapVYW49eyW5WCPBr2qtylZUnq7Wqw7sNqsSIOFIlRmqu2cKkRVjgU8UJ5J9MufBvy 5MW7JvP9e+U4YbBOLOsu5FlS8tyPoj8uXtjY8ddplBNuAwwRs83UZRMl+sdWNG6xlKdp8y1wWljY nX9bFdMZZmyFl/EKfA7zaEp8UKMmbf4z4rZ/gr+D/6+mTfxkmPhMW43tlftPbW9fD+ZOXSHkk4fc mxTdcbrAezzFB9xA2fmDz4HUJKggZf6wlRBZSPkzDT6wBciQgwN5BxF42cQSmEIYmoQPM221BtQ/ /WRTX1uUwffcc8qZRMpPPEGon1WwFGJQP3wN1EwsCkkz3UUY5kONic4hqCA+CiqIx5HThKhRM6gx tOJC5WmoZZYewgIkSI8gghKLC2UzjZk1QVWWLbac1J5B6nkUY0KjJCRlRnO6dWVzF23lTJNNRplW VTYxySSg0hxp6KJM4iFhgkhihRI11GXjVIZaZupQNg7N5uE0hArk4GoJ2faRLZLAVFOVd/YkamRT aP+RUTNDaWWVaDoihhyPLBlilZGU/gMsoAJl0xhTkbJ2IIJKAmrohMvecw81UVI4LaUHimUrigaZ ShB42xiX6bhUlUuVP7Aw8uU/pj3n7Y0ZiVRQTsmuZ1Js5n1U7z+LFKVRm2P+Y6KEGUnS70CrfATo kQvjkw+TBB7aoINhGbhsswpuc+iSiiopzaLU9nOPhM00M3GCziUUlpDfZvTQNN5JA/Nf4/5l7oRU xTJNLA6p18+dwx1UVquW+cdbttxJRnRQBCd0y2kGZUPqQKhoxFnAo2F9EsYcKziQZl1p989q1PQz FMMNOwvpxRcv3EyC0jQTZclnUjrhnkLvuBW1YTH/Oa6lU4U781TmFk7Vzl1+unO7bhFIFGBiRC75 5FxwMfnlknvokE+KCSTXKFSaVIyrWONt08Ino+xaSNq0vnBCbEMbabs4UZNKKn7kngraS+KzCCNs b8ww19OUXPIx1FLTzLWQDmdoaCoP1vRFFDb2t0SGZ2/up7F4mXgsjExzj1MILRJG1q/atI0YN+Dg fvvwxy///PHD7Llad07DskmgWMSr40br0dCooQVAvW1hySNWXhSGQBOBjTc3GQp22EKN3E1jChjM oB9416TgHShKyntbyRRkHLo1CRlQ8iCFgnUihqRFPFt5y/9q9pDyaI8qo8jZG5bwvR4mrhFAbESo /6x0P49QY4hG4cL7lki/JtIPFn0ZiEymZhN/SCt9pUIKAhO0wS0CKnXUKtl65uRF1QkEbPi4XSpE wTCEUAODfcjgFOK4QUNtkW22S9AIIeUsFcoueCyEHUOQ9BVSbQNw2LthzjzESFjggZE+bGQsGvEP RliSEUEUokYsRCP2MdGJoFwiFA2yv+JI6C1nIUqriAaiQpTxlVu8B4WMR8vQ/cQn4vuNF4VDJN4c yQ9TuMMU6sgwYMpxjsOEDT78QAi1dTBBIFwbdpZljGV9LHZKYhaTXkQ6KcqGZubCR/YgSc5ymjMW /uhSI7SRyXbmi0+eBOUN5knPetqzfaP0l2qAcv+PhIlli85IxdtgscVo7pJuJcOH3Iq3UITeCEC+ /GKUdicsOwZzmAzjDSqGecxgDg9kfOzg2ex4KLbRKj0qxCOCqLOVcMVLIBKZjUMKJ85z2vScQZxG EA3BTiBaEg2W1CRaWBLPT97znjY4aj55kieGvAQmeqRlCGG5MFcEyjgMpRtWsUpLNd5OjPeaEJ5W chQE/sl2cosoMIW5O0r9IRVxzMIU5IrMKBkopCDcWDbbltIDXbOvJcXOamwkwMIqhDCBMxwkEXLT xraTGu1k5yUbIYagMuKd3czbQuLZlXmi4hRHDa0982k6gZTyJLZLxVkVFFB/lMwZqy3oV8OYVSr/ lbChISyZV3f7VbCeRyPwUYo2SFXGVLgxQam4qB+iBI9/qCKuGaSrcUOKj2tmZa/LSpDFADstPHaM WnZ8SyoGIkGhLOQhiLyhOf9hTgmVs52NCOo621nJ+BqCEZELKmYP6xHMGEKJoj0qFQK8VIH8zyOn BcluD9gkMDZpjbmLMCrkhlAKz1K3vPVqLQ+40IEcqYVYMlU2VtKk2NoOVBW6YDAnRI1iVLCjpuBD HSd2Mase6GcdbJB39cooQJKQxYriJnTAg6lElquxkGxEObED3/ha1pLakK+TLWmIKlcWiOEazmIO nGAsMeS/ARYwgaPY1J9kmMHUmNbt/JAKEAIz/wtw1sYdUHHbrRZvQgvesFa3Ck3jjGSAC/sTmo0p s6xkJblxxCCcMUrjbEqzr3ysHknX1rHsXqukrHxLnMBls8IhOcngk3IupfzkKV/yklXGb+Tuy4iK bEU9tszIcwyxhTDf4BXaeIWtb5BPbh24ORm+XYJUIQ1p+IEmbZ4GKvpAkz74QRt0zi1Xsepa4201 UVe1cwhjhDdderGt2yCEctPMllTQNbpzRBt2mQUpHVMampJG4Cs4mMLshpCIlwKPPy7lHU+TE3E6 myT4PITJJjNCQtk4dVCv7FNMUvm+hhBDxCWXLkoaZSiUifVvv1xr0Q5n1zcIA6+LMx/9TCPYf/9y hir8oAU2Gwd3fYg5s4fD0FwulM/G4RvfDGrnnCuvzKYSBWE9/G02bwMWfkj07kb24jnSNY7TPVQn 2K2oqlc6sNqg1MKQB8tJU4MUddJshiQknkQ2VqcBb3IjCuFw+VJL4YagLMMbAXFGRNzKl7vkYiCa EWfcp4gYofUNphFmkYsWBvSEBYVgggaitDnDZ/3DHEUxt5jnzvIi7PnbtB0lrsYNqzs3zqPuvJ+M 4IMsyLHTt0eBE2DS8UhqRjcy/TDBjgWDWde5ujYVxa6L0RgYVnfm8D78EYiMjHCAcaw/Dp5JKQNR FQ13csIVLndGVNzuEp9cMUAxuYKnsooeETz/4UMbA1t3/AalNcgZHN/me+wWtnClyUJF0exjszmM Jlxez++8f5/beTh6lGabFj1QcxMl9mCpkA+pcA9TIA13kArp4Q+443RwlG7uBk29c3UclF1MUi2R Rg2uxDWP1iyT4SBO8RCJAAkzVS7ec1PxZSYKV3BPFoMyiElxl1/pYoNoIAZRgjmRA1SuhmAk0i1l khD/pWsgV0+ocE/T0GvAVRZedXJe5Qz2l2y4kzs8EHOpIDPMoD+hV3P9V0L7twjHkHPGcQ9dNmQn cQeq11YJQlCpVUHNIA1TUD1RYkyL1gds5W7RAkiA1SR3IArapApMQgiA1TYZdSJlpyXbg2Tx/zVl pnZqDVdqXvJwaSAGQCV3QDQcPig58VUNA3hLRsgF45eENyANoeWEf3YVwcZ68ecHImR/WRAGfUB5 P7d/acZ/2lZo/fcK7BBcrsVKHrEvoqB61KAKC6MKqTAKWXAPGwWBI5Nc6PZ6jpYg3XUgDdIV4rMx tEAhfYAKaYRR2HggzsCBPNZXUVRk/XZk5HRJHqJ24eNkkehwlYVJoSaDVRZxYwA+kQMbqtaJV1Zm CXE1CUEqR2iK81SKowUvSBJsa6aFXGR5Sedye3ZzfQZ6+Kc80UBhxmEmZgJ6JNMb72IRZRZorDWB WTANdfQsi0ZXd8BiJPVBbMMbU8BG2IEQ+P/gCs0wBahgIG8jgh+FTXxlRj3yHUaJfMmXZPJYXzX4 gjTYCFRwSfnVPVQmBtRgg1YWRJKjLv/og+GzX6WnEYIXYDFQfiCneF1wI03zDw6ZO/JnO/Znebuj iyPEYPxnbS4nep2nFVxFYSRzG1DlRQHleidnKNLYURC4e21zhRuUCkwgiMuSjReUmIoiChh0B8gV lELpaAzBiFTRgoz0WHggj0ElDVQ2ZVHWCFOwcFe2cNOASWiAd5Aog5OzCJOzMwlxRYhRDedHfmZZ T3mQB0r1D1YALxfHlmrkfrczChbUIM0gczLXRTcHQrGYbBPFZq4gCm8jUAx1CJ1nZw1VHQn/IQec YESCOYHpRkFvNlcZ1AdVt3tsKUcvqVDO0yT/sJOi4FpTcDvD1Aw2iS3ahCAXx4GtQi7V4D3wyAj/ gAdtZ0nTV4OMoA0Ep6AFIQY+VY+NMA0T54lK5lNxJ3eSY5tWGTQANDKhyBK8aWu/aWtQlH4R4lXK eYXOtp1/QBMTKUILhVy6A1duaDsPWEKioDvFcwg613NEKTDdoRGoc5LGtJKHWYFTcDSBlS3JtVxL MmIHcpiYSQ1MYFw7uUZTwBaLMkLCRiHFQw2jcI3L0pnrCEk9ZXBtZ2ryOJVR1iDLp2od2mR4Z1mS s6GYE19Z1ick4RgpOk+Gd08rGmaj5KLs//d4UuiWqKA8LGejtUhbWCUKzsZmdHOFt/OAbbajFNYM t5NVAvWGgYQUqmiMZoWexmUUxsSeceSevhSg1CBM1HBNw7GTb1OTYMpGD6hQ+ymNsHhXokpL0yAK qJCsyxh8A1EVgSNTSfkpjaAK0GdJ+KBwd0plxvFTFjpJ1PCD2DdxQDRJdMenkTNJkTMGALmVQ8So dgJBGcIF9XSo9ZSoYxZAGTGSbnE7xZBG7XejtpOpE9lmFpkKD6gguMOYfoCpayYKd5CXMbpGojCx aIYU2cAypaCk5+l62CKNciVXcZSfbqRNErifBhIlKpJcEMgwOwmLNXmfJtsMxpSYCjWXYv84L1Lq Nc06HuECrYxkSa8Qg/dAg1FGZQdnHJHjZNqgrquGSUlLj6sWXz/YCEx7OUy7g/nVCOKBRCDRBxih dQIBYGRJT2V5rxgRFopHGtWhRsUQhc5GLREWt5ZqHLnzYH0gqqkwDjXZB7eDB6IKTLvjn6hwO/iA ChPrkWdSF3gTIhn7tdlQdF74D++Ah3NFVyZDaRcDTAwDG4rxpbyxVv1Zk8A6XkPRsgjRDKYgCNzJ UMi1Ow6TIQKBD4nQCtuwb9UAKtG6iQ2aoZZ1X42QBtl6cJYkcUDEanCXtECUfcj7j34gOdOwrkIl EFUhkKsCXDhQT74wDvVqr6LlhF9hCPn/wRqDChPBlnSRqrC6s3MihAdslHO4458Tmw47igcCBQhU 8HhepVDNMGH2yRCrsC5i8bhbNIFy0w/FYBzsuWgr+Z4IorkIYjZMwgS7Cou16rLj9aUS+GKJObG2 Ew/ysJiu+0D50in3cLtJOVmW9JopPI+RA1nFW0nqGndSaaGWhbX2JQZV66diQAWS4wrPizmYZB5f UkpWJB82wQXUME+9Sbbce1QxkE+ypBCwcKI2Ub73N5GXR8EW2QyBuHOM6aMOO7ETu1xzY219+Tob 50Li4xFVgWMIlAp4QEyESVddaFyH8rhto7kCczG66gcvKTAP+0ZhOofHygQYBI1TeiCy/3QoXzNT 5tFp+BBwk9R2wzFl/lCup5Zf7DRJrTMGPkDDluTJFnqhU9mV6+q8r4CJTPshBgEkwrFJR4wDlHID S3wDZTt4N9ADR0UpTxy72+EYViypzmYcWdC+31k8ubOdEBbGuSPGX1WqAHiRDnak6LHGm7SktpMN tMckiTYFBcEMWfCAJ2sxd3UggAsxOvalwvQ2xuSfyaTF0kQpi6xj81whBIMk4XJkiKNwRXtJGtqa QRVx8XWV6BS0T2t3ILpT4PqtpwzEr7CDPqAuYCkTsXERMpOGCiG22uCbCanL5AdFAmkV+OtVdYu+ fEsNSrAMfGawcfu+ayRQPyk+tJQHgP+Ac/SmXWJjEO3QFk0CICczmYfxpCArjnk1Dbe3LNKoKNPg qVNQMhkkCq/ARtD0MBI0afamyIaSD1otLJrxQIFxu8cwCh7SD5a1TmHwO40AVHg6Sb6LvJTlcD8c RPjVCHdavJfD0A2Nw336yaxsJV6R08WC0U4VZmX5m8bx0elIFEOYEYuQCtnAW35AZ5gat/fXDG8Q DRjJqRypIBi2YJxnUA2WETv9TznGudTyq66gCpIHHyB7DxuUV8ty1A3iB4acdMHk1CvruvqWe8IT zz02Tduw1Vqt1dQANj67M7yLwsPLcKGAicV7X8uLvNkwceqSLtlAyngXOdqQ1+mKX6r/pi5FWCyd AQj2pAVawMRlW9gxMA2FzcS9xhMapxBywBD24BGEUL50Rtnyp3lmyNl4G2x7Btr9oB3C2ByvhDuc 6wcNomhTMJl3dXXblUbixrfZtce+zDs4ajzf9W4U8hVU0RAVgRCeEpop/HCsVsqNcAqteYOj/N0v uJXgo8KqBrx2Ezn+wN1Jmzlg+WuIkcTzZJbqXZbsHeREXtjv7SMZARrwyhL4LbNxK3/TSW0OCdM6 Z0KhTXLGeSHFtUES6A8d5eCYG5mGYiDaMEE+hmbKk3V9pFKRmRBVEeLSe8JwjdCnuYMOp4mnedBO FmqGgLU8eIP31YORkw2Sg9c8mGtI/4sGOxibmigeI5PlDWEIRa7eqDDpRR4ifpZLfIcY5btmcTuj HElteFtLZ4p/xVOqkKIQvBLSVlEQC/MHpICwXP6kcuSejaaBzXKBUWU8DnaOj5Ygw62O4MEWPjHi BBdE211wQJW1dhdxaeC0eBpf4LPnXbnd2aDolXU52+28koO1+HVfaHCtSSse+wISOKuvx0itW7AF 6v0KQf7jMBDv8l6WoRIWI1kNQ0cdnQ5zETbM01Y8AHKXoodho66zsgbp3rTllPKq7AlHmulBnbd5 /tdgvhfheyVSjRwe20Ds0ptkW1Bwnji8bx1fy97i0X5JNsxwp/aamCgGroC1qRA5wv8gDT/Y7ajG 8pGTb3iiFTBiE8VoJ1QQ7+ztm/N+5EQoigLBHAmx75QN6lu1xQSfWrrFYADEEGXmriBCEANcRwy/ aOKYyHjkcww85kPZ2/YGTdnQ1cOdD0bZEETmINEK7YAAog5nw94tBhENPuL63JeYfY9od80ulWjw wzv4vMLwg7FptI2AD8krBn2tRUTx8wbB7ioKA39ADWB5FWHhKwax7wJ7o2J4l8oD06IqgdbGQvmQ ehihr4alSmU0CpePDzHX8HT1bMIToOaYUuTGNXKTgYuy9sGOKW8+Xg0xoXfOCHOfOXIqcWPwdlLb 4h9avDSYasNrSa5QWd6OX4qucK//WX2ZzxIrEhuSnxBi4D7mf/7ofwPkwepYxBoase/1d6Oh+u/G o0ZS+JODYSFKbxVmchKNCyIAQU3gQIKi/OCj5mfKlCwLG07p4w8fQoETqU3EeNHfRYz4NgqcFpIg RYvUplmc9u/fRJX5XOaj9jLfv5n/UvVRWS3WTkY9fYrpKUZMo0Y9i55ZxCiNUGr+igo11BOfT6pV exrC6nMaUEZoqnqVyqiR0EbbVJ5F68/fWWfH0L6FC1fb2rii4lYTg0PvXr56ueAQY/bfXG1xDf/z V/jwv5SLUz2G/NiPtlR+LFvu4ydVs2YhQ3ae1uyetMfNCIGeRhdxWpViFh9WdVb1/+u3yeISxC3Q oMA7Dhk+9FORZEfiFHObHJg6+TTcIfFlw3cW5sCZ1fJV+0cNe6opfnLCsiqWUVQ0ZImK/8lVLNie 04yGh+/Tlc+o6IumZyRYsexstA+vpeasxvz7ZxtY/uIiQRz+6muvwAh8qyn/onMsMsgs0+YyPzLr AxVqOAsNRGbuCTGkRVJLTS3DZoNQpT9ka/GtabKZUaXjCKrMpIUY+m2h4CoSrqMgO8PNoxtvdGma RWBxaaCNnIlpJpdU4g6i74jC0j2xohqKrPd8Kk+MqM5DT8uiyPTpPqsamQbNNRkRSrDBYlyMxf0M C1ClbZbKqy8FEdTLB0FjoTNP//8GNCyyaS7MTJtpMNvwR4H8Qa1EzzZSi8W0NIWLUwHvpJPCnI6k JkdqGsriIR4lLbK4kigiEqFmLjpyopdAoomauahxBkqXrKOpyu6uvM+9MxsBSwwfhuKJqDHvU9On e9Ikkxqj3IxWLGijjRMtUOlUaS1RCfRnm1jSGAOPP8YwRAwuBA3UhwUFXVYvMWKRE9zFDOXUwkUr i9SPRy2joo9UkgPps2lcaUaajc4KcEBEDV2sHxs7lUZffO6JkNRU7gipIUd/a6iPZjIa6B5X8ZmC VOaALKmmArGrJptqioSpyX/uqbKPYWfeKRYt1xxLjDSyhS/aqcCryqn4nk6vrLf/PI1xXBjjMjcN f9Ado+sxDhEqXhzo7XNBv+5t0Z9UXlur7dXgsjCVFAe7LJsNq8hCs0lze5majKdGDNGLVXqFNjsZ o5NTUkud4uCmUE3VoVRQrkhlhCxCqOXjVsZHJpoEk4iuzmF6bJS1S53GZ4i8KzDoNu8LQwttrnpK PaTDIzN3qtwUa2jdwRwqX5U41vcsq88CdZs902CeGuaff77esP1psK9pYMHO8H+caZFitOJ+bGAN Oewjb8e1OVJwuvqx+K25uP+nkLQlQtzbxY630eM7BFYIclWDM85ANoaQaZAogBxxlQA7l5NqVGMb TbFOk0znjM0QRCHM6I5CcKKn/2qgIhXaOs/srjVCajHCH18iIdKw1ZNsJM0nS5EaXPAnoP4sRh6L 4ZjyzoUu6DkPeswbg7IW5A8G8YVePuDCKwCDr+L9J1xvAR/ANASpiORNFdTIxpHqp5LGtC87sIDY P54Ro4etRnCFqSGEPLaQVGRhGqhyiELuQKtWkYhWGykOAi+HEYkA6x8N3AbN/pgdKEUpQAnZ0RtT RYoxFiiQO4nGK6D1umvlTk2NECGWtoWe92DpWq9jRk9OoS35BO8w+AuJf5DhqUQk4lxd+yH0sjEG ICprentJUBGPOA16MSJ74UrNa/ohOLQ0BlNqaQr4LDMNZkyRQ47SmxYN8ze4CP+ETnc6njbAGCOP 4WEhnqHCjtyIisbhMUjZucfiRjI6z9FEJlJqYAMhRjqFTMFu9fyZnmKhE3zE4lpO0eSXstWIE1ZS k7+LViNaKJZQilI8yMpGDKcWTBl58TX9odo2thbLH87Sa4ISihi0cUR5OWdsyuIl2fDlkRZRFE/h WksUp3iZPpCvZI7LzRO7lylyzUZxhTpSKrz5zYWEU5yeyc5KmoJFf/RDIhjJ4kg48k6qvjMmNGmJ NRHpo8lMI45v0ck9ghaLbSUUhGjwJCO0Aa1O5m5oRmnT7kh5HlPKSDX+ICaEUpLXf3A0lmPQRkjF QMs0GMJ5QRSsUFwh2K0oyxD/IBUeWpqxtsXw9XvKDFikalq+DZVvCv/CDWKodpg8WZYxyulUEyEW 1KFOgZyJfK2P0AcTG3WuJAJBX5Bkws6qyiRPN9MOlfCpmXq+MZ9nEZpOYgGLWFBjrAf15BnuYy0T ghCFaZrGWhOapXtwy5eq9U82OLUNwv71o1spL/MM4VfmMUcbePioGAAhlGVt03tv6ccvuegfmWYW M5tNVRbwyhDLPCZPEuJmaS2qEjRMwkYqeksai4ebdA4kFfdI5I4cIg3jNi5AtpoJ5zDS25dMo7fY oW2uGLcjGmlYdYSIyz10KLSx1vhYmqSkfXYH3UaYRKAhMUphlqpf8L7mW9sY/yz0upbYNGSDvU+e Rhry8ApH/RCxYJzhfmU0PJVkcYs2kQxkxEdTDgU4C9ow8+r09hEIk4ti9w0XnLVMG2p2jCAVLpXA MKhhHjVkGtKACGWtI8/e3oPEMjFxBGUiT6zaBJ99mAYqVCcIDaMCLaIyVyzAUOOdnKcRZPUkdXkc UB1rxdNs7Ul59lnktMElpM/z2pNlDb0o/1Wwy4qskS/tjxrOJorZIJGGzDzsANfUMlfMbZsJZE09 6TTORV7wanHzkcp88x7aWIgW/OEb4MAvkCYu9KEX3UCqJjU7+Aw0PrMwCB65Fi3SGJcDtaBcTgct SzwW6I5vrG8yCQUWuWZ1i/+q8S7CauN5G0HfRmbNUVco2ZbwcgUOiEwbYkZnwXEjUSpekTfLFJvY GubfKHQ1KWYAVacDSkzAJSxtClNDFehuWcu04NWHAOdgykNIPHV+nWnE8506B7qir5Odau8IEI/S 8Cn4UGm09IN4l2YEM+r9XH+CetT5ptaxrIIVtAX8MKlZeVxgMbaC13rhC09sX25Q5yY6qpqpUFtk OgvgNO8oMwVW24Fxa9rbMHtnqpHzNb/McoJkseganku7F+Izo6aCZvgIOrnvsfPrRL7y5JbS4b3q eJjz2WARJqZYmfFpf44aoYww06mThi2hEGoxkKDFWcJO8WHaqBm0gcWr06D/DSob/OzPM0kthRIG efHlBlccPLgWYQYBQfFfktlQgMWpoccQD1QEGS2eJLRXlcwwJZTVa/KPlI3DL4QaC8E2n/kcHLo8 UDuMbknkswdcnWVnqygibitOsX7LmA78dHGYuMCrnTAE0mOu58K36uIk67IkaPG3iTOc2VsMUogL UJkNang1wogl32MvWEiFJQupBCkbLlAF+uk+bnqNk2i6yFAdAiswv9sZ5NGpaSOjgfiHV/CHdKoT OSOEwkmtvrsRu1G/IdSwyGGImzuLBnIG+fuleGoJiCk6R/EHzagMr8qgAoMMG4wL7zMQOCnAFUKT 83idBEQ1sfA3//CUGjmU/3+gQNm4L7rIhv7IPaF4nuzKLuZ5BfaiAi0ArJCCFxy4gUDcgn+DGPrh O/BKiYRYqjJakatJEdyYC7rIvvyhi1cwiTCCC5ciFyDMjV7xKuawQiLkM1Xpgx78lpzYJ/mbklI5 vPSjwir8gywciIk7RcMgHnMhBC0wj+tqq6tbQDgRA+xBw8UQL9nbRCcKl2yIBaEor2noh+dxMr8a AyvwByHaixsAREOAQLQIPFZ7usPAhquJsEyBRLpwi7egkLzCFP+YC3Gsk2oKKoERxXlUvxeEwQLh xrVoIGoYBYFJPyrAQkXpxghpIgNJLKgpofAIKSbSnq+ji1S6DYIkRhnJhv9lSa9pyMM0qDW5aYbE 2ooiOglhhJBtQosUU61DjL3k07LcaMdzlCyViLbsmMTki0naEIgrcoYrsjCFCEV69MlvokKEGQgK qozW8gNU8D8D00Kvg4ucxBrwUBaQSiyo4BLBAgNdDClGcL2GbMTCOMSZPIxteKwkg548rDXEskZq 6AttRAwEW4x0UAd8dLaAuwewjItpIAS6GAh5qAie+kGJtJ/YAJxOGQX4WTZVuCJVwKk8+8nGZIie 7A7xoQI8oEwNiUW408S/ZEr/MJB2iUqSepepzMqt5MqzqEsYwSsCkUACqYaxTC/hi8rqIcFtjJFp EIZgSJuBjMHiaQyCmBX/3KpLnxIcXZELlYgFw5yzTDSMU7xJXlnM8vusHXkFPouteazOKdgzPKA+ A0PHv/E+u8QhznyLp6M3RpgEYLQlf2PI4hkXuqjFRiSQ46EG14Q1tHSXv9gCQLyBQdwG8fLPJvKU b6xARhRAACVHlswUv3RDTgFPXes7nFzMrdKwUAwJDdsz3yjC1+qNuwtK//CiHLSM3ZzL5psQAVXJ uywm1UKIxYAHY2AMEuHN8IOL1hysqaSG4gvEG/AD5HsLWHjPY1TOzSSQlEjQxWGRSSlQvfpRvkIO 5ywkKOm8CZ3OHQE0UeQfP2gCpXTLNSTREy0mttNMd8zE2TjNmoxPcjlE/y4tTbTAi2URFFCknhzd AlXADhRJTVYLPKcS0oZE0o+gwbS4R/upwOVMOW58DSPdEQzD0E+c0FCkvn5YyuKpSRNtUBQNFTBt tS3bl5zQlzQ10ST8C2pQIhzQBv00BELcUyBN1R2UxP8IVAiRwGz4UbS4ISjUSYFwhgzJsAmVzh1B BbuBjFUtpjRsKUutzUoVQI5J053RzSbKsuwwBC7I0f3kUdWajVkV1iYaiDvBKyd5R9pwuySljVpN Qpc7n/SLzoXYNkclhMdgjG/B1vFkjNrDodFa1n8IO9P6Ay2I0SE9jL9RjXvlot58AfADl9ZMEOwB ODohJr4rhBco2Gz9Ov+b0IIX4Ne0yK1IHK0buteQeNiIVYl4xZNUyC1086qE0AxLNNbBaalC+AOI 7cZPNdRJNNPDSIUXIEmGVdO4aB8yFdh3nQYYuNgUPAzSLJ7T7FJv4RRYgIGmfYEX4btvIQTWgQt6 TcGKhdihBVQCqYlnDVnmaFoYeFoAXVChkgPLIITMPIw0EtkI2YJpgNkwZZu3mVh2zC5dgQEwUgWc 1dkmwtTkhBAtuFjBTdFhVdvKgsgVEZzFFVSIeQH5+YdRCFkHpTi4zdlpKgStJdxqssuZpAaQLTJh cEP7K9y08QSV2NvLvYu8RYvN9VLDMCY6SYWXtVi42NvtgAHarKyTbBH/WMhciDVYldACyIUByMVE iaWSip0GLTBYi5oN141ciqNbis1a+cErvOo5insBwVSJ4o2RaqDdx9Xd1tXa4pFEdkhWArVZrNU2 laDAVMhdAQkJq/2HfX0L751Lcm3c4rlZx7tZ1f2DF0HetWVNwU0FZ4BeG3kBapBZZC0ewQWjahhe /2Da4A2G4N2y3hRcwYTfQjhcm32B8X0NphXghxVhxoCB4C2EZpWhByummo2QDaYS/G0RGpbbeNha 1ZKbsxDaaorfhXXglkqHcaANLRDMQmBdc6tf+cmyII4RJP6lQsDguHjZS1QJLFuJiWWOF8CHOzHi qVFQuEjgf3gDN2BN/xquBhgY0gV+mzGGECf+B1io3dYthLb9h73l3qrNYnHVVn61mIflXgr54jg+ DJl1DL71uljk4Ys1FFW4WEM+WDdejB4+i1RQ3bhoWi5aCxMm2jTWgotAiz9g4SR8XHBpn4c1lOUl EBgYkPwq5cVAA0lg2SLzZLgQ5ScOYdj9VsOwmj8jEcEpBPlJiYplHQr5A8h92PJFYlYOXmpgXxt5 2cew2OxZZtC9H8PI5Tt+Zb2MX1jQgmbI4/gZBOCForClrFTQAjXWgiyAXG+GWDXGkzlWiRWu5IqF gTz+3KGdObh9ARjoxn6o2A+TxBKW53l2WvDD4yuu2Dym3fL9B4up4v8kRBRH7md8foHGkOOgzdqe Cs/JhQuSDGhbnueCjp+DPgvXdWfupejthRCvfYvM5aJ+tgvEcdk/euac+APsuAc2RpxUIF5+9emX zdzfymmbsAEwONRZzglEfti1oQsJDpCbvWhDAd+auVmKueWrlmA5Flz5iQ0p7l6HRoum/aWNyUH7 pQay/tx3hliWrgaSTpSx5SJ6leCNxulq8AhQWIaz4GSp5ul/0IIXuWoZwQe4NV4ts980zt21FtsX YAaW9mA460ZiVQkU+Ky4iI2bFeAZvek/KurB/qNX9us8YdoGkmS4gGSxy2ZVzmJHhubPFbShDdr9 UgXIhe34AWx5luD/k4bnxcievJrg+EFk4d0mUU7nJNTn3gZs3n4Gx+lnyqptwZTjKebraX7pofVg 8KtYtaCQvZ1JLQjAJ6ILWBBlkN3ttTjuk77YP/Dm3n5r6t4vsT1sxoDpkdbubBZesV4MB7NFuRzR 1v3rCCnv2Obts0jo+m3vnEBiIV1NfBhadH5pfxbe35oG403jf7AFbTaUpjWUT84JG5bew0Dlk75c SgbsbXpr4w3mRRYjm5Bnb67u8X1Zrb1tgx4QKz7pnguGS8AhVCjftZiHdhjpA3vqbU5xtOgErTXx w1Bsg61x4TbeJf9cC0fO/0YDLlUcuIYinvbw0FZx/P4HE7/ZcC4y/8uCAQqB8LfY3DTXZu4NYEJO 7+yQa4o1cJZmNdDWgirf23MeWlW4A8H83AMD3ZAWXu3WbzWXZyQ2lKbmGDmeb2d+jXvoh5s99PxO 3jqPjbXY8zpHBrTY20pXYDsX7ogR7rXZ4sOWGzJHx+Jpx06h9NdY8z4X9Ti/Yw8CcO853SayrJmj c7B63AAJ7LN42ez5XO4V81nf7GHX5RhJXcC+qn/YAoPOnmB3kSbIHvtF3b828b39rVcu4oKNjopF C0XPGEQQdcbw9sUQ6sp6ZWqv31xOCUXn6/gN5RfgAdr49AKnaXjn9tYtIMNIhLgIBdSFEG2QsLVY dyZv92TP5jTe7P9/QAUwT2vlVolc97pwhwFtEGs81o5X/tze7ndt1m56P3I5p3iMRVIKLljmHXdL 93IF7m0Tj/Mpn3eIt4V0hu+32NsX8YdMVm8uSgQYuKvB3u3DqNicv96XN3ny/SP5ceN0PoNvzxOf H2bZFvqxbgx3RYtZKNy9vmNWB+wUjgtAWIU2V/qPD5eEXmFpINzZ2PRsXV6LlRiVcAUTVszadWah dWZqUPbc3vChzefsSOdP7nL84iZyntFS/uTabW/C1+xsF4S/OXC/B2xUnl2b9HgJj2N6h3h+VY0/ IIJqgN+cx/n/MGG8YvzB3/sUl2BfKIbHRQUPeoFfKIaS9o+KzR7/DmeMtP4lH3+bz20GCZ43AVGN bPhbcMmTo18Mu3/1xkcOEy4EP5CGNHb6aRDg9w6VnxX8Fm6FdHbmvc3ata7dP6CCtRFcnqb5ULdY 8dfvn33yCEnhWGT/+a9div6DtSgML27r2n7nnA35SgaIF9T+/fvjT8s/ajAGEqT2otA/fwT/aXmR RgvDiRoJFnq4UeM0LTCqaVE17cULLdOkoUSosKKqf7BepPqTKtWLmLBgQNSoBeFGGEALpky4cKJD iBJlvjj5Z6K/aRqzfaxq1erSjj2tiqRWEqVQh0213Pv5E98/fDRtqiQostrVuP/uoZWrMRXcjXUr pnL74qnDkgRV/70QWq3jRMIxJ1Z8GqaGYLuSOX6E9eofYYz/Qv5NmHKxSBh4PRIUOrdhyjx5Km6d qFVjNdOMHf7JSxDnYm0cScvN/FEV6Jx+p00LvLhaSoaZGf4B2xc2Stv/OsLyibL2XeEahS6uKnUy +MRFN6YK/ryxZ5X3iD7HnDyhypTSO4WvH3fpZGp/FjcHz8M+gFf1c1VNBCHX2kQDThabFdX9k4ps domkEX7gwaQRLEN9JFE/39V3WVUdAeUVDA5KCEOA4FUo2YUTZThZNgpOtiJBwaR4Y112FaLhhBtN I+ONQX4kTVVededQexvd46Fc1fxRRWF/OAMeT0EqJNpgGsb1o/8L4TFJXkUpIShXlUJelSN4sWH5 oJbb6FbVeptRZSadde4YlJZQTYQPXXHWaRWaPn4EQ3fuZeTdVW9alY9kqowk5GEtFSrZFOFRs2Kg 2hxql6PS/TkNjQt2lA2ocuG3njZfDrbMKWn9SRCo+ES11I+LgqeNPwxp0VpHSW6kqGR+3qgqSA0N 9oJtseW5UTzEzhleLBuRNGl9m8L66paB2jftlikSq2KpctU6mSo5fottROHa9+Y2BP1Rorud3TcZ Ws8GqO1HQAaW5aNyyVMVsAQFvFE+0YaJkq90hqoijcQKW9/BNNmVzTL2WYuuvRFJttTC6MIJ4C27 SSrZwB/5mbH/xxiGuaZGqjzT8UQllzzRv0T9dbHATIJolaozmzrQw+cS1Gp9zd1cVVQbgYIuqE3D DJ7QVeFLkERPu2rfwylvBHOg2fiDK6gzu6I12et+tLNVKNtnj0Z+Rj30q7J+9PZVdKvY7VX+oEzj Pfj5k3WQgJctcH1qb9RK2QkTNKWXZuKsNTwT+Xko42Wj5fe1iVpF5N3z4o20qZkrOTWAgmM1+D/p qAM66hTiyjjaGlXeNpCia3Spx4dEG1eHMlqtMX6R/zP7mQCq6w/pVukmyUeGP77wisj/rZHPoZte p92bEdRhXMkXO2z1Hk85to+cb/hP7dFHnREzr4776+NWpQO1/5nZf8T8RNOYfu7FdNtPoV2uJy06 uU1Iv8OK4VCHDZ4Rxy7Rs0vA2Ca1moWHHRF51riAJQo/OG5jKZOG+fxhPp7lTVCSSaABITgYvWyi dAAyhrUkIsC0ycV7aWlhkaz2OGoEDIYmnMgIi6Q1fEjjGEManl1sqBEfdm4lsKFWgJYiwGngcHBM dKFcSmYMSnCRIZvgoiisYgwc3oOLXNQWk/DxRUpUUY1faoYZu/iPNYZxRnbZohznCEY9/UMUXKyi GZuxtYBRY41t3IQxfARHNtbFj9qoInjit0QzMmSR00BL5Ra5CbRQI5BJNCRB8LjJjWhyKZsAYR0V 1rar4JESXv/c40boSJBFUkKQPySIGv9IED9KgxmbKiQXbbmJMqZyMnBsBiIpAYsxpqWWH4EjDjdh SxJOZBOiMMYx9TiNRFoFjv+AIz7w4Uxx2fCYyfwHM8U5TX/4gxJoQeQcJeJNPsbymtmU5e2YIRVR tBCOA4Fntexizi0mxJkNRIoz+TnHRM4zLtbEZi3BOcdidlKQm2jhGC85zu79aaCUQGcL1amRY6pT pBLVSO0eekyJElQjlAijN8Ep0vNVpRm7EEZIZVJNbqJPKheN5jRNVUsfouUKEeHpRrIBT4Ay83Ny AWdONQLQf0zhBZuIiShEIU65bdQqtfQBGq620I10MpwxxWH/VrHlD6i6qqnam4hbm1mXrlZlqANB EzKXiMOG+hSpgALgCq/iqYmwNVBTXehAxogmumbMrmnJUVkJ+1F8MI6pkLRLJxVKVroa45o4ZGMw OfrTjLBgM35FijT+yc2GboQWb5VMZlsIpJk2xJV/qGVk/SFNuYw2lqcd5ljFSQ3aqjK21bwoI8P1 U0ZGdo5BrUpvfatXXLryH4Qo6HPn9hF8fEdxf6NG3x5mXL10FaCs3epEGmG76BKEKt4E0RbXqNpZ flR5XyOrH8cZlXv0TSNbbaoz/Qkn/IwxuQQ5rF5J5cdwfvEqrrWUH+8xzfgGCpp4+OYvRnrHL47y wDz9DjXi/9Fg+lqTnkKsVn4tyol34lAiF2VxQ6V5hT3QcykF3sQo6FtdyQrSjwMpBIVr+Ne4EO92 KYYrIwm3RQbX98DFVK/G9Jrkf2RjpolN6EeXnEv7qFGmsLqoVAXZ1BztlmpcbN9GsLkJVOzUq7ak 4h+bTNPwdNmdUoUkO6KJh05Wc5q0/IiaU3nY4tg5r3ldqLquIkmpSdOdmzDiN+VsXlc2WcKSpcSS qCYVNV9YsmmOM1o4B+biiYsge7ACKc/UaDSN2pRxxuWoJ7IOMyZEI6JAZh2zwVkcClePbNxE/EKx 3U0yQ4qR3lMcuRjLaermYjAUhYcQTF/bNfV/gNrkjqddzf920HcUdv4HXcVIDbcieAq8dmWZm5Fo atYHH1V2pWa9uZR4u/PbmLaKn76rWepejLXHDtLbcuxfbB9qnitKJyWQqiB51KVCz5bISrI7z17D 9bJzS+UYCzmNj24CzRelETMrKteprGiozZDGNOG5ohLPMqTj/JbdMi7N9Yw61n0cJZh3ywk5u1nN KfdrM6YwEHDyEy1UlMyAVgHFrYGUGtOIaXVVTt/57tab1xvqPTaxEmlsWs6psPNSo2lxrJlYI3mo eCG9WfMWg7SZgkz49yRHOJPjoxnUQAWxwFCDHmPU5dm9ZR8pwYzqwpmNLkZqU2n53KqNFJQQX8mA osLJjXL/l4vcFBoKbU1J5BnynYnMZZI7SYk4/L1lyNRlmyM9oFYKMpexkkz2vuPHfuxYkx7WMQ5F r9+rnJ6Nu/zj0O2cX1533kzSm0x+qwt6nOsG9DBNdjNohBbd9L6F0I4jNSQq+lGCHj+1s92ecMik A9rFEEvMyPf/gSt2v3Yi5gf/LBm9J6z4AxYDW3RBQvm479grjcOqG6wB3uIUmavoDe/oX+uIywwN nNzVxy5QDb6dX/4Ey5yhzPUIS8e0C7R8ygRuxO7A3zfNyMCwk0bIQzzkT9KkiPeVXZBMTahwT4Cs H6Iw3avMz8YoUejUh41wlAqOYJzAYOZkGqldhQYmoBHK/wXu1M1BScZ10dOzrEj4BMih6E8Jdc+5 qErmBYgN2kX2bAqTCGF4IJUN/EnGTI9GjNA9pJ9eHGGdzAF90EvpGeFWQJaCQCHZnItuQFwNPVDD sOFUAIjaLKBGFMNG3IDHwAwY+qEiAggBos53SATK4B8Ohkeu1JpYaRdZ0UrKnFb70VB9WFs2BBGd 2IAh+oi1CQkadSCsKM4i0lnctQ7OHBD5USAEdmIDbgZxyOCr0AikZeJ9kB8rEoQgOuIpysVTKJqS oAA1pAKR+EGlkIxVkIHW8Jd98I8ypgIK/IMzTgYhescskk1UyEP0gWBDXGM2TkOl+AwsjEnzcM6b TCIXHv/QVlChKnIhNZijNj5jK3IKJp5YKrDZNmrEJHgH11XFI3hMf8XMjOBDPySkwGjDm2BjPkpG K3TjhsQirMBMMX4M4WiMjGTNNGTjNkbhrRwieCRiLVYF4/RiqUhkQJrKKb4Ptlzhg4ikPk4EIwAM xnQO/VCZNmSMSz6jACHO6eDb22wk1awfSLYXQYhiSE6kJdYJPGKPsDSc+lmFwP1DL6aLTUKNGopL QU6EBX0ENk4BCqDAc5glCgjdPZplX+jPFEyBPlUKDy2jSNoNUnrHV5LlWp5lWp4lW/bld6CjWtIl Pr7kwqDQwuiPVJBkeJSlX+rGFMwKNbQlWk5EXAJmQlz/o1S8pCc6kEZYwTdeRVZKBmSiQF2oZXFY Zntk5lpu5jJKBTqGh4lMAyoEo+YQj1RgY19gIzUEpDPeIweBhNBtht2hQKqIJJtBI71wYVy4AlFO BG/W5G8+Y3CiAAflSFwOxBT4wT3aJVT+wzYsITkCVlIZy6tMp6ZUJ0H4QThh50ZsJ1V55zUC5E02 DyVOhFHRCSk8Jlriw3cC5ysIZ3wWZ3d+p0TOppKcC7Xoxj2gTMnsTU1OBFqepYUq42VqxBQ8hzMu iTYwY1TcJ50wyp+8QjYSRIVeKIb6yoZGxHWCp2e2i4dkYUKQYLHoRl7yJYVio4reI4tyqNCZ4zR4 5q8U/46l5KiOoiiPWmg2+Gh8AimC3iVILAyJdmRHdgh+XEaoHMMrtMdunug/VGiSOKmGQikK0MJT Kmi+XAUFNUl+1iOb7GiGluOP4lKQwqiIas//ZIRU4N8ZxsX7TaiSzulm1qk/BGdxYOM9ECnAGY/g xI5dpEKOiOntECpVmSl4FsJyDmJV2Iu9AAtj/oMiWOmWTGdQtmeQsihdbug9usKpWoWCUEubkpUK lp2pdmU+kqmm8Rc1TGaUhud5/iFokqpkiOJHQNmtQuV1qmqNpgI1+NKrwmlRztlkAOHWUMVgxUWy AmeqFmhCsOph5mkxMEn6sCDr3Ac2MsNZMoQfAGZlZv+obKKjZt7jh+JqXJjEAe2MY6ril5ym0y2q u+oqQbhmpfhDuMZFNWRENuzrntiQsRJIXypje/rBHwSmqgJmriSqvWrPcLbN5HgO7PGRbNJoStak WrJrwFoqwcJmtGoEm13Sg+InekLQpSThRvSDojpk3UxPi95IJcaFn55QPUokSDQkzPRsROCgtZpn u12FNMwi0cbFpmKms0LF9UjE1LYNjZDkQRELjlKZfeBH1IYH0tbHW74NXQCI/UkOPZ7JlDQNWpSt 9jjm7zCsXEAnU0onmFpFEZbp9jhn0VoFihhp326NII4tcchINiBO1rZoRnTMgGRBnrKgn64EcUhF rlT/DZKOLXjIbeNwzp1QyM8SkLsco7Bey7qdBrHmYAJaW+ECSD/AwtJthIaEYqm97taM5tzQQicg w0fIw6wCoBQK2c0+otzso134btp8CTs9zSKYyEk6lS1Ob0nuI8ki7wx+ItMK7/9Zyo0oyGBWIxKS rkbs4BGRzQLazTDqJPL+ju5qr/jWh7BIxexKK/aeq89CRerWyfs2Jy1OzEecnZIICQbRySVcQlVw nQIbTzUu8GRMQxZKkracCtMVShA5cOvs77AKyZd4wjSmzAHhoKqUZn3AjG7YLQhXIQ2yrlVIwhS9 KQ1+CbkGEZJ60IZocPa2II14sMc0pkkSLxtWSM3a/699FCFSLm1CfIvVfOFHLILqbkQilCf+IoVc hKWMPOwPSwa+fIkaUkO2+ogZUrEXv0qqeItczNALpzD7Og4Sw2rjKDELpwtHasQsSDF4kA7zxvGN UEOV+sNepkWoYKHQTnHKLKwdR2AS/YM0pF/UkGdcQC8PsmANw8qhKMqceAhNCgrMMXD0BsiccBKt SmH/lhoiJ7B3CM0kB8gpAkv64ibgEoQTXwUk5836fu9HKAomw9+4HAoFV4UroLDFBEgbq9IZOjKd kM7D/vEo+2GF/I5U4C54kIpGnMH9Ik8Vf07mGfMrbvNMeqF/kXJ9xPIDY7FGKG8Pe8giR4TN5i3P vP9v0JoNN/ewM1jbAZHCEzzBF0/rllSDHtyzCr1KTOCzGhfvVVBF00jzhzAneHDbGnqMLsoFIDBO FupN1TSzXUhCyBBM2ThIlU6GFfRn9gDCEzQDcKDaVVhBPgeJNDiDSf+DHgCC9G7EWBJER1+FHiTs 8Ah0VTxB/YLzVSzBEpyup6Qy9c7sxjTNztayZHz0RuSkXPSO16AiVwBCH9ZHddS0YPVzNagCT0uL Pd9zfxLES/8DKUSNKuhBikShHkCRKoR1sFrFTDeKFQAz2dVJGdfJ9d7vnmg1VxcKlBGESHd1AuYJ Qzw0utw0cEjLWmOGTjuDTuewFfR0FiHsExRZNVT/Ntm89FI8DlY/sLl+RMX05Om6cj/eyCHANJ3w sPcQx1bPrhXANCmgdSsG1V3zyatYASq4wqQk9j8Agmz3NmpPKzVgNiHbB1dXxXFrzWVbxTn0gpnE 4VVEw408C2nrNUG4NUEMw2d/hxVMg2B/BCm0tA3fSDVE9kmOcqg4A0zzs1idNUF0dRj8g2ATx2+r ghUwg0AfN1cHdy3y8z2jdV/ndF5UQ2Cjtm8PBk9f9j3z9FmbNEsr9k3rASpUgz2jdnk/QX0vOFz4 91Kogkiowj0AghNMCT+jWoUbCD48AUr/w4XfdAJe7zv7dABdhenSj3qz+G/DxnfDRj/ntxXcs0SM /3VvI4hIOwNX+3hbM3Z3BDaJ93N3B4n7quSCP8EW4DOp2PdiJLlJpAUgvHZ5T8pAuLd8tzVXT0l4 G8hNe/dimDdwELd593Z59+dyT0SJv7R3A0I1TENMsPRWW4EHkwJM2zeLA7oe6AYgwLQe2Dk+E7ge eHlXl3c1+INA6/llE2BKE+F4y0Ujgiz1gIcqtItSc2+U/QY+1w6fl3dk3/Sh+4NjhzVvAzZXa+pl t7VI43mbM85afzmkO3Y+X/olDqFWTsSZA/aTV0OlDw9MhxN3L/pja095L84T4MFWPwFBvDlKTwOv szhmT7uBEDeC43jLtPpmoJpjQ3BkhzdceIJJj//1cLG5eBN49KnCZQO4QB86ls8Sf/9GDMYzUX/z qBf1R+QYNKeI+XzLgbffm4s0cHA1XHh3XqhC5Ri7fed5pbd5THA7cGsEIJD0m1vFphNxQ08EpL32 RJD8YJi0eR/7ZTMmud/zcPd2lqOaH4z1sasCIEjFwSe3S7s6tW9EZRv5RjC8P5j3gatCVHTHmwt2 tgv5RHQ1q9c7Wiu4W09DnJfNOvMkgPDpRHgN1y9zeCiI6XR8rOp0oou1aGIG1bN4vrs0ak/Dure0 kH93nj8BDns2UpfyRmR7TnfHWGd7cj9dkAMCxFuiypP8rPc2Poc3dy/GgaM1T1Nz0VfOWpOCpwD/ Apsde2SDgUhvhpH7feJjhkk/gYEPT9qnBcovvEATeFlru68LCDiqclSu8BEKDsNPxCvshz3nhWDr gVRcuLHLQTHBCuOgwmJ8d1c7NuObRO+vPfwybdZEdtUjuG14wigIPj6rgrpfN6pFRZfjdETMun/H BMN3+UvneX/281nzc6LjOU/rwRl8tM1r/KF/xEcTB7XPOimEwfWjNMNzdWTHBEAA0qMK0BM9/0gB +qdqmrODehRWe6Jq4MRqVqrhO6jqibOC1ab9EzmSZMl//USGNLmSZcuR/lC6NKnSH8ts/7TJJJlT Z8+a/2iKvGglIalq/wZyVPUPkEKR/p6cAuXs/wmpgyad4TsqMCTVo/8kUlSKVJXSi9UkkuppUprJ mzJJPZlIUo9cKyLlAuI4EZAnkVacGvwq8t4/K81IeV34BFA1QBiZMg7zxMpSK5X/UcV8eSnJsSTD Mg1ZjZnCvZ0lVn7cue4WxwY7Mxz4by7ViHKNArUid+ljlWuBjvwNnLi/aT974lvJ859x4G9ZMiJe OKXIbHvlZmcMdhrvlxS/Yl7JMO9IVXdFalZ1UTBY3EdDEw/uVr5Ox1ud6lQe8vzaM/VFImgt5ACk r7kC51truAQRdIlAmR4kqaYIXWKuJUkaPNAl6IDTxp+cIMpQRJYWLHAa6gQUSQ+1qFEQqfxGfP+K JECmKXEl6mIEykYXcyTOFZl2HKnFtYYkzsIeiQtSpLZmwiu2P5BkiRp/imQpphyf+Co+Ao3rsqR+ JsrGn2yObHDMzJQsCTkK5UszSgiJY9JKkaos8EMj36yPw5KykZOkt7wqK0+SplRuUJM4GWmui64i jpm58pxGLRMbdPNQlnBscE+T/DEUSE8vNdHSkaTZ8beCoAyVJVDfHMW83aqST6LsOsuxIPEA9EdX n0a6ssc9rojRuUpHZLU5nnD0dcRROukpG2WBbIm5uspbS7k6CzRW1QYHY4nNS3Gk8tt/qBt1W5fM TemedP/BtqRpriRQGmpgYVBTW0SyRbqZVLL/kd0ch9Upm2nKHElb4KiMsttzMxxuXA13HLifaTZt yUuGOf23XetqpPi3ikn6bUExQXYQ33Fr9BZjgx/mdGCTDF3GpEUIWVmoBt2t77i1mKmv4Bi1Idhm BOukeMSXV6om5+qQXulg4YAbxRlyNR4pp5ZbMrbqoXfyVtedBwwX2qx9lg9rrtHeJsrjdFWuZDgB BDvXrVc6uyRB0f6n5KXhVjLgAvleaew3M22JnWPyFqnekDN05aa3eRywxyltBmRqtPdicteFdoOx wMHlzpAnuwsM2mCZCgduGmnWRXvwVICT5qbBLY+SzWRYeu2JxEkiCm09qqEOFeRSpK3WuE2a/3jt kS4vKfCf+Q0Jn6dTNylw1V06HnuWCsHez94nre7QZMj87aKeFLu0mrru+SylibvLrpnuFnYJ+Ozv qr4jkq7YYy3IB/WgfFjPW3RriQGT5JLr3ahuC5TJ+rKkFHjdrSByuR+RPHcsk8yGd3QBifbAQpRp uEJkoxLISl4xkhDZiyOVIp3OVqKxneHrKdDT2Qsp1RIxKTCGOsGhBxmyoPXNBkS7WwuuXCKR5uXp TMSxgh7aZxIxFOImuMpgS5BIkhRuqSQnbMkSW7JCJPmrPn+joUjKVIjuPWeCdzpUkCL0tOJk6InT 0N5FevOEm6TvgfvTSQvHqBMbOgMV3CmJR/+Esr/1bCwulBlJBQminfFkhxotguBVxFMQZ0DQkaO4 ymnAApH1xIU1IIThSODxj0Qkok2XmhcsbBgqzTGQOMr6IUkQub6SkKIzXslGUx4pl6lxkj0WNAkE IXPCgqCmLs2AT13M4x07ekdvPbHhjlKEHSP6YzYrdMZxTsgQliSEcyl0hhU8NrH96WV3lZFINVah SwGJsiB6WQ9HtnK8nwxQTRYjSTp8qKaCmfJ79aGO6VjCzw3pxGHKKaiZtoUeoDDGi2Qx3kIUgpmK ggYjVJnaExuzv3OiBZ2OsYpIyKmHjbRohf6iEAyalDGoHEWlInGKHZ1EtSwJp1GeQU+IClH/GVJA hiNUcsxBshQrhKyHLxuhCilSZpjeNA85Ch1J9TSUwFmypF6lKEVJHioTasAuej+8iZKmIcf6YItC rZMPc3A3EscIxzRP5BxFJtWfkWTxL8dLDef6atMnHAczek2kbEayJ7eyRAtgVZmi/PoTQAYInbox pXjmwhFc3QMf9/DHunoJKYUUhIOL+QrFKIIUNMbyQboSl91CstWXiEStepJJLHWoEkLUrG4IdFBJ sFqcuKroKPgQbZY61y1ANKOzSjQJGHYaTZqaJro1dQY1pkuSuAxEZA0K692ia9OrnPCdQAFEqToy V+btFJ8JMaIzLDMNx6SPKr05CmACdJRB//yIJMYYLCr6BUBLRXUl0viubxX3Jx7+g6w9WUR10ACg VMYodfcILoGl5dOJ7hUjkBqIFSxc2N1V43jQhc9SUmu8pkQ3s+hRakadskhCAWhwp3tMF+9CSnbK Bg/TXN/x8KnZsnzkPEdhjB054hD30OgrjgTmRYVTjBr5Iy1AceMB/ye0PylJG7Wt0M6O9C03ptCH D05JNhihPODYo4w4cRotS4IPNcvnHpXBriYl0pikZAmPTMHIBQW7yfv57qk7ZopTBBLJg3SKNnd5 8kjQQCB83PJuc6BVNIGHG6Y0wyCimGgGU0OQ2YDSPcCbJgcxfKvQ1s+R/gCw+NB1ypuMC/+AEgqZ Dd9GOg71o1Rm83KM5NQvXpEqfk/4Q2P+0h6kVGuZx9S0e5Zim1BSc9mNUbVg+SqdB8kDQJ7NUXAl ZK7QySe8yHHTv0AlZrMBTT619prTrFrGkgUFKChBXEvibUBKH6oZdD7OiS61OICv5AwYehe3nPK3 GjOOtgMmyRoNlJynLKjXiV04rJ31aysT7Fo2eVPKpCGvf3h6xrg8eOnEaq20djBDvG1JvXxrrvxE aFzhEk7CXOIpQ+w7pnNm+G+Lo60FmcvdcfN53XRycRnZrH5Dk11z0uTyXSIJOW9DNkooBDo+Icjb wtLVz7Zmt79hnKEIotuEdEILNxEIQzX/wS3LExc+gJHdPYwZjNhTd0tD8Tzp9VFbyLBGoX+lqRSr QPrnZvuPxdFH6chpu70SB3HiaDzyP0cwYUxCHZy7JN74eEvR2/Q2QpDZJIvXm5vGxveenJYKSWv6 z0li+jb3kDgORGNPnhG+MNSH8jpci9JdggzJJ35EFOI5coDfysnB/ZgHamzsRJJ8uBEfuIMqUzXA WKzZn94lhocaAdHn+0MdP0rUMN3lmY/l+rQFwYt1SWEKSfX02xprsYC19HIE+m4Dp+lvP5c8sm/+ /InOlo5IXOLoMIWsem+hQkX/EkusBoEGJDCF2uIVUIEGsOAnXoEGXmH3mkQCsSBwNpAG/76AYUju ZqwMNPJkA1UPOECwRUYQC9SPXKKEEGTw/WBBAr+LRP4hAjlQJCLwFV5hR4oB9jAlOYbE/0TklqBn A3lLG3zwKQbBHxZBOjYwhcSAgS5wgZChBM9FFAbh3Q7lCnPERh5kA4skAmlr66gvRmwQdVKCBurj C0rwDelQb27QLYphYJBFJnYQbbamYqiBBEtCDUWCENJlGtCwJ7rQakKFGsIQQTpBGEriq4YGqzbn HxbxEPNwifpE2OqDEc7IoIQjD9dCG34wC74AFVNIFdfQmlguJOKNB3PkC2igTgaRJ96QOFiwJwjB CzVRPq7kP3piCKPEEkkxgYyQJTbxH/92sZ+qL1qEpTDW5RnXggxFggxfSAlZghsFZlCeZhDl0CQG YUissRinYYF+sexIpDDM7LZoANwwRh5jCDroURNvcSTOke68DP3+AR+kYR9lIgdJDxsjBAze8eQK pGJGUfm8xRthBoUI0SV20RZ/kE58cBByYkpuURyx4CJ7pQe/4AInUIssUmhGsGYikBBq4hUsUiNN YgRBkMxeIQskUOpGYgOnoWZskbdg4SRrgiRpABW0wSLpsCTR6B4k8AvIDAQJQShRQSb7YU8gcSa1 KB+B0BSto10sEhVqJiVtkASLBAqngQRJrypJMCeKAQOLxCXLMgtSyDkEkhPNUiQscgL/7/IH/cEG 8QELyMwiqWEEU4gauhInK6QlGvI5iE9cWOIPe+ICgZElnnEQyQwVeQsLStA48pEwC4Ya+iECs6BF bHBIKDMlsmAkvuApB1EGlfIvT3MlsEDqsHEQIpMk8EE1sUAGS3Mns6AlL5IaRo9OQBILmGQTY1M4 yYwasoAnhuM4/+ECCxIrnVErRyILQoIsR+IjQ/MfbJEnXFER89EyRWI70wENlYMMpyECEWoQqNMu vRAbNxDisLEHyeQf4TIbOXD0UrFFoNALa+G2Pq4N0eUeWwIyXaIWrPEiCeE1/wELwtCzbnEaajPx piEEkdMuGZQaFPEf8uEXU2gRSvAL/36jNE3COUUCM4UEJEliEPAhhe7wCxhUG7LBNbOTJC7yAhHK OQmBvzbwNaMSJzhEPNvlB9WoGXfRQjSUOSORO5dTOGsGR1PiONkzO1kSH4cEGztGH9vTSE8zMEES PkFyQZ0UH19BOZljSRPTEaWF5yCBFmwvQ3pUJsDAFP1SJGhgSasJHyt0QjdmatbxQlERAyUQA3lr FCz0H6QDBAeVBgyzQZ9wEOPvRBt1ENLRRkHQFW4SP1PoFaSuTrlTUSXwNQexLQbBBluxSOpTSFDB Jr9UOo+UT25Sy7gzMlHUIj8yVP/BFUtPOjVRKK9kSslxHEViC8k0J28UVCVwIxm1JP9ekigFcPt6 IjexRQiz0kabEk9VYgi1YRBxEjmc4U+H9BVyYiJN4hzJ1SVM1B+GMmRCTkx+w1ynwFtc8Quq5CJt sSVEVBtOMwsIgTBNgidglChJ1Er18TUtpFO8MhswEDUjkxDvtUS9kEAKYTtxgg4LiUu3UktJgljn Exuh83SaY2BHwis/sj255oc27xqXtSTyEFhPlEajlGNCYj7rBFxzcTyFtVc5sSRsUosilSScswQl NEVJb0W1EgvwwGdT4goZ9GU5cSyXdAMD8jljs2g3Fis7VhjSUCvBACgQ8Sc8FUZzIh2X1RDEAGqZ FPNucBNhdGQj1Die8TeMdG1B8hT/TIEmQRIfhFZkORVordbsmKegYCmgZAIVGuxAxq1w0zIbmXIk DBEnLnIDI3Ea4k8pf0I9WcJlzQ9vI9ElNfYqO5dPG7QE+3YIU6goRfccnZBxZ8smi5YV0UgVW4Qz gRYLUCJQf8ZUNdEWC0lmNnAYPnckzkAbNrCQqIRiAfMfpKFJ9ZVeuTInJDcl4m8TbRJ6bZH0XDZB 7rBYubd72ZPM/CCF7oFv17VdKBbyaokkHNNizOVNS4JTnfJKFxUVvkAaBlVqXFICI/FWaUAbCCFU tVIcMdACB1UKGDdT8VFRTVJ/0VdfybUmEdg2ZfIjF/hOGWcDRYKVbDU8M7JOVtVx//G0JKAwUzew BEFhUJlyfp2nVJfyNyxWAisVjTo4J08yJBZVDiH4B1dSJsu3JP63Lv/hhnlYQUMVDLbgU19AAuMP En+4cQVUMXvk7VprUMTtH/5uRNghbDIMY2gBSRaQtb6PJLa3ALe4BXtk5UhiFbxPcpCHaUTkX1rm 3/QjpoBD9mZi7Fji3t7vWZcPT3wocbOgaQWJj4FCGBbElAZlDYzGZmriSvpk4uYIQXrA/6YEIm2N ob7nKCYoVwjZJ0qEh/+WJGyOj2tiGPyx9tYgq2KNRG4iVf4HfTGmB1QFIisOLDJDFe6hlpeRUOSO OOx4ZVRvdcx4LWzhl9WUDWGZxv/gZZNpURlFGTpcOXL+pIkAxH1DRRssuY1d4hkAJE0ZZpi1Qfo6 pEHK5C3G5fXexI5ZZeBAVpV7QlkQqiekQZyHxgFFIh8W0J75uIuRxJqBw59FwgPfhR7ROUqMORrp WJq5Zn0X0kyKrkVGheecIQDZuCf4K1ROuT4EehmHeZBHxE2UZv50uSQKoWsZZpMpZ47NhU1e4aD/ c0TcZVRyGf0YuiUibHnub0TW90gA2p2fVU76rVcspafNhqjzZQDbbXKsim8mRukWwZtnsCeYeST2 hWw45UC+hZ3p+ZJP4ondDHAVpKMzpNewZaTBT0GahkiQAx+2JpTb0K1FxIHEei3/dtAfDCElanqX rwpdhoNuUGJBtOVh2AQBgWRM5hrxrsr9RCSeTUStGKGqRQSudcIWbqH45s8fCiHsWqLG8JjvFqTr vJreIm4l3MDgEi+v9RlBFhCmmWuTEnqMsIGfv5kd5w/D3hir2Jkkeoxw4jiMZUKtPIXorO+qGYaw RwIZRqIWIKFHqDmAdqRLoKdqDjtSWkLzTCJpiQMh10Ie5Yvs1E0albdhzCSm0y8YBOfsVKV1tGD4 8JjdGEaxnRmpB6VOcs2WofEV93r6GuQKVCIfKBro8qSgbaZqtvpLfPqaGWa1a0/AUadn1k2EyThZ ghq/yVi+W4IaEPkfWACiLgWi/8eIQPWatnPowEPm8jJ6/hLyTSIkpUPG27hNWBDksC8PxM2mildC j+dEvwF0i+euk0kCsokjxXOks04pRwD6bBJBtlUHgdbOhUS8JE6wmXNuQBDo7X5Gwd27JYB8exjK tkkii8kFy+WP5SatzI37scTnzE88v7X5jKWPEYjxmDnrQO/bZrJ52EZkHWhcVab7oyevxNGlvYED DEz6CMswb3ghHMhFHi2saFF2R+SIGjzF/wy3yDOko18gfZeDJbi5wtPv71TBGQojoictxg9GrGWx QeyvPiCuzzGF0dSktu4cOLTFGzs6Xn8vD1xFIVei0/f8jdNaJ66YBusDoNQ3+SY4y2p/ve+cZyX8 giWOZxZZYgt+wp+nm8veJBX8wDbVxAF/aDgCAgA7 ------=_NextPart_000_000E_01C80C7A.8AB2B490-- From luttrullntsh@pb-anal.sk Thu Oct 11 22:54:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAf8-0001ZX-3e for nfsv4-archive@lists.ietf.org; Thu, 11 Oct 2007 22:54:06 -0400 Received: from host230-86-static.28-87-b.business.telecomitalia.it ([87.28.86.230]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgAf0-0000LK-UU for nfsv4-archive@lists.ietf.org; Thu, 11 Oct 2007 22:53:59 -0400 Received: from professi-0f9937 by pb-anal.sk with ASMTP id 26AEE68E for ; Fri, 12 Oct 2007 04:54:20 +0200 Received: from professi-0f9937 ([126.143.22.112]) by pb-anal.sk with ESMTP id 43C53D08601D for ; Fri, 12 Oct 2007 04:54:20 +0200 Message-ID: <000b01c80c7b$24ba50c0$e6561c57@professi0f9937> From: "Audi luttrull" To: Subject: iskilaam Date: Fri, 12 Oct 2007 04:54:01 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C80C8B.E84320C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.4 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C80C8B.E84320C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Watcha nfsv4-archive 1, 2 oh no 3 orgasms! WOW you can have them too Audi luttrull http://bloglfux.com/ ------=_NextPart_000_0007_01C80C8B.E84320C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Watcha nfsv4-archive
1, 2 oh no 3 orgasms! WOW you can have them = too
Audi luttrull
http://bloglfux.com/
------=_NextPart_000_0007_01C80C8B.E84320C0-- From padergsnvb@www.amazingblondemen.com Fri Oct 12 06:30:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHmK-0005jE-F4 for nfsv4-archive@lists.ietf.org; Fri, 12 Oct 2007 06:30:00 -0400 Received: from eco86.internetdsl.tpnet.pl ([83.14.170.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgHm5-00077Y-G9 for nfsv4-archive@lists.ietf.org; Fri, 12 Oct 2007 06:29:45 -0400 Received: from mariusz-8qo0q1r by www.amazingblondemen.com with ASMTP id 5BE46BA6 for ; Fri, 12 Oct 2007 12:32:32 +0200 Received: from mariusz-8qo0q1r ([106.125.134.98]) by www.amazingblondemen.com with ESMTP id 7F6EB2686E82 for ; Fri, 12 Oct 2007 12:32:32 +0200 Message-ID: <000301c80cbb$2a072c70$56aa0e53@mariusz8qo0q1r> From: "tabbitha pader" To: Subject: aicifene Date: Fri, 12 Oct 2007 12:32:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C80CCB.ED8FFC70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C80CCB.ED8FFC70 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Watcha nfsv4-archive you'll wake the kids, sound familiar? tabbitha pader http://bitoffon.com/ ------=_NextPart_000_0009_01C80CCB.ED8FFC70 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Watcha nfsv4-archive
you'll wake the kids, sound = familiar?
tabbitha pader
http://bitoffon.com/
------=_NextPart_000_0009_01C80CCB.ED8FFC70-- From kouch@atrium-sa.com Fri Oct 12 10:39:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLfe-0004iw-Hr for nfsv4-archive@lists.ietf.org; Fri, 12 Oct 2007 10:39:22 -0400 Received: from host210-20-static.24-87-b.business.telecomitalia.it ([87.24.20.210]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgLfR-0002pa-RX for nfsv4-archive@lists.ietf.org; Fri, 12 Oct 2007 10:39:10 -0400 Received: by 10.233.143.154 with SMTP id JKbgGGSvEWnvW; Fri, 12 Oct 2007 16:39:15 +0200 (GMT) Received: by 192.168.141.103 with SMTP id JWcZQFPSDEMKKY.7627042209126; Fri, 12 Oct 2007 16:39:13 +0200 (GMT) Message-ID: <000201c80cdd$a6ab0270$d2141857@Andreanotebook> From: "Claudine kouch" To: Subject: bondsark Date: Fri, 12 Oct 2007 16:39:10 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C80CEE.6A33D270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ------=_NextPart_000_0009_01C80CEE.6A33D270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hay you nfsv4-archive CAUTION! she might be tight when you reach your new size, stretching may = be required Claudine kouch http://anarasha.com/ ------=_NextPart_000_0009_01C80CEE.6A33D270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hay you nfsv4-archive
CAUTION! she might be tight when you reach = your new=20 size, stretching may be required
Claudine kouch
http://anarasha.com/
------=_NextPart_000_0009_01C80CEE.6A33D270-- From apostol@athilat.com Fri Oct 12 11:11:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMAy-0004d6-TX for nfsv4-archive@lists.ietf.org; Fri, 12 Oct 2007 11:11:44 -0400 Received: from [86.120.165.13] (helo=86-120-165-13.rdsnet.ro) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgMAs-0004M7-AT for nfsv4-archive@lists.ietf.org; Fri, 12 Oct 2007 11:11:38 -0400 Received: from PETRUBOG ([174.146.80.181]:3798 "EHLO PETRUBOG" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 86-120-165-13.rdsnet.ro with ESMTP id S22HWQLCCQLKFYHQ (ORCPT ); Fri, 12 Oct 2007 18:11:56 +0300 Message-ID: <000301c80ce2$2f897960$0da57856@PETRUBOG> From: "Marla apostol" To: Subject: verfoeis Date: Fri, 12 Oct 2007 18:11:37 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C80CFB.54D6B160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.6 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0008_01C80CFB.54D6B160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hey honey nfsv4-archive women love dick driving deep inside. Marla apostol http://www.aogelai.com/ ------=_NextPart_000_0008_01C80CFB.54D6B160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hey honey nfsv4-archive
women love dick driving deep = inside.
Marla apostol
http://www.aogelai.com/
------=_NextPart_000_0008_01C80CFB.54D6B160-- From nfsv4-bounces@ietf.org Fri Oct 12 15:58:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQdE-0006zj-Q5; Fri, 12 Oct 2007 15:57:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQdD-0006zb-CL for nfsv4@ietf.org; Fri, 12 Oct 2007 15:57:11 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQd7-0002cm-6V for nfsv4@ietf.org; Fri, 12 Oct 2007 15:57:11 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9CJv3u2006494 for ; Fri, 12 Oct 2007 15:57:03 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9CJv3FV363508 for ; Fri, 12 Oct 2007 13:57:03 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9CJv35c030913 for ; Fri, 12 Oct 2007 13:57:03 -0600 Received: from d03nm115.boulder.ibm.com (d03nm115.boulder.ibm.com [9.17.195.141]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9CJv3Bo030903 for ; Fri, 12 Oct 2007 13:57:03 -0600 Auto-Submitted: auto-generated From: Tom Beglin To: nfsv4@ietf.org Message-ID: Date: Fri, 12 Oct 2007 13:57:01 -0600 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 8.0|August 02, 2007) at 10/12/2007 13:57:02 MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [nfsv4] Tom Beglin/Tucson/IBM is out of the office. X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1192657106==" Errors-To: nfsv4-bounces@ietf.org --===============1192657106== Content-type: multipart/alternative; Boundary="0__=08BBF9E1DFFE11BC8f9e8a93df938690918c08BBF9E1DFFE11BC" Content-Disposition: inline --0__=08BBF9E1DFFE11BC8f9e8a93df938690918c08BBF9E1DFFE11BC Content-type: text/plain; charset=US-ASCII I will be out of the office starting 10/12/2007 and will not return until 10/16/2007. --0__=08BBF9E1DFFE11BC8f9e8a93df938690918c08BBF9E1DFFE11BC Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 10/12/2007 and will not return until 10/16/2007.

--0__=08BBF9E1DFFE11BC8f9e8a93df938690918c08BBF9E1DFFE11BC-- --===============1192657106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1192657106==-- From nfsv4-bounces@ietf.org Fri Oct 12 17:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRfI-0003wt-PP; Fri, 12 Oct 2007 17:03:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRfI-0003vt-2E for nfsv4@ietf.org; Fri, 12 Oct 2007 17:03:24 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgRfH-0007q9-AW for nfsv4@ietf.org; Fri, 12 Oct 2007 17:03:23 -0400 X-IronPort-AV: E=Sophos;i="4.21,268,1188802800"; d="scan'208";a="113310676" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Oct 2007 14:03:22 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9CL3MKL012170 for ; Fri, 12 Oct 2007 14:03:22 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 14:03:22 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 14:03:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Oct 2007 17:03:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Persistent sessions, NFS4ERR_STALE_CLIENTID and related stuff Thread-Index: AcgNE1HquDz3Tj97T+aNijTfSitqiA== From: "Noveck, Dave" To: X-OriginalArrivalTime: 12 Oct 2007 21:03:22.0167 (UTC) FILETIME=[529DC470:01C80D13] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [nfsv4] Persistent sessions, NFS4ERR_STALE_CLIENTID and related stuff X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org This email is about some issues that arose in reviewing the v4.1 mapping of ops to the set of acceptable errors, but since it turns out that possible solutions change the protocol in ways that are outside the scope of the error sets (not enormous though), I'm sending this to the working group as a whole. The issue started with the question of whether it was valid for operations within a session context, beyond SEQUENCE, to return the error NFS4ERR_STALE_CLIENTID. From what I've been able to determine, this is the general opinion among people doing the error review, but I had been worried that this was not right. To anticipate my conclusion a bit, I think there are a number of reasonable options here, one of which is to allow OPEN to return NFS4ERR_STALE_CLIENTID. So as the protocol stands in draft-14, when we have a server reboot and the session is persistent, we have session in a somewhat odd state. Although, the spec does not use this word, the session is in a kind of moribund state. You can do operations on it, but you can't do state-related operations. Any that involve operations that incorporate state in the args will return NFS4ERR_STALE_STATEID. This state of affairs is a consequence of the fact that on a reboot with a persistent session, the server retains information about the session but not about locking. (If the server managed to also retain information about lock state persistently, we would have a situation that looked, from the protocol point of view, not like a reboot, but merely as a temporary communication failure). Although the spec says that the clientid like the session is persistent, this only means that the clientid is recognized and you don't get NFS4ERR_STALE_CLIENTID on SEQUENCE; you can't access the state from the previous session instance. So this causes issues for requests like OPEN that manipulate state but which don't have stateid's in their arguments of which OPEN is the big issue. In draft-14, there is a very large case-by-case discussion of this in section 18.46.5 including restrictions on open-upgrades during reclaim. I believe that this complexity is unneeded, if we simply do the same thing with a stale clientid as we do with stale stateids, and that is reject the OPEN if the clientid is one associated with a moribund session, i.e. one that has a clientid which cannot be used to manipulate state. This approach would differ from the current spec which stresses that with a persistent session, the sessionid and clientid are still "valid" after the reboot. Where I think this goes astray is that the clientid may be valid for the purpose of accepting a SEQUENCE, but not valid for the purpose of using it to change the state corpus associated with that clientid. So I'm proposing that such clientids be considered moribund just as the session is. They really continue to exist mainly for the purpose of making sure we know what operations from the previous instance of the session were completed and how (the exactly-one-semantics function). So if the clientid is a moribund one, then SEQUENCE would not return NFS4ERR_STALE_CLIENTID, although OPEN would. Alternatively, we could create a new error for OPEN ot return in this situation if we find it too disconcerting that the same clientid would generate NFS4ERR_STALE_CLIENTID for one op but not another. Another alternative would be to draw the line between allowed and not-allowed operations on moribund sessions in a different place. The idea would be that for such sessions it would be valid only to re-issue requests/ops already executed, and any new requests/ops on such a session would be rejected with an error, let's say NFS4ERR_OLD_SESSION. Since you could have partially executed requests, any op that could be part of session could return that error. This would allow you to delete NFS4ERR_STALE_CLIENTID from OPEN and NFS4ERR_STALE_STATEID from all ops in which it appeared. This is because validity of the state corpus is tied to clientids which are in turn are tied to sessions. You simply could not get past the session layer with a stateid/ckientid pair from an earlier instance. If you sent the bit pattern from the stateid form an earlier clientid, you would get NFS4ERR_BAD_STATEID. I think either of these are valid approaches and both are superior to what we currently have in draft-14. Both would allow us to delete the current restriction on open-upgrade on reclaim and most of the big case-by-case discussion in section 18.46.5. Comments? =20 =20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Saurikhane@jetrepairanywhere.com Fri Oct 12 23:20:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgXY9-0001L8-8Q for nfsv4-archive@lists.ietf.org; Fri, 12 Oct 2007 23:20:25 -0400 Received: from host86-130-96-240.range86-130.btcentralplus.com ([86.130.96.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgXY2-0002IB-Um for nfsv4-archive@lists.ietf.org; Fri, 12 Oct 2007 23:20:25 -0400 Received: from LEVIATHAN ([125.120.2.16] helo=LEVIATHAN) by host86-138-72-38.range86-138.btcentralplus.com ( sendmail 8.13.3/8.13.1) with esmtpa id 1rBewR-000MDM-CT for nfsv4-archive@lists.ietf.org; Sat, 13 Oct 2007 04:10:13 +0100 Message-ID: <000701c80d46$7f13b950$26488a56@LEVIATHAN> From: "Saurikhane Dore" To: Subject: leajsdle Date: Sat, 13 Oct 2007 04:09:41 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C80D4E.E0D82150" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ------=_NextPart_000_0005_01C80D4E.E0D82150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How do you do? nfsv4-archive CAUTION! she might be tight when you reach your new size, stretching may = be required Saurikhane Dore http://altishrl.com/ ------=_NextPart_000_0005_01C80D4E.E0D82150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

How do you do? nfsv4-archive
CAUTION! she might be tight when you reach = your new=20 size, stretching may be required
Saurikhane Dore
http://altishrl.com/
------=_NextPart_000_0005_01C80D4E.E0D82150-- From PulidoMacDonald@eversonward.com Sat Oct 13 01:37:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgZgK-0004Cv-0c for nfsv4-archive@lists.ietf.org; Sat, 13 Oct 2007 01:37:00 -0400 Received: from static-81-17-187-91.dunaweb.hu ([81.17.187.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgZgE-000453-GE for nfsv4-archive@lists.ietf.org; Sat, 13 Oct 2007 01:36:54 -0400 Received: from brigipc ([176.134.22.92]:5140 "EHLO brigipc" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by static-81-17-187-91.dunaweb.hu with ESMTP id S22KNRJAYWUSSONC (ORCPT ); Sat, 13 Oct 2007 07:37:22 +0200 Message-ID: <000e01c80d5b$0da7b9a0$5bbb1151@brigipc> From: "Pulido MacDonald" To: Subject: omotamen Date: Sat, 13 Oct 2007 07:36:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C80D6B.D13089A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.3 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0008_01C80D6B.D13089A0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable hi mommy nfsv4-archive gigantic, heavyweight, king sized. Thats how my dick is now described Pulido MacDonald http://www.amentar.com/ ------=_NextPart_000_0008_01C80D6B.D13089A0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
hi mommy nfsv4-archive
gigantic, heavyweight, king sized. Thats how = my dick is=20 now described
Pulido MacDonald
http://www.amentar.com/
------=_NextPart_000_0008_01C80D6B.D13089A0-- From Bien-RAWE@guideboards.dumplings.biz Sat Oct 13 01:59:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iga1g-0005O4-3H for nfsv4-archive@lists.ietf.org; Sat, 13 Oct 2007 01:59:04 -0400 Received: from calypso-access-2.calypso.net ([82.117.96.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iga1X-0006fF-69 for nfsv4-archive@lists.ietf.org; Sat, 13 Oct 2007 01:59:04 -0400 Received: by 10.150.92.208 with SMTP id AWPjMyQMOglxY; Sat, 13 Oct 2007 07:59:04 +0200 (GMT) Received: by 192.168.44.225 with SMTP id TmfufKWPdwrcTt.9192755156183; Sat, 13 Oct 2007 07:59:02 +0200 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 13 Oct 2007 07:58:59 +0200 To: nfsv4-archive@lists.ietf.org From: "Bien RAWE" Subject: tyylikse Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed welcom nfsv4-archive CAUTION! she might be tight when you reach your new size, stretching may be required Bien RAWE http://www.amianrts.com/ From nfsv4-bounces@ietf.org Sat Oct 13 08:53:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IggSY-0004pH-4W; Sat, 13 Oct 2007 08:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IggSW-0004p5-Ny for nfsv4@ietf.org; Sat, 13 Oct 2007 08:51:12 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IggSQ-0002LE-Ca for nfsv4@ietf.org; Sat, 13 Oct 2007 08:51:12 -0400 X-IronPort-AV: E=Sophos;i="4.21,270,1188802800"; d="scan'208";a="113468214" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 13 Oct 2007 05:50:55 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9DCot7w006023 for ; Sat, 13 Oct 2007 05:50:55 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Oct 2007 05:50:55 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Oct 2007 05:50:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Persistent sessions, NFS4ERR_STALE_CLIENTID and related stuff Date: Sat, 13 Oct 2007 08:50:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Persistent sessions, NFS4ERR_STALE_CLIENTID and related stuff Thread-Index: AcgNE1HquDz3Tj97T+aNijTfSitqiAAglgLA From: "Noveck, Dave" To: "Noveck, Dave" , X-OriginalArrivalTime: 13 Oct 2007 12:50:55.0167 (UTC) FILETIME=[B1A51CF0:01C80D97] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I've been doing a little more research about this, and it appears that draft-14, at least in part, does embrace the second of the alternatives I offered. Section 2.10.5.5 talks about what I have been calling "moribund sessions" and calls them "dead".=20 So that leaves two issues: The treatment there is incomplete because it does not recognize=20 that a COMPOUND may be partially executed at the time of server=20 reboot, so that you can have a request that considered a replay at SEQUENCE but has new ops (including possibly nasty ones changing state). The treatment related issues in section 9.8 and 18.46.5 ignore the fact that the session will be dead. With the server handling dead sessions properly, many of he situations that it discusses should=20 not be possible. Discussion on this will probably continue, but for my version of the error xml for the eror review, I am going to: Add NFS4ERR_DEADSESSION to all ops that can be in a sesssion=20 context (not callbacks). Delete NFS4ERR_STALE_CLIENTID from everything except sequence. Delete NFS4ERR_STALE_STATEID from everything. BTW, NFS4ERR_LEASE_MOVED is also going away, a least in my version of the xml. =20 -----Original Message----- From: Noveck, Dave=20 Sent: Friday, October 12, 2007 5:03 PM To: nfsv4@ietf.org Subject: [nfsv4] Persistent sessions,NFS4ERR_STALE_CLIENTID and related stuff This email is about some issues that arose in reviewing the v4.1 mapping of ops to the set of acceptable errors, but since it turns out that possible solutions change the protocol in ways that are outside the scope of the error sets (not enormous though), I'm sending this to the working group as a whole. The issue started with the question of whether it was valid for operations within a session context, beyond SEQUENCE, to return the error NFS4ERR_STALE_CLIENTID. From what I've been able to determine, this is the general opinion among people doing the error review, but I had been worried that this was not right. To anticipate my conclusion a bit, I think there are a number of reasonable options here, one of which is to allow OPEN to return NFS4ERR_STALE_CLIENTID. So as the protocol stands in draft-14, when we have a server reboot and the session is persistent, we have session in a somewhat odd state. Although, the spec does not use this word, the session is in a kind of moribund state. You can do operations on it, but you can't do state-related operations. Any that involve operations that incorporate state in the args will return NFS4ERR_STALE_STATEID. This state of affairs is a consequence of the fact that on a reboot with a persistent session, the server retains information about the session but not about locking. (If the server managed to also retain information about lock state persistently, we would have a situation that looked, from the protocol point of view, not like a reboot, but merely as a temporary communication failure). Although the spec says that the clientid like the session is persistent, this only means that the clientid is recognized and you don't get NFS4ERR_STALE_CLIENTID on SEQUENCE; you can't access the state from the previous session instance. So this causes issues for requests like OPEN that manipulate state but which don't have stateid's in their arguments of which OPEN is the big issue. In draft-14, there is a very large case-by-case discussion of this in section 18.46.5 including restrictions on open-upgrades during reclaim. I believe that this complexity is unneeded, if we simply do the same thing with a stale clientid as we do with stale stateids, and that is reject the OPEN if the clientid is one associated with a moribund session, i.e. one that has a clientid which cannot be used to manipulate state. This approach would differ from the current spec which stresses that with a persistent session, the sessionid and clientid are still "valid" after the reboot. Where I think this goes astray is that the clientid may be valid for the purpose of accepting a SEQUENCE, but not valid for the purpose of using it to change the state corpus associated with that clientid. So I'm proposing that such clientids be considered moribund just as the session is. They really continue to exist mainly for the purpose of making sure we know what operations from the previous instance of the session were completed and how (the exactly-one-semantics function). So if the clientid is a moribund one, then SEQUENCE would not return NFS4ERR_STALE_CLIENTID, although OPEN would. Alternatively, we could create a new error for OPEN ot return in this situation if we find it too disconcerting that the same clientid would generate NFS4ERR_STALE_CLIENTID for one op but not another. Another alternative would be to draw the line between allowed and not-allowed operations on moribund sessions in a different place. The idea would be that for such sessions it would be valid only to re-issue requests/ops already executed, and any new requests/ops on such a session would be rejected with an error, let's say NFS4ERR_OLD_SESSION. Since you could have partially executed requests, any op that could be part of session could return that error. This would allow you to delete NFS4ERR_STALE_CLIENTID from OPEN and NFS4ERR_STALE_STATEID from all ops in which it appeared. This is because validity of the state corpus is tied to clientids which are in turn are tied to sessions. You simply could not get past the session layer with a stateid/ckientid pair from an earlier instance. If you sent the bit pattern from the stateid form an earlier clientid, you would get NFS4ERR_BAD_STATEID. I think either of these are valid approaches and both are superior to what we currently have in draft-14. Both would allow us to delete the current restriction on open-upgrade on reclaim and most of the big case-by-case discussion in section 18.46.5. Comments? =20 =20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From keagxqui@borzi.com Mon Oct 15 04:24:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLFs-0007Wl-1G for nfsv4-archive@lists.ietf.org; Mon, 15 Oct 2007 04:24:52 -0400 Received: from [88.235.96.235] (helo=[88.235.96.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhLFU-000783-Nt for nfsv4-archive@lists.ietf.org; Mon, 15 Oct 2007 04:24:47 -0400 Received: from [88.235.96.235] by mx.borzi.com; Mon, 15 Oct 2007 10:22:19 +0200 From: "Erna Tipton" To: Subject: Venezuela, U.S. diplomats hold 'cordial' talks Date: Mon, 15 Oct 2007 10:22:19 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000E_01C80F15.442CB690" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6Q7PXW6E8CFGNS41Q5ET1Y6CSR1== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Message-ID: <01c80f15$442cb690$eb60eb58@keagxqui> X-Spam-Score: 0.9 (/) X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C80F15.442CB690 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C80F15.442CB690" ------=_NextPart_001_000F_01C80F15.442CB690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit CNN and other news organizations did so until the child was found, and De Meo asked media to stop showing the picture. "You're seeing a continuation of the recent momentum," said Chris Johnson, CEO of Johnson Research Group. "The mother has cooperated with us," De Meo said. "We believe that the mother was not aware of anything that went on with this young girl. It was very sad for her to find this out." "According to investigators, it appeared as though Ms. Gotbaum had possibly tried to manipulate the handcuffs from behind her to the front, got tangled up in the process, and they ended up around her neck area," he said. Witnesses told police that Gotbaum was "yelling and screaming" and running through the terminal Friday. She was arrested for disorderly conduct. Authorities have identified Chester A. Stiles, 37, as the suspect in the tape. A resident of Pahrump, Nevada, he remains at-large, De Meo said. Pahrump is about 60 miles west of Las Vegas. Stiles was a distant friend of the girl's family, De Meo said. (CNN) -- Darren Tuck, the man who gave police a tape depicting the rape of a 3-year-old girl, turned himself in Sunday to Nye County, Nevada, authorities. Allen said he never witnessed Stiles physically assault anyone. Finding Gotbaum "unconscious and not breathing," Hill said, officers performed CPR. "But I have seen him verbally and mentally assault many people," Allen told CNN. "He's good with mind games. He's good at twisting people's realities and manipulating people." The tech-dominated Nasdaq also gained 1.5 percent for its highest close since February 2001 while the S&P 500 gained 1.3 percent. Someone close to Stiles told investigators Stiles is a "survivalist type" and always carries a weapon, Nye County District Attorney Bob Beckett said. Todd Allen, a Las Vegas resident, told CNN he once lived with the girl from the video and her mother. He said he recognizes his old apartment from scenes in the video. He said he knows the suspect because Allen's mother dated Stiles and the couple spent time together at Allen's apartment. Watch Allen describe Stiles and the girl » Allen said nobody realized the child had been abused. "She's what you'd expect a little girl in elementary school to be like," he said. "You would never know something like that happened. Ever." The Dow Jones industrial average added nearly 192 points to end at an all-time high of 14,087.55 points on Monday amid hopes that banks have put the worst of the recent 'credit crunch' behind them and expectations that the Federal Reserve will continue to cut interest rates. "Sometime during the time she went into custody, she went into medical distress," he said. While handcuffed, the New Yorker became "disruptive" and she was taken to a holding room, where she was left alone, Hill told CNN affiliate KTVK. Betsy Gotbaum called Carol Ann Gotbaum "a wonderful, wonderful person" and a great mother. She said the family was dealing with the situation "the best way we can." "It becomes a psychological phenomenon. Investors know that there are inherent risks in the market, but at the same time, they're rationalizing any bad news." Investigators said officers went to check on her five to 10 minutes later. Police policy requires that be done every 15 minutes. ------=_NextPart_001_000F_01C80F15.442CB690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

CNN and other news organizations did so until the child was found, an= d De Meo asked media to stop showing the picture.


"You're seeing a continuation of the recent momentum," said Chris Joh= nson, CEO of Johnson Research Group.


"The mother has cooperated with us," De Meo said. "We believe that th= e mother was not aware of anything that went on with this young girl. It = was very sad for her to find this out."


"According to investigators, it appeared as though Ms. Gotbaum had po= ssibly tried to manipulate the handcuffs from behind her to the front, go= t tangled up in the process, and they ended up around her neck area," he = said.


Witnesses told police that Gotbaum was "yelling and screaming" and ru= nning through the terminal Friday. She was arrested for disorderly conduc= t.


Authorities have identified Chester A. Stiles, 37, as the suspect in = the tape. A resident of Pahrump, Nevada, he remains at-large, De Meo sai= d. Pahrump is about 60 miles west of Las Vegas.


Stiles was a distant friend of the girl's family, De Meo said.

(CNN) -- Darren Tuck, the man who gave police a tape depicting th= e rape of a 3-year-old girl, turned himself in Sunday to Nye County, Neva= da, authorities.


Allen said he never witnessed Stiles physically assault anyone.

Finding Gotbaum "unconscious and not breathing," Hill said, officers = performed CPR.


"But I have seen him verbally and mentally assault many people," Alle= n told CNN. "He's good with mind games. He's good at twisting people's re= alities and manipulating people."


The tech-dominated Nasdaq also gained 1.5 percent for its highest clo= se since February 2001 while the S&P 500 gained 1.3 percent.


Someone close to Stiles told investigators Stiles is a "survivalist t= ype" and always carries a weapon, Nye County District Attorney Bob Becket= t said.


Todd Allen, a Las Vegas resident, told CNN he once lived with the g= irl from the video and her mother. He said he recognizes his old apartmen= t from scenes in the video. He said he knows the suspect because Allen's = mother dated Stiles and the couple spent time together at Allen's apartme= nt. Watch Allen describe Stiles and the girl =BB


Allen said nobody realized the child had been abused.


"She's what you'd expect a little girl in elementary school to be lik= e," he said. "You would never know something like that happened. Ever."

The Dow Jones industrial average added nearly 192 points to end at an= all-time high of 14,087.55 points on Monday amid hopes that banks have p= ut the worst of the recent 'credit crunch' behind them and expectations t= hat the Federal Reserve will continue to cut interest rates.


"Sometime during the time she went into custody, she went into medica= l distress," he said.


While handcuffed, the New Yorker became "disruptive" and she was take= n to a holding room, where she was left alone, Hill told CNN affiliate KT= VK.


Betsy Gotbaum called Carol Ann Gotbaum "a wonderful, wonderful person= " and a great mother. She said the family was dealing with the situation = "the best way we can."


"It becomes a psychological phenomenon. Investors know that there are= inherent risks in the market, but at the same time, they're rationalizin= g any bad news."


Investigators said officers went to check on her five to 10 minutes l= ater. Police policy requires that be done every 15 minutes.


------=_NextPart_001_000F_01C80F15.442CB690-- ------=_NextPart_000_000E_01C80F15.442CB690 Content-Type: image/gif; name="footer" Content-Disposition: attachment; filename="footer" Content-Transfer-Encoding: base64 Content-ID: <006901c80f15$442cb690$eb60eb58@PWVAVUU> R0lGODlhigHWAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/ /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/ MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/ mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/ /5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAACKAdYA AAj/AP8JHEiwoEGB+A4WrLatocOH1SIK9KewYL9/FAdqq8ixo8KMCqd1vOexJEKTKFOqVEgSJT6Q Ai/+u9ev5cqbOHN2FKmwFU580zLyLLmxIklq+QY29Jhw5sB7DiUazCZw6L+iOhXSMujPKkGbB71y rMHRH7WDYLOq9SjNYLWD+NJWXUt34Fu12qZhrUgRpNiVXQn+rbi3IMyUzQY2deq0YbVYDbNtm6ix 7lSF2g7LZJkSjMKXFRf/04PT32a6VD3eJSjasuuBZ3NOCopTLmCMFlEOprtMMeOC26ZBXjr3ZrNj Ov1taTq08G61oheTqoiqz+udqQu2vs79qe2VaJ4L/4yt0FbKafde+lu/veIw82b9Zc7+elnTbf0c /ns4bfJ+hpMd1t1BhtB22oBc+caReP8gMwp3/vj0Dz4JLSYggmrdc6FO2azHEXkGmddWSf4ss4yG FOJDzYorNtPeP8P8s4hBDOY0lFcPPbTfNrFAZtkfKX33oWUbonVTjQWh55VIEk4I1D8gYlhQlFJW RM000gRGXj7UvEiQPaFRyGKXY6q4opklVZMUX0nmlJBI20iW45wP9QhLLGupEuRNVFbpJW40DkSf Qv0g+cpEXfkDWklC0jXNk9yNySKU1LTlYUHmlaRifCtupE2XKoqZIqgs/qlpQSNaCZJ+Sj2UTX8O yf/p2KzbPBYLLNUUKdhaplapK0GJedQJQVgNqtahlKmEpEmpTrOsoApxidQ/0ko6UXQHZapYiqGa OaZZoI4q5pnfUmhYsh0JeKB2CtHJX34NaQNRRPRGBAsjhYVklG51ndWrQdOhlJZcyAx0UUbG1kUR Nh8dNIldBlHzK6o5ZfNpmZIilY+KAylq7YSGcTshi9mUWm64ZoqpaD9jNuNyM2NCCRLHGLqbI4D8 zVsvvdQwEguAGzb6bEXOrDkQGmI0/M/QeWT1F3rFJXyTgBkx3KZCDwu0GkGBuYbshK5kTOakAq3p T5Z6sQZuQmNL6g/MK06TTbcUPjqqpDCf7TI1Lk//U+qiXDvp2jb40AkrrXPWO83O9PZ4qz+x+Iwn R/9+dtBjYmSu+eZccLH552LcIwbkDHVElTN9Oh34P/Tlq9jQU4ods75ewaJtTmMSAiIt3PbOUZYs ppKKH36IyqLf4yrK7T2vkjnu8S/vLbE0cJ8ZapdTsmZZQ4dzfzPj1VCjjeKNO35nj9T0KDlxgSqU OkGqWLWNGDfgYH/9+Oevf/6u3DANDvi4ARf8ozRGnacjkhCI6xpFENk5UGwKORTsBHKPwchONEab UoUmpKj4TOGDIGRG2+Jmt/Rwy298g5n0rjSNvmUMKL3jlsSuYpKMENAkSyFczqICvnrJx3G3AuL5 /8wXi0YYsRFbK8vqNoSnG3HhflDc3w2kOA38VdEfN4BFulDiDwai5HYoeaDbxAi9YEFrabpCQ9YC RxOviJEga8KH8FIhirFB6YN9AOEU8ijC64lNeR5LRYuq5y3rxfCQMpzYQMyIw4f4wzHNoFc2wAdE OwFRG9oYohCLGDlGePKISDSJs9r0p7zMr344yF8qp8jKKa5yiqhgJQ6qiAMtLkhZXswKiy5Gxl7G LXrRC1SAboMuSj0QSpTChx+mcIcp+MF51FimHvc4BWYEpZCdOMbYUGgmFBpSeYg8pPVINTG/5AWT HomKP+o1CnxUY5Llq6Q85zlPUNrTiDfcCbE6Uv+UU6byla0MaCurGND/2ZIjUkOQA1MBN3D50pst bEZE+xZRZ/WNkdD6VL8WepaNkYmZziQTlFDhzGky03ndMtk9/gal66XskBwMp6g2VRK5NRIWtapV +NZZr2zQ86f0vOc9PYmGTyZRJYqk3z//KdCmSqOpWaxSRwb5shRm7FG+ZKFFK+qsrkZ0E82Yo/Bc ViWxoY4aDH0Li5bZTEEGL49ZmEJcqSkfj42QTCsdl7hQJtPl2U151vtVoVLiGIZEhCIRAaJP5Skc oDpOqEP9pBg+yYh8pkSRXWEqVJvqrKYeVKpoTcVZWeQMQrzMGWetHovMMo2xXgmYFKXoNPoRvTn/ qqIQqeCEWF/mEXOs5YFmMWYqQOoHFP6jGXCdxgfnmgqzbIRcMcyrDP1lLpmGCz2GJBVNK5JQgiSO ce4E4ivm2dig2vOTQqWsIRiRuU9aNowlMQQXurpZqDbDs1IdiFgZKqlFiA1udCSegFEhUWC20KIu E2trU7Fghr6tqnwbZUd8W5FUmGRMzpDGmFKxkYgM74N3wKqKpDkFVMw1pC8RX3wyEy5Jpfgld3Po TE/4PJOB6jATI+B369UjyDm2EbHQBhAh2wh/UPbIR/SkJw1RoMniUyDd1Yl861tfggb0s9z5bDT3 y19JCc8PDF7RMrNAZmaiAsES7WqBGQyUB0ev/6IJ6QoKu6rLCx+PtHwbE4ndqqLh5nEK0yjzM8El D70aMpxrQxk0tds7jInUIFjpR3d1xuNY6KlHiZCnM3rUiGwoObKNkBiSlUxqIzOZEc3I3HoZcZd8 yWEthtgClQNKBVZauZUHxe11wMjlOa5IFWLOApidVR1h98EPfThzCtN8YDTL1llxI6FW/dY3ZZ0z bXauVJ6Dt6JtEIK4k0rFiUsc1z6MTa8yTJlZXrralF7QxY0GFUfY1xBD+CdHq6g0EXvkCk5Hrkeq MGI2zssII3oSH592ssELvmRTi8EQm/skR149kK+lJNazbuUf/LdZLEup18JDnTNU4YeNMHgarf84 RR9W3gdhI/jAzI6f36BNc2hLbNpdbdFgOrTRK2VsePuBBbI/6FazSLPlU5BGHpvbNuMx+tAqcpHT C9lLl66okfsxxI4KW41DoC+o/4bskQueZFIbohHtNeI/1sv2tUP8c0pGicX/cdTtYDzjrUxFx9Ok qIO8r8IgP+sf9igKaq+ceIdXoVctysKT+1zNzZ754hcBi9YSIiSPmmDExsRLtI4Ck8vM4zPNNNzl ftAVzkwxX0PFntWn1EUY4dba3O1ik4WqkTlsCE/liY9KAtlnoEQvqElNfLRP9l6NWPvDM/ePzVEj 7ckvSJNSAiQq3X2zMWjqfW3Nys96HCOKRAn/yEXrjFS03A/MNrYfhC3IiVIb51tdvFfhb3OYdQSG usSwc9Hqj3yIG8Sp8AoS82FIR03mtm5iExcSQyFzM0J7RS6LRiovFG/kwQmvAxS5Nyu5Yi/zJDGP RXyktnCNAIKfNoJ64TftdS/xgTQP93xiMANioA2ZU1RHNX0ooXVLUxBThkV4B1WvMEVYpicdYyp/ dzXjJ1rrN2wVJGDI1gft50KLx2zyB3lyM4VeJVGUsxYOxXl+w3Shh2KoEE3LVW5thYCHlHMwhEhX Rw13IArG4zEx1E5q+GgYMSwCcW90cli2Qk8iUUQMN3bFN4Kf9kl3smSGkAZiUFQbIQZFBjqZ/3MF LjiCR5UVhyFfPNhU/1Bl2mBrrvB9SDUSrKNfwhNawjMKaHV+j9IMSWhshRdhU0h/OSdRFZQXryJ/ y1aEbnESXPRH1KAK/jAKJ5YK5lJ6pid6Ekh1FZRisTcypTINySZHKAZjjSYmwNZXXuIuPCNPjHAK p8Bp01BkwfeHI2hkgzhZBRdkr0B2jMBkEDcGkdNeseCCjph21ZBLKSEa8nVrAnWJGecKfqcSmcFd VmFbXNaEKNSEiDds1EOFczZ/r6V4afYqtTh/jDcQSII9KZExqOM35ecHZxBXozdiJhZXcxViVjcq zpIid2SK6gEyzVBiigIzNWZ71mhHBjEZOP/JQ4n1D0O2aoJogj9Jgp7kD40AC4XAXpN1K0tmMQXH joxoRJrjM/4wj+1VWfDwGn/gBwJxfVAVA5kIVdRwZX/hOjexETAxfsSzCOiHVkl4eE+oZioEPWg2 PCeXc1UIl81mRpdiGQsoO5/SkUOwdKEyDag3BYMHQsI4U+GyUsNDPGjFBMUDSGehXIkJKqIAYisi SHRjXXSIETLhEIrCdXeiF+NVRGEwVNIwDWNnCMWgmoMoWU4Gm9rwCmjAZJnTCK45ggbnOY4IZBhS DbJWXzEQA/zYSs2wid03INmxGCA3CsSDW3yzcncQCoenczmXZ6qYCrXIlgwlCjDDUC/jLBP/SYUY FX4ekXmw4UDl9wpYYm6TOWZTQAUgZG6KKSb/QIzMlIrYsyK6c1xTIApvMwXC40zNUEebIi6j0lJ7 RSOguXU6dT5i94fOsmqkNnDpEBSSQ47GZ3DmOIJvpzkC9woeCpWOuF6T6BrAOWvZ95UBxaJAmF8C AXIJ+Z3nh2xrSVEl05jC0wclEzx3wGDdSTyudSWfIn/2tytbtBLANQ3SFJL4SU0ldowqKQ0E+jd2 Y2FydQcrwgTN9ZJ0NAX+0iURFVpi2kJoZaAiUxAk8V2+F6GNIA1/iGTTkI5KiS+CKAZ+AGT2JDPU 8HaMAEOvoGpUOYLvhaLBKZxTVJxdcWUw/3qfvUY8WRCGqpiEyFZHkTcNonBswyZROpoKP9qYYAae CcZg2ZBgqmWeUMYn6vlhAkoRTApC5bZHN8doKnIHYegkFPKSMPOfX1pHP4oPzfCpH4R+2aBhYfVm ooAKyjqKz0MSzKAU+QEg8fRYZSeInuSaSkahjIA0emp8RQVxhqAFT1lEnuAJnuRpmUMhxjcGVBmV Jzo4XMBKYdlU2bePNzCvyXkdErMujlqQx0ajAnZsDMZsaPWjqwVmTJipXyYKdzBsDSY8ohCx3jk7 KHEKNphtZkWA/lJ6JLlHQKEh40Qh/jBcbHYmIyug1/OSxfWfx6Vbb7NM0pCYwNp+WxVWef+gmd5i FfJyOPFEaosglELpk0hpreyqagV3mwyXOXkxgjPYCEX7OUXLgk5WqK/xRPLqolNUrzcwnDeAnALl iQNxeTgxGDJ6bFfChAL2Wl7lmCsysn0QVh+msMMTVn5ACsjAN8kKsagQsaq1Ev6opA/0YbcqhnIF aNY0BRKVUtyyTF0iDS/mpVDCVs50D/8JrFpgYR/rTBTxMgyFYCsyCpppNPKDHzqVWNRKWUZmrR5a cGkglA9nRNqqZNpgMUf0cDL4lEg5j80HOqFUJVY7RQHkolxLZf0TVRwxdyoBOKLor2EIqgJGs2ba DHhgqY8ijAUasc9Ll8f5ow87Vs1AYBT/ey4KEWVWslDL5CIjewd/AIxyBZI3lh4txriKgjwqwgS7 upYNy6n+KVqCtEyJ2YoM1WjMKroWCSv69prXCoieJAbZ8AraALtFxa5np2SZk5vbirSGoA1PC3G8 MI9TCToFR7Wu4SyrFEACNbybVbwxALZ1kRD5cBcyCmbUcA9pdg//elyx2IZaNTzRVLAMK7GF5weS Gp7QtkJkczUH0RYZBGlKERuBiwejJ4ZwZXrNVUgyhAdTUCHcoqt+EGIT0rDUwAxg6qWiwARE9xLQ NocD8cI51RLc4yx76IfWWnDY2gja6sAK54eMMAY+wIhKxsdi8I1MC4+MMA2OKAzZADr+/xC1Resj UsUFDWzCJ6y1TVW8W6tFqEoiRVEonCwSMcw3NgqporA0ktdCxPOdAeaG/0A8Eis8Iws3EDVzsnMQ upIqbBI7spMKUCwmf1a4WVrFgdUt/ssx6+alzQQz0lSgzIB+NxpYKBMfspciSbSmpQtEQItwrzKb 2vBpEGetkbNeSLuOxhfIsDuDeTGPifw5LsheSOMDPiPCJhFWJmG1rvCD9ErJAWXPl6xAjvIrMtqF aNsHZiGFXdiwzztoogCeLVKqROyQDrQeMPEcf3EYhRG4KHufehSrIQl1FFJ6oDINwuoyIJSsdcQi G6PFYko3EJgi+dDS1JIURgMZPUtZc/+MmwvMiHq8oVD5h+TMofhyrXacOdWwClQZqKCzwX3syDlB lh1TEIBwA6fQD/rcSsOJz9zHSiusMExNEDKKCveQqcSzzPfpitepoxLVFSwyqvtF0D4nO4fxIFMj ELeQQMeVngv1q4TbvtQUxa5ndGY8dHcArCiLVvsJ0X5UJhSyCJupPC0N043dD2tSzZzmSVwwdtDX tKt7m4NscIaQyD5zL/fAoQ8XBkY9j6UNteyFlD4jJTDx1Dcw1Vhd1Vtb1bQd2ywcOTUkfo+KCspU CMSzDP6AfkY6Z2kNtyD3bG6zlxwB1xmpEHAtRsMTFHnty636UjGUmgQos9R1Em2jQtH/02K6g24L 8RYR4cZxPMeAoCirRsjGV8ji3NOqfacy6DOMcA8ULAZpAK7t2q7jDBmVkxLrAhLzOg31StsGfuAI zsIGQyIm0dUugrBJ2Dfj2UJHuDdFLFF3lsmA8okfEriD5qkmRXSzt3plOjebOS6qZVXwNo0svRBa ExN0t4erWdnijDQMt6FwenZiQA1BSd/rWNrToOMZnLv7/TlogDS1uaHwDF9P0RHVYAjDSeAIPuVT /nf30BIMstVcow0F+WVMOqPNUKpR6L3hCcsX1WXYUyNUIiDiIRanAd3PtAhPOp/UUAvWkxfgJIE3 V0jN4GbeZGMtpmh849J3yD37QR79/xHHZNfeC5d26whxrWvI7CXI9C2I72jImnPk813kMziV7GVk tTm0S35ZKtGL06AKW7AFVF7gMNDqrj6c79pFBMGvBaHlMfqoX6apNiqeLVQNkZdmwD6qcFs9yQsX CQIYqQHn1GALJEbd5vYpMeQPHVI3r6VVcbOFvaM8jGAL6IbYwcLGDlETweUf541eILpkaMdwRaXZ C8zj1sqC6b5wnrTNiTiDVCm1n1LI63W7YsA+BnEGKPGuTV1A1EAFr659NPzqCv4PWYCk7dPgXBYU X8aE/xrmzqIKBMu54Om9XSYg8OwlPOEPzgAySpqD1GAM5tslzV5mmotuKcIeKmJzjP9GvzF0V3dz Ji7d2C2NkzYVHLGh6KoblSMI76ktBu78zT1tx4coqLq5jo9Owete70Ye6oyARmfXCDIYC0deEXR9 EFuBVLdQEqquopk36v/wBQRxlWGh22K1Hgum6zYK7PGnQqIKpOF5dSthKnH2D8+g4bGjTZLShd0y xb6MgH8TLoDVVyiFN95kPBSi843tXcGxNNVgYXSnPjQtWYUgBnosWYZQtEmLu1cPuyR4agtMwRds jolYVHFXyMZHDf6xFzVysSYR9h0hBvaT+7q/+zdwF7TfEcYwGEjS9qFVXIEWyhXPVXmp1sOOkZ91 IViOTOdpjx7hQCtVeDFver5Mv4f/P10vRiGnEA1b+ELjFLII0RQ6rzEujSX3aR2Xj/mkZo5hIAbM 8JPkyAiI+JSDLLRAa3amr9oA8Q8NI4IEBxL0x2iaGDGNpv2DGPHfPYkS/VXEmFHjxojVxOAAGVKk NhxccIjZBrEVR5YtOaaCCdMfTD9+Uk2rWbOPzWbNpv2c5jNoT5jTpPX7Se1ixqUWJVLc6A/fvYcu rVLDmjXrNGqi/OCjdufelCxky+LEig8sNbVt3arVGlduVn9cnVXj2pZtxHxa8/2rlq/av2mDU03x c7EarIKNGzEyxAjNNGaNLDNqlJAgw4KNDjbGDFr0aILUIBN8HLrgQkbb6lasmjG2/1XaErfBMslF d0mROPyBXJiy9vCWMWPWzekHp5+dfVBR6xnUn0+hzaRl4zotm1J/TSt6hxoR3+yIzuRNg9qdWsRm xCPOTUst1ddpU6ag6mPW/jRt8dm+TUstn+LCxx/4/KPmHmry+esfBvvSypkF/8qnKmrs6+Offhaz rMPUGomMmkYY+pARzdBgKLLLVOsMs9RanEa0x/x5UUZGGBLuNYjI+849wCLqJ6Jp6iJymzT++Kg3 LqbgzaR/fPBhmlhqC88lfIqLSZt/itopueb80Oof6n5qhhOguKKmn+68+ycbiLp7E6MqOdJSoitp uxOiag6UD0x8igllkCzqIwsxav+02U6rt9zyb0CwmmHrQKoexAoiCLFyRkIGq6Eon1T8sc8PPWFZ ETVGKkNDmxt9aCiWWDDzR8USSXOxxlqladGxD2sMA6WI5vxnmVMwctNH2MyxLZY0xhjDkDEY4gJK kHxgMlofqPlooViEa+mePFtqj6WY5ItJp+R06iMVuYDyaRNIK4VovYrq/EdeHglryR96fYyNT/nu +CmLULIoi+Cy+mhGr1cCXHStA9Gkhpn/sMpHGoq2GSxjAvtikBpp5DMwP1H/wdjVWGrENSHLGEqj Rs1spNWxmGdmJI+GuJ3IpWIr2rk2ZLdRNo1lmSWaoWl9wAFKVkFKxCR8uBBjypb/7tXo241g0sa4 +c41Nwub/M0qIjZ3lGi9sa3aV6OznYqXz8PU9aNQg+3LIhW9slIrEbDgcniut5hp68F77snHte4Y hAgfBrFLZZRU6q0Pnynw2QkioIU5ecXUTDPkMc5Qw4cRagqhVfNZUbO1Rs0bQ+OPRjBmO6K0IepZ duK22WYaoXfnfXdWp3Elyd4SAQ4kMWAZzNiKrNZI63K5bq4Pr9UFG6LZhZR9Tuxqh+0fOCVy5nGx XVrK31TuUC7uggm2z9C+02pl77vxbthhtRqsBi98MK6GSGocD59PEqWcKfgjMVPIkOWqIQzGeIgR qkJdBAmCj1KxyEUEscUrQFNB/1vBjBFpuFniYtcm2nBvI7gL2hh017vePQtpr5iGSXqjtBgab1si 5MjacCgu520NesyRnh9U4S+X7ItqanuIgViiw424zT6pKBg+ykKWuN0hUlwZ4n/4phQt6oVRbpFK YPRUDdcM6UfUwAPF+tImabSvD/4g2MhIVjKT7Upz0zBd6C5Yq11Z8DEdiiAgO/MiQ2TjdTvUSLFW MTWXKItZLezc0ITmQqOB5BWu0I0Mk6Y0TjIieT/ZyBFpY5x0PI9rzAHiTqgHH5aoAjbwakmQrMcS 5rnEbXho337ax74pfIotHyOFWur1Pj7d70GIc9Ax11Oh/A0GD/Xqy3zoVpMLIf8mWdUwGeo8dBk8 mooRelTdNgV5uj128I8LaUSdajkviCySJderiJFYuLsx0JNoUPIHQ8TASaSJhFX/1AaUopYSpGQE WOPDiDb8UTutldKH5+pD9A62yrjESSPyKtZFuMNEizCRo008UCpwmUvJZaN9Y/HDK+r1D7AYaGKM ItB/jkm4Y9aUY9JoEITqFbdQ1WQK/6BiRbCJzTpqszEx2iYFJViicdpIdRe8jIhS4iY21RKeGBEl RObJQmbpUwxj0AbvnuVVsnrVH5z0Fb4qclDZ6AgjPdxal1AZ0SBGtCw2oajZPkoYelEDPRKhmhKz 6p5bkrR9lCEUYvqzxmHmAy7/fjNmTRVnU2USZk/USJ40Q6XZQskxIq4iKixMVkcP4bFESh0kORcR mjCAIZyrK0hCkue9HmXEhO7ZRj3nSbSxflVoddmqP7hKNG3o8xWsgoVG2Doc52nnFaj0UkS1YTD2 eQ2v8lKKVfCBCj8gZS8IxQh3CNOzwao1I4U9bPuYkQVQTVFdLJ0sfOsXWZtOg7IPGkzFLgKhw7TP JrnMzxQIkREyAi0WUhrtaB9j2kJ4SIOqee0fHagQb6KGFJ6TxmwRWV5jUQMWvrUnWdMQVqH5datC A8tW/5EGP2ghDa54xfHM+A9p/CQb17moVYyTjVfQBKLNIVg2qMu+LqnLpd+T/4hKsSe27/4KI0qU DW1+grO2uTQunJ1CYssCVGlMVE+Cye99xfwg+wrGpvkjTD7cxNl04cc+rsglKjRiYGxSI8GXacTJ 8Eg6gphWnE21IAXT2U0WjSJqVUrbOpWXEX3aU7e7I7Fw8XHi3V2JhWEVhlexM7ZnaNgqbILrH6Bb kyGXOgsRrYm6+iNejNgCvPEiz5ygjFVaRhkiFFkPfFJh0lzusk2vyHKonNGRwIxZzPJwLJiLfUzI 1YvXcE4XT4O9XvvcQyoaIWP+7JxgBTvEMq/YJiP+oSU/4tkyesQMf1bEEFhsI0HglYqiFw3YakRr hSre3b0pfell7XOfhwLOvP9rCdf5WNcPBgMFMYacy5yoGitIZopsuDgTZ8RGX1i9yGCt9pDwWPtA 2ZB2r7NwISzYwyibpQbu6tVMlis7fw8ihWDuUhiWL1sw9dIsnG3CU+DdJ84teVUsts1tV+X5J3/u EG0rXCtBEwSCkDFE1J68PHmrjUoQgQUOtPFofu+b0mIYEldC4olO3IDDFXGleJrYw1TalboAbjhM sIsVhQ4HTbGTl9juJMsl1rZs8FloyHMJR/sUA4FToMITM1bzlrucQYBgfGAa7yDOwpkmuuw1AsUH kRrXOJ6vyjPokR4jCOtKwqMR9KD9AW6GSM0718t7Ca0yG1gsRAxbJbHXW8j/kJ/0MyQ3GOKcwvVq ibhyGlXfktZ0Mrdpxh2kD7c79Jc3fbJ9mvgQGUVIf5L5n3Kf4dklGVbwomGXs1xP2rHv3EPuip2n t6d+cNzmXULUZIRetN32M2xfW4zLeFwzI2IE5FG7eSOWiggDNCCfRtM9SlOhfIIWTSqJIao+9mAn jSAPUTKOAKOidPia2Iu4etGKvbIIWPKe9Vgu9zio7NM1wfO+XOKlukk5YqO5aug08/sHYcCLbHCT BsE5wcMrn0KMuJM7ErSKbUCGGzEEEXkqQiunP4sR/quwETkecSNAlqgKZKiNafgwJJknatA9FbI9 KMEHHLiBMtyCdhuhLOye/5aghuSAl3T4NPXQCoUSwSp7D/OqwosKKRZsQRcsoH/oA0J4BXiKPBx8 ub8gFxbEq62ZhnHJCk+LMm85IVXRJ9iSGXEykYcIHVthN0jMQ9uCiHYYjljYAmdhoRVjQLDbJ5EY wxswBE+krU+sQld7sjWJi7pzjzXBQ1n8uwTRCq7Asj4UxiBcpY3gO20bBZZqHypINa1xhuEbDkjJ qqa4DbKimT5ji9EQA1QYKF70RqxjFa4Trt0iK6jRJHwwBAFcsjT8xl3kCCp8vqzAxSyEk7OjjWVY hvDyq2lwhizCimAcRu6jDF1qRrkwkPCZj5EylJlwRHixR+rru3hijH2KEv+v+gd9MoTIwIey8iop 8RF3ascTMoRw3J1xFCt98r3eeMWMuKqNQD6dqcOoKJ+HU5ACYZOwGw+LAAsn85Hbuqh7UAV/UAWK AsiAFEikyLzk+AcqwIOmTI4/GEI2WQqfrMKmqKXbwBaKxAd+6gGy2kjOkBofIYV8YQnGmDqWqIaR BLGTZAhp6Y0IhEV3dInjWzQ3OUHrA8GtAAs69A6IMxB6eUjAiheWtKiJoIYhCp+HO77EMkrvY8zM Szx/4K5Uk4b3kghIJA8PrEqJkIcc0pNYwAfQu5G2ZAh8EC0q+8aLiEm5BCykUMtH6yp92g2QMEM0 fCcfecmNoMqNOAMa+w7/W5QLvtTFEVzNRLI6O3kTrEDMvOLDw3pMP+xDuaKxvPNJT0O0kJw92qGt 68lNgVspfrHA2EjLryortyxDatgCCUQb7DRO9wgDHlkTKwO8ipC+qwglgzpLyMGUVJAQapAQwbuD /XhOYTyXqJQGwbw69qwNLckqeWtJBY0T7zgij/gnpNGkMryBLfiR2tjNb+xQjuAe6JNPuvgOImRH jshJjPiWscEKiIkLFhSLXgMq7kuOIYw9vtPO4bhL4tjRiIgHjtBE2si7wPTGqqiSCYXA33NF24TQ Ji1M38Q6JlsKHXKplmAeHUpR5BzB8EoFf/TPNjRKUJkC9FlEjsAxBFVQ/6oUQWbITxzVrm8EJeLg kROkBkPgAgzNUPV8UquQBNqgRSdVrohIrveguxKtT7I8UcDKE+YpEGw7zFUiBMzzPj8YMC3RTGI5 UEBVQ5f4Ay040bPbq+LckayihheQP1vDNtzgAuRBzYvTzYyIBD+FiEJ4AVNt0qV4iKpIBS14AU/t KLobzk+kVVtlTeyBuPcYwoObAl7rqVRYGPq0QuxgifWohj+o1UvFzh5NhReABX05mw+NyD3lRRjw 1TxcTXDlCFiAgXV9gT+wElHNGerDB16t1XJtR21Iu3pZVxhoV7eKCjYMn7ipiUb0wH7IhoJqCXTF h1q9Vk3t0drTkoUdVP+J6ARhGI61OdaqUR4t8FWOTdTbPE5UJawXKIRcbFSOUAVu5ckB/IdCgEaP XbT+wIhXUIR/cNd6IVaWEtf81Ig1giXueVC0U1m0NE2JgNkmDZJPqVeMSFnDgAFPI1LPJB+2goVC oNdT/QctKNl/gIGtTVGrrQhpyFSe/UDboS3JpFctwFqNOFp3dFMPq4hdrdethYhUeNqVrb5SVYXO hIiuHY5qZdhCqIZsQE2eASUiwVvaCJc/9RG59QetBay7ZYk/uBN4yEe/VR43LY4XwKxtndiI+AN3 pZqozQhAIB+lYFOMqAaOfZy2/QfR4dy1AlKf/Ki10QaOTa7Vpdt0hQH/+eMKLpCIsT0vjk07u91d 2c2Iba2G7sQIdb1ZWi0vdT1cpfgrH2kPxl1DiAhA+iTeizDespET8oAB5pWyUYpFcg0vyQVa+xQS aATdeO2WjNCCtKPVQeUEiGiEPzheK8SIfHiGj2WJQpDcll1bjLDW2FPXVAhLzX2PXq2I+d0ItnLd v8VcwICBvfoDrgAse/3EM90IWHBgo83XnQ27f0hZ8mUJqsjSaW0KWs3XpYBgiGDg8o0Iz43Sp9gr 8oDKiEDfiLhfVeBgvLTA1Q1ilujhuv3cKFvX8aFVqCWwIwZdzcRWPSFZ5aHV2NOCD13ijqhi2gha zmuJaoBiiPgDD+Qo/1pFYQu8B+CdwACOCF4djJPV31ntVRwVYH49VWpIW1gz1W3VguQpBAHOWcLg KBx9geRJ2eOlhruFBV4d4Zbl10GeiX0Vn129YEfGOnqFgSYK4VnNO7mFgREu1XLVAn9gWBgYUvmN 3Yq42YXl4DvO2ZRNu0Z+gRG21k72DmtN0WotPl4N5bIJYRB+gUguYo0IWuHdCF7VzOcN4aWA5c07 WlrOVyCu1UfeiENA040AW4gY5u9sWXdd3Xqtimo1jFWu261F31QohAy2Wnkh539gBnNu4/AEjKGl Vflb3fXY1obVkz8oZ4yyWX3m3NUFYS2YBrotBPEh1zjFiHX1xE7V1/+nLVXOjeRaxtlijtt2tUBe nYZyfedtzbsm3pIX0AZz1gJ3BemMKISD1giIFmOJrtWKtugrbk9auz4d0+h1DGdc9ueRducu3udV Vtf8meBam2fAAuHk6WQT9lVqKGNbLQxS3uSIUIWtderHKVmO7gipJkxxZYdjwBfIbdmhhQgtGNQy 1oKpBgyu1pCsfeNNpp4XaMSIKIRZJla6rAha/eO8Ltd7fmN/0LAhsmZVxlZYUJAXaNTVfWuj1QIt 0ZK05uIClgh+3V+rnWu/fpNDZuxXNWaS2Vh5JqF6eWrxUeyyVmtZJuNGVmsBtjuWFSWG7uRdzWtU Luufplsxnoif+AP/HVnXvNMCd67gkG0Jmi7rJD5is6ZihKbbI04FVyjXRqZrzeYIa7XXUt08AV5u hs5a6eaIUY6Kg47dxx3Uaujiei5ZeTniRcbojljXGcPZ6y5vt27g/ZUIn3yIwrWlpV7HlM7aayNv hOZuri3XbR1s2ZiNOykvqOhh2X5gX93VYkFtMr5Z76GXe2CGCWdwE7ZojUiDN/jiul3l377DlK3k co3wUsWunDVo34bm9a6LfuDVvqZtOhYf7DjeMW4e/ZYIBnVwNEBADZ9mW72ICH+TjuaIH53ooMwG fyDusRafUs3oAp8ltUGDSWhcHc9RmGXw7qhl8YFsqh5kZU5YOclR/zu51I721Azn4q096WKx1uTR W+tBX/Qg8Dee8DcPV2gV2uQScb6A5OQ5adCVboiGiJQdUi2ACkNPbjU2WmLlVYkQYGqAoTqfb4wQ BVFg5fhWXZJ9iEAnY+6O9DcR4MGIjSEphDtZhIowhkLv5C+nY0SWZ1cnjjQW9JI1XQLrYk+3Wbk2 YTGe8LHWsEVWawskwE4PZU+VJTAoWdQm7zop1dNeZRJ/6+T573jp5jwE4V1dW5itdpxV6+NWa7/K E9Y2bckW2pvd4rKWag1L6dJOnGsra1OVhpXIiJRVjC5+9s2uhpJ9XDzs9/BIdcLu22H32Iu4hwEW 8Lo1d5eghdpIa//xCQSJwGYgz4Zuz3dWd6VCWI8JlnbszOpOrpImHsoXUCk9hgGu+G083+68S28H XoQaIFc9nuKKwHROHuQ1z1rvVu3fRoVtvdmULddp2PCVz1plToVfL5sGKVV0nvGh5mEOfnO7FZ8V LneOgN6R99Sdl/n/Xt1U+O+OTumDHt+WgOOBx66nvRNmqO52JeK4tIpEQNRxU1uNwOYmzgY//gfV NpDfbmKwFeNCcAZS8HQxNvdkjNkwsFkO5ru01uOUFfrfrlWj2PXWFXOcpduJ7lXMX++47e6bf4/e hUrNx3yucGBqnvC0ni16reVhhYHPVXSJ4G/q1te8W/oHrteZH+v/QsBeo43qlL19hvVU9bbobM+a OlfXU9/sijhi2V9k8POr3YWFO6hVpA9JZ9YG+n5rPTblYYb8Wr2IGG9qU4VKmE3rAr/ffzB8Wxob XYVEqOBVL9foUTY+oSfXapCGFwDzEeZVd5V/Yd0IoAcIav/+aXnx5x+1F1pUSSMIA0aqai8KDfwH Q0tFhAphEZyYcWAhjxWrXcxY0GC1jKleqPoYkuLHmP9WKXz1b1pFVS0JTms5reDBhD0HStQi8J+q F82O/nnxAuI/fCOdpqwYkmPFk39S4vy3cmdFPAtlfgRD9uw/f2fVJsX4MdXOgqluAtU49l/TuQPb CqR2UktVspzQ/8ZUS5is4cMD/flrea+p4oqJI1OuLDPVwX8SYaIVpVcmSRhYU5VUrAUGWbBoqxV0 PBCWlmn+svmTPdD2wH6E1UqV2RukwoF+RaO9lxW15YphDuPL95Ex4o6qscrMlvzfoesZYWmTPFl7 5UJujZ+m/B28zHzyrvsFO+3FZ/DVmj79czQqYRicPz5D2xXhQ3P15FZaMt2D03+K4TPNgb+p9Nd+ MiWon2XTWOgges+FplcqRlmGYUzZZbgYeBYO1Nt5MYknmUUEooVPYrplmOJ1MKiGzwv3KaaaYgnG pAoMgRnoDz6/+aOjZiG9MFRGNI5IFpI7TvNbf4R196RMkoyk5P9dTmJJlnFrjWjhNEeB+JEWMBkX Unxk+djQc4ehEh81Xu74QmDV/BTZfaRU5mNGrPF4mJ3/wDlQPvgc+CVhzlUmKINdDZqRdehdSZaW jGJZqKYFnvUHcXgZxFxMMrIIHqdQBofUNEHuRmJy553kVJuaxvJRmDM+WZAr2cDnKaCFoZdqpyOe d+aX/12akZIKTarYobgVe5Y0XZlyEgzIDnQoPsv+GRN99k07UkzBVuYtWob454pB99VGKKU3VXbe oNuQ1cy4HyVaEb7/3YNPPPmqay5ab6BRmYxSObqpbNp4eekpFZ353zSVohuZtopNRmy+aC1cESPV OVmot7QpiBb/dUSRtV7HMrGc61lTYjlwhoAQ1tB/znwUpaYEf2Tiz9I4eWu5hB1zjGL38dypzvJW 1JWdH/tcXHLSyuRwVBdXpkmxQg5UqdOeTgv2R6ccmtyzGHeMLhUy0fixTEQHHO+TiV3JcXJN93OP PzBbBp1lfvNJKOCNwp0RMRU9c/hh2RD9DztkgQ31dVNnZHnLH2X8pLlTdKrOR2d/+HQ/d/9Ddr6y Yb7b6vIKnrlkqku8mB+EjBhyRci4WZHor54aWestbz6i1rCHnRw+exuWWIKGLZL0vJymqFZiqfKG dWSmtoz3WSajdan2Vgr7zzKbIDSiuoQZQw2+7MnE83fNZ4SP//kZvX7W0mSt7x96QqdF8eymgZXn aa5+FTmKH/yAlsRkrE4D2R9+yjW8BBXvZ8lZ1IkMeB2OQRBdCZpchoyBC1BQwoGboAQlRKG/+p0Q hZSQSvp808JNhIl+xojgP5rhQhQKpIUq1JjmZGIMFwrkHkZMYUxEgcL6UcOF7TuLNqgxQ4lt4oYV 0Y0OKbGJ3oiiSBp020D4ViAikYhnQ+ThQHSoBT9gKBVLlEoTKYHDwvBmiv844xYVxa83DsSH/4AZ p8JnmTOW0FB+/Mghm4EPFLZvGrYgC/2WOJBWLLFvGZEiIxtySMrosBlVxIkxzLfIJ+6RhaQkzCZE YYxO/qOFN/9MkQ5z+MJRQolc8ZtMJ6sox1DehBKk1KFUqthKYwgjloTpgypZuUnh+PIfoshjkYbp uzEqJpdDREgzn3kbhGwCX9oUZjRRmUxfArOVDmoivjZhPl6OMlUA1I41qzUNUTZzj0XyJT7YJ8s+ nC5TMUnlKslJiYbcQ44ZQWIsgUlLTr5QlJMRpiX7qM4+nhItvtzfb4TJM2EK845fXOD4sgFMUSLS immsnyi6+MJ2/KOeZ7moQDJqUmZKJaEoDV6qRoofXsaJpyd64Ykq+rXuwHSOnswIT41ZkSoKsjAJ ampkRpoNfJCto320Yign48tByKQfDCpqOI8E1DQadKlY/aj/b5g5io+i82kHUmX9tMjIw6hzE0jq KJKa2EMrKnVnx/OHK2LSG2lIQ5uaa2ZX9DrKJi7oHt1EpTrvOlOKSnOR1Bhl8PiUQgPWVYu/mac6 PctYysYEbHWNklU9+lOlufR3sLoceJrYh8CGbaFXTWOCFrmgijQtI6eNSV+H2MK9kjVQMoFErqih irk+0LPzeyFPm6nD/FUklM69rRBROssTgjQqanmFk6gxDWa4VLgwyogOU5lDDD5WfSfcohhTy0zu RiW9PywWNZTYzE3IbKJL3WIru1nW9qLFugCW5fn26M1C3vG6xkOIfinm4AZ7kRKmVaH2omTgcC5S NcaoxIKP/1hh48YkEZOhXzn/e5/H8jSjT8xiWavrybZhF0kunWGML9mb+2BlaSgeax/PdtRhNnGp L3ZhTFapXuweEKievMeQpWGMzFLmx/QLU187Ot0BHxmFSW5GYZsEjI/gEcgBHlfFINnNMj3Nv0st oT+YkcEvwjiJzfjDDzv5ONX+kRk9XGKOwTS/LTK4uN1Z5A5z/Fh8UU+I+d3ETuRb3CSj9UQJHoi9 nOYt+ln2cjFuLzDH2tqzrC+UXbHrZHjpDEVJsX3Z6N1hhLGLszyR0yXU5iL6KgqzyFK3Axn1R1KC jymLQlpF6i16c9zXDaZoGsVbUJF0RJvueOuG95ys+vJ7EP9WfiSWRCo0n59moAfaVcBnPjeZzddW X+fvop58ojDDt2TV2taCh/lPKFstx4mCNiPPDKb5Fh3omLj7saqb7HRHMY0XPlNn1erUMfJt7un6 Iwsz1eEZonLDRTPHl9J4N5hBSYnElJOjLKy0Zeq0LAyme56KPPcmzsbOZlLilXWibsGXAuyoZHOd 9DxlpVLmbyJGZYbBnGlSnXgYT0rSrP/ohw6N09YMohDbGcEeWVYxGf0WMpKOPXrR+RjHnXf7hNIw nzZ0o2WgDrGg+KJfzA9MFkehTjFcP0oWK7X2sY69mvzV4kD0a9deO7PpkZzwYWr1EW20ZDYV8dbC Rx7Tgnr/Vhvg9COMmRvEk1IiF+bjOg/LGUcAH36yUC0gWmANHghK6H5/I9gqUO+04V2KZ0KvLjVe vU2qiftk3Ct6df5BCMX/ZnhIpW6xFP+PS/mkIsJYvrjpN5BEvPZ4yCMz8qv2JNd3ivvwGpP3KbNn snitVJ2ickXqPjv+PTgyYPMSS6EPIlq4VjHlt/S4GFO42vD/W9DvmG0ADWVQAx5QhvpVhJzBTtr8 UbGgX3KQjQM+3pF0SgUFw9WsxnXcn/EhhnhVDGFlTgVxTokMRCe4X8xYX2W8zu+9DjxkSASCEVl4 Vd3cRG141enFClo83/iAxmKc1/cViz9owwH2SEXATCqg/0JMaEMrEIZsZIMfVMH9dYo/ZcPUdMcQ Utl3YIijYB0RykQLnoUcvE9yyODuJaGzsV/7VcYQaofMUEZmHcUEMqGYHIaZKAb9Mcp5wAJ3BCGn SIL0DMShBQvHnJiXFM4kdUoBSkZ3cIwgaUtXxN/fpGHmsNxhhF+c1I3ldMUGvg8KUEMqoMA/+IHn vMjvaQcu3U+q9EPhUEMnTgMoiqIYZgRXdYxhZN+LnOA/6CBCdGIq4EQW2E4SgscolODJpKGFHIhQ CUcryhks/gPSZMjtaUdMZUg1fGIojmJ0aEc2hCCqRIYhSkwvOiE2pt4ySOIGncX94MMrlhanZFo1 xYQDef/jvBAGjMiGUJHNJ/pDMzrjiNiiG1KighiGNe6jYMViWkDV6hxMJMJjqdAIPljjNIyjOV7i 4BSkhAwE7tzGQI4joCDL+BHGE5ECFr4g9IiNV7yiRF7OMFyfdnziFKAACgjIS6LAFFADK77kZ7xC NtiEVPgDL6IkG5qKUHGKG0gGVLkkTOrFTNbkTcakvEzBUu6iJzKDPo4i40hioSAlEyglTDIlTTrl QEAlTC6CETHDgQBlGc6PpmRGFJIiYaQCNcwkV9KkTX7lZ0yBFsBkYLGiJ6JAVfoGTuii2pTiJ87F J06DH7SPKLKiAt0EFU5Bb3hlX15j5cTEM9afGwpSYZ7/JDU042KiQGN2BVQKxBT4ASueJWWyYafc YEVs5id25iiKois2ZkWM5j+UJl9upDmqgp2oQoQknsy8pmfWJGh+xBRkgUBMAxjkJiju1uW84NJw ozX+Qz7ggSuqI0x2IliC40B85mSK4uYgCeZsjuotBj6C4kDEZHZmJyu2yRToxWKWiW6CxyaehZFE xnT+g3quZye6gnvCJ3F+Z0pOpJ0MTz7ixH6uZ3sap03cxHL+5DX6IC3uoFdQzGYe0HaGJYAyZ2oS hi26Qi24YWXkJwr8QYYuaAS9Z3cG6HyOIH1i5lmQ6IUKxzT854pyKEEqRoO25UKOSAl+Ym+oJ51k 6G3q/0VE4uiAJofpdA9F/tE9OOV8fqZ7ek5cwiWEEqQbTELdiBEu4ieUoqWUsghUIsR7smIztCh/ XOVzMMh1LIKzec9HjEJmvMWXpuZnos6YVimSWsZcNGj7YYiQ+IlrgilxTimZWqmAYolx2MmyABBS dqJ1+EFX1uWUdqVUomlkJBAktaEcGqRKfGUndicKMINXVipNXipaxkxtnMFy4IrV/AkBaQZlPCoC TWp7poxYnuqeXhr7+ele7E5aGAZAsiGIpIIrzCQCnQIolKpxRiVzImaS8t7m+Y42XEqY5KdJooWK Gsu9vYuCBA+2Nom2Kt8FeWtuwCgP4h+5eKnGwEKjbf+rYnAjjaQNl15ORK3hbhghbVkGvFJo4zie 4BDL8uBEYoRrZPTrgQwrPSZLfQ6EwRbhWfTr2NzGgZhrsKVlcjzs5cCMVKiog5DJO90bpVRMNuCr xdqbN+aBJ1xObxxmacWEO96mrx6QNqxOyaJsGE1kRnzktB6QuFYIiPiN7KDH/ZzDzzagzsqjuvoV xJLK+VXG8GhPmqGjYWxjV31JKXaKIUwJ11qkz/YexhAMSQLrR/DC0Zoi2d4ba6JZznqq01BhbeDr tNgJp1iHNpRn0uat02ZjMaLtOU6TpqztueQLx4xt5tRn1uqtYxJGNUTjmDxJwzYpxqbOHF5kcvCM P1b/xjKEwtJ24Sgo7kfE7OCCrmIILuzwGnqACI9K7uSKqBrCYIb8xpUg25N41YGQIdH+g+6QbkWI rnlQRgVxCjd2V2XEHpbYQ1lALkO+aEbMg/+5rsRsIqdIQ8RcJu8qBrleL3r4TKpUUKzGhCXKhPES htwi70egQasyb4ZkZLY6rxtyDOpw4S2mrfbeBqdk7gxiJfEeRgX509ki7bRMI/5aRgz9w/jhTeJK Xd9+hIwMryRS4UDMLGF8r86S0e+SL9ii60DYDHjoxjdKsH2iIQXXr2LsWeRmSPjSCMF26sWyZI/g o2WM8B8l7v9W7pdIRa6442QQY0aIiK4YBjB2Ydpm/xwJZ6qLiI+m5Io2OC7+oODLZkg8Jkj4BTEK G26+XEkUEUb4DoZTyYQ55AsgcB9JksITPMHqakc16EEZ+0cyngUXE4YqPIExnHHglm7qAmLdrS0S RgbthhENUwYg9LHSchJ4HGDkjIsVUGVlAEIZ64QVoIUV0HHMDKEzPPJA6AEHU1knhGFGvDFZ6EFK wIMzmDFZPMECxsTmsvDaoGMwXodUnDDnTAMpRK4D40plYPLpZE5ipLEZx7EhVgMZP4Eo7PE/4DIp cPBZqIIe1G6w6MGg9ISf5IsqWHK8FrGrAqIW++vzYo4kr4YaV4MvIwsjm7Lyvm4G98xHgLIqtELE JP9nGrdEHFfFKEuyFZwyelTDE/TxNOQzWgywTOByNVvzbThn+0FN64BFBXGfOrdEPn2HFYQxKSzz 18oEGqTBWgjOf8THfwgECKMHJDJgV1iBHjjz4yHFTgCCRP8DICCzh/JzsTBDHBdGTGuOBY8IPttz tpJvPtAx39CG1WqzZvDoH7tyTtcuYYg0OXtKb5BCM5ye6YrsQIxCPQsxeAjm1/yDM9hMIKQ0W5B0 Uv9DUleDSOeEFZRxSsR0HLN0oKjxEyxzHLfEPBPFONsMPKD0XphyNbwCNTSyMltyJcOhZow0LwPz E3CwWLd1TpQxKfNyYpOzNvBzGj8yGRu2GkdybTz/Nii3MUJA8NVeR/j2DI0wMfDwTkxkdWAbCCpM Ci8/AU5McyMXMwcDAo8Agj84Q0ynxCvUs5+8dUWMs87oyTREcqcc4GQEsmIrdkrY9lQjxW5bMiA8 tFhPijIPhCmTQhzrDClYchqnRFJPtU64tBUYBiCItZ/g81qLtGwX9k1jdSRP80AcM1I8MjA7DLXZ zEgz3hNoBkpDNzmLdTXMszY4sxDqDCld1uNpy/thsAab4yPZ32E89WLEc2lHsli/gjJXw0pj9RNE s05kRHr7A3erwjGr93c3jTNHdzVkw3+TMmUI8pxaRnbn8nMTBT7rjGkXczSXdTXgc/mJ9UDMMzjn //c/LLdwx3WNa8ZM13hi3LYe3IcqjLKfAAJ47XNK6LYVSIV7w7asejc167db47Nbk/JKT/NOUINa V6Zw8K/+5q5l4O3iqYVdp/lALDcju8J3nzWLP/lIgLNlg7Vtv3UjBPkGs7Qsk/n3Xck6V4Tt5AFV z7nNWMdDk/Wct8SRr7d7jzJyy/ZeWDIuH7kqxLZEzzSO3/Vr5bNtf0Q810ZL2HUck7RaLPcTGIYz 2AZAV4QpX4GGp4Rd4/OGf4QVRLPxfIfjCQ9iiK30FE74Xspy/0OmSXgx64Fu6IElSziGVwSja3l8 X7IlTwJAfzWvA/v+XskSggRl+E1c38RX43Jcz//0KF+ybCNbpUf6ejMyMBO5T9j1Mic1qzuDYTgz KXgNPizzkes2I/+4KuBDM5y1FwBzbVhyYW8wulfDHmT7kOsEtQMCfPsDi5PFMnxh1XysE/+0Fb+P CpsrgsSKbOAMEiPFxjuDv5OyxrdEP0i7Zuh4GmdENIP3Tnw1OY/ySV/8/o5ImNQzeaffxtezbIN4 HFtyjIP1cwvJTfMyPJvxc2MyPvuJGqvCNKTxSI+3KYPyr3+6h2f4zux2ft80KWhBL7f3E8DIE1hB Iqw6nCP2MePDdS9zp3/9W/s3q+czvWNtwLZu+lXZ34qtE1+u/VnBr2N8SvzBd6+6VEwCGsTxMUP/ eUpbWlzH+bnftDOTszPvvWXH45MsTZgEs2rowT5bwWCUsWzv86cDgm5EOliDckyUNSmsu3o/vTYw cuun9pBP9ShPteLzCG9fDjnv+sMTwmtrxturAjUstxqPNyM7s0C0ekv0/MN/e0oc9vF3ecWgnwCq JSDWMhpqX5dyTsbE8XErts2stmpc+KTbm/o//KbzVvMfNu3jsxPUrDasd9KCDUBw+jewmr9q/wAB +udvYEOHDweqsgJxIMOG/ShmhKhK4UOLGkGGFAkRn7+S+EZm6zdtZMNsGVG2lDnzIUuNH2mGxJkz Z8x/ejrybEiN5k6NRIVuVMhQD6mH0kQChehP/5vDl0kBHWz5Bk1Sr19BstTqFelDYV9Zsiym0ebI tiN9Jo0Zl6LPJ6rA8qyaV+aTg9Sq3W249y1FwQ6NenWGly/Pso15Hpx2z+tHi+2S+nv8b63Xq183 h8w3MDTihs78Qp6Z+GHpkCsN461mRY9Lh1AzknoSdCFkVU5V53z1zzVIukNz3ivc8HhDqq0raqRM ce/A5g3HhmyWquFyjcAzsuYLKHVwocO9os+2U+KTaeCrP4y/7Un9w43JW2FsPjLN69towmiqaa6z zKPoKJruQP5yYmg/kmoSDySj9LCPt+y+wlAkQr5Cz7jBbnKouJbiY7AVBsOyjrmQ3vjnM5Gm8f+O tJBQKtGhwiREUSMbofsHHxlH4vEomWLBjaJYrvsQxRx70zE4I510CCV8PlMwIzcGEhKit/wRsEmd JoxSzMooggUWsM4M0z8UgQQpTba0KazNKEVpCJngpovHRYomkm+gOSFyZh4RQ9LyLcqYTOyeH++x siFDQBLywZBGlOlFyAD1kbppLmXOO0cf8jKkOY/TcLDq4mLSxUz/EVUkhvwYiJ2MPJypE2FAhYg3 56rqdKrwvIqLskp5wkiVVB3S0pkxIaOLVaOmcXVLioBkFa6k3krynxj/5Nah7HI1raZ/8EpyuBij lUnb7qTJBtJktw0pXLRUS9chUFF6S8uc9h3/ky5f/SNw0WkHAmRZtlQ7TpX6NGwPEJym8yeM6vyx 9k9xMXZO1Rv5ykYajCxipEHV/LlnY5FMnlfKLK2iyeCp+lWtGvKeeGhdmVgSaCYrwEswr2xk1MNU coN64rowsP1VNSh5mowiadVNeJqKTzaJzHhB3LnnoU5+iMOZZsvIStRGaSgfbd+MV2frEqumwmoW nvSfakhhxj77spMDJKEbwsNViTR64mDnnOy6oXv6yTUfqKldCWrYFkxOKGqaqWvNxgwn6O2Fc+XI Pr7DLIS4XTXSY9K9mqt8pLSxXqhSoVV5kKjZnAKkz58ewqO7hwCpzSHdHZKKooV5YnJOYncf/wgq At/KBnme4FmGcQYBVPof7miUiZqYvYJdlcLcNn3un2oOsSH9RgpscOIyv1lliGi773yt0K+K9OTP l/tb+R3qnSaiHiM8/PWEWgPByCS6wjEdZe4ik4lWpmLhs4Z4iIHMih9eFDQbvJAHL84wCLCwI7iR EO9bFRzXQ3I1MIc4QyFuewgLCSJCVYxFN0+4HSBQcRea1Wd4T6DG1DT3BN+hDyGCm0aFbEgu3y0s D8dyGyBmqBvG6MFizrmOgqoIMGatTC6tG+CY7iSvf8DQhQ4hBWNQcxBAlIVmy6rGNBhWhSrUx3ff qpAV1FgbDlYEiQdxW/nIVR/GLEx+yoFIuP9KdjOORORuDRGf8JxhhX74j4QQIYVCADdGPAJOfQgh 3jRmmBoXLhIoqvDHbmJ3xtSA8nJqglLMtOiSaYRRKNY6Tiz3lCwueaVfQpqVbVbkRT41hDwJKYv4 BKMNhaDPfxCZTTVQsyzaZEWEztBGNWaDR0CQwneX/EltSMkbyngnTkIJzEH04LuOQHEghznnVZr5 kEwKTz+kwGMgCeK/aQQGOIsJDEfACceeoW8a6xsK9oQCqlqB8Is2OQa9RsKQVUxBCxcbFcGwBjR0 yUko/YpeLoWZkZmdD5O0IZd+mhKR2/2DiA9p6dxs2IxMEpE8B0FfJmMIUBKF5WbtfFDY8Nn/EIlU YyWshB9jBLOwlsZTMAU9jELIIz5GZkcVVKwjT94nkvs5pBWQq1dLGDIWXHYraSDZWsuCFMyo+PGp frHCbrSSxxgadIzlmeo/OoHJ8qSzrujkjW6kar2nhGVOC8tOM5lRm3PeAxViEdxIT5Maw16yfIth 6QwNVh7U5AEhNu3IDL/5ljRulRCxEmNrNKMZSgUiJK5QXhXd0jSchUQLFdUILIZ21i9q5DPeoQvg KmkFPB4GFUO9LD7h5hDDzs2UVfVpQp5QzqT26QnAWeZnx6IN8cBWVytFyERIYYyExO2bgXTbgwyr 1NjV1Li70U8hBKfYJ4wiK+2cSEKsQxSf/wTGYPykSNlM8xHu9qZ6LRFG4kz4paSMVYHM4l6tZGQU Dc6NPM7g7xtj55cJ285thxUc1VjqFNRckrzT0MZLeuc5PTqluggJSo6yChJCClKoQgxMi2nGt4Wt 8SGB0U+KyXUJwWQjMDq2gVRfmh80+oV5DUniP//LHwY/xBwLMbFQErxbjfQ0opYroEgWShHVDWRZ O6xPfVn6BFRoBYnr5N/cCESKsAoGNS1E4n4qlBUlF+wJntjPKU6bkSmPSR4DGXTU/mHXLXJPadrg 8hbNg5KIWScmA26JnuJVKe7GJMuC/Yc01LFgSKeEQZCNLaawio9xhmtoUXrel6U0nSn5iP+jOmoT UZYT45CgQRI5ASJEMJ2xHY3aohQ5dE52ta5slDMvmTNZ1tSkI2yCpVN0YUhiGKdrLvJF20k5sT+W vZ4Ydw22JwYrNVjDDEHzMiRopgmztyinmP26MYbEjv5oMtY2LWfAr87IiRDkJtYNKdDEhsiyjbMx gL8qKTd2t1e8WjwZ6RaYEPn2i54DFqe1hB3B2GlwOo3WVyUCYxoNVsWo9SNUGxwirm1JVv3NE2lY GjHe4axGpocwlm9RQscI9mwjtxBo1Ysu9g4OzVke8p3PyGJKX/qpVNNtS1nO6V0GqWdSlCx/KL3q Nqul1HWE66Cf8Ollx2izCScfCTWBL4n/OQWgWwKkY0MG3NQ6MaPBhDKkm6frE5q72WE0OZkYDngo Ws9Aqmw+wHfHItQYBA0gP5ws/OMVkO/DaChPgzA7BPJY2N5NqAH5L1AkR1qwwZIsfm7VPqTyr9i7 TDpPlMrTAAtiogshav+QdzwEFjQoRO4p8hicPF7zAyH+QlvNl5X8MiNZ9E7fK1L5r2mD+A15/ASL DxJU0IAoEsLHF0Y/JupnRtDkZL3moT+8zJfl+mLCCe4pAg+ItD/tLPMI+P8Bf/zD/1tRUpmE3sJb tgUVGoIAKyiWQi/8rI8GGoL/ZKLykIcQFHAmHq01BkE1tIghbOT1WkIVILABgU8kYq4x/xyw2Gak O7Sh+LLgC1JQ8iaQWVSIOUriUBospFREdTIH3ijiC7ivNWhgL0ow9e7lAxlKAoWiAifoayiiwDDn aZiFCPMvBCsiMdJvQ6SwX1oP+zbPPGLp2kqi+bTs7E4QZ7Qk9BgQIr4AKYJwQcoiRlzj/cIP6ZiG OmhACRvE34QkLXjiC2cCCktw9fJCEbZQI4KhEyDCAe3B/h6iFFCi9zwkC78Cl+CBGfBObExwyzTi XTQCG+qPIirvBQdiESqC/3gw+/4hFgoB8v5hLyDQDLHAFB1iEL5g+zSvVl6hFAehKmaPQx6PQ+7h FVyBBvwhFyFi9joPPV4hCyDPDrGvDv//gQe/BhZwsSpokQYIsBTBL/JQjvpEbzj8AfKkgRCqERWM UcGIg/iwwBZ70PiADyeooRRRgUN2EfdoIA0Hg/i+YDg4YRQcT/SqIvYmqBSzoFYckDL6AQhfMR9L 4RkhL/JKMfIGgh7T8R9QoRSpYfaqwh94MBviMTN0LeeIQ0U04g/uZTk4EdYosh5BIhscMPTORRuo 4WuwQLU+8B33olMeLwuIghBc4SpcMiInbyC+QBxDDwumwSWh4guCEiKwwA4hURYzYihRgRqwoPZ+ Mv8mTxsgMf/QwyVtAgsuMPMsoikn4yqPIQt4pCkHYvsecR2jMCN0chUHISz/4RXjkgf/CSP8PjAF v2YFB4IIn/IHrQ/4Zq4h8C/zkNEUt1IWdXEguaP1CCELdXLZoNLXum1OtmEZ1G0lB+LZVsMhtg8U WS8Es68tti4sIfAWDY1HcA8pXLIqlHIosk8ChwP8NHIpW5Ai1LIhsEABr/Ih5vJcRi82pxA9iNMf SBM9tq86tOFr+O8eaCAoUeGhLM4ZiUMx3VIUNiH40NL6DLM7r9MXBXMg1HIQgG83ATP7/DD3oMQP g3IrIXErCSEoQ08eNY8asuDw/oEuUQTsDu4fjE4kzATaKm8pkcMlQnAi/4EG2qIspK83tcwISaP4 sqHzGnI3CUEakOIeqsFC/6EGrPN6/9JkN6+TAHmTGY1vHVniQhvya7LwFa4CJaTBOC2UQemz+AYB 9ySvOKgBFZQRO8tiDYVyGVGhOg6TPL/gHnhwGl4R8ibPLyFCGtyS8qqR/aQwRUGzB+Ez+2ixSb9g B6qiPp9CGAfhEQjDIc4CIsYM0nLugS6KNz3PNF4BPcyT89CDBgZh6+JD+sRUERvQN7NPJaml9hau BuKQauiNPJUw9EyUPPkTBG9EUD/tIfwyDbduIBh0SKFNKFnwSQnhHTVCKYv0N91TI+Kx8wxzAuvx R1ACEOvyBVEiGJFCG8CPAEv1EIFPG7ZP9rATPaYBFmUzzDpyDVhiJ5LBy8bEJv4uJP+kjykH0yEU VClRri7/UkuB1SEk9DrRQxkd4hUIcBrgbxYaglsnqFHbYjdHD0q1lSLqFFpD0BUatfUmj0r+QRKM Et1a8x6xL0cpsim3cFer1UOg00o90Q6jFTxD70fyNUsukDjRLfeIkDhTMkivdP1GEWJ79S+nwUO0 weV+k/I2cyCYgZwQDiTuwUgqMfCKp6dCkxXzcQEHQz3xFED9wUSJ8PFO7GOAM2SvsvJQMw7hry18 9i8n0EsglCURcxWP1EXArWIupVkp7wugRBk5VhuE4BWu7R0BiAXdlShScDxxdThu0Rq7wy21oWIr z0Txkzot8hnxoSq0YQW3VhdnNv//bHYdlVEXeRA97qFd0VAvtTJgse8jzJNOYRQmYbHycOOHHuPb YMQ/4y5KXoEQOu9Tq7UhK7IhtXQjL5AWmpQBKRdV02AaZs4MrdFbL5Rol1F5WFRocVEjktEVFDAZ V7czm5H2zlB167ZbGdAiSvEVvZb4BmEzfNT6HjVZiM8+R48t67FiMHcoqMHxQvcLCopTaTENw6AH 5BLy0C0ga1dzGZB2cbQOFRfyGvUfjMEY8k/0bAJ8K88FauBX0SN0B1IogdF8SSNHRW8OR4J/G2ME NeIMzAMc6o8WQqIRIMKruoaBVIVJ9IZZMkcDiydVKUITTwbzRIJxEjXviiJUfK0l/55BtiBDgFXj HPyUOkZFQTYmFJZh6R548VAYZ2LEIrLAQOElJwAYhawli8gucmViIcEi+YjtUhlKJzauCrMOhhuD wTilLfrBGK+V9PgjZWti0DbGM1FIiYWCDB4hOPBuLxAlKSD3ErXYSWrtM/WOJjjw1GQiPiztI2Im hxui1zym4mYiZMFKeVo42gIuPLbujy0q4nCm7lqlJTD4IqIkglpCHtaU1DoRT4xiCxOjFBaSivn4 g79CVRAqKUi4XQwtq+IDSgClaoSCCJZggKqoLWxCGnBDPABx464HRSFjFTJCEfKCU8CQQDLCkovR 2ARLjiHDf2diWUcCefBYci7ZR/+opjmwGDscIhXqpBMtbTkuhTUELCSkwSKI2DwGcWS+LJFsLxtO QibQIIEYBN+wjj+0BQ0QWHu0oUSqiMtUjlDAMAwx0dDEkEfKQpgdwhWmFSyQGCIsoQY1YqukuIxH KInjjlGIjVi0S0iQkCZM5mZMSEJ8hZcTJKAdAiRlYqDtOCMMeuwQGssKxTmaeYwV4whbZ4OL+FrG bsCUbSBc4SSdJBios4MzQnTw+ehqifHyAqUhQhT/IR+IRVX2Qkiq41IypR80uo8tETFwKaKhj0mY cKQdAsAaQqd3GtGkjJDBwku0TUKEOq1EopplAqgJjhAPumm6hvky4pi9wibiAhX/Nrk1gPleFohc /lMu1tgh5G/vFGXqbtmRuYbhKiNleOIY8MEnnM4nZKTQFNorUFoTSdrgiJnWUMbTHuLnMrmzK9sc Uc2BrDpqbnLnItohtqBH3AKtqS2uNWIslmOx7xpCUOi0ETmhHtkxnPBwSma0s8eerfoQ1tpkcwKX iJpBHjrjtvohFNl2t61Q/G0nKMO2abbsMNq36znfsluCBk+kQ1rnZmJOAlQk4uO7B1skWyK6xRC4 Oca8kxm7ye+8QyIYwmg4tEhG+AHnLA4nlgEemnq72WK8Q2SPWSudJQhkeI63rKXANcIWoFq+2Xjn /lkEOfPUvLEwYiJc7AUijtlQwkZtmhH1IxrhXTpDsyNF8cDOcCpQQlBFJBx8WyhG42SCo2nCtiRH 267bpZ17xn0ix5XrtwdiG56HtTGwmCcYjUXaqeuvgkyIl4m8IWxcU67FKJCir0WCugEULPYYIopD kCUahq2cZBL8fGhi4IgDl8L8uUPk2rjcBok7vnP7zTeaJuQPySFu8fAuwRjIJ9S3pfGjMWj8fxfB Q25GD9Wcn8eHoLv7kM7aOZR10YWQJFJ5o/Aavq0izRXvH6JZtyGtNAICADs= ------=_NextPart_000_000E_01C80F15.442CB690-- From Cherly_Rothstein@friendsofbucksrock.com Mon Oct 15 10:17:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQlX-0002Ny-OS for nfsv4-archive@lists.ietf.org; Mon, 15 Oct 2007 10:17:55 -0400 Received: from adsl-ull-72-16.47-151.net24.it ([151.47.16.72]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhQlT-0004TQ-Vc for nfsv4-archive@lists.ietf.org; Mon, 15 Oct 2007 10:17:52 -0400 Received: from VE000031 ([160.195.73.9] helo=VE000031) by adsl-ull-22-56.47-151.net24.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1VPmnh-000PDU-cQ for nfsv4-archive@lists.ietf.org; Mon, 15 Oct 2007 16:18:29 +0200 Message-ID: Date: Mon, 15 Oct 2007 16:17:50 +0200 From: "Cherly Rothstein" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: {tsiliit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello hello nfsv4-archive keep her entertained and swinging off your manhood http://www.glasswre.com/ Cherly Rothstein From Doodlyfuiom@graciaella.com Mon Oct 15 23:39:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhdGu-0007fK-Uc for nfsv4-archive@lists.ietf.org; Mon, 15 Oct 2007 23:39:08 -0400 Received: from [201.29.217.244] (helo=20129217244.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhdGr-0000W7-Hm for nfsv4-archive@lists.ietf.org; Mon, 15 Oct 2007 23:39:06 -0400 Received: from andre ([171.199.71.23] helo=andre) by 20129217244.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1piCMC-000OWT-md for nfsv4-archive@lists.ietf.org; Tue, 16 Oct 2007 00:39:19 -0300 Message-ID: <2287DEFC.B4D525E0@graciaella.com> Date: Tue, 16 Oct 2007 00:39:01 -0300 From: "WeII Doodly" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: elbiahcs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hay dude nfsv4-archive will she wait or has she found a bigger dick already? http://faitgweb.com/ WeII Doodly From Mlejnekkqx@praxis-doolittle.de Tue Oct 16 12:33:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpM8-0008RG-8U for nfsv4-archive@lists.ietf.org; Tue, 16 Oct 2007 12:33:20 -0400 Received: from ip216-180-211-87.adsl2.versatel.nl ([87.211.180.216]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhpM4-0001aj-JK for nfsv4-archive@lists.ietf.org; Tue, 16 Oct 2007 12:33:17 -0400 Received: from guido ([113.112.46.192] helo=guido) by ip216-180-211-87.adsl2.versatel.nl ( sendmail 8.13.3/8.13.1) with esmtpa id 1zSMwS-000TZA-Ja for nfsv4-archive@lists.ietf.org; Tue, 16 Oct 2007 18:33:33 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Oct 2007 18:33:13 +0200 To: nfsv4-archive@lists.ietf.org From: "Ismaell Mlejnek" Subject: rflo"hen Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.2 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hallo buddy nfsv4-archive hey cat dick! you can make it much bigger, what are you waiting for? http://www.goisposa.com/ Ismaell Mlejnek From nfsv4-bounces@ietf.org Tue Oct 16 15:22:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihryr-00086e-LN; Tue, 16 Oct 2007 15:21:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihryp-00085o-Vk for nfsv4@ietf.org; Tue, 16 Oct 2007 15:21:28 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihryp-0002WO-Le for nfsv4@ietf.org; Tue, 16 Oct 2007 15:21:27 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9GJLRGb026897 for ; Tue, 16 Oct 2007 19:21:27 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ000G01QP8DP00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Tue, 16 Oct 2007 13:21:27 -0600 (MDT) Received: from [10.1.194.250] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ0005DNR3NNZ80@mail-amer.sun.com> for nfsv4@ietf.org; Tue, 16 Oct 2007 13:21:24 -0600 (MDT) Date: Tue, 16 Oct 2007 14:21:22 -0500 From: Robert Gordon To: NFSv4 Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [nfsv4] Bake-a-thon For NFSv4.1 in Austin, Tx. X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Save this date! Feb 18th 2008 -> Feb 22nd 2008. The SUN Microsystems NFS team is pleased to announce and sponsor the next NFSv4.1 bake-a-thon. The purpose of this event is to test implementation interoperability of NFSv4.1 protocol. Please drop me a note letting me know you plan to attend, even if you nodded in my general direction at CITI ;-) Thanks and Happy Coding; Robert.. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Maxlme.Gullestad@livewild.com Tue Oct 16 23:29:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihzb3-0003Bu-KH for nfsv4-archive@lists.ietf.org; Tue, 16 Oct 2007 23:29:25 -0400 Received: from athedsl-214261.home.otenet.gr ([85.74.156.147]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihzaq-00044q-MH for nfsv4-archive@lists.ietf.org; Tue, 16 Oct 2007 23:29:19 -0400 Received: by 10.124.30.5 with SMTP id UzDDBrUuhuRBQ; Wed, 17 Oct 2007 06:29:02 +0300 (GMT) Received: by 192.168.204.97 with SMTP id sIPZddBiPRiUem.7438095889443; Wed, 17 Oct 2007 06:29:00 +0300 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Oct 2007 06:28:57 +0300 To: nfsv4-archive@lists.ietf.org From: "Maxlme Gullestad" Subject: e'puisa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good day nfsv4-archive keep the kitty kat happy and make ya cock massive http://hasrland.com/ Maxlme Gullestad From Goadntdin@afoure.be Wed Oct 17 03:06:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii2zU-0000zM-0e for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 03:06:52 -0400 Received: from host98-175-static.21-80-b.business.telecomitalia.it ([80.21.175.98]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii2zN-0000zP-Hu for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 03:06:46 -0400 Received: from POURG ([195.121.0.145]:18428 "EHLO POURG" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [80.21.175.98] with ESMTP id S22NYVIWLRONXNTM (ORCPT ); Wed, 17 Oct 2007 09:07:17 +0200 Message-ID: <000b01c8108c$44876950$62af1550@POURG> From: "Knut Goad" To: Subject: niimtipl Date: Wed, 17 Oct 2007 09:06:41 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8109D.08103950" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000762-5, 31/07/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C8109D.08103950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi ya nfsv4-archive never be limp again, make your cock rock solid! http://www.hgqals.com/ Knut Goad ------=_NextPart_000_0009_01C8109D.08103950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi ya nfsv4-archive
never be limp again, make your cock rock=20 solid!
http://www.hgqals.com/
Knut Goad
------=_NextPart_000_0009_01C8109D.08103950-- From mcaleeocf@hntv.de Wed Oct 17 08:54:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8QH-00010D-UU for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 08:54:53 -0400 Received: from awz26.neoplus.adsl.tpnet.pl ([83.27.85.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii8QH-00043L-Di for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 08:54:53 -0400 Received: by 10.147.140.5 with SMTP id XCUHcDLbpikDf; Wed, 17 Oct 2007 14:54:25 +0200 (GMT) Received: by 192.168.40.102 with SMTP id TQFAIOGxhVLGts.6608283155648; Wed, 17 Oct 2007 14:54:23 +0200 (GMT) Message-ID: <000801c810bc$d5a81e40$1a551b53@eprish> From: "alin mcalee" To: Subject: lgq Date: Wed, 17 Oct 2007 14:54:20 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C810CD.9930EE40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.8 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C810CD.9930EE40 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable hello there nfsv4-archive drop a cum load on her today, they seriously love it! http://www.hargris.com/ alin mcalee ------=_NextPart_000_0008_01C810CD.9930EE40 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
hello there nfsv4-archive
drop a cum load on her today, they seriously = love=20 it!
http://www.hargris.com/
alin mcalee
------=_NextPart_000_0008_01C810CD.9930EE40-- From LILY109@ppncmin.com Wed Oct 17 10:56:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiAKI-0000fq-Fi for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 10:56:50 -0400 Received: from [88.228.16.180] (helo=[88.228.38.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiAKE-0007rD-LU for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 10:56:47 -0400 Received: from ilyas-17744bfb5 ([109.145.95.184] helo=ilyas-17744bfb5) by [88.228.38.135] ( sendmail 8.13.3/8.13.1) with esmtpa id 1SLZek-000OFR-SG for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 17:57:25 +0300 Message-ID: Date: Wed, 17 Oct 2007 17:56:54 +0300 From: "LILY Becheru" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: timmarf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hey baby nfsv4-archive not tomorrow, not next week, enlarge you cock today http://gradpoto.com/ LILY Becheru From sanguen_Matrov@rcid.ncl.ac.uk Wed Oct 17 13:42:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiCut-0002mz-6K for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 13:42:47 -0400 Received: from [81.214.42.227] (helo=dsl.dynamic8121442227.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiCur-0004eR-9Z for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 13:42:47 -0400 Received: from filiz1 ([155.154.40.123] helo=filiz1) by dsl.dynamic8121442227.ttnet.net.tr ( sendmail 8.13.3/8.13.1) with esmtpa id 1iSoEk-000QLK-Sa for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 20:43:16 +0300 Date: Wed, 17 Oct 2007 20:42:42 +0300 From: "sanguen Matrov" Reply-To: "sanguen Matrov" Message-ID: <727358879284.074831099724@rcid.ncl.ac.uk> To: Subject: sserevil MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-9"; reply-type=original X-Spam-Score: 4.0 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Haven't seen you for ages nfsv4-archive i'd be scared too if my dick was that small http://hanboton.com/ sanguen Matrov From Lorraine_Kuhlmann@109norfolk.com Wed Oct 17 22:00:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiKgX-00008c-T5 for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 22:00:29 -0400 Received: from [201.238.219.53] (helo=[201.238.219.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiKgU-0004Ty-Ix for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 22:00:29 -0400 Received: from tickets ([181.191.54.175]:9609 "EHLO tickets" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [201.238.219.53] with ESMTP id S22YFXDTMNKYNVPF (ORCPT ); Wed, 17 Oct 2007 23:01:29 -0300 Message-ID: <42CD00FD.25B95142@109norfolk.com> Date: Wed, 17 Oct 2007 23:01:03 -0300 From: "Lorraine Kuhlmann" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: esnakkek Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hey honey nfsv4-archive she loves it when i squirt cum all over her face now http://www.hargris.com/ Lorraine Kuhlmann From GabrielstandethChapman@lifetimedoors.com Wed Oct 17 22:01:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiKhQ-0001VO-Et for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 22:01:24 -0400 Received: from 24-183-178-6.dhcp.oxfr.ma.charter.com ([24.183.178.6] helo=pimp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IiKhO-0004Ao-3S for nfsv4-archive@lists.ietf.org; Wed, 17 Oct 2007 22:01:22 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host41481888.lifetimedoors.com (8.13.1/8.13.1) with SMTP id IedqQPnd73.316851.jKS.Bg0.0175490173809 for ; Wed, 17 Oct 2007 22:01:07 +0500 Message-ID: <2662301c8112a$c79f3ea0$6601a8c0@pimp> From: "Nathaniel Williamson" To: Subject: Your family Date: Wed, 17 Oct 2007 22:01:07 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2661F_01C8112A.C79F3EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_2661F_01C8112A.C79F3EA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_2661F_01C8112A.C79F3EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_2661F_01C8112A.C79F3EA0-- From perdon@IEGLTDA.CL Thu Oct 18 10:59:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWqp-0006fj-IL for nfsv4-archive@lists.ietf.org; Thu, 18 Oct 2007 10:59:55 -0400 Received: from [79.114.86.80] (helo=79-114-86-80.rdsnet.ro) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiWqe-0004sJ-3L for nfsv4-archive@lists.ietf.org; Thu, 18 Oct 2007 10:59:45 -0400 Received: from bambina ([108.102.130.82] helo=bambina) by 79-114-86-80.rdsnet.ro ( sendmail 8.13.3/8.13.1) with esmtpa id 1WimPW-000DLZ-iM for nfsv4-archive@lists.ietf.org; Thu, 18 Oct 2007 17:59:43 +0300 Message-ID: <000c01c81197$7de08860$5056724f@bambina> From: "ilmari perdon" To: Subject: issamsal Date: Thu, 18 Oct 2007 17:59:32 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C811B0.A32DC060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0006_01C811B0.A32DC060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hey poppi nfsv4-archive no pissing around now, you need to enlarge your cock http://www.grannick.com/ ilmari perdon ------=_NextPart_000_0006_01C811B0.A32DC060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hey poppi nfsv4-archive
no pissing around now, you need to enlarge = your=20 cock
http://www.grannick.com/
ilmari perdon
------=_NextPart_000_0006_01C811B0.A32DC060-- From Jacy401@bestbuy.bfi0.com Thu Oct 18 13:01:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiYkJ-0006wF-I3 for nfsv4-archive@lists.ietf.org; Thu, 18 Oct 2007 13:01:19 -0400 Received: from host186-94-static.106-82-b.business.telecomitalia.it ([82.106.94.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiYkE-0001D8-VW for nfsv4-archive@lists.ietf.org; Thu, 18 Oct 2007 13:01:15 -0400 Received: from desktop ([125.118.2.114]:4136 "EHLO desktop" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host186-94-static.106-82-b.business.telecomitalia.it with ESMTP id S22GATTUYCEMJTEF (ORCPT ); Thu, 18 Oct 2007 19:05:30 +0200 Message-ID: Date: Thu, 18 Oct 2007 19:05:18 +0200 From: "Jacy Heard" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: keus Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Great to see you again nfsv4-archive you get no love for having a small dick, only big gets it http://imevg.com/ Jacy Heard From iugauhg@lgsporthorses.com Thu Oct 18 13:56:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZba-0002mk-AI for nfsv4-archive@lists.ietf.org; Thu, 18 Oct 2007 13:56:22 -0400 Received: from [60.53.189.222] (helo=51.60.in-addr.arpa.tm.net.my) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiZbZ-0002uO-Cj for nfsv4-archive@lists.ietf.org; Thu, 18 Oct 2007 13:56:22 -0400 Received: from BRANDON ([117.173.150.12] helo=BRANDON) by 51.60.in-addr.arpa.tm.net.my ( sendmail 8.13.3/8.13.1) with esmtpa id 1mSgNw-000FZH-XA for nfsv4-archive@lists.ietf.org; Fri, 19 Oct 2007 01:56:34 +0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Oct 2007 01:56:16 +0800 To: nfsv4-archive@lists.ietf.org From: "Christos iuga" Subject: v|rder Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea whatz craken nfsv4-archive blow her out of the room with huge amounts of cum! http://imrmsls.com/ Christos iuga From nfsv4-bounces@ietf.org Thu Oct 18 18:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieDS-0004tx-KL; Thu, 18 Oct 2007 18:51:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieDP-0004qC-Rn for nfsv4@ietf.org; Thu, 18 Oct 2007 18:51:43 -0400 Received: from p01c11o142.mxlogic.net ([208.65.144.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IieDJ-0004er-M3 for nfsv4@ietf.org; Thu, 18 Oct 2007 18:51:43 -0400 Received: from unknown [63.110.244.103] (EHLO us-email.terastack.bluearc.com) by p01c11o142.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id c63e7174.1759361968.76276.00-001.p01c11o142.mxlogic.net (envelope-from ); Thu, 18 Oct 2007 16:51:24 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Oct 2007 15:50:45 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on file layout! Thread-Index: AcgQ1wvGxVglRjyqS0WZuJIIk1ev2ABANXWw References: From: "Suchit Kaura" To: X-Spam: [F=0.4458789317; S=0.445(2007101601); SS=0.500] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [nfsv4] Question on file layout! X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I have been reading the spec and on page 272: http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-13#section-14 The following are very confusing if not inconsistent, I would really appreciate your taking a few moments to look through and explain the same:=20 The number of elements in nfla_stripe_indices is always equal to the stripe count. 4. nfl_fh_list. An array of data server filehandles for each list of data servers in each element of the nflda_multipath_ds_list array. The number of elements in nfl_fh_list MUST be of three values: ... * The stripe count, i.e. the number of elements as nflda_multipath_ds_list. When issuing an I/O to any data server in nfla_multipath_ds_list[X], the filehandle in nfl_fh_list[X] MUST be used. In the following example: nflda_multipath_ds_list<> =3D { A, B, C, D }, { E }, { F, G } stipe count =3D 3 ? nflda_stripe_indices<> =3D { 2, 0, 1, 0 } stripe count =3D 4? The example seems to take this route so the file handle list should have 4 elements but it has=20 nfl_fh_list =3D { 0x36, 0x87, 0x67 }. 3 elements? Regards, Suchit _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Oct 19 03:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IimXO-0002m7-1x; Fri, 19 Oct 2007 03:44:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IimXM-0002lT-M7 for nfsv4@ietf.org; Fri, 19 Oct 2007 03:44:52 -0400 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IimXG-0002PC-Dw for nfsv4@ietf.org; Fri, 19 Oct 2007 03:44:52 -0400 Received: from [10.0.1.195] ([72.179.36.242]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1IimWi12km-0003ZC; Fri, 19 Oct 2007 03:44:31 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Gordon Subject: Re: [nfsv4] Question on file layout! Date: Fri, 19 Oct 2007 02:44:10 -0500 To: Suchit Kaura X-Mailer: Apple Mail (2.752.3) X-Provags-ID: V01U2FsdGVkX1/wDVFt8QrNEBSBX4ekYx8mOz3gDJhCq1424RX Ju5rJ2ItoJ0qU+LvgVx+yXC6DwF9l6h3jJHsoUq62IfgbRaAHx 3erc0du5/kyF0JYlVAb0A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 18, 2007, at 5:50 PM, Suchit Kaura wrote: > I have been reading the spec and on page 272: > > http://tools.ietf.org/html/draft-ietf-nfsv4- > minorversion1-13#section-14 > > > The following are very confusing if not inconsistent, I would really > appreciate your taking a few moments to look through and explain the > same: > > > The number of elements in nfla_stripe_indices is always equal > to the > stripe count. > > 4. nfl_fh_list. An array of data server filehandles for each list > of data servers in each element of the nflda_multipath_ds_list > array. The number of elements in nfl_fh_list MUST be of three > values: > > ... > > * The stripe count, i.e. the number of elements as > nflda_multipath_ds_list. When issuing an I/O to any data > server in nfla_multipath_ds_list[X], the filehandle in > nfl_fh_list[X] MUST be used. > > > In the following example: > > nflda_multipath_ds_list<> = { A, B, C, D }, { E }, { F, G } > stipe count = 3 ? > > nflda_stripe_indices<> = { 2, 0, 1, 0 } > stripe count = 4? The example seems to take this route so the file > handle list should have 4 elements but it has > > nfl_fh_list = { 0x36, 0x87, 0x67 }. > 3 elements? Suchit; It is a know draft issue and (not speaking for) the editors know about it. the example, of course, should read something like this. nflda_stripe_indices<> = { 2, 0, 1} I put together a couple of pretty pictures over here in an effort to help illustrate. http://blogs.sun.com/macrbg/ Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From lary791@ufpb.ru Fri Oct 19 05:44:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IioPB-00035o-PQ for nfsv4-archive@lists.ietf.org; Fri, 19 Oct 2007 05:44:33 -0400 Received: from host132-39-static.5-79-b.business.telecomitalia.it ([79.5.39.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IioOs-0004dL-Ux for nfsv4-archive@lists.ietf.org; Fri, 19 Oct 2007 05:44:15 -0400 Received: from biagio-c9a6a41b by ufpb.ru with ASMTP id 71FF8706 for ; Fri, 19 Oct 2007 11:44:17 +0200 Received: from biagio-c9a6a41b ([110.162.100.164]) by ufpb.ru with ESMTP id 1090F2107C34 for ; Fri, 19 Oct 2007 11:44:17 +0200 Message-ID: <000e01c81234$95c8bfe0$8427054f@biagioc9a6a41b> From: "lary Proulx" To: Subject: doorgege Date: Fri, 19 Oct 2007 11:44:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C81245.59518FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.4 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0004_01C81245.59518FE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Howdy nfsv4-archive if you never get the girls, you will with a big penis http://kalaheri.com/ lary Proulx ------=_NextPart_000_0004_01C81245.59518FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Howdy nfsv4-archive
if you never get the girls, you will with a = big=20 penis
http://kalaheri.com/
lary Proulx
------=_NextPart_000_0004_01C81245.59518FE0-- From nfsv4-bounces@ietf.org Fri Oct 19 10:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iissh-00087S-AB; Fri, 19 Oct 2007 10:31:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iissf-00085a-Uq for nfsv4@ietf.org; Fri, 19 Oct 2007 10:31:17 -0400 Received: from web38109.mail.mud.yahoo.com ([209.191.124.136]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IissZ-0001PQ-Oa for nfsv4@ietf.org; Fri, 19 Oct 2007 10:31:17 -0400 Received: (qmail 39454 invoked by uid 60001); 19 Oct 2007 14:30:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=T/RqyzEcMHiZnQiaEH/Yaxrjd4AxB0XFKXbm6yxJvoArKfIBS7tUgRA45nmT+xe2Lkrrr9HKP9ZLYikDx6QVRbhChLuQ3FRm3bFGFRYJpgY/z0To+5XyfjNy45oo8cNJG7P2/7PBtE5vIjZA5wBEpUS7E6iVR9x3Z3QOdjDgxns=; X-YMail-OSG: vkBoOQIVM1lL5vWwnPP3Tgflg8_99MSMI7hUj41eew2a73M2HNHF55JutrBX6Cv3DIHr_miXVTBzNxlR4b1OxnT.W8kfFPy3W5oVaSFVcqbxPgNWXCA- Received: from [198.95.226.230] by web38109.mail.mud.yahoo.com via HTTP; Fri, 19 Oct 2007 07:30:56 PDT Date: Fri, 19 Oct 2007 07:30:56 -0700 (PDT) From: Mike Eisler Subject: Re: [nfsv4] Question on file layout! To: Suchit Kaura , nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <218707.38541.qm@web38109.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Suchit Kaura wrote: > I have been reading the spec and on page 272: > > http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-13#section-14 > > > The following are very confusing if not inconsistent, I would really > appreciate your taking a few moments to look through and explain the > same: Suchit, You are absolutely correct: it is inconsistent and confusing. The problem is that stripe_count is being defined two ways: - the length of index array - the length data server array The former is the correct definition. Thus the valid values for the length of nfl_fh_list are zero, one, or the length of nflda_multipath_ds_list. I will fix this now. > > > The number of elements in nfla_stripe_indices is always equal to > the > stripe count. > > 4. nfl_fh_list. An array of data server filehandles for each > list > of data servers in each element of the nflda_multipath_ds_list > array. The number of elements in nfl_fh_list MUST be of three > values: > > ... > > * The stripe count, i.e. the number of elements as > nflda_multipath_ds_list. When issuing an I/O to any data > server in nfla_multipath_ds_list[X], the filehandle in > nfl_fh_list[X] MUST be used. > > > In the following example: > > nflda_multipath_ds_list<> = { A, B, C, D }, { E }, { F, G } > stipe count = 3 ? > > nflda_stripe_indices<> = { 2, 0, 1, 0 } > stripe count = 4? The example seems to take this route so the file > handle list should have 4 elements but it has > > nfl_fh_list = { 0x36, 0x87, 0x67 }. > 3 elements? > > Regards, > > Suchit > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Reinhart625@arantave.e.telefonica.net Fri Oct 19 10:55:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IitGP-0004Eg-84 for nfsv4-archive@lists.ietf.org; Fri, 19 Oct 2007 10:55:49 -0400 Received: from host-84-220-35-167.cust-adsl.tiscali.it ([84.220.35.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IitGO-0006mg-GX for nfsv4-archive@lists.ietf.org; Fri, 19 Oct 2007 10:55:49 -0400 Received: from antonio by arantave.e.telefonica.net with ASMTP id 1C29A6E3 for ; Fri, 19 Oct 2007 16:56:06 +0200 Received: from antonio ([160.136.188.125]) by arantave.e.telefonica.net with ESMTP id 339ED00E2107 for ; Fri, 19 Oct 2007 16:56:06 +0200 Message-ID: <000501c81260$2558dc00$a723dc54@antonio> From: "Reinhart Lindh" To: Subject: mortiz Date: Fri, 19 Oct 2007 16:55:53 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C81270.E8E1AC00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d ------=_NextPart_000_0006_01C81270.E8E1AC00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Monday update. Symb: T A D F (Tactical Air Defense Services) Tactical Air Defense Services (TADS), a leading provider of tactical = aviation training and services to the United States and Allied Nations, has = quietly positioned itself to utilize a fleet of the most advanced fighter jets = and aerial refueling tankers in the world for military aviation training = needs. Those who get in now are likely to see profits soar through the = stratosphere. Headquartered at the Grayson County Airport in Denison, Texas =96 formerly the Perrin Air Force Base =96 Tactical Air Defense has the = capability to provide clients with the most comprehensive logistical, repair, and = aircraft training support available. TADS IS AS CLOSE AS IT COMES TO A SUREFIRE = MONEY-MAKER. ------=_NextPart_000_0006_01C81270.E8E1AC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Monday update.
Symb: T A D F (Tactical Air Defense = Services)
Tactical Air Defense Services (TADS), a = leading provider=20 of tactical aviation
training and services to the United States and = Allied=20 Nations, has quietly
positioned itself to utilize a fleet of the = most=20 advanced fighter jets and
aerial refueling tankers in the world for = military=20 aviation training needs.
Those who get in now are likely to see profits = soar=20 through the stratosphere.
Headquartered at the Grayson County Airport in = Denison,=20 Texas =96
formerly the Perrin Air Force Base =96 = Tactical Air=20 Defense has the capability
to provide clients with the most comprehensive = logistical, repair, and aircraft
training support available. TADS IS AS CLOSE = AS IT=20 COMES TO A SUREFIRE MONEY-MAKER.
------=_NextPart_000_0006_01C81270.E8E1AC00-- From nfsv4-bounces@ietf.org Fri Oct 19 13:08:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivJz-0004pt-TY; Fri, 19 Oct 2007 13:07:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivJx-0004l8-V4 for nfsv4@ietf.org; Fri, 19 Oct 2007 13:07:37 -0400 Received: from rn-out-0910.google.com ([64.233.170.188] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IivJs-00006c-HR for nfsv4@ietf.org; Fri, 19 Oct 2007 13:07:37 -0400 Received: by rn-out-0102.google.com with SMTP id a46so323042rne for ; Fri, 19 Oct 2007 10:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=LtnLMMNVDzXbz7ugoLct3X9Tdej+h4G4sGHZeQB0yYA=; b=J9g+ThRdFbmq607+v09kBKp4XUJRAivvuVksNUFmk3oLh5aSjsY2y4suhl1HwChiVyYDV9A6CJER7VDFtn9nZ9xnQl87cCykgdDocGUqOYyZhSZ8JY1wy+QiYAm1NTU0cKteXIZkRzwMeg5JvqxWO6uCmRGKV6Hhit/c1DVynlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=kfLvQrd6UNLqhEWi7t9qeDPHknfKSEHo7wq5XCYwWtZcDYQuJKQH4CEdSELI6P6j5wFeJ0kH654mjeJaBQHNR2ybm1pTA+idNm9knOMZM3fgukAcdoGCwRwEJNNwftWaur8mT4AOEyiVn83nMMLfpO2HTskOkmACdKkWd9jdz2k= Received: by 10.142.213.9 with SMTP id l9mr785039wfg.1192813629144; Fri, 19 Oct 2007 10:07:09 -0700 (PDT) Received: by 10.142.98.1 with HTTP; Fri, 19 Oct 2007 10:07:09 -0700 (PDT) Message-ID: <89c397150710191007m5d5f8306s1f1fe6ad3bdbcd32@mail.gmail.com> Date: Fri, 19 Oct 2007 13:07:09 -0400 From: "William A. (Andy) Adamson" To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] Question on file layout! In-Reply-To: <218707.38541.qm@web38109.mail.mud.yahoo.com> MIME-Version: 1.0 References: <218707.38541.qm@web38109.mail.mud.yahoo.com> X-Google-Sender-Auth: d636d0c97a103cb4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Suchit Kaura , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1418594998==" Errors-To: nfsv4-bounces@ietf.org --===============1418594998== Content-Type: multipart/alternative; boundary="----=_Part_9777_21136385.1192813629122" ------=_Part_9777_21136385.1192813629122 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/19/07, Mike Eisler wrote: > > > --- Suchit Kaura wrote: > > > I have been reading the spec and on page 272: > > > > > http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-13#section-14 > > > > > > The following are very confusing if not inconsistent, I would really > > appreciate your taking a few moments to look through and explain the > > same: > > Suchit, > > You are absolutely correct: it is inconsistent and confusing. > > The problem is that stripe_count is being defined two ways: > > - the length of index array > - the length data server array > > The former is the correct definition. isn't it requried that the length of the index array = length of the dataserver array = length of nfl_fh_list (if nfl_fh_list is not 0 or 1)? -->Andy Thus the valid values for the length of nfl_fh_list > are zero, one, or the length of nflda_multipath_ds_list. > > I will fix this now. > > > > > > The number of elements in nfla_stripe_indices is always equal to > > the > > stripe count. > > > > 4. nfl_fh_list. An array of data server filehandles for each > > list > > of data servers in each element of the nflda_multipath_ds_list > > array. The number of elements in nfl_fh_list MUST be of three > > values: > > > > ... > > > > * The stripe count, i.e. the number of elements as > > nflda_multipath_ds_list. When issuing an I/O to any data > > server in nfla_multipath_ds_list[X], the filehandle in > > nfl_fh_list[X] MUST be used. > > > > > > In the following example: > > > > nflda_multipath_ds_list<> = { A, B, C, D }, { E }, { F, G } > > stipe count = 3 ? > > > > nflda_stripe_indices<> = { 2, 0, 1, 0 } > > stripe count = 4? The example seems to take this route so the file > > handle list should have 4 elements but it has > > > > nfl_fh_list = { 0x36, 0x87, 0x67 }. > > 3 elements? > > > > Regards, > > > > Suchit > > > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > ------=_Part_9777_21136385.1192813629122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/19/07, Mike Eisler <email2mre-ietf@yahoo.com> wrote:

--- Suchit Kaura <skaura@bluearc.com> wrote:

> I have been reading the spec and on page 272:
>
>
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-13#section-14
>
>
> The following are very confusing if not inconsistent, I would really
> appreciate your taking a few moments to look through and explain the
> same:

Suchit,

You are absolutely correct: it is inconsistent and confusing.

The problem is that stripe_count is being defined two ways:

- the length of index array
- the length data server array

The former is the correct definition.

isn't it requried that the length of the index array = length of the dataserver array = length of nfl_fh_list (if nfl_fh_list is not 0 or 1)?

-->Andy

Thus the valid values for the length of nfl_fh_list
are zero, one, or the length of nflda_multipath_ds_list.

I will fix this now.
>
>
>     The number of elements in nfla_stripe_indices is always equal to
> the
> stripe count.
>
>    4.  nfl_fh_list.  An array of data server filehandles for each
> list
>        of data servers in each element of the nflda_multipath_ds_list
>        array.  The number of elements in nfl_fh_list MUST be of three
>        values:
>
> ...
>
>        *  The stripe count, i.e. the number of elements as
>           nflda_multipath_ds_list.  When issuing an I/O to any data
>           server in nfla_multipath_ds_list[X], the filehandle in
>           nfl_fh_list[X] MUST be used.
>
>
> In the following example:
>
>       nflda_multipath_ds_list<> = { A, B, C, D }, { E }, { F, G }
> stipe count = 3 ?
>
>       nflda_stripe_indices<> = { 2, 0, 1, 0 }
> stripe count = 4? The example seems to take this route so the file
> handle list should have 4 elements but it has
>
>       nfl_fh_list = { 0x36, 0x87, 0x67 }.
> 3 elements?
>
> Regards,
>
> Suchit
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
>


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


------=_Part_9777_21136385.1192813629122-- --===============1418594998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1418594998==-- From nfsv4-bounces@ietf.org Fri Oct 19 13:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivWv-0003V9-8y; Fri, 19 Oct 2007 13:21:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivWu-0003U0-3v for nfsv4@ietf.org; Fri, 19 Oct 2007 13:21:00 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IivWt-0004ap-6v for nfsv4@ietf.org; Fri, 19 Oct 2007 13:20:59 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9JHKwI0000167 for ; Fri, 19 Oct 2007 17:20:58 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ6004013S3W000@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Fri, 19 Oct 2007 11:20:58 -0600 (MDT) Received: from [10.0.1.192] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ600E1W5INZAB0@mail-amer.sun.com>; Fri, 19 Oct 2007 11:20:48 -0600 (MDT) Date: Fri, 19 Oct 2007 12:20:46 -0500 From: Robert Gordon Subject: Re: [nfsv4] Question on file layout! In-reply-to: <89c397150710191007m5d5f8306s1f1fe6ad3bdbcd32@mail.gmail.com> To: "William A. Adamson" (Andy) Message-id: <5B1FBA87-9E4B-4AA9-9716-AC1817691C6B@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <218707.38541.qm@web38109.mail.mud.yahoo.com> <89c397150710191007m5d5f8306s1f1fe6ad3bdbcd32@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: email2mre-ietf@yahoo.com, Suchit Kaura , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 19, 2007, at 12:07 PM, William A. (Andy) Adamson wrote: > On 10/19/07, Mike Eisler wrote: >> >> >> --- Suchit Kaura wrote: >> >>> I have been reading the spec and on page 272: >>> >>> >> http://tools.ietf.org/html/draft-ietf-nfsv4- >> minorversion1-13#section-14 >>> >>> >>> The following are very confusing if not inconsistent, I would really >>> appreciate your taking a few moments to look through and explain the >>> same: >> >> Suchit, >> >> You are absolutely correct: it is inconsistent and confusing. >> >> The problem is that stripe_count is being defined two ways: >> >> - the length of index array >> - the length data server array >> >> The former is the correct definition. > > > isn't it requried that the length of the index array = length of the > dataserver array = length of nfl_fh_list (if nfl_fh_list is not 0 > or 1)? > > -->Andy That's certainly what i understood. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Oct 19 13:38:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivnO-0006J0-0a; Fri, 19 Oct 2007 13:38:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivnM-0006IT-Eg for nfsv4@ietf.org; Fri, 19 Oct 2007 13:38:00 -0400 Received: from web38112.mail.mud.yahoo.com ([209.191.124.139]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IivnG-0001fN-8J for nfsv4@ietf.org; Fri, 19 Oct 2007 13:38:00 -0400 Received: (qmail 54593 invoked by uid 60001); 19 Oct 2007 17:37:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=hPbhAvB7ZhTk7YhRBIWZqv0Z6JsYqHzHo0JtwTti9byo5DUP5bLXrPs4JSUDPi2K3b9Ifg6UJ9XAJ9QqoAmhqIfRJmcRhQHC5rIuGr+IlXORtp7HUdXDs6A3x6371ZNmuvfmKkCEUAyXDtXoB3xLXzSgyly38ZAZ5Wz03HHrim0=; X-YMail-OSG: lQ5IDRIVM1kvYsFVfhDrpiHws.8x6bK_i0Sq07O3 Received: from [198.95.226.230] by web38112.mail.mud.yahoo.com via HTTP; Fri, 19 Oct 2007 10:37:44 PDT Date: Fri, 19 Oct 2007 10:37:44 -0700 (PDT) From: Mike Eisler Subject: Re: [nfsv4] Question on file layout! To: "William A. \(Andy\) Adamson" In-Reply-To: <89c397150710191007m5d5f8306s1f1fe6ad3bdbcd32@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <799415.54459.qm@web38112.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Suchit Kaura , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "William A. (Andy) Adamson" wrote: > On 10/19/07, Mike Eisler wrote: > > You are absolutely correct: it is inconsistent and confusing. > > > > The problem is that stripe_count is being defined two ways: > > > > - the length of index array > > - the length data server array > > > > The former is the correct definition. > > > isn't it requried that the length of the index array = length of the > dataserver array = length of nfl_fh_list (if nfl_fh_list is not 0 or > 1)? No. If it were, there would be no point in having a separate index array and data server array. Actually there would be no point in having an index array at all. Keep in mind the index and ds arrays are in the same data structure: the device address. It is certainly RECOMMENDED that the index array be at least as long as the data server array. Otherwise the data address has ds addresses that will never be accessed, and this would be wasteful. http://www1.ietf.org/mail-archive/web/nfsv4/current/msg04360.html In the link you see an example that shows the index and ds array's of different length. The same example that is in the I-D now, which Suchit reproduced. There is even a spreadsheet in that email that encodes the algorithm. If Excel can do it, pNFS servers can do it. > > -->Andy > > Thus the valid values for the length of nfl_fh_list > > are zero, one, or the length of nflda_multipath_ds_list. > > > > I will fix this now. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Oct 19 13:47:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivvY-0000JE-L0; Fri, 19 Oct 2007 13:46:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IivvX-0000IL-Vi for nfsv4@ietf.org; Fri, 19 Oct 2007 13:46:27 -0400 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IivvQ-0001zU-Bj for nfsv4@ietf.org; Fri, 19 Oct 2007 13:46:27 -0400 Received: by nz-out-0506.google.com with SMTP id n1so104981nzf for ; Fri, 19 Oct 2007 10:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=qAQQ4aR3aLCeal6zaizROL8kYnkGl0rDeghYnwus5rw=; b=m18an/XDwSSHDtrJdwHfr8Ko/p9JxANowimhPUTBMW4S+c+I6dohgzFNS8/2GVWnQ7CgS20vNIWY5fA0Tq6h9mOrWb6JMEjXtiz9qDmDhJGMb/+838PEJMo7q7rXmxugDwWuBsYRGUBONupKR5KpB3WpWMjuTtP2Jxme0fYvtMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=d63GmUE6jG7Bdf46mEBc9JW5ymIQo/ZfGyuHd3sFNZHt9mNUsfSA92WsZpl6w09oTkiisEI32ZEyFR6v4dV9fwWSUp41cd4fIlamZYEiriEYTmcWTTBY9tiTQ3Z4mZshRajkbryI/CEr6x44eERyyX7lmJxWAi+hnj6MPOElKVo= Received: by 10.114.170.1 with SMTP id s1mr2345444wae.1192815949388; Fri, 19 Oct 2007 10:45:49 -0700 (PDT) Received: by 10.114.78.14 with HTTP; Fri, 19 Oct 2007 10:45:49 -0700 (PDT) Message-ID: Date: Fri, 19 Oct 2007 10:45:49 -0700 From: "dean hildebrand" To: "Robert Gordon" Subject: Re: [nfsv4] Question on file layout! In-Reply-To: <5B1FBA87-9E4B-4AA9-9716-AC1817691C6B@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <218707.38541.qm@web38109.mail.mud.yahoo.com> <89c397150710191007m5d5f8306s1f1fe6ad3bdbcd32@mail.gmail.com> <5B1FBA87-9E4B-4AA9-9716-AC1817691C6B@Sun.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: email2mre-ietf@yahoo.com, "William A. Adamson" , Suchit Kaura , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On 10/19/07, Robert Gordon wrote: > > On Oct 19, 2007, at 12:07 PM, William A. (Andy) Adamson wrote: > > > On 10/19/07, Mike Eisler wrote: > >> > >> > >> --- Suchit Kaura wrote: > >> > >>> I have been reading the spec and on page 272: > >>> > >>> > >> http://tools.ietf.org/html/draft-ietf-nfsv4- > >> minorversion1-13#section-14 > >>> > >>> > >>> The following are very confusing if not inconsistent, I would really > >>> appreciate your taking a few moments to look through and explain the > >>> same: > >> > >> Suchit, > >> > >> You are absolutely correct: it is inconsistent and confusing. > >> > >> The problem is that stripe_count is being defined two ways: > >> > >> - the length of index array > >> - the length data server array > >> > >> The former is the correct definition. The *correct* yet abstract definition is on page 276: Stripe Count. A stripe count is the number of stripe units in a pattern. To me, this means that the stripe count is the number of data servers in a pattern where each data server can appear multiple times. The i.e. part of the following line is wrong and should be either removed or changed to indicate indices list. * The stripe count, i.e. the number of elements as nflda_multipath_ds_list. > > > > isn't it requried that the length of the index array = length of the > > dataserver array = length of nfl_fh_list (if nfl_fh_list is not 0 > > or 1)? So I would say no, the index array creates the repeatable pattern which may have each data server listed multiple times, e.g., {2, 0, 1, 0}. But this raises an interesting question of whether the size(index array) must be >= size(data server array) I would say no, I don't see why it should have to use all of the devices. Dean > > > > -->Andy > > That's certainly what i understood. > > Robert. > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Oct 19 21:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij37U-0000t0-Q6; Fri, 19 Oct 2007 21:27:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij37S-0000nq-R3 for nfsv4@ietf.org; Fri, 19 Oct 2007 21:27:14 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij37Q-0004YV-SV for nfsv4@ietf.org; Fri, 19 Oct 2007 21:27:14 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9K1RCpg009596 for ; Sat, 20 Oct 2007 01:27:12 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ600F01RVMX100@mail-amer.sun.com> (original mail from Lisa.Week@Sun.COM) for nfsv4@ietf.org; Fri, 19 Oct 2007 19:27:12 -0600 (MDT) Received: from [192.168.1.101] ([129.150.32.118]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ600FD2S1A0R00@mail-amer.sun.com>; Fri, 19 Oct 2007 19:27:11 -0600 (MDT) Date: Fri, 19 Oct 2007 19:27:09 -0600 From: Lisa Week Subject: Re: [nfsv4] Question on file layout! In-reply-to: <799415.54459.qm@web38112.mail.mud.yahoo.com> To: email2mre-ietf@yahoo.com Message-id: <41D2D297-C501-4353-955B-3EA4DF2A1ED1@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) References: <799415.54459.qm@web38112.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08156cf414e01129f6a937203576bf20 Cc: "William A. \(Andy\) Adamson" , Suchit Kaura , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1637222799==" Errors-To: nfsv4-bounces@ietf.org --===============1637222799== Content-type: multipart/alternative; boundary="Boundary_(ID_/Vu1iknSZSWdHvrslsWzvg)" --Boundary_(ID_/Vu1iknSZSWdHvrslsWzvg) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT On Oct 19, 2007, at 11:37 AM, Mike Eisler wrote: > > --- "William A. (Andy) Adamson" wrote: > >> On 10/19/07, Mike Eisler wrote: > >>> You are absolutely correct: it is inconsistent and confusing. >>> >>> The problem is that stripe_count is being defined two ways: >>> >>> - the length of index array >>> - the length data server array >>> >>> The former is the correct definition. >> >> >> isn't it requried that the length of the index array = length of the >> dataserver array = length of nfl_fh_list (if nfl_fh_list is not 0 or >> 1)? > > No. If it were, there would be no point in having a separate index > array > and data server array. Actually there would be no point in > having an index array at all. Keep in mind the index and ds > arrays are in the same data structure: the device address. > > It is certainly RECOMMENDED that the index array be at least as long > as the data server array. Otherwise the data address has ds addresses > that will never be accessed, and this would be wasteful. > > http://www1.ietf.org/mail-archive/web/nfsv4/current/msg04360.html > > In the link you see an example that shows the index and ds array's > of different length. The same example that is in the I-D now, which > Suchit reproduced. > > There is even a spreadsheet in that email that encodes the algorithm. > If Excel can do it, pNFS servers can do it. > Hi, (I apologize in advance for being so long winded...) One thing that has been confusing to me (and I have just noticed this now after studying it harder) is that the example in "Section 14.4 - Interpreting the File Layout" of Draft 14 (http://www.nfsv4- editor.org/draft-14/draft-ietf-nfsv4- minorversion1-14.html#file_layout_interpret) just implicitly assumes we are using SPARSE packing. Actually, there would be some bad side effects if it were using DENSE packing in that situation. That is as follows: The following table is from Section 14.4 of Draft 14 - If the example was using DENSE packing we'd be trashing SU1 with SU3 data (or vice versa), SU5 with SU7 data (or vice versa) and so on... Because we are using the same file handle for multiple stripe units on the same data servers. +-----+------------+--------------+ | SUi | filehandle | data servers | +-----+------------+--------------+ | 0 | 87 | E | | 1 | 36 | A,B,C,D | | 2 | 67 | F,G | | 3 | 36 | A,B,C,D | | 4 | 87 | E | | 5 | 36 | A,B,C,D | | 6 | 67 | F,G | | 7 | 36 | A,B,C,D | | 8 | 87 | E | | 9 | 36 | A,B,C,D | | 10 | 67 | F,G | | 11 | 36 | A,B,C,D | | 12 | 87 | E | +-----+------------+--------------+ I explain more about some of the subtleties of this assumption and of SPARSE vs. DENSE packing below... ---- Further, in Draft-11 (this was prior to the new layout structures being introduced) we had the following text: (Quoted from draft 11, section 13.4) "A data server that has more than one stripe unit of a pattern to store each unit may store those stripes in different files, but to do so, will need unique filehandles in the data server list, as the previous example showed. While data servers may be repeated multiple times within the flattened data server list, if a STRIPE4_DENSE stripe type is used (see Section 13.5 (Sparse and Dense Stripe Unit Packing)), the same filehandle MUST NOT be used on the same data server for different stripe units of the same file. A data file stored on a data server MUST map to a single file as defined by the metadata server; i.e., data from two files as viewed by the metadata server MUST NOT be stored within the same data file on any data server." ------- The important part of that text is "if a STRIPE4_DENSE stripe type is used (see Section 13.5 (Sparse and Dense Stripe Unit Packing)), the same filehandle MUST NOT be used on the same data server for different stripe units of the same file." This text appears to have been removed in draft-12 and later. I don't recall if there was an explicit decision that this text/ requirement ("if a STRIPE4_DENSE stripe type is used, the same filehandle MUST NOT be used on the same data server for different stripe units of the same file.") should be removed. Mike (or anyone else), do you remember? Anyway... it is not so much the text being removed that I am worried about. I am more worried about requirements it used to put on the layout structures. That text effectively required us to be able to assign a different file handle to each stripe unit of a file's striping pattern. Most importantly, if a file's striping pattern defines there to be multiple different stripe units stored on the same data server we need the capability to use unique file handles to access each stripe unit. With the current layout structure (in Draft-14) I believe we have lost that capability. Another way to say it is: I interpret the lines 15651 - 15666 (as quoted from Draft-14) to mean that from a single data server's point of view, all stripe units in a single file's striping pattern stored on that data server will be accessed with the same file handle. 15651 4. nfl_fh_list. An array of data server filehandles for each list 15652 of data servers in each element of the nflda_multipath_ds_list 15653 array. The number of elements in nfl_fh_list MUST be of three 15654 values: 15655 15656 * Zero. This means that filehandles used for each data server 15657 are the same as the filehandle returned by the OPEN operation 15658 from the metadata server. 15659 15660 * One. This means that every data server uses the same 15661 filehandle: what is specified in nfl_fh_list[0]. 15662 15663 * The stripe count, i.e. the number of elements as 15664 nflda_multipath_ds_list. When issuing an I/O to any data 15665 server in nfla_multipath_ds_list[X], the filehandle in 15666 nfl_fh_list[X] MUST be used. Therefore, you can't have a repeated value in the nflda_stripe_indicies list (e.g. nflda_stripe_indicies = {2, 0, 1, 0}) if you are using DENSE packing. Thanks, Lisa > >> >> -->Andy >> >> Thus the valid values for the length of nfl_fh_list >>> are zero, one, or the length of nflda_multipath_ds_list. >>> >>> I will fix this now. > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 --Boundary_(ID_/Vu1iknSZSWdHvrslsWzvg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE
On Oct 19, 2007= , at 11:37 AM, Mike Eisler wrote:


--- "William A. (Andy) Adamson" = <andros@citi.umich.edu> wrote:

<= BLOCKQUOTE type=3D"cite">

You are absolutely correct: it is inconsiste= nt and confusing.

The problem is that stripe_count is being def= ined two ways:

=
- the length of index array
- the length data server array

The former is the correct = definition.


isn't it requried that the length of the index array = =3D length of the
dataserver array =3D leng= th of nfl_fh_list (if nfl_fh_list is not 0 or

=
No. If it were, there would be no point in= having a separate index
array
and data server array. Actually there would be no point= in=A0
having an index array at all. Keep in mind the index and d= s
arrays are in the same data structure: th= e device address.

It is certainly RECOMMENDED that the index ar= ray be at least as long
as the data server = array. Otherwise the data address has ds addresses
that will never be accessed, and this would be wasteful.


=
In the link you see an example that shows the in= dex and ds array's
of different length. The= same example that is in the I-D now, which
Suchit reproduced.

<= /DIV>
There is even a spreadsheet in that email t= hat encodes the algorithm.
If Excel can do = it, pNFS servers can do it.
=
Hi,

=
(I apologize in advance for being so long winded...)
<= BR class=3D"khtml-block-placeholder">
One thing that has be= en confusing to me (and I have just noticed this now after studying i= t harder) is that=A0the example in "Section=A014.4 -=A0Interpreting t= he File Layout" of Draft 14 (http://www.nfsv4-editor.org/draft-14/draft-ietf-nfsv4-minorversion1-= 14.html#file_layout_interpret) just implicitly assumes we are usi= ng SPARSE packing.=A0 Actually, there would be some bad side effects = if it were using DENSE packing in that situation.=A0 That is as follo= ws:

<= /DIV>
The following table is from Section 14.4 of= Draft 14 - If the example was using DENSE packing we'd be trashing S= U1 with SU3 data (or vice versa), SU5 with SU7 data (or vice versa) a= nd so on...=A0 Because we are using the same file handle for multiple= stripe units on the same data servers.
=A0 =A0 =A0=A0 =A0= =A0 =A0=A0 =A0=A0 =A0=A0 =A0+-----+------------+--------------+
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | SUi | filehandle | data server= s |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +-----+--------= ----+--------------+
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | 0 =A0 = | 87 = =A0 =A0 =A0 =A0 | E=A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | 1 =A0 = | 36 = =A0 =A0 =A0 =A0 | A,B,C,D=A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | 2 = =A0 | 67= =A0 = =A0 =A0 =A0 | F,G=A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | 3 = =A0 | 36= =A0 = =A0 =A0 =A0 | A,B,C,D=A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 | 4 = =A0 | 87 = =A0 =A0 =A0 = =A0 | E<= /FONT>=A0 =A0 = =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <= /FONT>| 5 =A0 | 36 =A0 =A0 =A0 =A0 | A,B,C,D=A0 =A0 = =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 6 =A0 | 67 =A0 =A0 =A0 =A0 | F,G=A0 =A0 =A0 =A0 =A0 <= /FONT>|<= /DIV>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 7 =A0 | 36 =A0 =A0 =A0 =A0 | A,B,C,D=A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 8 =A0 | 87 =A0 =A0 =A0 =A0 | E=A0 =A0 =A0 =A0 =A0 = =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 9 =A0 | 36 =A0 =A0 =A0 =A0 | A,B,C,D=A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 10=A0 | 67 =A0 =A0 =A0 =A0 | F,G=A0 =A0 =A0 =A0 =A0 <= /FONT>|<= /DIV>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 11=A0 | 36 =A0 =A0 =A0 =A0 | A,B,C,D=A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 12=A0 | 87 =A0 =A0 =A0 =A0 | E=A0 =A0 =A0 =A0 =A0 = =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-----+------------+= --------------+

I explain more about some of the subtleties of this assu= mption and of SPARSE vs. DENSE packing below...

----

Further, in Draft-11 (this was pri= or to the new layout structures being introduced) we had the followin= g text:
(Quoted from draft 11, section 13.4)
"A data server that has more than one stripe unit of a pa= ttern to store each unit may store those stripes in different files, = but to do so, will need unique filehandles in the data server list, a= s the previous example showed. While data servers may be repeated mul= tiple times within the flattened data server list, if a STRIPE4_DENSE= stripe type is used (see Section 13.5 (Sparse and Dense Stripe Unit = Packing)), the same filehandle MUST NOT be used on the same data serv= er for different stripe units of the same file.

A data file stored on a data serve= r MUST map to a single file as defined by the metadata server; i.e., = data from two files as viewed by the metadata server MUST NOT be stor= ed within the same data file on any data server."

-------

The important part of that t= ext is "if a STRIPE4_DENSE stripe type is used (see Section 13.5 (Spa= rse and Dense Stripe Unit Packing)), the same filehandle MUST NOT be = used on the same data server for different stripe units of the same f= ile."

This text appears to have been removed in= draft-12 and later.

I don't recall if there wa= s an explicit decision that this text/requirement ("if a STRIPE4_DENS= E stripe type is used, the same filehandle MUST NOT be used on the sa= me data server for different stripe units of the same file.") should = be removed.=A0 Mike (or anyone else), do you remember?

Anyway... it is not so much the text being removed that I = am worried about.=A0 I am more worried about requirements it used to = put on the layout structures.=A0 That text effectively required us to= be able to assign a different file handle to each stripe unit of a f= ile's striping pattern.=A0 Most importantly, if a file's striping pat= tern defines there to be multiple different stripe units stored on th= e same data server we need the capability to use unique file handles = to access each stripe unit.

With the current la= yout structure (in Draft-14) I believe we have lost that capability.= =A0=A0

Another way to say it is:
I interpret the lines 15651 - 15666 (as quoted from Draft= -14) to mean that from a single data server's point of view, all stri= pe units in a single file's striping pattern stored on that data serv= er will be accessed with the same file handle.

= =A015651= =09 =A0 4.=A0 nfl_fh_list.=A0 An array of data server filehand= les for each list
=A015652=09 =A0 =A0 =A0 of dat= a servers in each element of the nflda_multipath_ds_list
=A015653=09 =A0 =A0 =A0 array.=A0 The number of elements in = nfl_fh_list MUST be of three
=A015654=09 =A0 = =A0 =A0 values:
=A015655=09
=A015656=09 =A0 =A0 =A0 *=A0 Zero.=A0 This means that filehandles us= ed for each data server
=A015657=09=A0 =A0 =A0 = =A0 =A0 are the same as the filehandle returned by the OPEN operation=
=A015658=09=A0 =A0 =A0 =A0 =A0 from the metadat= a server.
=A015659
= =09 =A0 =A0 =A0 *=A0 One. This means that every data server us= es the same
=A015661=09=A0 =A0 =A0 =A0 =A0 fileh= andle: what is specified in nfl_fh_list[0].
=A015662= =09
=A015663=09 =A0 =A0 =A0 *=A0 The stri= pe count, i.e. the number of elements as
= =A015664= =09=A0 =A0 =A0 =A0 =A0 nflda_multipath_ds_list.=A0 When issuin= g an I/O to any data
=A015665=09=A0 =A0 =A0 = =A0 =A0 server in nfla_multipath_ds_list[X], the filehandle in
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">=A015666=09=A0 =A0 =A0 =A0 =A0 nfl_fh_list[X] MUST be = used.


Therefore, you can't have a repeated value in= the nflda_stripe_indicies list (e.g. nflda_stripe_indicies =3D {2, 0= , 1, 0}) if you are using DENSE packing.
Thanks= ,
Lisa

<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; min-height: 14px; ">


-->Andy
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; min-height: 14px; ">
= Thus the valid values for the length of nfl_fh_list
are zero, one, or the length of n= flda_multipath_ds_list.
<= BR>
I will fix this now.


_____= __________________________________________
= nfsv4 mailing list

--Boundary_(ID_/Vu1iknSZSWdHvrslsWzvg)-- --===============1637222799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1637222799==-- From ABRAHAM.innocent@medacnj.com Fri Oct 19 22:45:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij4Ku-0001MH-Cr for nfsv4-archive@lists.ietf.org; Fri, 19 Oct 2007 22:45:12 -0400 Received: from [122.32.190.162] (helo=[122.32.190.162]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij4Kt-0006S5-Oj for nfsv4-archive@lists.ietf.org; Fri, 19 Oct 2007 22:45:12 -0400 Received: by 10.199.38.190 with SMTP id LtmigADmBPkxd; Sat, 20 Oct 2007 11:45:59 +0900 (GMT) Received: by 192.168.223.45 with SMTP id NLeQyLFtiSKtbN.6134736869288; Sat, 20 Oct 2007 11:45:57 +0900 (GMT) Message-ID: <000301c812c3$555add00$a2be207a@mywindows> From: "ABRAHAM innocent" To: nfsv4-archive@lists.ietf.org Subject: feisnetn Date: Sat, 20 Oct 2007 11:45:54 +0900 Message-ID: <000301c812c3$555add00$a2be207a@mywindows> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hello Baby nfsv4-archive you can bump ugly all night when you take virility pills http://www.kekeres.com/ ABRAHAM innocent From nfsv4-bounces@ietf.org Sat Oct 20 00:43:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij68r-0006IW-Po; Sat, 20 Oct 2007 00:40:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij68q-0006IQ-3l for nfsv4@ietf.org; Sat, 20 Oct 2007 00:40:52 -0400 Received: from web38110.mail.mud.yahoo.com ([209.191.124.137]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ij68j-0008PU-S9 for nfsv4@ietf.org; Sat, 20 Oct 2007 00:40:52 -0400 Received: (qmail 23153 invoked by uid 60001); 20 Oct 2007 04:40:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=hiZAIdiuDove0n/MCWgON+5WJ25UFkIj+iqZbMWyV2Kk4NyMlRgK4Ji+c17pyLI59xjABZKFtzCuCsYBVSn+vb/JTwC2QQXlYA66Ddax2CZ4se4RAIFhQkSeYMXg4Uae5Vx+WwY7tg2/xOA5k5kbEIaW3h+9CGzmfp9dZ6+M8ak=; X-YMail-OSG: cbzuhJUVM1nHUw5ngjwRlDOyFKktnjxJuMDOf7HHZxeDvFLI4CclSnV20t8VjT.mynd6ew-- Received: from [198.95.226.230] by web38110.mail.mud.yahoo.com via HTTP; Fri, 19 Oct 2007 21:40:36 PDT Date: Fri, 19 Oct 2007 21:40:36 -0700 (PDT) From: Mike Eisler Subject: Re: [nfsv4] Question on file layout! To: Lisa Week In-Reply-To: <41D2D297-C501-4353-955B-3EA4DF2A1ED1@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <319506.22406.qm@web38110.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Lisa Week wrote: > The following table is from Section 14.4 of Draft 14 - If the example > > was using DENSE packing we'd be trashing SU1 with SU3 data (or vice > versa), SU5 with SU7 data (or vice versa) and so on... Because we > are using the same file handle for multiple stripe units on the same > > data servers. > > +-----+------------+--------------+ > | SUi | filehandle | data servers | > +-----+------------+--------------+ > | 0 | 87 | E | > | 1 | 36 | A,B,C,D | > | 2 | 67 | F,G | > | 3 | 36 | A,B,C,D | Yes, you are correct, this is broken. [...] > The important part of that text is "if a STRIPE4_DENSE stripe type is > > used (see Section 13.5 (Sparse and Dense Stripe Unit Packing)), the > same filehandle MUST NOT be used on the same data server for > different stripe units of the same file." > > This text appears to have been removed in draft-12 and later. > > I don't recall if there was an explicit decision that this text/ > requirement ("if a STRIPE4_DENSE stripe type is used, the same > filehandle MUST NOT be used on the same data server for different > stripe units of the same file.") should be removed. Mike (or anyone > else), do you remember? I don't recall such an explicit decision. Without looking at earlier drafts, I suspect it got wiped out as part of the SIMPLE/COMPLEX purge. > > Anyway... it is not so much the text being removed that I am worried > > about. I am more worried about requirements it used to put on the > layout structures. That text effectively required us to be able to > assign a different file handle to each stripe unit of a file's > striping pattern. Most importantly, if a file's striping pattern > defines there to be multiple different stripe units stored on the > same data server we need the capability to use unique file handles to > > access each stripe unit. > > With the current layout structure (in Draft-14) I believe we have > lost that capability. Agreed. I think this may account for the inconsistency Suchit discovered. So what to do? The simplest is to re-define nfl_fh_list to be the same length as nflda_stripe_indices and have nfl_fh_list[X] correspond to nflda_stripe_indices[X]. However, for SPARSE packing, combined with long index arrays, this makes layouts not very economical. So I think what we want is for SPARSE packing, state that fh list to corresponds to the ds list (same number of elements as the ds list, one element, or zero elements in the fh list as in draft -14), and for DENSE packing state that the fh list must be the same length as the index array, and fh list[X] corresponds to indices[X]. The algorithm for determining the file handle in the DENSE packing case is thus: stripe_count = number of elements in nflda_stripe_indices; fh_idx = ( SUi + nfl_first_stripe_index ) % stripe_count; fh = nfl_fh_list[fh_idx]; For dense packing, we use the same example, with the same index and data server arrays, but change the fh list from, 36 87 67 to, 67 37 87 36 The result is: SUi fh data servers 0 87 E 1 36 A,B,C,D 2 67 F,G 3 37 A,B,C,D 4 87 E 5 36 A,B,C,D 6 67 F,G 7 37 A,B,C,D 8 87 E 9 36 A,B,C,D 10 67 F,G 11 37 A,B,C,D 12 87 E _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sat Oct 20 01:25:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij6pM-00079V-4R; Sat, 20 Oct 2007 01:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij6pJ-00077N-K8 for nfsv4@ietf.org; Sat, 20 Oct 2007 01:24:45 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij6p7-00018m-Jq for nfsv4@ietf.org; Sat, 20 Oct 2007 01:24:42 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9K5NWN1008095 for ; Sat, 20 Oct 2007 05:23:32 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ7006012UYZV00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Fri, 19 Oct 2007 23:23:32 -0600 (MDT) Received: from [10.1.194.250] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ700DHW2Z89E80@mail-amer.sun.com>; Fri, 19 Oct 2007 23:23:32 -0600 (MDT) Date: Sat, 20 Oct 2007 00:23:29 -0500 From: Robert Gordon Subject: Re: [nfsv4] Question on file layout! In-reply-to: <319506.22406.qm@web38110.mail.mud.yahoo.com> To: email2mre-ietf@yahoo.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <319506.22406.qm@web38110.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 19, 2007, at 11:40 PM, Mike Eisler wrote: > So I think what we want is for SPARSE packing, > state that fh list to corresponds to the ds list > (same number of elements as the ds list, one element, or > zero elements in the fh list as in draft -14), and for > DENSE packing state that the fh list must be the same > length as the index array, and fh list[X] corresponds to indices[X]. yes. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sat Oct 20 02:09:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij7Ub-0000za-7Y; Sat, 20 Oct 2007 02:07:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij7UZ-0000kk-QE for nfsv4@ietf.org; Sat, 20 Oct 2007 02:07:23 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij7U3-0004AJ-Oc for nfsv4@ietf.org; Sat, 20 Oct 2007 02:06:52 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9K66lJP013297 for ; Sat, 20 Oct 2007 06:06:47 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ700E014R1JO00@mail-amer.sun.com> (original mail from Lisa.Week@Sun.COM) for nfsv4@ietf.org; Sat, 20 Oct 2007 00:06:47 -0600 (MDT) Received: from [192.168.1.101] ([129.150.32.118]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ700DKH4ZAVU00@mail-amer.sun.com>; Sat, 20 Oct 2007 00:06:47 -0600 (MDT) Date: Sat, 20 Oct 2007 00:06:45 -0600 From: Lisa Week Subject: Re: [nfsv4] Question on file layout! In-reply-to: <319506.22406.qm@web38110.mail.mud.yahoo.com> To: email2mre-ietf@yahoo.com Message-id: <9EEE37F4-E464-457E-8471-62A316972801@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <319506.22406.qm@web38110.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 19, 2007, at 10:40 PM, Mike Eisler wrote: > > --- Lisa Week wrote: > > >> The following table is from Section 14.4 of Draft 14 - If the example >> >> was using DENSE packing we'd be trashing SU1 with SU3 data (or vice >> versa), SU5 with SU7 data (or vice versa) and so on... Because we >> are using the same file handle for multiple stripe units on the same >> >> data servers. >> >> +-----+------------+--------------+ >> | SUi | filehandle | data servers | >> +-----+------------+--------------+ >> | 0 | 87 | E | >> | 1 | 36 | A,B,C,D | >> | 2 | 67 | F,G | >> | 3 | 36 | A,B,C,D | > > Yes, you are correct, this is broken. > > [...] >> The important part of that text is "if a STRIPE4_DENSE stripe type is >> >> used (see Section 13.5 (Sparse and Dense Stripe Unit Packing)), the >> same filehandle MUST NOT be used on the same data server for >> different stripe units of the same file." >> >> This text appears to have been removed in draft-12 and later. >> >> I don't recall if there was an explicit decision that this text/ >> requirement ("if a STRIPE4_DENSE stripe type is used, the same >> filehandle MUST NOT be used on the same data server for different >> stripe units of the same file.") should be removed. Mike (or anyone > >> else), do you remember? > > I don't recall such an explicit decision. Without looking at earlier > drafts, I suspect it got wiped out as part of the SIMPLE/COMPLEX > purge. Okay. That is kind of what I expected. It seems like this text is important enough to put back in. > >> >> Anyway... it is not so much the text being removed that I am worried >> >> about. I am more worried about requirements it used to put on the >> layout structures. That text effectively required us to be able to >> assign a different file handle to each stripe unit of a file's >> striping pattern. Most importantly, if a file's striping pattern >> defines there to be multiple different stripe units stored on the >> same data server we need the capability to use unique file handles to >> >> access each stripe unit. >> >> With the current layout structure (in Draft-14) I believe we have >> lost that capability. > > Agreed. I think this may account for the inconsistency Suchit > discovered. > > So what to do? > > The simplest is to re-define nfl_fh_list to be the > same length as nflda_stripe_indices and have nfl_fh_list[X] > correspond to nflda_stripe_indices[X]. > > However, for SPARSE packing, combined with long index arrays, > this makes layouts not very economical. > > So I think what we want is for SPARSE packing, > state that fh list to corresponds to the ds list > (same number of elements as the ds list, one element, or > zero elements in the fh list as in draft -14), and for > DENSE packing state that the fh list must be the same > length as the index array, and fh list[X] corresponds to indices[X]. > > The algorithm for determining the file handle in the DENSE packing > case is thus: > > stripe_count = number of elements in nflda_stripe_indices; > > fh_idx = > ( SUi + nfl_first_stripe_index ) % stripe_count; > > fh = nfl_fh_list[fh_idx]; > > For dense packing, we use the same example, with the same > index and data server arrays, but change the fh list from, > > 36 87 67 > to, > > 67 37 87 36 > > The result is: > > SUi fh data servers > 0 87 E > 1 36 A,B,C,D > 2 67 F,G > 3 37 A,B,C,D > 4 87 E > 5 36 A,B,C,D > 6 67 F,G > 7 37 A,B,C,D > 8 87 E > 9 36 A,B,C,D > 10 67 F,G > 11 37 A,B,C,D > 12 87 E Yes, I think this is a good solution. Thanks, Lisa _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From JohnathonsuccubusMorse@acquisitionp2p.com Sat Oct 20 04:12:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij9S2-0006CE-8f for nfsv4-archive@lists.ietf.org; Sat, 20 Oct 2007 04:12:54 -0400 Received: from 82-47-133-139.cable.ubr09.brad.blueyonder.co.uk ([82.47.133.139] helo=latiffamily) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ij9S1-00088O-D3 for nfsv4-archive@lists.ietf.org; Sat, 20 Oct 2007 04:12:54 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host51817850.acquisitionp2p.com (8.13.1/8.13.1) with SMTP id XLTftOV421.940076.DJD.w1p.5904648472731 for ; Sat, 20 Oct 2007 09:12:34 +0000 Message-ID: <13edd901c812f1$03ccc970$8b852f52@latiffamily> From: "Art Chen" To: Subject: Your order Date: Sat, 20 Oct 2007 09:12:34 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_13EDD5_01C812F1.03CCC970" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_13EDD5_01C812F1.03CCC970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_13EDD5_01C812F1.03CCC970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_13EDD5_01C812F1.03CCC970-- From nfsv4-bounces@ietf.org Sat Oct 20 09:41:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjEXs-0005bJ-S7; Sat, 20 Oct 2007 09:39:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjEXr-0005YH-NA for nfsv4@ietf.org; Sat, 20 Oct 2007 09:39:16 -0400 Received: from p01c11o144.mxlogic.net ([208.65.144.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjEXe-0000nV-8a for nfsv4@ietf.org; Sat, 20 Oct 2007 09:39:04 -0400 Received: from unknown [63.110.244.103] (EHLO p01c11o144.mxlogic.net) by p01c11o144.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id 6f40a174.2697046960.13382.00-500.p01c11o144.mxlogic.net (envelope-from ); Sat, 20 Oct 2007 07:39:02 -0600 (MDT) Received: from unknown [63.110.244.103] (EHLO us-email.terastack.bluearc.com) by p01c11o144.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id 0f40a174.2455780272.13378.00-004.p01c11o144.mxlogic.net (envelope-from ); Sat, 20 Oct 2007 07:38:56 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [nfsv4] Question on file layout! Date: Sat, 20 Oct 2007 06:38:54 -0700 Message-ID: In-Reply-To: <41D2D297-C501-4353-955B-3EA4DF2A1ED1@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Question on file layout! Thread-Index: AcgSuFfSiIEymGx9RSycPoJNoFX14AAY2CMA References: <799415.54459.qm@web38112.mail.mud.yahoo.com> <41D2D297-C501-4353-955B-3EA4DF2A1ED1@sun.com> From: "Suchit Kaura" To: , X-Spam: [F=0.0100000000; S=0.010(2007101601); SS=0.500] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34474d0466a434d4c6281ffb0db1cdfa Cc: "William A. \(Andy\) Adamson" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1534492979==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============1534492979== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8131E.8F39F0C9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8131E.8F39F0C9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 First, I would like to thank everybody for the responses. The clarifications help a lot. =20 I definitely agree with Lisa about the dense layout issue, in fact the formula supplied in the example would not work=20 The following was supposed to be the last part of the email. --------- The formula for the dense layout is incorrect/inconsistent too as it we will soon start overwriting the data in fh =3D 0x36 for ... The calculation to determine the octet offset within the data file for dense data server layouts is: stripe_width =3D stripe_unit_size * N; where N =3D number of elements in nflda_stripe_indices. data_file_offset =3D floor(file_offset / stripe_width) * stripe_unit_size + file_offset % stripe_unit_size ------------- In general I would like to ask a question about whether we allow the flexibility to have a different non overlapping patterns within the same file.=20 Thus, conceptually do we imagine a layout having a pattern from let's say starting offset in user file O till a length L.=20 Can the file then have a different pattern from offset O1 till a length L1 ?=20 I was on vacation yesterday hence the delay in responding. Once again thanks a lot ... Regards, Suchit ________________________________ From: Lisa.Week@Sun.COM [mailto:Lisa.Week@Sun.COM]=20 Sent: Friday, October 19, 2007 6:27 PM To: email2mre-ietf@yahoo.com Cc: William A. (Andy) Adamson; Suchit Kaura; nfsv4@ietf.org Subject: Re: [nfsv4] Question on file layout! On Oct 19, 2007, at 11:37 AM, Mike Eisler wrote: =09 =09 --- "William A. (Andy) Adamson" wrote: =09 =09 On 10/19/07, Mike Eisler wrote: =09 =09 You are absolutely correct: it is inconsistent and confusing. =09 =09 The problem is that stripe_count is being defined two ways: =09 =09 - the length of index array - the length data server array =09 =09 The former is the correct definition. =09 =09 =09 =09 isn't it requried that the length of the index array =3D length of the dataserver array =3D length of nfl_fh_list (if nfl_fh_list is not 0 or 1)? =09 =09 No. If it were, there would be no point in having a separate index array and data server array. Actually there would be no point in=20 having an index array at all. Keep in mind the index and ds arrays are in the same data structure: the device address. =09 =09 It is certainly RECOMMENDED that the index array be at least as long as the data server array. Otherwise the data address has ds addresses that will never be accessed, and this would be wasteful. =09 =09 =09 http://www1.ietf.org/mail-archive/web/nfsv4/current/msg04360.html =09 =09 In the link you see an example that shows the index and ds array's of different length. The same example that is in the I-D now, which Suchit reproduced. =09 =09 There is even a spreadsheet in that email that encodes the algorithm. If Excel can do it, pNFS servers can do it. =09 =09 Hi, (I apologize in advance for being so long winded...) One thing that has been confusing to me (and I have just noticed this now after studying it harder) is that the example in "Section 14.4 - Interpreting the File Layout" of Draft 14 (http://www.nfsv4-editor.org/draft-14/draft-ietf-nfsv4-minorversion1-14. html#file_layout_interpret) just implicitly assumes we are using SPARSE packing. Actually, there would be some bad side effects if it were using DENSE packing in that situation. That is as follows: The following table is from Section 14.4 of Draft 14 - If the example was using DENSE packing we'd be trashing SU1 with SU3 data (or vice versa), SU5 with SU7 data (or vice versa) and so on... Because we are using the same file handle for multiple stripe units on the same data servers. +-----+------------+--------------+ | SUi | filehandle | data servers | +-----+------------+--------------+ | 0 | 87 | E | | 1 | 36 | A,B,C,D | | 2 | 67 | F,G | | 3 | 36 | A,B,C,D | | 4 | 87 | E | | 5 | 36 | A,B,C,D | | 6 | 67 | F,G | | 7 | 36 | A,B,C,D | | 8 | 87 | E | | 9 | 36 | A,B,C,D | | 10 | 67 | F,G | | 11 | 36 | A,B,C,D | | 12 | 87 | E | +-----+------------+--------------+ I explain more about some of the subtleties of this assumption and of SPARSE vs. DENSE packing below... ---- Further, in Draft-11 (this was prior to the new layout structures being introduced) we had the following text: (Quoted from draft 11, section 13.4) "A data server that has more than one stripe unit of a pattern to store each unit may store those stripes in different files, but to do so, will need unique filehandles in the data server list, as the previous example showed. While data servers may be repeated multiple times within the flattened data server list, if a STRIPE4_DENSE stripe type is used (see Section 13.5 (Sparse and Dense Stripe Unit Packing)), the same filehandle MUST NOT be used on the same data server for different stripe units of the same file. A data file stored on a data server MUST map to a single file as defined by the metadata server; i.e., data from two files as viewed by the metadata server MUST NOT be stored within the same data file on any data server." ------- The important part of that text is "if a STRIPE4_DENSE stripe type is used (see Section 13.5 (Sparse and Dense Stripe Unit Packing)), the same filehandle MUST NOT be used on the same data server for different stripe units of the same file." This text appears to have been removed in draft-12 and later. I don't recall if there was an explicit decision that this text/requirement ("if a STRIPE4_DENSE stripe type is used, the same filehandle MUST NOT be used on the same data server for different stripe units of the same file.") should be removed. Mike (or anyone else), do you remember? Anyway... it is not so much the text being removed that I am worried about. I am more worried about requirements it used to put on the layout structures. That text effectively required us to be able to assign a different file handle to each stripe unit of a file's striping pattern. Most importantly, if a file's striping pattern defines there to be multiple different stripe units stored on the same data server we need the capability to use unique file handles to access each stripe unit. With the current layout structure (in Draft-14) I believe we have lost that capability. =20 Another way to say it is: I interpret the lines 15651 - 15666 (as quoted from Draft-14) to mean that from a single data server's point of view, all stripe units in a single file's striping pattern stored on that data server will be accessed with the same file handle. 15651 4. nfl_fh_list. An array of data server filehandles for each list 15652 of data servers in each element of the nflda_multipath_ds_list 15653 array. The number of elements in nfl_fh_list MUST be of three 15654 values: 15655=20 15656 * Zero. This means that filehandles used for each data server 15657 are the same as the filehandle returned by the OPEN operation 15658 from the metadata server. 15659 15660 * One. This means that every data server uses the same 15661 filehandle: what is specified in nfl_fh_list[0]. 15662=20 15663 * The stripe count, i.e. the number of elements as 15664 nflda_multipath_ds_list. When issuing an I/O to any data 15665 server in nfla_multipath_ds_list[X], the filehandle in 15666 nfl_fh_list[X] MUST be used. Therefore, you can't have a repeated value in the nflda_stripe_indicies list (e.g. nflda_stripe_indicies =3D {2, 0, 1, 0}) if you are using = DENSE packing. Thanks, Lisa -->Andy Thus the valid values for the length of nfl_fh_list are zero, one, or the length of nflda_multipath_ds_list. I will fix this now. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 ------_=_NextPart_001_01C8131E.8F39F0C9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
First, I would like to thank everybody for the responses. The=20 clarifications help a lot.
 
I=20 definitely agree with Lisa about the dense layout issue, in fact the = formula=20 supplied in the example would not work

The following was supposed to be = the last=20 part of the email.

---------=

The formula for the dense = layout is=20 incorrect/inconsistent too as it = we will=20 soon start overwriting the data in fh =3D 0x36 for=20 ...

The calculation to = determine the=20 octet offset within the data file
   for dense data server = layouts=20 is:

      stripe_width =3D = stripe_unit_size *=20 N;
         where N =3D = number of=20 elements in nflda_stripe_indices.

     =20 data_file_offset =3D floor(file_offset /=20 stripe_width)
         *=20 stripe_unit_size
         +=20 file_offset % stripe_unit_size

-------------

In general I would like to ask a question = about whether=20 we allow the flexibility to have a different non overlapping patterns = within the=20 same file.

Thus, conceptually do we imagine a layout = having a=20 pattern from let's say starting offset in user file O till a length = L.=20

Can the file then have a different pattern = from offset=20 O1 till a length L1 ?

I was on vacation yesterday hence the delay = in=20 responding. Once again thanks a lot ...

Regards,

Suchit



From: Lisa.Week@Sun.COM=20 [mailto:Lisa.Week@Sun.COM]
Sent: Friday, October 19, 2007 = 6:27=20 PM
To: email2mre-ietf@yahoo.com
Cc: William A. = (Andy)=20 Adamson; Suchit Kaura; nfsv4@ietf.org
Subject: Re: [nfsv4] = Question on=20 file layout!


On Oct 19, 2007, at 11:37 AM, Mike Eisler wrote:

--- "William A. (Andy) Adamson" <andros@citi.umich.edu> = wrote:

On 10/19/07, Mike Eisler <email2mre-ietf@yahoo.com>= =20 wrote:

You are absolutely correct: it is = inconsistent=20 and confusing.

The problem is that stripe_count is = being defined=20 two ways:

- the length of index array
- the length data server array

The former is the correct=20 definition.


isn't it requried that the length of the = index=20 array =3D length of the
dataserver array =3D length of = nfl_fh_list (if=20 nfl_fh_list is not 0 or
1)?

No. If it were, there would be no point in = having a=20 separate index
array
and data server array. Actually there would = be no=20 point in 
having an index array at all. Keep in mind = the index=20 and ds
arrays are in the same data structure: the = device=20 address.

It is certainly RECOMMENDED that the index = array be=20 at least as long
as the data server array. Otherwise the = data address=20 has ds addresses
that will never be accessed, and this would = be=20 wasteful.

http://www1.ietf.org/mail-archive/web/nfsv4/current/msg04360.html

In the link you see an example that shows = the index=20 and ds array's
of different length. The same example that = is in the=20 I-D now, which
Suchit reproduced.

There is even a spreadsheet in that email = that=20 encodes the algorithm.
If Excel can do it, pNFS servers can do = it.


Hi,

(I apologize in advance for being so long winded...)

One thing that has been confusing to me (and I have just noticed = this now=20 after studying it harder) is that the example in "Section 14.4 = - Interpreting the File Layout" of Draft 14 (http://www.nfsv4-editor.org/draft-14/dr= aft-ietf-nfsv4-minorversion1-14.html#file_layout_interpret)=20 just implicitly assumes we are using SPARSE packing.  Actually, = there would=20 be some bad side effects if it were using DENSE packing in that = situation. =20 That is as follows:
The following table is from Section 14.4 of = Draft 14 -=20 If the example was using DENSE packing we'd be trashing SU1 with SU3 = data (or=20 vice versa), SU5 with SU7 data (or vice versa) and so on...  = Because we are=20 using the same file handle for multiple stripe units on the same data=20 servers.
 =20                 =20  +-----+------------+--------------+
 =20                   = | SUi | filehandle | data = servers=20 |
 =20                   = +-----+------------+--------------+
 =20                   = | 0   | 87       =  =20 | = E      =    =20   |
 =20                   = | 1   | 36       =  =20 | = A,B,C,D      = |
 =20                   = | 2   | 67       =  =20 | = F,G      =    =20 |
 =20                   = | 3   | 36       =  =20 | = A,B,C,D      = |
 =20                   = | 4   | 87       =  =20 | = E      =    =20   |
 =20                   = | 5   | 36       =  =20 | = A,B,C,D      = |
 =20                   = | 6   | 67       =  =20 | = F,G      =    =20 |
 =20                   = | 7   | 36       =  =20 | = A,B,C,D      = |
 =20                   = | 8   | 87       =  =20 | = E      =    =20   |
 =20                   = | 9   | 36       =  =20 | = A,B,C,D      = |
 =20                   = | 10  | 67       =  =20 | = F,G      =    =20 |
 =20                   = | 11  | 36       =  =20 | = A,B,C,D      = |
 =20                   = | 12  | 87       =  =20 | = E      =    =20   |
 =20                   = +-----+------------+--------------+

I explain more about some of the subtleties of this assumption and = of=20 SPARSE vs. DENSE packing below...

----

Further, in Draft-11 (this was prior to the new layout structures = being=20 introduced) we had the following text:
(Quoted from draft 11, section 13.4)
"A data server that has more than one stripe = unit of a=20 pattern to store each unit may store those stripes in different files, = but to do=20 so, will need unique filehandles in the data server list, as the = previous=20 example showed. While data servers may be repeated multiple times within = the=20 flattened data server list, if a STRIPE4_DENSE stripe type is used (see = Section=20 13.5 (Sparse and Dense Stripe Unit Packing)), the same filehandle MUST = NOT be=20 used on the same data server for different stripe units of the same = file.

A data file stored on a data server MUST map = to a=20 single file as defined by the metadata server; i.e., data from two files = as=20 viewed by the metadata server MUST NOT be stored within the same data = file on=20 any data server."
-------
The important part of that text is "if a = STRIPE4_DENSE=20 stripe type is used (see Section 13.5 (Sparse and Dense Stripe Unit = Packing)),=20 the same filehandle MUST NOT be used on the same data server for = different=20 stripe units of the same file."
This text appears to have been removed in = draft-12 and=20 later.
I don't recall if there was an explicit = decision that=20 this text/requirement ("if a STRIPE4_DENSE stripe type is used, the same = filehandle MUST NOT be used on the same data server for different stripe = units=20 of the same file.") should be removed.  Mike (or anyone else), do = you=20 remember?
Anyway... it is not so much the text being = removed that=20 I am worried about.  I am more worried about requirements it used = to put on=20 the layout structures.  That text effectively required us to be = able to=20 assign a different file handle to each stripe unit of a file's striping=20 pattern.  Most importantly, if a file's striping pattern defines = there to=20 be multiple different stripe units stored on the same data server we = need the=20 capability to use unique file handles to access each stripe unit.
With the current layout structure (in = Draft-14) I=20 believe we have lost that capability.  
Another way to say it is:
I interpret the lines 15651 - 15666 (as = quoted from=20 Draft-14) to mean that from a single data server's point of view, all = stripe=20 units in a single file's striping pattern stored on that data server = will be=20 accessed with the same file handle.

 15651   4.  nfl_fh_list.  An = array of=20 data server filehandles for each list
 15652       of data servers = in each=20 element of the nflda_multipath_ds_list
 15653       array.  The = number of=20 elements in nfl_fh_list MUST be of three
 15654       values:
 15655
 15656       *  = Zero.  This=20 means that filehandles used for each data server
 15657           = are the same=20 as the filehandle returned by the OPEN operation
 15658           = from the=20 metadata server.
 15659
 15660       *  One. = This means=20 that every data server uses the same
 15661           = filehandle:=20 what is specified in nfl_fh_list[0].
 15662
 15663       *  The = stripe count,=20 i.e. the number of elements as
 15664          =20 nflda_multipath_ds_list.  When issuing an I/O to any data
 15665           = server in=20 nfla_multipath_ds_list[X], the filehandle in
 15666          =20 nfl_fh_list[X] MUST be used.


Therefore, you can't have a repeated value in = the=20 nflda_stripe_indicies list (e.g. nflda_stripe_indicies =3D {2, 0, 1, 0}) = if you=20 are using DENSE packing.

Thanks,
Lisa



-->Andy

Thus the valid values for the length of=20 nfl_fh_list
are zero, one, or the length of=20 nflda_multipath_ds_list.

I will fix this = now.


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/nfsv4

------_=_NextPart_001_01C8131E.8F39F0C9-- --===============1534492979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1534492979==-- From nfsv4-bounces@ietf.org Sat Oct 20 10:08:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjEzn-0007vN-Rs; Sat, 20 Oct 2007 10:08:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjEzm-0007qg-G5 for nfsv4@ietf.org; Sat, 20 Oct 2007 10:08:06 -0400 Received: from web38113.mail.mud.yahoo.com ([209.191.124.140]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IjEzm-0002fi-63 for nfsv4@ietf.org; Sat, 20 Oct 2007 10:08:06 -0400 Received: (qmail 67934 invoked by uid 60001); 20 Oct 2007 14:08:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=JC2SErH7oe5uspEDRyv7dwl/usft+0PSh9FHydvujRKdUSbspDrYdowkILAYfzSgYkqAIBatqnvUBe0uUPiOsqc4AChLX0Jo7kZIr1fRKTw8mbDj3ZuDy6NjOfMAtBuuvk1k3NlCWOEZ1yGGi+UOOIEaaCPLhTMiQzAy9ODl3uo=; X-YMail-OSG: e.KNWq8VM1l_NZ4T.JM7b1_Vr0jjiKZvItOJddD8pd2sXZQNLCtQ22rtIKoLJk0jiipvpWck1g-- Received: from [198.95.226.230] by web38113.mail.mud.yahoo.com via HTTP; Sat, 20 Oct 2007 07:08:05 PDT Date: Sat, 20 Oct 2007 07:08:05 -0700 (PDT) From: Mike Eisler Subject: RE: [nfsv4] Question on file layout! To: Suchit Kaura , nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <568352.67520.qm@web38113.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Suchit Kaura wrote: > In general I would like to ask a question about whether we allow the > flexibility to have a different non overlapping patterns within the > same > file. > > Thus, conceptually do we imagine a layout having a pattern from let's > say starting offset in user file O till a length L. > > Can the file then have a different pattern from offset O1 till a > length > L1 ? The file layout specification does not explicitly support this. A smarter pNFS server with smarter data servers could presumably map the incoming tuple of into any local combination of one or tuples of , ..., where the sum of length(1) ... length(N) == length, and there is no i, and j, such that overlaps . There's been no discussion (that I recall) arguing for explicit support (i.e. placing the intelligence in the pNFS client) if such a packing method, and I think it is too late for NFSv4.1 to consider it. (BTW, I think with sparse layouts, one could implement dense packing on the server by remapping the offsets, but again, the data servers would have to be smarter.) As you can see we have difficulties supporting two packing methods as it is now. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From OlamanumissionLackey@zabasearch.com Sat Oct 20 15:21:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjJt7-0000QA-CF for nfsv4-archive@lists.ietf.org; Sat, 20 Oct 2007 15:21:33 -0400 Received: from c-71-58-103-218.hsd1.pa.comcast.net ([71.58.103.218] helo=toshibadad.hsd1.pa.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IjJt7-0004vT-43 for nfsv4-archive@lists.ietf.org; Sat, 20 Oct 2007 15:21:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host08278650.zabasearch.com (8.13.1/8.13.1) with SMTP id UO6CME0j64.619077.diC.xty.2588582245066 for ; Sat, 20 Oct 2007 15:21:23 +0500 Message-ID: From: "Trudy Mansfield" To: Subject: Your life Date: Sat, 20 Oct 2007 15:21:23 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_BA71A_01C8134E.6CBB4C10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_BA71A_01C8134E.6CBB4C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_BA71A_01C8134E.6CBB4C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_BA71A_01C8134E.6CBB4C10-- From AgnescarneBergeron@buffaloair.com Sun Oct 21 01:03:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjSy1-0000Gb-5I for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 01:03:13 -0400 Received: from c-69-251-73-211.hsd1.md.comcast.net ([69.251.73.211] helo=dell4600.hsd1.md.comcast.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IjSxm-0001YQ-42 for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 01:03:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host20985155.buffaloair.com (8.13.1/8.13.1) with SMTP id DfIIZuHT85.512159.m2t.KuI.5254109673086 for ; Sun, 21 Oct 2007 01:02:40 +0500 Message-ID: <208f9a01c8139f$a159e4d0$6401a8c0@dell4600> From: "Carla Ivey" To: Subject: Hi Date: Sun, 21 Oct 2007 01:02:40 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_208F96_01C8139F.A159E4D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.5 (+++) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_208F96_01C8139F.A159E4D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_208F96_01C8139F.A159E4D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_208F96_01C8139F.A159E4D0-- From Bourduasnecc@abruptmusic.com Sun Oct 21 09:52:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjbEB-0004QT-FO for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 09:52:27 -0400 Received: from host232-200-dynamic.12-79-r.retail.telecomitalia.it ([79.12.200.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjbEA-0006Ou-Sa for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 09:52:27 -0400 Received: from abc-675ee489908 ([126.158.187.121] helo=abc-675ee489908) by [79.12.200.232] ( sendmail 8.13.3/8.13.1) with esmtpa id 1JsVVM-000DVC-ML for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 15:52:57 +0200 Message-ID: <834346B2.EA361484@abruptmusic.com> Date: Sun, 21 Oct 2007 15:52:30 +0200 From: "jules Bourdua" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: usogar Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello you nfsv4-archive stop wondering because now you really can make it big! http://laraauto.com/ jules Bourdua From NolancitrateHumphrey@icbl.org Sun Oct 21 12:29:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijdfu-0001Sv-1f for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 12:29:14 -0400 Received: from cz194.internetdsl.tpnet.pl ([80.53.235.194] helo=komputer) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ijdfl-0006px-Bx for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 12:29:09 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host09621206.icbl.org (8.13.1/8.13.1) with SMTP id 2zgyebWv85.242883.Jmc.8Ts.4035076500119 for ; Sun, 21 Oct 2007 18:28:29 -0100 Message-ID: <9c28801c813ff$751f1a60$1460a705@komputer> From: "Ashley Patel" To: Subject: Confirmation link Date: Sun, 21 Oct 2007 18:28:29 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_9C284_01C813FF.751F1A60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 1.7 (+) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_9C284_01C813FF.751F1A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_9C284_01C813FF.751F1A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_9C284_01C813FF.751F1A60-- From TyreeabandonHuber@oracle.com Sun Oct 21 15:56:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijgsy-0004XK-Cq for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 15:54:57 -0400 Received: from pool-72-78-105-139.phlapa.fios.verizon.net ([72.78.105.139] helo=familyroom) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ijgsy-0006qh-5a for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 15:54:56 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host47046295.oracle.com (8.13.1/8.13.1) with SMTP id Nq2t8slT27.347029.vzz.MgC.4846344082106 for ; Sun, 21 Oct 2007 15:54:57 +0500 Message-ID: <9f76301c8141c$46665310$6600a8c0@FAMILYROOM> From: "Walker Forbes" To: Subject: Hi Date: Sun, 21 Oct 2007 15:54:57 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_9F75F_01C8141C.46665310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_9F75F_01C8141C.46665310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_9F75F_01C8141C.46665310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_9F75F_01C8141C.46665310-- From Garronfarley@hohmancompany.com Sun Oct 21 18:14:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijj4A-0006Us-W3 for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 18:14:38 -0400 Received: from [189.25.24.245] (helo=18925126199.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijj3z-0001nT-9w for nfsv4-archive@lists.ietf.org; Sun, 21 Oct 2007 18:14:28 -0400 Received: from xp-0d122e4676d5 ([133.176.166.127]:31353 "EHLO xp-0d122e4676d5" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 18925126199.user.veloxzone.com.br with ESMTP id S22EJTYYZEVWTFCO (ORCPT ); Sun, 21 Oct 2007 20:14:26 -0200 Message-ID: <000d01c8142f$b57f33d0$c77e19bd@xp0d122e4676d5> From: "Garron farley" To: Subject: htwerten Date: Sun, 21 Oct 2007 20:14:12 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C8141E.F1F663D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0003_01C8141E.F1F663D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello hello nfsv4-archive hit that pussy and hit it hard with a new imrpoved cock size http://lepotan.com/ Garron farley ------=_NextPart_000_0003_01C8141E.F1F663D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello hello nfsv4-archive
hit that pussy and hit it hard with a new = imrpoved cock=20 size
http://lepotan.com/
Garron farley
------=_NextPart_000_0003_01C8141E.F1F663D0-- From LenoraphenotypeHightower@canadiandriver.com Mon Oct 22 00:14:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjogB-00010d-Fg for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 00:14:15 -0400 Received: from [190.80.158.36] (helo=nonec13d862bef.domain.invalid) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ijog9-00048Q-5a for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 00:14:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host27487298.canadiandriver.com (8.13.1/8.13.1) with SMTP id vmYEvnQi44.051295.M6K.xwZ.0845018725432 for ; Sun, 21 Oct 2007 22:13:09 +0600 Message-ID: <8069401c81461$ecac30b0$0200000a@nonec13d862bef> From: "Etta Scruggs" To: Subject: Your family Date: Sun, 21 Oct 2007 22:13:09 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_80690_01C81461.ECAC30B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_80690_01C81461.ECAC30B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_80690_01C81461.ECAC30B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_80690_01C81461.ECAC30B0-- From iksoea@brant-allen.com Mon Oct 22 04:25:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsaR-0002nK-5F for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 04:24:35 -0400 Received: from [89.31.90.132] (helo=[89.31.90.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjsaG-0002y0-97 for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 04:24:27 -0400 Received: from [89.31.90.132] by mx1.biz.mindspring.com; Mon, 22 Oct 2007 11:24:39 +0300 From: "Russell Fisher" To: Subject: Craft carrying first Malaysian space traveler Date: Mon, 22 Oct 2007 11:24:39 +0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000E_01C8149E.2247AC90" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QZVK693LIPDVUX3KP8NOGTWN7B== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <01c8149e$2247ac90$845a1f59@iksoea> X-Spam-Score: 0.1 (/) X-Scan-Signature: 441502cf25997484ff0b8b79626c6b69 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C8149E.2247AC90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C8149E.2247AC90" ------=_NextPart_001_000F_01C8149E.2247AC90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit "I know that we don't always see eye to eye on every element of the solutions to these issues," Rice said. "Nonetheless, I believe we will do this in a constructive spirit, that we will make progress during these talks as we continue to pursue cooperation.""Events have triggered more detailed planning for the curtailment or closure" of access to Turkey, one official said. The key issue is to find ways to ship supplies and other critical equipment into Iraq.The U.S. proposals are intended to ease fears that its missile defense plans threaten Russia's nuclear deterrent and include the creation of a so-called joint regional missile defense architecture to protect the United States, NATO allies in Europe and Russia.Turkey has threatened such action after congressional moves to declare that the killing of Armenians by Ottoman Turks in World War I was "genocide."The wounded troops were transported to a military medical facility for "emergency treatment and further evaluation," the military said, adding the incident is under investigation.Turkey -- now a NATO member and a key U.S. ally in the war on terror -- accepts Armenians were killed but calls it a massacre during a chaotic time, not an organized campaign of genocide.The recent rise in tensions between Turkey and the United States has led the military to increase its planning for alternatives, two military officials with direct knowledge of the ongoing assessment said.But he stressed: "It will take some time before we are able to make public our estimation.""I agree that we did not agree on anything today," one official told reporters. He added quickly that neither Washington nor Moscow had expected significant breakthroughs.In a series of meetings Friday, Rice and Gates failed to turn around Moscow's opposition to the system and other strategic arms issues and got little more than a pledge to meet again. ------=_NextPart_001_000F_01C8149E.2247AC90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

"I know that we don't always see eye to eye on every element of the solut= ions to these issues," Rice said. "Nonetheless, I believe we will do this= in a constructive spirit, that we will make progress during these talks = as we continue to pursue cooperation."

"Events have triggered more detailed planning for the curtailment or clos= ure" of access to Turkey, one official said. The key issue is to find way= s to ship supplies and other critical equipment into Iraq.

The U.S. proposals are intended to ease fears that its missile defense pl= ans threaten Russia's nuclear deterrent and include the creation of a so-= called joint regional missile defense architecture to protect the United = States, NATO allies in Europe and Russia.

Turkey has threatened such action after congressional moves to declare th= at the killing of Armenians by Ottoman Turks in World War I was "genocide= "

The wounded troops were transported to a military medical facility for "e= mergency treatment and further evaluation," the military said, adding the= incident is under investigation.

Turkey -- now a NATO member and a key U.S. ally in the war on terror -- a= ccepts Armenians were killed but calls it a massacre during a chaotic tim= e, not an organized campaign of genocide.

The recent rise in tensions between Turkey and the United States has led = the military to increase its planning for alternatives, two military offi= cials with direct knowledge of the ongoing assessment said.

But he stressed: "It will take some time before we are able to make publi= c our estimation."

"I agree that we did not agree on anything today," one official told repo= rters. He added quickly that neither Washington nor Moscow had expected s= ignificant breakthroughs.

In a series of meetings Friday, Rice and Gates failed to turn around Mosc= ow's opposition to the system and other strategic arms issues and got lit= tle more than a pledge to meet again.

------=_NextPart_001_000F_01C8149E.2247AC90-- ------=_NextPart_000_000E_01C8149E.2247AC90 Content-Type: image/jpeg; name="pic01.jpg" Content-Disposition: attachment; filename="pic01.jpg" Content-Transfer-Encoding: base64 Content-ID: <006901c8149e$2247ac90$845a1f59@7QYQ6482> R0lGODlhjQGcAfcAAMnHx3eXPv+cAJVcAf///2CSqPT19DUxMF9Mw5QNDfjyVoycYu/Qyw9FZgWj 3E96m3VLBfzOBrKz1ZmM2FOq1Vw2BQSHt3trzfzpCuzt7vTu9Pz8+VG25//26VpXWJLP7QQCA+bm 8rOq4m6v0dns9ry8vWi14WlmZvu0BXDE69mtqeWTXPv9+kdERAaYxMnm8zMassd3dgRlkcuIiNTQ 7rnX6gYyZMvRrc+7wft0BeTl5TClz3p2dq7B1TGv4q/Hqui7t5C31IiFhZyZmgVooi+UyaOTJAVY mAV+xAVzv9zd3AWKzNbk1Uucx/fLuqilpfn1sRip2qezidTT08jb6MXA5gV4rAVVirfn9+vz9Pjt 1ZHG1/rq6+vk1vlZCTaMuNr297zKatyHAWZSVIF9fKk7Oi99rixomMvNzo6tjujb3+n1+uT05fn3 huv7+/vyLwRHf21rbKuLe5GXrCEaFI3B5S0pJ8yrfo2sv+6okjmjstfk7wiFkbzVyLfM4AdttPv9 /JCMjN7Z1kFHH/b1+gSW1ajb9cPRnxeYwjOSil1GQd7V0qnU6FFUaiPE7e2Gfe+qM7hfXrGxsfc7 DPPc3CpagMRtNmSANdHWvtvJyGNfYBpPfwspPdWpDbqApr2vR9SZmrOBXYx9M3VvcbuqpqKh0ajK 5Albr9XHOO2KOReZ08fT3tZaTEpqh/uGBc3N5m6gwu/l55S6QqqpuGa0nLm4reLf9FVWP0w2u7ma S+rZQsvkexhfk5bf+OrUduJ3LqG6rz06Ovz2+Y9XPxEREKZyk+tkVoWXmcJ3AF1mLYGHm1BNTiY5 HheGxEpYIb2swufh5pZHcyQkImpwihuArwVHkfySBbvf8fz7/Prhy+6SAPH34Ofv9fz41OT98tLZ 1BpxsuPq5ebo7tfV1/vu8PH+9dTb2dbhufn5+hdrmZWUkNjN00RHWdjX6eP39+LuzgyZoOKTHXN3 bPn5/b72+xZNmm9uSTNVXuyAFmmAjCFWsq3WJ4E1J+c5TMVQKdTyHCH5BAAAAAAALAAAAACNAZwB AAj/AAkIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKDUIA5SypcuX MGPKnMkRDTSD48jYazTEAM2fQIMKHUq04RA0BKAFamGnRQmWA1sMMAIBAg90DNEAwFq0q9evYMMe HKfJjqYhTT0MqsrjaVI7EeJGGGRrIIC7Wm8SeEKHjqSE4/AiFUu4sOHDF0u0aDQNBJ1A8wgIgdCJ qqancSh3skpIYCBiB0JLOwB5lONRCMcFGz3a6cKycRDLnk1bKNpppaat9iBJyAEQgzpFGDCI9xAe yHt7sGeEquPnTz4Tc4uT2HPogPseqM29u3eSPIIp/ytFvlSw68EUC99cXEjZWwM6yYdAjHeL0zok bUVYwrG0OL+BcIJdd0ElnQcEARAIdd816OCDCY0iXnm5SVNfI47dFVxcm00lXFxG2JFhUo4tZp0B APRl3Yon4JcicAag9ZwmgPB1nQfS+bcfhDz26J17FJbHzgGNrAbZHBDIpWQEm03jwYhD+Begated FiUIQhDwYgumVekeemVV2UIGPpZp5kZKCJHlRNGR2RBjFCpTJDtOjimQBx8qSdVT9wkYJmm/BZMT GUv5p9RpAPTJFHCS2OhUgAs+SYwQio14ZlAT4ALDBZfKhJaFEqGhFgiDZTXhHEP+N41uOzYywJKb 1f8FzXlebunTnSPGUSWjbSp4GgF9aqmdTWRY2mlSE8CEAAzMIoDScWoyCFMJalIaUgnSVHSAEhLd Jl54jNFp14ZKdoLgW/49d0CXNHr2qwGSXjeOZ33iF+he6opo7Hc0ZNpsQbbgUoVdMAxc0gW41DWQ wiQpwRS3nlL6RAai2unRCQOyud1Eo5zgVqKhhSCQenLlCcFT4wyLBq0qxiYsjOiCpl1S8dKapYVj SrLrvt1lmqwIzBa0bIIwMCwSDTAkO9AESpeEZURoUYTxQVdlcN9AJ2Tr0aRSV53REH9pQAZlctGX 5HBkAPJiuzx4GbNbs2YoaW/4SfcEGn0hKISUq63/e6t3Ijg7sqYEZSp4S5kynLhJeFNHbVJremYt sBkbBLcQ3JYwsUBcFxQ5kQs/LXmpAkF8t2duYq7l5v2VehzpdiW4d08cSXKLERwSdxR8TNrzMmpW Vzlxi6KTCOOBT25LAPGN/to2CGF3vPl3CIiwNMJL+xxqwRcRPhACh4MHwkC+eXzfmsjNft9opRKf ZQktigqqb8BZnNT0xQNrp1Pxo4Hcw/1ZkzQ0F7+sjU8yWrPaE+JHPuuca3nIIdVGFDMII8znFqqr UZLMhQ1HAUhKGdKZlcB2JUHhrUSOiQ6LdCUgUSFKEyl0UPW+tzgNXABoBqPBshiGMO4FrGiaooEO /5llvcHB4HA95BTQmMXEZTGxaSJRy8gy8J+JQY9zE0MK3iCmJTtJUIVZCo9nEki+gfCFQYsBFu2w hKDGSeaKkkEDGDMgRsrdaY1rcg1p7oiv2i3HHsh5BVRKdwv5ZOlKXmKehXZVLAFhZZEBEpOMGKWi Gf0NcDD4Hg4JwCnsaelfSUGALXQ4AREYrpSfpAEBdpiUoiFtYLhIFsKKWAXuDa6IToucEq4YpYGM hnwbE4jy+IK1jUkjj14ro7sKUkViDARLE2OKMBOYsawJU4A96c8zw7jGzGnNN6FqhzjHSc7OmFNk 6BQZOwYwAMw9b0WkeUVZ/mMH1rDmLBY6gTjn5P8keKbQFpLSRDsaA88qjDMyDqpCKYtmylUKjmmx FMgMl6aBpBVRYALJlPVqqUqJKq2WSstU4TLJODjuRWtTG5nolgPMO1XumCSC2HQsZ0z7Na6OBIDj Su2kuWvGVFhkwin08DZGn6oxIv0KkgSWytRXOLWcIajLNCAwiBLYQnPR0Y8QhYjVrnp1FmBlalgl MIfxlNWsuUHrWdVainN+54avdFbAmsbRVBYEpBklKQE0KlHB1bWVSgMfQXARvpHsjSAp5RrErpbT LB6VimvaJbfACVQteU4Ju4yc/jbbR869DzSQK50EKQvOlfHUmXVM4y5RZlKHtEOpBn3qQd06LuX/ NcSqIQgrOceZm9jK1rdNFatwy0Pb7sj1iBu15V5J6smRXlSvzXXocju6SQIkbWHXNUnIfJlNUoUn jM4kqppyepXZlRelHvAfOD1GNQnSbGNP4qMw04ucAXotavrzH8YWGN+jSvM2bcGSw7wLkdfC1rej jGpxdbBHXelTJQqOqjixRa0S4Va2yvBLFSQwpPEM98OwLW5tbiiQI+Z1sKI0HEWlK1G9xhJpdeFo DS/AKbsOrl+iFImM9vjT/jilfAMUVpAJgDMfBzVj53uj/RbGl2O6h8f4Wg7txtiTKGk2pUlOMl+k jKsBgsYmVnJkgQ+M4AhzJUHQgE0GuaHgRM3B/xaR+nGZ5anhxtBpFuvaMIiVSh4Rz6a5RevrYDUa RB12dFPfuy6NP2k9kWpPpCde2hNl4jjcTnFhg4Fd6bioactZOkGfvnRSOr3pUpcu1B/D9KhDRWbZ mnmQXHnFY8w5hEY4NQ6z0NUBcj0H0ESL168tkoaHtNQM71pO43ESbu6sVD8bpofKrTHSmFjiHC+R rsr9YXaXe8SOOrHGgiZYjkciRxKa+9zoTre6183udrv73fCG944aYuBWJxjCsO4Mfk+6GGPD8JjH LNEAiSSevk3nFcaehb8XmeH6hQY3QXJ2YRA2bqDM9SV725nGN87xjnv84yAPucjzlxV7Q/XMCP+t ER3QCZvHaPjlqMI1wLNmpLYx1c4SeExZzJMqY4+m2cdCHC6mhbGiG/3oSE+60pfO9KY7/elQf3rY XGvye/uZwriSsjRee/CZZ/g9jPFLhpuKoV7LadcE5wlomE0hiQf9IxN9+7HqHdw54/sguzkOHc7y Gaf+3OsA55LPD3729NAhGBg6j27YYZ7RsLWtch8JE7cd+UvRve5bfXW+50GW/yjFDoRyjW/klGse oIqsTaGWWdKD8J9X4buL5znqQQ/0yoNEU3G3/Zkuj3mrb/6c9x6H1RP8W+A6te7I3zOfIa/75jv/ Irzvve/vbmbiW3+3mS++nrev/OW3/fngD3//gbXvauyb//zozz75189+8qNc/PCPv/xZQP/6258c 98+//vfP//77///zRxFTgFkDqBWCsQiZUIAEqAYMqAMNGAsQSH2XJIETWIHYcIEWiIEZGID0hn9g AIAgGIIiOIJd4YALaIAo6IEbsIIs2IIu+IIVIUIbZyH1VIM2KBp9k4OLsYPL0IM++IN/pAlCGAdE WIRGSChImITqsIQbyIH7twpNcAZBYAqMAAApYAbpUANuwGYk2IVemBImeILYVwKCQYZm+FVniIaC 4CZNCIMxmC7aYU84OIc6iHg8eId4mId1mINyqCI2yCJtmBVlmIbshoSAtBxz8oN8SIeMuBtE/wg2 ZCgOXcBFv1eJt/UAm5CJVzCFH1AHKXAKRIAFWziKXKiCpAiANdADWvgCJPCBpfiFGCGGaTiL+vED tXCLtJiLuLiLvDiIXrUKs+WGwvgQL+KHN9iIe6iHyriMeDiEBteH5/FAAohVgZA+OkGEioiM2miH itCN3giEOxGOHpCIi4FrF+aKlkh1BXAGcFAN7XgER+CJHJACUWgG3JCADxiBpgiCFAAORPAHABmQ zTCQA0kBBjkCCMmJqbiK6JgRgvCLungDKBiRvkiRpMCLd3CRGZkHvShOgRgqcHiM28iNzAiEJbmD 8TQF1GKIyBEHC7JlH6kQjSInPRgI0HIcy/8QB3egDjvxjWPwk0AZlEj3AERZlEb5BU2AlElZBF9A DVjIjg0AJ8K3hulIb5r4jvB4BZtoAonAARRwBQXgBpkwA2SpAmYJCmiJljigF/43AknwlkgQl3Ip kG+ZlXQJiv8Ij+DQkBaBWVl1NzZBMZPIZqw4icBofLrIkWe5kRsJCY75mJAZD5I5mSuQkRc5gDFJ jOgBjSKZjCdpkqCpiJvDgIA5kTqgDp6ngWxyD2dQlHgwVtDSA2SVD7RZm0eZCEqZm7qJCLzpAg7g m8AZnBYwnMRpAVCpDAdYlQvRAHaJlbzQiUVAj+kwAveoBvqXj/93hXA5l9vZnf54l3UZkHz/WRF+ 2SiluYboSYWr4AS+sJiW+Z53gAryKR/0iQL1aZ/4mZ8CsJ/WwJ/9+Z+pUJkqgJnDGCqrtxydOZKf GZoM2oOjUC1JaHoQugypaREFwJz/2AwHuQNeqZQGqQcc6gM70JtRUKImKpwoWpwpuqIBmQ6VkA9T SYnKCTDMWQ1msI5xUAnMWQe9YALXEIVBIJZqCQREWqQDygD4OC/VaX+MgIXc+aR1WQS9YAh1sI5O +p1mwJRncIp96YvoiX+MgAcjIAXzmSf6iQKwgqZnuqb+2aYA6gpwGg8ZSaAFSoxmIYQUmqCeuaAN 2qAjeU+qORGwoJVa2ZtNIKLA+aEnuqgr/9qoKsqij0qc6fAF5zijOOGOVyCFZJAKolAPzxkEKfAB RVAJhTmki0mkZWmkRaoXhgClrhqXTUAPW+gHW3ANC/maWtiUsAgwXvqKXhkGabokwjqsasqmxvqm OYAPlZkXdepa2oGSekqSfDqO1FqtjWCtfsoUi/hwK2EReECoVoAIhwoLsMCUv6moIpqujOqokcqu 7eqbrXmYSmqpBJGVLxoHltCpYHmQcVmYSKqPr8iW+8gChtCUBPmq3BmqVMiJU4gFC4mFu0oQDjiL g+mB9AisxJqxGlusx+qmcZqsqXCLVNmsC4E3rbF20Tqt2LqyLJuNzFihMQiuGgqi6FqzIf86oji7 ru66s5H6j9QZGOJAr/Vqr43gDyfgqTn7jx94gKv6r0DrtPX3Ak3gnQhbtQZ7owAZsZhmgFJwB6jK kRvQDgaJsRtbthx7th37scmaA8u6CpmZHaD3bwqqsi1bt9m6iMlEEd+al82gDLx5qH8LuDebszrL s5D6rkswnNNJBZj1iq6VlT3JD40Aj0VQCIl7BA/QioGhqk2LA57btPQHC1U7ulTbonuptSvItU+Q kbnAuvhnAhxAtmY7u2ibtmrLtvhIsgphsgg6t3Rrt8DrsnWYt2xCqA/AAbnACjwAok0ZBTZLuNBr uIeLuFbwj35QsUILDfBoD/EgCvaQDJr/WLlxWQ1hCQ3YObCmyAShW7qJ277ua7UHS5Com7pn6LVe 6wsroAUG8Ku027+1a7triw95QKdveEx5uqe/O4QKvMAMHLzQaiTdGrNX4JJ1sAKuwAqB6wLPG73S y7PV+8Hxa5ywwLgjCxHwuKneGwBZebXVgAc3kQlmOYhI+rlc6pbve8M4TLrxO78Ugxdd21V5oL8X 679EDMABvLYrQKRsKID1M0++26cNHHUO/MBpE8HF+6I7uQuVUaJN4AIeOrgc3MHTC8JerKLWi70m PMGfYAQBoMKUe7ktrLn5OMOfq8RMqsOWm8c5rKWm+508PJGfYItV6A7l4A6wK7tFXMQe/3u7yTrA hUmewPFkTwyOdXuElhzFU9w3VeytWjkMrdsGYUCzleu80IuohSvGZky9kurC8/oQ2uuOKezGkwrH pgAGj8yluEx/orrHvMydTPnLSdmhWPrHPrwAUvADVEjI5QCqiJzItLvIjJwDXhCytzwRvHvAk1zJ l7zNUqyHmyzBrVkAshAASznKgquup4zKxUnG7LzORPAFe4DGVkm07PjGcXkGtgqMtxzPjmuxvazH AI3DOZulIdwMxIyLkAiwzIwBDO3MzwzN/3nEqeDIujsWa4fN0tqMlIzJHdPRHs3NeJrJkGHFoeKi mWoGAYCb5UzKpRyc6Yy4KQrC7SypGf96vTLaEFepl+kAikUQrqeQuVQgm7Q61PKqvkwqvgGd1P/c oV5Zroe6nQetOdESmCvoic3c0A4drBAdzQLsthVtOZGM0Qi80VL80WaNycLLFCNtEa160uV8zhv8 0jD9mzEt0+6suHkZpDddsuDKC+X6nSEKDiMc1EQt1LQKDF6ty6OsCkrd2I5dkEgN1fNbhsiZ0FUd u1id2cOq2Q+91dGcxEsMkgV3eGNN1lHXkqh91mgtvGtNnryglQUAqtEb13KtzjN910TAyv28nHrZ BLCAiTzNoYLNijbNzyTMBMZNsF1M14/d3Ik7rk39y3MZ1dTylyxoCpjN2Zut3Z3t2R//C9qFzMTr ohbZzNGpfY3nnd4gzaBQ5tqwjZBv7ZvoWttzXde4fd/VO9it6MrGuwnkWs/R+Yl18AKGvZDFTdih 69zM3dyk/NyRLZfUXY2UYjAbgN1Xzd0Y3t3eDd4FTAZiXZLmbY0ROuLqDXUo2doCCODkirNwLcph bNvAadcyftf6LbThG9ut8NrvLKJZSOCYV9hbaAI5vOBEXuQA/aHRPaKSrRETuYSm5zjZneFSruER Dc0cLt4flNEazbJmTeIQ6uUlbrfiEagl/d7wvdLMC8b0Xd85PON4nd+SuNuAoePs+N+Uq+SquAcH nudFfYUMbuSArgrlTNAPHuFICOW7/6DZb6DojJ7h/+vdcXrl1gwaJ6CtIM7lXf7lmr7pYV637Z3i hbriaj7fLw7jbn7DfGsBP0uBCnHjeADcfyC+ZnC9Ba7Px00CpuC+gb7rRt7Uvh7Chn4XUye1F97o U76xkB7pmACwoh0eraHlpm3JYM7p1K7aDIri1gzcDxAE/cji8o3mJGrqMU7Tt03jGlDC8xzOv/2U lfvTJFzrhu0GvfDnvF7vBW3Qk+3DhDLsYRvlxv7vjv7oVT7wuMvsSOVrlp6HmC7tSkjtNlnt1r6y Y07mBabtYvrFGbzmbC6cp97xq27jOp0PZwDYlhurt6qeBf4BiUDv9q7gB2vo08OCFP9wCABf81Tu 2ZJuoOMdGgm/5VEs4g7/8EIP8Uy3g+rwtmNh8Wee5moe7uJO7uX+5s8d5yA/qdsus8/tB6nIsKqY zAXr2On80rs+3fluhkDiuCZA8za/9sie7AX/1XeF8M+u8AsP9EHv5EPP6UYY0tl49BTvykoP3ebK 0hq/8VIf9am+BHot5wlhvERJ53iO8lr/7vI+omBvouic+WLf5khA3b0xbz6R9pm96KRf+qN/7Fqd 7CuQ2FjuAXPv8wxs95u+hENA+7af9+gd8aKJ9AdxoZka27vpxSAq34XP5h2P34tf9TcqugEZ+ZNP 3IWJBcud1Jiv+da/+QH9lp6/hKD/P6am//3gz/bE6varH9oHb4c8T/fWyvCzf/u1//7ur/d7j63p wfsAE/jATJDnXPxzDRBWBA4kWNBgsy1dBHEDRMDhQ4gRSWw6csZMgSBmiFSkoMqMqTpBRPYg2ePF nhGFVKpi6cBlFJg+ZM7kUJPmzZgvV+5c0tMnkmYshEokWhQiGgAllAIIJORJhg0GpKZI8wbD1TcK tG7N2tUqVrBXI4wlWxaFWQFp1Vpb68qtqxXtGBqlKxUNsQPLgtkJ1sKvXsAeBGsiHMcwD8RkFDtt 2njIY8iRJTsWsjjx4cKNBut9KrVu3QdXrnyE9aXJjtPNXKzOCZP169UWYsumXXv2/+yNuQ/WFrjS pJK5nx+KTgfuQQFeFdNxaPbFz4eQJf2cLNBS5/WbNrVvn9n6Os+fQYcKrzsFaS2llQF4jkr1q1eu 8N+HFWvWPtq2bPW/jQuVPNEp8EIsr78C02yzEzC7rDLKJnviQQgdZNCyURRE0K/O/isKudFgKQ21 1GBzDRERb7PtRBMt2E3F3nrSLbbf1mjoP+Iu4pCjIoqQrgYqeiQhJfCwy447Irv7LsifxtOwKEGS UuoJp2Jhj5w6qrIqPizjo6++++7Lbz8w+4tqyYcWEXAUvgo0EEEFLWvQwQjjVIcyCi28MEMyIeLQ jBH6zDHEElMEDyhBU3yRGt3+IP+CNytW8mE9NMCYkbwaW4FFt148jM6Q6fa4pg4kvRvSBFKLNHLE I8MTL08AnSyhMf/G7AMPBTDYqo0sa9VyPi57xe9LMN3KI9Ix87yLjhPWVDazCuVx80045Zxswssw uzAYPFnV4MYCQgQ00EKBahRFQ61oorhzLerooh2WeNG3hSTVsNJLlaujCVigM4XHa7BI4YsgRS0y BVO5S3XQVbU9aimmmpKr2BdohQ9XXXfl1Vdfz/o12P2GLdbYM9NUk80Em302FDlmSFlalqel1uSS 7xRmZoXrXdRPCtYNF8nmWGSxtHGD7pnPdLo9rol/+Vw3N51WiXdS4ejVbQSM9P3/LemAR92O4IEN RhXhnpRUOCpXoYySvYhv1eoXSOLRhWIsUemkLIzp1vhuYMH0+OMljyVM5GULg9nNUFZYIZJh5Gh5 cTqrZRYwbKdkFZYGRDPt8m/B1UO1dfsUVyDnTuuO6hS2SPcLG0e4yKKM3l0Cphih/ky5om3+g/RN n2v3SIG35rrU3039Gmyxxy4bsRJ0gFjirXyxxBdIUNnlh110MeITuT/JZe4tM/Yy77dc2Vtbvz0g cGSSB2ew8F/K4AflNICJH5gnZ2H8ZWsfbyHbyWvE+fKdueBeetiDHpB2tH9RgFMiGQFJFNjAGiDH Rqk7jZ9c54hHjQM4sqsL7Y5T/5yKEGwkEtDd67KmNeCVDg8rfFDwvHawJBWPfEsZgmKe5pkg+AJu qFgBrsLQC+opIAzY80Uurlex7nUJb+ATFrHIRwxi6EUa6EufydZXuMOVYRiicEYiaJEIeUDoGZIg 4/3qFLPNRI5m2qLcaI5mQADuzHQUEEefRmLHlIwgU3xyIAm61QPWaQRf5xqkRhRFGx+I8IY0Ug5G QHg7PIIkc0JCoQgf1DZWFAMPLnwhDGU4wydVRkpTyuEO2QaJO/ShD7i6Xiuvl73rJVGJKGBiEyXX Nzogy3xUrOLJDOcPfmzRGZegxSXyQb8y2s+MjssM5PiXpzaiKzWThI1sHrgFbP8iLQgdqUFG9Fia Pr1AD5nK2RkWVZzVjWZFBGsGADTIwQ428kaQHMkHfECoE1bSkm37hRf8EQg89ilnp4KhKj5prPM0 LBAbLJYpdEixbETPF7ugaEXbYERRZNQI1hMF9+q2RFrWUnyruKWGAhTFwPXSlzNAnD0u8dIAEPMH yaSptPCXP2diY439sxzV/gQwct0GCz3YQTcfWME6GPWbjEpUU3EjrkL04l/uJAE86eJBc8oTj6qi pD5Ld4dUYPKfAaBFWc3aSYQdFKGhVMciN8CIh+IKCm+D2y6wd9FXGhEVGUVF3XTRibmdBbAitSXf TArFZJ1vGSpd0IRS9thhxlT/pjW1aeNg1kzO6HRsQYADR1RHojiCazXQQUhHvkVNnzX1UOdUzet6 0YwzUFVG86KdZnKjKSBx9SVe/Z0EDJeK9hVjAQGQRXFl0S20DkqtZDpeW2NFtl3IFQpzbd4QwyAK 7aFCu0Pc6Cz/2gkjRGCwYohHeUPKsRzgQwVTMOxhp7jLlArOiouZwys80QJNDBemAZgpeurXspvi dLFq3KxoOvshEAFVtNZk6ooarNpFpbYlUoWtbK1aFIoox7Y385DO8snbKoUVuP9MA3GNC4vkKne5 JqWhDUfpGSVgQrpznWhFo6u9um60Vn0drCuNOICNjte8tVxve/+TiZDxUr7z/2VQfZWRFykMURbW 9e9/KxtgzGa2pBribI3M8NPWVjOAQgvziRwcYZ/5xAH+QkJsGUpbDVfitgPF54d9Vzo8b4EUv2XF WE0sC7KmGDwrZjFb2TslHci4DdOlcVzbsIvhWhd72DUCpTG6V1fyVchCRq96D/1ElAJusYylEEmm YQd75EJ6QpQCKSh7ZSynUcsF7inmFCxmRGZumgNljpkhDGGfcAAL7UqHheG8kUrIWVEfqrOda+JC q7HQbCX+My1SaJPh8YTQR2aYi/l2DkZ3Q9zhnu51n2BpjWa60uvWXqWjN97zMrHIRhaOEqDYF1GP mtQ2nEMjgoEy7bLa1VaG9f8Z0biZWWhWYYCsdYLLjGuBAgycEx9kztKcWtW6CM2yocdrN+LWetOu qUBTs7OfnedNidAETTgOHv583GsT9EjbJk9C0/Np9oCb3Du/bhElbURVt1K7Hp2lYOX9MFBLsS9K bpObSpEPf29PF1PPxcDH+GqXxXrUBF54ctz4ZTAH1ZodrjghVTdNXwP74px7AXMqwoA3M1Lkt9Xt d0AMnZVvU5DykwUtiotiTmZ7JzSvt6u8TY6c75znYXj0d7UiS7tt7Oj0rjdelJ7SyjiLvo1BzBya omqt+JzgBTd4lrlOvmR/PexiRwTZmQOijVPj4Rh3qqB6YQhVIBvu0Lgwhuf/npsc1X23MTm5ylFu TwaGJh+qlrRAYy74sBG+PIZfqGEVP25Gww1uF/Oe5CdP+fLcey9LR59kkjmnJkMIe9pTnBjPT3oB p1ESO2WVH87QWYugDrSzNxHaH0yuM3uqlWg7d3m7uAu537sZnumq4js+vBMoixgCqaO6bXq+gpK+ 6VuKBHGiKbm+7JMui4G87xGpeUs6pluGzGuMV1mQFYSWJ4CUV7mfaSODGdS3AZu/LTuy1AM7/Qs+ 1ku7AGwz1to4nkmBttONGBOH3iMK4vg9HzS5Bkw56NCmdAGrCJi6CIifwJO5wcNAoygbCEG6YvHA DwxBEfS+7zPB96IiMooD/wPQhPRwilFYqCkgg/MIw0VQgvl7kvOACqUYpTu8OcZoChucta6rhg7h Qf37wf87Mwe7jd3quM85A4VQwiWMiARclCeEwijUlxTIl9Koh+Uzr6nbpC28QC9kkrIxj5JSvEV7 xe0zw+5Dw/BJr/QqwfoTv3zbOjtsqxckI/Nwp6dICuBInkhRg0wQAhiMhUxgryFINA34wyc4gUBo Q4UixDQ6gOShP+baQZbrQf5jRNoDQiLkHQcwwhQQQgO0xGObu03kROPDpilMvkCYwL/Kl1P0pFRs FRqSBA4cQ1gsQ+17PO77KFqsxVt8AfALPzrwC8UqxBaIsad4kKSgw1EAjv+LDMYM8MdEA0YN6Egl EIKNzENhXCj3iwxZ08Yc1EH8A8dbE8fPicm1m8nhk40Rub0oUMcHgAaSukRMzMR3zCcHtBqitBpV u0Jd+ISAErSV2Ed+rJ9/hLGAFEhZPMODrMVUaMaFpIuTGjDys8E4CAakcMNqNA86NMZI+UUd4Mhn 7EiGESM0QL9q5Dxmkj9uJJM9aIWWVMRwBMBxlMkGUwnQMSRNTCQ208kmCQ65O4Im1EThGz6ZGEpG 8MSi/AD5aTUtVDnXg77oG5uF6UecS7wZA8FYLMjIG0ESVEyQacjxY7oh8IAaGsQ5MZtaSD/zkxC6 LL1rkaJt9Ey99LJFhMn/RpxJM7uHllMGZQgNXnABeiDAzymAxPRJiGjMRAnKEyoVqSqdBaLMoZLH B/wmy3QMXuNMp5QIm/PIVgy9gaxKg7xKjslK5dlKJtHFrwTLOEjBw9i8Y3AYyrrGrNPNg/PK3hyb 35Sn4PRLwHxERhHMCJQAZUJOqNuEWTAERwgPWIhO6RQK6qQd69wJ4hM2QzCBjkuqEa2nfplMFK1M yVg5LlSz8oyI8ySj9FQbGiVI0zxN98RKrZRPAIGiXNpFfZNNihzSfgTGt4zB/8y8y0oQiMSQuyST AkWnA0VQ4jwkBd2IucwHLd3SVngAf3sA1/iDnsADDG3H6nxMyPyATwGD/6E6CUY4CTaF037hBk/h FzcNz8caKM5MGM98K1dBCpCLivVkz/ZEzdTk0R79USAdDMdYHElgDKybzdwE0GRJSSddSfJQTuVo jikdzr88s8rh0qyyiFYwzlK1AbB7iSB4pwzVUMZ81UNB0w/tuBM1hOZ0AzXFgoiRlBfIVTltTqXa TFTsU7L500BFvEEtzRvFUZASKTFBVBj10UUdjDmsk/20VsdqnEml1N28VN+sHHXiSyr91CvdhA8a VXDdhHsAVxuAgzJb1QOMGlg9U1klvuaE14Rggh+B023s1V8liV7Nx4N50c9kmPi8pdJU1mVl1nhr WITMgWcFNWmYVog8uP/7fJZs1VYl5dYmHVCF0VQp7VRVSdAhBFWLYIe+KANgUgQbYAY4aFeXbVfT wCAkgFfVlNd5Bb5m+7BecAMR9Vld9ddfJQFgjdNczU49bVEXJdhiNdiDlZxzyBUsscqic9iHhdgd lViK3TfNw9iX+dq6ND3I8VYCTVdxbRFPVbuSQ4J2rQQbUAR/mAS5nYRI8DeYXdcGQNWaKAQrINN4 nZ2c1dm19dA0HTa8O9rKDFHvjDlsU9rOJNYmcdotmy6p9QqqNVRnjUrmktattc+SaSyvBVuOtVSH 9FhtAVlDAjtHXN2ZPIK2tYFh8IJJ8Ad8gIRhMK6YWgC8bYCl8dubBdz/wBXTev1Q4KEAaAuJoeSk xi0oPvXMyJXcGV3Yy21WworYXFTUh4yvz81PJgvd0e1Wh1RJhTvdtuWFs61S1l27131bL6jd6FEE itqHfQA0t5VZF7HZVuWGDRXc4U2kw/XOxEVc5U1a5mXapoVexPsYHbrcQqXe6tVcXMLe8D3BJete 7/3eJg1f02UV1D3ftM24i3Pddm3ZMqjdsdgHD2i8+b2EEUZVcYmdVg1ex+xf/+VOxO2mFN3O4mXK GCLWAwbU50I0JJLeWTQ6q+209LLe1ZzYzuXaaim9sM0y0t2LDYam8s0/1U1fg6g9B2iGFmZffCCL AFAG6tqFfWBhRGxX/xdQFBg2U9cZXMJV1QoE4BvezgXaYccdWQP+4WMtBympFbEgYoY14iO+WiXe XM6dYAqu4Kaz4CUN0CkevyomE2W44iyOPXL9tYv74mHAB6BDYcZrg334BxTGv8rxiTZezJzt0Dgm 3uSNxwFeXuZtXudF4Ft6AUBm4KotZCTGWmg1z0Suz0VmZPV54keW4gymYkzNVEu+5C0u2WcuRwcg ghG+gnsYA2y+v0bYBAAoN/o1sFMe00rMXxkWXhoenU68tljO4/DYY24w1hcTN0SrHl3eZV6+Wl/+ 5aMIZmEe5u0t5mNG5mReOmmY5CUpgGYmTEyOZrVljSv4YvMNguacg/8G6NL9dClTHo0u7ts+vioZ LoKdbWXIBLEG5GEV82FmtGWo3YVArmfMJayEXGaG5Asm7md//udGxmmB9ko1kWSZ/gyKxr+QfSSG 1uQ3fuh0dQBHuNVZ8JBWSDXtAaF6OAKNS2VK2V9zDumSG2neKmlZnmWgcGd4DuIE9tNcbmB7vmdb XGsvSKWyvl5Ftumb1mm6vpBIJr8DKOifrgs8qGYsHtWiNupyROqHPgMM6lk/ii5cuYpASI77OwMG BWJy/mitFmmuLhjhEZUC3uOx3rJE04W6KeIcxef2zYG2Ds3V/JsmrlhqJWaL3Wme7unx0+u9Noq+ FuovswiiDmzBtkn/wjZXmDBCQ8gHxRYLvdTtLD7G/NVfyq5sy+7qzAbrzxFrlUY0uApt0VbrXjbt 9h0fNVxt1m7txxlvux7ouKZtz+wyRPxrwF7oXwteF1HXqSYUR/gAWCDuXO4Exzan1vo4Vo3h5oaq cwYRFBqSPSUezq7uKWGEG8DutNZu7o7wCHdrfS4Ty7uFms5eJQtv8hbv8t462ca3vEbvzfJrUm1v aH5v+ObbDFtOlaBZWeCSUGAR/lYUxpRsAF9x535umTNwdgYbQqFuBffjcmBwB39wmJbw0vbuXAwG w8jw1pRrDq+iDzfv8+aL9ajtougBEz/x3VbxcsYnRGlxKW2FvhKL/05QBtlTaBt3Gt6bbB3fcR7v nR+XbiE3NrK2ixQA7UF+6SRX8tOucAtHlkDAixE/dCmf8ipf9Ni+cjugAwjuxoT2OjAPcyIsauwR r1zIB079skl0szfP8VOgzpcccFTpcc2Wbqi6cxxHND0PgyP38z8vbdklBTGEa02AckRPdEVndCsX 8UOHdC3f8rw1W+NA8Uq39E/nQaA4mi/rYh8kiEpodVWeV5BOUFNP9QMH8ulO8CHHoR/g8z534FlX cly8Xn7edV5PZl8H8RCf7WCP9L4pdjLX7WRX9oLwUkVE9QN91f8W9VVW0K02R7sjeFWPSVbvaMQL CXEfd0Iud0A/9/8llmB1X3d2v/ixdXSafnRhH3bz3IRJp/R7V3ZV0DvM8fH+Pid/V3jfi3OBn3OD P/iRpWXj+Xb/YAQTgHWHh3DSBnRWkHhEBnaO3/iKf3eM/3WNJ3p5N6n6rXdkH/kVV6EexKD65pp7 0jgbX/mqgvPAFdlsj3mZl8mEf9o8XwUO0Hkkh3hAl91AF3SpAAEQ0PWit/ijN/qkH/qOd96mN190 LWe//+jgtm/MsXqLS/ncWO9/d+NXvXZsH96AsewFFHOx93Y89+yaaPi0V3u29yegj2DOlfu5t3vR H32hx/uJXXqWDPm/X/13qXqaIPyczOrDR/zEv+rgLXU5f3ywj/z/mUd4yqf2krr8u5H17V57Wt/8 WiD7icde0w99uid9vK54vEd9GlF91md9oKB6pcYggvmaaMY/DaKC5TawrgeHJDj/lx943Q97kj3/ sc9zUtqBHxAv+h/+hy9+tjZ+tjeGzgcIAgIHEiyIbQoIYgrpMJRm5yHEAxInBqtoscXFjBoxcuzo cSNFhyIZTjFg0iDKlIBWVrLhctOZmDKP0Kxp8ybOnH9UOerp4CfQHap+IrHy5yiRpDhboRm3aiVU lQWv6CTyJQnWolq3Lunq9WuhsGLHki1rFixXo1lZsJXq1uAUACXmCuKW4e7JvCdNFUmDIsLfwIIH WyvsyvDhxDkU/y9unMML5MiQjdVqt+HyW5UIEzaM6DkkyNCiR2v83Lmk3swpW76sNBNmVaqxcfL0 EcUFWKJpleZk2jSqam6ycxbJujtt7rPKl6M9frRt8LdN6dbFm1pvEViQCHNHIeA7Y8fhH0suL5mU EszRC25eONI0fNLy58cnie3+epStWr+GPft/Us34ZEFyXyHFG042PCDXU8BlNhxtBxqHXHMFMlch hcdBl19KcVEXi3XXkXNZEUV84h2KKaoIHmLkiecijOZNhp56HJrEmXud1QdaafT1yCN8CqEhIoes +dcfgLMtEYVtGUqIYE5wLCiXgw9GeUpxT07opIUXGvilc89taP+jetN9SOSIJsHSjF/dsfjmeC/G KOMkk7BCY435tZfje33GJ5oHgWrykY9+NoQamVHtx59rR15ZDYSRcqlKllA+CoeC01X5VqQ2XbXl pBh6GapaWiYxZqKXCcLgb2jmFUQzBWy3Ipy1yjknrufpkKeeOPJp6EbLCDoKD8SSUSyyx8bhQaFB 6ohoqmss2kA9jVrbKbaQSvplTc0MZWmUmFIrJYObupWtVaCqC6ao7XK5rpjRlslqda6OuIq3d9Bq a4tx5krnnbvyGt2eObYwrCYJx4GswsQmLGyghAI5sbM6HmpvcNM6em246Iap1aXZZjqXuVJ5DI6p 8Lq78rvropr/qof0YhyLGX/IsS+//v5Lp514DqxawTqe4PB8ED/M7J8UV2yxHQLLqzHHIp+8W7cE hqytuDVjWkAPJJe82pU1q9wyy2SP/XKiSsgcIppz/PHArDjr7BjPdVPmNJlo+GqwHRB71PDQDC+8 7DI/Jk2R0QgPPjjeqT7AaNTgYptygAdKDds9DxQASw0FUMu1JAB8DbZOn1Judtmoa4l23mvPjAeW cec8986SGbPCCnVa8kTjHAbdUCODAh6x34Z/FqzigS8+fPJsJ/o45DGhO/nplmMdqW+w4OFHEAU8 UI9LoKc3ukHVll792Kqr/yTrrZ+JcRX62PxdirTTHhnuuOex/z/uuvP+c3B+9yumDTAjyVse4Y6m QOYhMGLje1r0pCc5OGwLfUihIAYzqKAtdE96Lwlf6OxCvqmEzYIp81aJUtiEHVCghes7Xfts5LqZ 1Qxu9Jvd/WznCyfkIX+sqJP/etervRXwIgc0lsOUt0AGJlGJEhPJwYY0s7fkI4K8mOD1kmS9y33w g5lThuhGWL6baE0fpkOfCleoRha2sIVfSOEL4RVDPc0QYwU4xRludsN+3ap2XkjFD4EoyJ4JcT16 89XBjthAJipxkYN6IhSDx4NjPKEyZooLfiBoxXR0bGpbzCIouwiTViijlEEoATQ0IEYSYuuMNVwj Bd4YyzbCsf+W3opj+syQJnlhpo72gl01FiA7PvZxToM8pj+SaQk5/K8cAJTO3hTJyCYuMCQ6qkjD KmlJtV0yZtxU2xQz4zlG1RCLj6qcOTXoRVKa0perJIH5rihPqojNDLSM5RsrdcJc8lNCr2zCCOZo SHeiaRVnqIYNiVlMYw5Smctk5hC0icpnZkYHLTCYIxNYuMJZ00+Bi2jouinSkVKnpM4jkzL4U84y grKT6OykuCAVE2XM4kOrsosfWiXCd8qmnvL83kv3icvTyXIERjWFIZJag6UaQqADfd/M9pNHhS6U oay4KkRrYVMdWIaimZlLHBZCvI5eM5FCmINESarWtbKKLnP/eetJbYQHlZZzE9Mr4QVvMq5xaQ6k q/gmU/8qWJ2+ky12xSMnJehKPiSisaXq59jUqL0g1AGpgWXENS6rVCo4NYDdjKuIUrqJAlCVbrmy BGrlwEytTqcdDHitE2L72nBKhbW1CMR7IEYGSoa0td6MC2CDu4jfsrW4YcxkonpwUApSo7lvnGcG XRrULH6Rpl3bw2Czq1nB7rSwywXl5miRhvGKlxaOhSzK/jnZD2y2vZl973Yv21nPQhVjQZBpKkpr 2sWkdrWsrReIsgFb2c7Wq9J5a2+Nq2DgMti3Dl5wuZCb3FGaQZZfgO5dW0rGvl4Xu1TQ7odBnN3u vhOpTYDa/2jTEIAA/EAK4j0vUds4Ava6F742ji+ONzvfihLUVYcNhX5/gQ98hKLIdyDFW5vi2i4M mMkCfjKBaauZ/0JYyVZ+8JUbrOUtY1mkoM2PBIxUYZZqmHrzZOcps/yCEOeYzSMmMX17UFkzgO8K 4S2veRnrXICut7I1bvONAy1oze74q0kuJJqAeoL83srIaeVukwksaSgX2MBuaWuVs5wJLnO605ru tJTdEoR7uGTMkZPuTK0LAHDi1M1rBrSr/7oGVRbWDR1mah1gobnGNja8HLTsoIMNa2HnuNAH7rGI gNmKXCwmHv2dwZGp7ORpU7rak660paec6U9z29Pe/vaXDf+J3e8y93KHbQUptyfiWLO73SCmda3d Texhz5vegDb2pX0b7uscVghFzkW0q/BpaxM80k3eN9Aw/e1uL7zhDYd3tL7ZwWvtda+plsCqPewU Esib4x4Hw6s7zuZZxzun9j55vVNObHxLhasMRrgzQYSGUqJVBVuldsENrvODZ1vbDHc40IMO6lB3 aOOA8PDmHoDupW8uhKl8ush3GvKpU13jroZ4iU2u9VtjVuUo/3p8Wd7ybwZYRC5HsLSXXPacs33n sIX5sX8udLKzmu52DzrRi64EjZO873z/uNUDP3LAg5zwhTf838XR98KuG+xer/rj5Sv2sbu88oBF +5WhoIX/zXO+85pvO+h53nO9z33vpj896lOv+tWz3u55Jz3iYy/72R8ezrQ3POO37vjIY4H37Z58 Rde+Ki6z7fPG93zok5+NXY6ePaVvPfQtH/3pQyvit78+9hevfb/bXvG1HkjjIe/73pO//OI/v/iB z8vuI7/9y1c+25uPkudTX/r2v3/9TS/htLG///7/PwAGYMKFH/oVoAEeoAGqn/wtYDe4nwN2HjnE HwMSBPHlH/5dIAZm4P3t3/phnQBy3wduHwiG4PxFHQKeIAomoAJOIAlCoAu+IOgxH/9pIA2yTQ0K zA1uYAeKIA96oA/+YA8GIRB6lgkmXvYdIRKSwAqy4OvB/6ATPqEMtk4O4qANViEVWiEW1uAODuH3 caEXdiHlCV72VQEuwIAEJCEaKqERbuHrlGEVGMAEwAAMIEADRmETQqEd5s0VTiHbkKEZZiEgBuKu qMEdjo4ZTsAEfCEYQgUMtGC8SZ0a2sUFICIusF8NVGLt4V4kbqIbcCIC/GEnhqIoOiIbigAdXgYi 1iET4iErzqAGTqIpZiEmCiIt1iLMXIAclgJUIAANdGEpfGIuLqIwzh8uniIN8KJdpGL/TcAFjKIz PuMzBiMCJCIJ4KIc4oIuimIczqESWuMcigAB+OEpwgwwIuNlYKOqzKKBCcInmqM1vqEBvOOIXCM3 5uEqDv9iBlRBMd7FK8yiMmLhBTSjLV4HMMKjPGbANlJjKQRj3mBjLK6ELYwjcDykuSDANB7dQtrC MG4kCxzjL8KjRYaiOUJjJ14k8E3jBIBjP17AK3QiLkZiHL5CO/AiDLCkQLwkHYoAKJKJKb7hMWIi GfbiBkxiz7GkIMBAIk4AHSrlUPIiU1YBNQqkKtoj/5HhR95FGeLFSBKJSQ6kdaRkBoTkBThlJeok VDaiAbwhMyYKWO7kNHLjTyalVCYkVKxlHJYCDTRiHDYjUS4kUn7iWdKkQH5iM/olOLZjYbHkQzLj KYqAUuolUt4lWxRkRyImMLIkWqIlYm7IWFIjMiIlC+j/5E6Z5Fj2ImiKpkDYAlomympugFm65mqi JVMOpRzC5k6qIjr+4TM0om62pk2uIuUpJiYGZGM+JhxGJmhCA2XOJDdeZlAaQCP2Y3LqRUBCQ2+G JTW6pSKmRFv6JC9CJV9SIj0CwlpqJyBYpU16JCD8ITaWZiNaZHuGZ3maYkrSZAgKZ2gy42BWQSzC p1WywDTm5WTiZWQGZRxKoi18ZGuyBWo6Jluwp1SGZnE+qMDhwlxSI09KpGpuIz3SY3hixntiaC8t pWwiZYliBlhS5T3exQU4Zk7qJ1byZyX6JzoGqGYSKDMaqGa2wyTOZl7MZDsc6HH2Y0u2g24Cpryw p0au/6dKjiNakuF5+uZKlOZYrkR0yqZA/uJKXOQ00icmruWWCmWtKWVEskB1niJRcoOS2mVOnmKN JmJ1csN+ogqSlkIi6iRDQoeW2mloXiOGOmiqVGkv3Sgq7ieUFqqglgmaLqqgziagAmcYIiQv0uGZ hkA8ZucbHmJhtqlJvGk8DmZaauhJIGOjvqVJoGanRiiZmKE5CuhKrGUswiiYvmozXqdo+ihRpumV ymlNigA4AkKaHqMjKiWpliaF9qmEsgCEmqmbmqYuWqiZCqWwciZ9TiYNzCqqVCq2EsA/sqU66uqS guus5qKIuuZcDiaMbgA6limkRgexWgZxdpWt0uGyCv8qexIoX7YkHKoqj3ZVnDokWiaqAXQla6oj Ux6iXnamhZJhnNYlHf4kebZoTX6inNKrLkIpsdqogI7lJKomPBbWQv4qknYkljIruUZmlf5rQHLs G3bsbTootqKjnq5mosqsQKRouYJZPQoqRWIpfA6lTtqpRELlZWyqpB4tmTZlu0aqBoRsp4IikQrD WgbkyepnJaoscX6mr7Ymj5pEUpYl2MpkwmJDSMrLVu4lMOqisX7iu0YFMMrhYP4lNrajaaIkXyKn m3KjX6pqdDzqb5LspCaiRSYkXMJtW1RnTzKo4bbFbG5jn17jkpLs197peHJr5aYKh15oOhYtcoJm GYr/qGr66TnWY1iSLsEurahh6N8yrD4KLjbmYuHW5Khuqr5aYzY+7eLSrUnYblouLhv+LvAG7+8y 7Hps4+kKL0qA4rYiL/M2r/M+L/RGr/ROr7y4KgFsJfVmr/ZuL/d2r/d2b4pO6/eOL/mWr/meL/pa bm7Kbvq2r/u+L/zGr/zOL/3Wr/3eL/7mr/7uL//2r//+LwAHsAAPMAEXhAqUQQEbMAIncLQcMAOr hAM/cAdGggQLBAVXMJlcMAYThAZvMDmUQQIkAAGoQAgnQCQwQAgvcGqmsEAAQQnHLwiLcAsjMAqb MAWy8Ai/cAHHcA6H8Anj8AzbcA/LcP3yMAFQQiSY/3ANq3APz0AL6zDyzoAJS3EZIHEC1LAMu3AC OHESi3AZdDABzEAMODEBXDAFl4ETJ4AKDAQak4MahzEDBC8VU7EVY/ETb3EZh3AZg7EYk/ER23Ab v7FABPIax0Ack+8cKzEI23ET57EX8/EYW/CInHEar/EgVzIcP28ilwEQfDEo6LAWc7Eef3FB9PET VzEBEPJAqLELT/IhNy8DxMAWf/IYm7DNiTAKp4kYk3BKJPErlzElpDIoEAAeXzIxD/MnD/PwyjIo 0DIV3/If63Ik8DJK+HILR0IkYHIxHzM3JzP5xvIshzMn83IuC8QuE3FBWPNAnDA3bzMe47E3wzIz 0/9yEk8zORPxOffyFQ+yCr+zMlPCFZdzPDdvG88AAsvyJMeAMK+yFANBh2wztJlzCTu0RIcwRZfz 7xb0QctwNi+0QGyxIMNFMSPwPsuyRa/zRD9x+Wp0GHO0QrfxRzf0QytzGFuySYf0TV80OiMvS5Py Hnu0G8v0/OGxFuNxTrMxFGM08+5zG8P0G+9zS3OyHxsECN8LGFd1QWD1ETPxFjK1Ezv1GkP1M091 VntxCauwViM1+HF193q1Rz/1IY+1SmB1LJc1VRMxA7B18Lo1VMO1REv1XIvwJ7e0Wt+wBue18/Ly YLtxHOeyC9tcNl9xSBuwQQ/yK+c1VAfxIVMCTLP/oWLL8D47NitHNkBTtEGoQGXHcWVvdWaz9mZ3 tvd+9oiEdkCPthSXdkqg9gKjsmZT4CKnJmwLr2xTs2hD9m1PNkHodg6TQ2r/9kB8sgpzNk1HcQoH M3HbcgoDAXTHsU+vcgLwNhGDMDtLcSorcUtvMxuaNCpfNydn93anMhhX9zp/tXmTt3gHs0mTdfeq t3Vn8XeT8H+/d3d/9HcfcnjXt1mPdwjrtxzLdwxcsAu3d4AXOHwXhHyX9xXfN2EveEUzOPAGd7SA MfmCeKqI+P6SeKKYOPqieAbLb2sn8It7cGbEeAXT+AN/cjDfuI3LeG7veALjuIwX9XQPsJDz+FeV //CQP3CRGzmTN7mTPzmUR7mUTzmVV7mVXzmWZ7mWbzmXd7mXfzmYh7mYjzmZl7mZnzmap7marzmb t7mbvzmcx7mczzmd17md33n8miJopq+e5+xA9LmRA/pXse3//qREfrOfcy+HJjr08u1ALDp3ii6f /+oWQvpbWDr/+iHpSu+1XuOhR+THfi+qXi+jA+9j+m5BjDpKvOb5dvo1hvr6qfql3Wb22oI3lrpq QKv2KiXlquP1Lqj3EiytIy8C/OpepsTxFkTZmm/PArtKHLpbJPuzQ/v06mSWDnvfOjv0UqSeE8Sx fzO2O+9D6uOes0e4p2a5ly8ugCTFZoauV9S5J/8vrjevZA4E9q6HwE5vsT/6S95svdvIsnegrG/7 jWL7wBMEq5svOlIitcNFvKe6tnfIwzNvXqqqozu8n7Nv9nblJNJswofjZYKf7t7lsRsvrd2lKbbp LBo6vHmjve+knqf777ZoTCr7NXq778YkYYr8ptc6vUolxFquRnbon+vuy286XYK8HPbige6jvke8 BljjXLLqH8rjf+66xwds1LdmKj4nyFtu67KqKoWktUf9XvrpzYN8gqIlu5pkGa5m10885t4tvLW9 VJI9++58uwvrx1PvZypktV7vOAb8bJquRnK84KKrBnCpRdJA38OyxhvEwlf9S87paUI9p6dkdCb/ /p9H5SxyrWMqr5N+ZzHqeeAKBOOj/pLqJnH6+036OhuiaWuao+gPRD3uLKHme7VTLjUO/a/u+YaC H83uqEDUfl7+vojW48Ejb82jhEkybOIbe2EGLOzveoU+ZLnH5rVL/r4TQPbn7dA/7B/eZdmCacLv ufYLrzeSrvmD4veHIyhSLPk3PPSG7qv/+ZMqr1sO/tgCBAERMKoQIIDrwgSCBgUubCjiIUOJEylW tHjRIAIYGipWcUgDxgSDMC7QIABywgUEtjJewPgSZsyKCE6ShDiwoECaEQ+6nEjSoEeRNUXaChlR YUaSJjNCPLhRpMeCE3bilHl1YhWfPRnicqpR/8MEoQaNiqTa1aXGlVjZsl3bkCkBlUoZzkV71ytd sTCOTrywsSFfBE7bFqbI16JCplbHNhzMsKxhyS8Tjtz5ty4unQRXAj15s+/AoWfhygWMsMpAmrYS jlUrtmFYsAM5s5x8cefIoa5JihVtkLRdxQdXV759W8RQ0xxbsgYqEoHLlBo8g6TBO3ryhVQjHzTr Nfdxw7gAUxwu1+d5zHJpDrRFQ7l4yXYPMkXYVfDfpYhFXP4IYzWH1ruvLJf4Euy6AzXqC4HsFoxO MPnMI6wx2gDkKyoAa2Jqrt+eQlDCwmwJDyyyFAyppA/X4oulxyxc8LsDDcwQovvoC/GqEs17Lv+3 BjM7EKK/uMPRLSDrMvFAx0wbDUDlcAlPIQBtI46omvzri7r9nMxLIZqEJBK4rQI7irySsIzyrZoA JEy/+MCMKU0VrazxLY2Uo+0xpcwcyigpgxIMou6wfBMjheJLTinPqgQOQ+a+JFSmv+KElNJKJerP 0kxhylPTwpLq1K/QwgOV1FJNlcmjQU+tVK24Vo2puvI0RdPNV229FddcdSX1N6OY2xXYYIUdllhh +2u02GSVXZbZZp19FtpopZ2W2mqtvRbbbLXdlttuvf0W3HDFHZdcLgg5l4V01V2X3XbdfRfeeOUt F5B67b0XX3oN2DeLfudF9Yl/BR6Y4ILbQgP/gFrUicODhluZBuIH8imAYjwsDsKUjP3YuAYqrvEY ZBJEdgNdg03WN9+URexCB4SncFmQmHWIZeYMbOYX55x19nfnnn3m+efCFG5BGhCYofnkpJVe+lI7 iAEBaqhtmJrqquGwuoGrtd6kkq69PgNsicWuuOKLL+Y45DXUXpvkttlGWeXbYi7hBgBoVgLmhOne W++X8a757psFHzzowg2P6WUhFKHjacaJOeDwyJmeXCZJGo+aE6+vOILzzTv/HPStRdca69JN5/rr sB/4YvUH5ngb7rhXdltewP2+PW+Zcf87HKQJlxz4iYKJ+nLGg/k9+OQpn8xy4o3mJXQipJ+e//rq ow89a9K133706zlvBYzlZR+ffKDLPx99XG3XPffd10ce/qsOcN5xo7dR951DztE/fybOeed+ARSg +AgIkxLUT2rUsIL1FthABloPDp6L4AQpyL0KXhB01gPf0vD2BA8gcBm/gt/GfoA2WpQtDSXcg/mY EL59OeEOK7BEKGj4BLulD4fDel/7eMi7ghWteI973ODqpj8j8q+I/fOfEgFYQCcGJYg2UKADLVBF K1IRgtjD4Ba5KMEMdm6Dkxke/ewXtFWosGM12EIT2DgCWqSwBO+rFwxlOENRrOAOTsgGcwDHR+XB BIZ6fCLlapY3vqHhh2R82vHw10RH/m9/SP/8wRHDcIgwtPCP5MhkW5pHvAYg4oqhFKUDZVBKL56y i6lEpSmnF0bJIJB4jIwf2j4WhCYkwo16eGMaMMkyftHxF8HEoy83OZk8sCIGThjkMl94Q/kF0XGy BN4jk1hMa1aucUD8pAu42U1vfpOUrFylKsk5Tji40jBApF8LCoeHWm4BnrjUAyjdSIs+dkEFdZwh KDLhx/g9AaBqiJ9k8vAIZTKTmXHEyvyyeTlpMtGRA2XDNSmKTaONsQGOcIAqNspRcI5SnOYs50gl +ADaFUadUKuA8cbXgx68QI0YIxsodfkDQIxjbzScoSXysEeJ3lOhfcxhRWLIAIQmNJHQHCL//o4Y yaZCEqoR/QYmj8q8RTqNGBmNwg58wNWtfjSUISXpWMd5BqallA78YOksPQbPeOYSHtwcgQ6AkcI0 jIEfZdinT1nYVwPArKLqKuhBq+pEhT6zodkkYlQx4dQiPtWI+ZvkDXbR1AEGVmiJbUAKutpZr4I1 nCIlq2hLetK2oHWlZXQhERlBBYzFU5cUmCc8dJmGAqRBHsGoAATuCAQVjOOe/iRcQIU6VKImUwuF NSzw0OrQaVJzqpCcbCWpW8nLYpYtT1gnZ2Xb3a+CNoujFe/3zqrIh7LWrR84YS5ny4dEUOwedqjA MtQhhcn+1lw/faFEjWlQ5S53oYpUbWCh/4tdqzrvHtz1rkdBGlrSPpikJl0aatcq3H65NAW2bCNc S/le3drhBHaVgv9UgF/DzeyMQTXuRQb73wI6UybNVayLDZzd7XKAjZ8FZYPDC2Efc1HCYnReas87 OGC4FRYbHgE8OnyGYEgjGPJIQ33t29gqE1OiODgsf9nSYhoTEsYxYSg0i1xjM3PyxgvmKo97/GM3 l3bCQ67w79CAZCV/oQHu5QMn6BDlEx7jB1JIIcsEjQm/ErFh6ljxS4DwiJ5yML80DjNMsEpmAp95 eUNIs5rB22bvffHNnkMnSs0btz08w85t/EIpFzi/e7y3tpO8raHtu4BeDvQEJaDvolmsR/8gnMy3 QPC1sInthGIbVWaRVvayTzzpl1QamgbmHVW/bBHtIljBOmazp0MdYdOyhcIDJtxrU1C2JrB6z0bT c215CUc2YGIB9o0f4IRwAh7woLjHITazBbZvvrLv2MYW+MADTnAG/NuHWUBkgIXoAUlIQhPitiaK fUtcTNsY293NcRF2vG2xghrk4w3yK+UscX5dI8MapoAb05FnKzTgcetmNxhKcGVB23reHBmCw7nc loLyE9hGTRrCfWrwYRM8XQtH7OMAMASnLxXSRKw5GW4hiWpf5NqezDanPR7yj3ebgiNPZ6n7ukb2 rvzl0rNBzGVeW/8F2qbwjrcI6X5T+p7/gNq8XtfPkybspCOzXYJcFwxNfFBK+L122TB20pNKjBO0 AGqjgPp1T6yzqU59GB4gw6+vThFNZ3zl2u70A0PKbfGKndSxnDPQmvDNrrIa5iCQAZNl/sY+/NXm c4dfzTw4BOxm4+d8LRjiH9EP5Pq6+I9gweKzYQxWPDoP/dBj8h+deMYzHASaWIbRNA25qC8RYU+o 9zLsMQxRINumF39J1qNWia2Lvuul//p44Sxk4hFZZdf4wjdByTkrPM3l9My9Ym2iJuvtbg1+Hg/f eg4rgi/olu+YDAoUJND5HA2ZCsoYOI8LnK+nYsAC82BeFG+/sK8FpgDEhGDyNOm5BCf8/3KrBZwh GWKQn8hAHm5PBfMNoT5P60IP/uJP/sAulVDvtMjOfLYgCcDJ/9YuAAUwtgaN5gLtACfq0KjO6epO 7/4KFEDwAaPP+YzB0XzLCzEQCCowv5wAmRzNv7wwBIuu8bIPylYveaZNYVxwEGIwBochFLTvBPjp 4HDwzNgPAN+vBx3sB7WI/vxPeoQQ3BBs+7yPcCjAClxgyfigijyH7WaPEmmLtnbJ0J7Q0FQMedCA B5zO9xgQK/rwAZOvC1nBCx/BFV0xAr3w8IrPGCYBFs1QC+MFFZUuxi4nEGLhBKCmzCSnD/xmDp+M GWBQGfMq8/JKDvrpZqbgBqcRuzTt1f8K4B5kTxA7bvQK0RAPcYEUEfuM5hl44MnwpWYKwAw+YAeO MAkiyAWKBt0ycQBh7Y3CBxNGDMuk0HzqZQjuzQptRdgOD9kq7gsnUAwPjxVv0RW7sPp0UeicDSPU aQwWJhDgkBqDBhjyoRbQ4B9vgRkO4MMGoQ6TgRmHgRnziB9N8TbUwWhsoGuybxu70fQO0XM06NvG 0WiCscw2ZgT+ACgREQRgMh1uKa4ycbb+rIUaax/n7d5A8QqTbhGm8gGbrQwFb/kUbyD/RQQVrvEW xw1TEHg2kiM/EhlFkiSXkRn5wRkgIBSYciUvrvu8RiY1bhAJEQhVifTEcekijwf67Kb/+nEPEiEo NycJnmZ6PoAekXKedGkpgSsuBZMjzFEIpK0jWVKwhE+5ulIiL2LMSrAEUNDkDucHAsA0F+Ys0TIk b+EO8yotB4EfSCG4KC8jJ8MlXy2+6CDBvGq2aLImgXAvS2bsYgkFHbEf8YAaUMcC4CCrGsiWFjOu YksPgGsV8m737E78/HAyEs5gEE/Srm/ppMHegGgYNXIBTDMZFoAOX1A11RICngwG88pulkj9WEAH YRIE7sGzuNE3vQ7sHsiKCiAn+5IOzHE0XUgxj+AdL/EICuAaoLMep3OFZjMyb2bnAiYqsyJhMHME aYwzG+8E//JAf6YP4g09qS6+XnM1/xWBNV1Tt5bxGTnUNnfyARohP7+L/3zQP0MNQK2AL3uReD6P nSRTBwoAHplTQRfoChJhMKEzKYl0lkaxMmUUI/CmM+fFO//rQ0kwYYQ0eEo0AKYsPZPhDVf0RV8Q JdkyGWHwEkySylRSLo0Gvm40R/vzN3mUgX5UzGLp8UYUDbhmORl0gdToKKFzC6AUfp4AyjA0ICXj dqrSQ8ETSH1xkUyxD+oqTKXAHhrGDkLSTF8zr9RqTW8BPc1PFPCwKasRc1wtCkTJTu90R2NVTymN TyGvPIEBDpS0OUkJDwChUBuItlYLUQmHBqeUSi1ibv4oSzczItswGDhVLEkUU08TJP9VU75Isj1D FS0TYLdM01QHAFVz0C8BsFXr9FVj9SY/bZWoR0DjjHjubUSN9Aj5LKysoAnYABg0kfb4oAYs7DpR LMQ8IFX1zYZ8Z/iEbkCfaBe/UhpFszx1ZsqmNRlyE1vL1Fpd9Fnj0x7U81vPD9NQ8B7woBWcZhPK 1VzP1RvT1ceqZ1afjU/J4EAZoRKCclcjcXq+oGUQob34wJ40QDv/KdeO9SIE4TIhVUublQTHgPww cme+oa5SiFo9NZqktlNDEmNL0iRFQWvbdAA8lpluM/Z002QZ7GTrlfRSdmVZVjhTL2r6dEh3Rl4D tRKtp18nkckoYEKF9V8DExDkwd7/hPZNljUWuvTeMm8M8FAOZLMfDWZLl65hRpFpdSbQInYBxpRq oaxiVfNqneE8IaBr2/QSujb9vKHGLjJkR5ZOybajUPZs1fXBbnZthzBqMvZAAfX/pCiLguCvdqwJ +pXf9nYcKJNR67PfEHZoQhV5k5cfRmF4E/ZdFpYENy8YR/TkJtdE7fBys9dq1TQZT7AttzZ0B2DE vnZcswpHz7ds8bJ18RR23TVqhmB4ygwWDPMKiOFs50oH2hEefPdnd08I/rcUARdHfG0I0jR50XK3 Drgihw5pZUIHoO0sqffdJus8421j7TAGM5dqYZMfUrMk5UsetBZcodHMTFcdoaYS/9B3ddNXfWG1 i6rHAu7VfXcyftHxr262ATiBEguTehCBI5asZykUeP82Q4nkmA4YlhIrgbl18xLPfdiQS21GUY2z aZ22bip4AQbhPDE4AOxhEDC3arfXU1U0JPEwAAYgFGozsEwYG1NXhVl4fb9RL4HV9WJ3ETFHRN9W cObXHTPHbOFxhbbgDBih8hKVU59hYE9FCeQAeWUssbIJeRcQXqaShyQVJh44m5CxUifZSm+ugrVY 0NqUTZ3BYqu2g9tTRXmrcnPhqEyXE2wA8kq2bFnXhSeoh/lvq/B2hqXhf6EsX2ogHdyRCOggCZSU h3PVBV5gd5XAZ4d1cfcFgBWNeP9rhxQUQVuTWKmCKFRHwQ93J44ad1IPIJqjFWeM0ZN5Scoq91TX NIzDeLfGmJRfk03vKJEzLT8nZnhkeYX3mZbdzGa5ybNwLKDLizjFMgiA9R5wN4uKkgr+qleduZnh 5yH7t1JwwIDB8pGzWZvLYHmlcWAEjxcv+TPV5YDsgJkr9O1q7uY8OgNu7oO/2IPduc+uVRlB1wiM 4AbElRNO2I35uZ/l2JZv1qsEmqiLGn/tr21rGF/4uPUOIFeNuTBzVZdfABggOucGS6DqmS3MgasJ ZgoYOYFn2pHrB9rIei2buA+N7uigMaRpVRgv8gC0SxoMtpxTeqXbRR3guZ33eoP/WRODbxphB+k2 1VEeNcqnfbqF01ZnuQrHUs4EHPuxi5qg3xcOV23NdLjNptoPrDqif8cBBVgqEYbLgCAS+GGl5mum TzuBV3ulwNhaRdK0ORpxC06t6dpxu0+uSbQYVTqi+IUnM5ivS7mUE7hrWflj5fQB+CyFD/unuSgS F5sDIrsOphuyI5sHowAW7Hgco4wn8cUIm4GNzOCTeDiqG3RCq7Oz9za9ZwarCaxvThpewJotlXbM NPpx2jOlWvskhaCta8d5hWfG7NNPd1sidW2mgfu1MTeeNxi2b5o2xccld7oSyJW5+/OFhXrlUu4D Npy6O9y6i3oHjprk3lWpbYYK/1qvjbqGm4ISqg1TvV/cZw1KcHnNSg+JpdXFDE17vg43gjX6We+N /MRvjNLqyXZrDO6NI726DWsQfkczuvymZ/ogt/pslGOaprXXaulZXNlBYtjBfCv8j4E6Sasolx+7 wzkczZHsw69bxIcz8gCgxHMWvFludYqZfkMqb2F89xrN0bRaaMIv/JS2YJevtPlBafVQJLE5m45c EyDmyZxOE6DMNZ/GGYu1Fn438BJpGTZ9FORBcZwcxRCwnFETLbG3U1kby00ZsLc8q2LZsFW3G7lH egBayaZbY1oL19O8uqObBzkAuyc7+xpmwEZAyTZBHZvBBQwztNBbzw9NA9obtP9DW7QV9XHoSxIu +tAxOqOrvdOfzEAh/Vkn3Q7wEMntzepCsL8nMthPgKSjtRhRmojgt2qX8dTfU4PVqd5JNReaV1Wv 0dXBfG7X9bm7yszT3BDSKNdv3cN3ndcJXrsJtN7y016UIMnqCRvtlghmthl22JSgstkJZ+DW+zhY hpLzWoiM5wAYPdvLOrHwih8C4RZCNr6UgRQeL6wfZwbkoFj/Nw743V2utCKK5vFSXvy6j3DenaLJ 4atLXSSHvkUTXbhPPRnvKBmsc425D3WXG+DDaeB53eARnpbAXtcZ/rpj+OEnVRg3OQNqoOItpkaf Uw/CZl93mEnh/Zn3fCujPfD/II6sw7jRR4FFFb1xqC4Y6OZ/l4GXd077aHgB/3HnNcHn2eXGRdrx irP3JA7pubJl1hPKEPyLxXq4RXJrF4B8Mcd+3xisOC7Dvz7sxd71FX7h13wH5ArY31DiTbztf/IB 1Au88SwRft9QC9nZGaACJ7qIRx3xyVP5A1/wn8YcW6Aj50D8IF8dWHSMNO+k663TeT7E5m3yaZVF 2d3ExW23hRh5POilN3XBg9udtdiLq36ZLvLkxbbCGbvgD/5jXj/h9X//AcKUwDpbUowwgZCCwh1R HLiAxSIigYkUK1q8KA2ERo0ZQRwABLIHrCAkg2wq0CMFtSYF7iXS8xIen5i0/wywycDFZhacPHv6 /Kkhm5OhaoKCPHoxqVKJOpk+GQPVTkepdKRRJYY1q1ZicYItqyXoyRxlo8SeaHE1WBcWi4RoGgWX jNuySpjanWJ3KcUDXDUFq6XpqUeffX70uUnOm87CiBfjZTJkELNgdgYlcwZBkWa0LTqnpZoMsGZ1 eZvqPU1RHTGXrTJWaogI9g4OChF+uF0j9zXdfgYy+s0bePDhvYvjvm0w4UKGFigQKo26YkeOlAfr uD6yZCU8Kb+wdAmTJi09Nff02GMa6M716rPleZTNKNLo9O0+AUvG62erV6tuPTsGWAAM4ZY6BI6C lkbLLGJAJnPFJYQ6cg1RV/9peNWXAV8IVrfRRxEB8E1hhzUl4g+SjPhhCVMwocQCklkmmT0nvFUW GR7cclZVB0xmzwKkbGgPJtANiaEyHh3QSAsgvCZbbQQJRJxvBR0nXJRWVklQcsr5wNwIRNI3HUd0 WAeIH9mNtB1yBdDSCi9rvkTeeOWV1x576oEExCN6rnUnhtFViIaB6iTIn479aTUMP5EIeN8Qkhy4 THWBrOXgjBBGOKEgFn6JEVeBaKIDGVl5uJhhTDFhKovA/MATMPeBCJk8Lk6G3zJCkDNFhCW4tWMy PcpzQmQViOLjNpz6OZGRDdwzTTBLOsKlbU9CSW2WJR007ZXaSjmllrR965D/c24gK91GR45JakrX nmHcmw28mUgatMyLR5mJMGJnn+3pmUd88s1H7rERXWeAWLz2tyPCw0QyA6Un1vJofoY+8aGNll4c SKZ5oSHwXn0dUJcSopLaoIkoNhgiY6h+E5HBrwKwq2SksRVhijwtMGFZFJagCLGhvdNxfcoW8IBr 30prrbWwLO0k0tUaB3XU3F675WxFXN0cN0EnFSaSYy5zlLrcEd3uvODR+wO99tJJsL6N2elEv/8C jGzb6RG5iFhKjpqwjqPIAbiNgZjFA86VQQVATjjwcHHjGf994cAcY6hhIHTAdV9VidlU2Kqnsiji dYmz1ahYJZCSTGVCLiZ5/8gEGnhiLDdZ7MwgM98dMAuqdcjV0VUvN1vTyVGJRfEvHI988ugpz3zz u/UC/W3P5Q5ImOYGA5ISYpuJ0nHuor3FvMdv8RIYRbld59voY6ii3R0/dQvCoDGu4+M0IuiXWjk9 danjGksUuT+BRhrqUBEAyEQ6YDBBMSULWcoyACuUQXBFT7EDGTjFMtlViIFduMWwJDO6renFcqMC ARno4bwUGsJ4K2yhC4lHpRgiZ4YEAQPShmcQEXbKXB3K3ge405vuGQcP85JBK4D4g4KsDSYfyJf7 1gdF9p0ugnw6lvbUkT//YIVDXolUZ1rAuM1ccH/3i4v/GBfCydXHDiCgUf/L+EIyVKVhgZsb0YqU 4EDoiAKEOiSRB8gghRYMoY9LIeEWl6ScNQGPJYxspCMfCclILtKRH5AkSwh5FOv1sGQkCSISzyOS 8XCCFp3bwgILcpDyzQ13q4xi3aZowEc5SlOs/FwtHscXvh0KSX6ByiBpBhUzMu6MQijBh7aWETEm E4EFU6D6QNc2NfrRMrWs5qkWFEJMWsSQ/mmFtyZZG99taZziLKdyzqmcXoRTnHUYF/U0yREfgtJM PagnFewZPpjco5TmOdMDePAMa7ZyoHQjFwVhBjOJgbGY0sRbF8ISCEKNaSsJ8wpAbfKjMzYOYxGk XBtFFRgdHDCOsjoZBxH/wzJn2kUetNJmHVe3OZcmi3dt/OY6b4pTdOp0p9jKaR2w0ARzUiAI7swd PMn0yezgs570YtbKUFUSomXsfOZzpVWliNBAsXGLFi1gJqC4K79ocaxb5AEtLQaXMqb1LcEs0BMC GJ3KgS0WADiB5pwyx5NyjjDpYcBlnFFFgcZUsDLlJhu9eZCh0vA4PeWpY336WEMEFZxe0uZEt4LU IUqtN0AMRgGeBwySHAMPLpvbONZx1YIaNKtoQAMPtkrRrnYUbxKTX1bM2qAwamaja+3iMAORzbhe bkYF29sgBtvMZ9otRHkJpO3YIlMtRPcihu1dOYMHrslq97rAQ+d2c/ot/6A6CXoJIaplOZEOOPAQ e5zD5zE2695RQjUIDH2CJ4oRUKquArUEJWzu7ngDA74Ws7F9CyloSaSDHQorMzvQMDqj1o0uVC7G 9OiNqkKaWhBDf0xJGx1ZCaK82IOP/i2xiZUiBDEd1qaGQKVihaM0acHihcOD3gNGgC8wYKEO3z2n eFOwQiD/eHpGbYAjXGCD64VNs5tFj2HycY/QSpkBz7hvMTLxDBwojgrLS61qMSQI1rqWQ2Qt8N8O LN3mDjNSYwUZWyzlls0Ec868LWbQdJBMi0pCC09gZgK/1L5pJuPEhKZedRGLLeV1UtGmVA49wqdj KIGhkk0MQhOKRxIU2v/U0UG1sXfoURsiB4wORj6yktez1Nb6IcvGEV1h7vGXLQDRyp7ggife2lon KtfLf1K1qgdM0TLHFpBwzQCkxpDLr61FDrcYzbHpvNsZtTW4qMnzCXTnrA0DxURPBBSrVhqj6RY6 Oiku4Y0TcrwmrIS8LGkiIxs9WRbwmBsqYcgKi0BU2sj7ajuwxQvAi2Ph3SbU54UHtBowKqSMA4if 7KQ9g7KqD8BayrTGcjTequv+8vo0eMyqxZJ9WQIH21ZeVZyAcrRhHOmulzjCFJCizVZpg5Hap5GK tB8zMtwh9HOk+8kUmi2NG4gbudMtt1YQfWk3WHqR7g51Yr1kgiYQopL/Ud+CG4bKgqH+eyHtBLh4 KcBCyWL9vDJwhEESzh5n1hMH9fxk29Lgqns0grTFuG9A7b7xvFtEpLRcxOIoox9DTUXkZi7gnvlM CkkU7lW000RbAQcVOa9V2mW5c56x4oEplEDbRC8RdG0mYhgJfdykF5qKQXDuqhsv0uElAdfX8PR9 03uoqsi3CbIOb9V7XSHsnnFyRE2uifICyJyIp8L3CzW398RVx/BK3euep4t3W+//pWJk2uzFigp7 +5UBZOK5gIPEh/WL0Q6cbi0a+WlbnsBKYu/AWheih01xg5sbFI7sIYWhlx7Fp0c6doNQA0rHe65H G1YXTlMndVS3A113/3taF3UDuHtgJ3af9XuWxRH3cg/GF033NERIlB7M53zPJ33Ut3+OEWAddyBh tEtstmDcx1WQcwP50UVy9ngbsgyOB22jQHN6AUceEHKcV0uhM33k5wxjVIIkSF39x2O8t4QrgYAL aEMFeHXeAXXOUUkFAHaux4ACiIU6FoG9B2pNYF7vZC4NUHx+xne+VhLn0RR8YhZ2EA11F4fTh4QG ZTfwMwYFZD/IBni6VBmDR3gaAUgRZShEqAjBYiO+lX7pV2Fr9FFeoWJ5hwnMgDN/dYSXmITmpiVO NoBbMBsB+Ho79lMEGGkfgAVu4Af4Rgiqx0LYxU5f1wso9GhBNYZGxf9DaOdzyMdZQKQeT2AjdKAo 0bBcGleHS9Fxb7chO0J+cyEoyahiLfgfQCAEcESNUgFhOPhFurWIOrh+fOgivnJXpJd5lkNN+oeJ unMuKxaKskh1OHYNPsaOn8aOSwdkD/hTLQZwjeVTLnVU7qdcmtUn60CII0iHxVgfvoZROHeI9FNR lNdb0BiN0wiR1gh4vMRyi9iIYPIxlyALsnAJQFh6ShBu5oiJoqKJ2YUQRJSPtaEH32U1KAmTjvV1 TMOS7WSBt4iG7cWBD9dfmcAXbViQ6BNYX4ZVXUAgWuYgg7QIb4FlgJd9MyhRBDYHonE4tmVm2xhM O7gUNucsySALRsD/DDmZWjxzbSQpbiZZKKn3dD22kkL1WG5pAurklkU1ajgplj2BkO1xWhAEksRo kBwnOoTYRUjyI4owOGsGchPpEYmnCMoGANXIfWOgjRiJTB/lDB4ZAKJwl1tzjGkoEQRibBQCKpGh IrLABGHAKgsgC2FgLOc4U4aCepsGl2+5lrXZlg7oWPxol/6ol1wWkKpWMJdzFFQllBlHlLkjCchG eIWyS1TRN7d1S31zQT7pgvzxFsoIcyeglUrRg4SSOrzpFEKQQQkWIRP1KBxRlljBMweweZ+iP6u5 mmEgn6bZmueIllYRm7dJm9ylnzV5hS6JEmtwk7cInumjl2xXIT44/w4KV5yAwADGST1DonmKt2aB yFV8wxEGgnJjEghsgRYT2SuaUIg3KJnbyTUpVxmRWBoAYgdBOSNDYEI7YjmSQBksIAkaQSB2AKP5 UZZh0JHbsEDyaZboCJtqeZsMwW+W5JJtOTwvMCUuxEK6iZMFCqHqAZwhgxUNuh5A4ARlQhQacJwR KkE9YSQdERjn1zUZYUG3JKKC16HrKXjOSZGO95wJEyDr10ULQAy1g4ZTQAeJ86c/d0EHsp5hBaMi czkg8JjYgz+BIQ12lTozcwhGwJossAuryUDmeJ/q6FhJ86TRA6XEkUIkUFWk2jzdgqoBOqAUNZxa iperlmtOZkLZ4/+gVdoFk2AMbGAMk/BVrvmBsRRmRqed/tJxowBbZfV3G8acb9qHdTqi+VMdzlkL 3YggtWMZfWksj1kXKgJGOmqskeEo93eoKcYDHgECFLNQf1EVF0YxlkqpQPMOPlqf9pmO5xp2q6dC 2/I01HIla8kciGABVkANAisDBVsAAkqGJkSuatqquwahuhirgFCu7Vqck9AvecCrvkoiKYiNymkH EeaxOpKucUoVt7IIFcmczAlGXnSd/vEXlfkWzuArMouGT9CiiYEGLToEjndBvBQMwKIaiGqsrwU2 1vinGJYRo+OjpnkITUufvrqpxHAGSNqSSrqk+eipMpQ0wAOwAUv/sAR7sDd5OsRQV5splMWBfD2x IwsalDvhBP2QDcYABHLrl9RTV9nHh1FplSIbrSmLYR5KsnF6g7lkVo25rhkpXMrakR6JrTZ6s7mi swvFAmB0H4wzrhakqAqqI+fqLJv3p2wBn/OJqRobtVawAxagCrGRpKtrtZD1qVrrr12Lul5LBAVr sHQZfDhartNotm2LtnvZIA46q0B5J7naD/DRpWAapgEjMjeiH4Hnt9jnrHLqHxmGstP7sW16OWVr jYjLcYkJI31KDDhxAK+1csQFMrmCOW20p0HrgzPKACakoJ2Rray5C4cApLswr/TKnGaQurNLu7Ir wKpLwKxbXq8b/0OxC8Bfa7u2+wDAhyyDFxnO0gJhGpS/u19tk2Leq7x30qt/eRcKNpiBS8J6O1bW 64efERUM9pjK+rIeJXJUqqN9VgIHMCj8g23BICGAZI3ac227MiA4+6B49HkAtiu+yMFFV6+VULtN /LUBPMAFXMACh6oullgtKbsM3MBXcARc/MCrCmxU2ravmsFErLZi/BOvY2c5obGn4p4jjL3WYytH xWANkphtdjjLAJ3ZVhWH54gxjDuqoaM2CkbGNjr38X4fhjICklBv5ShpJZo5IxfaOaQjcxWbwAtd zMWavMVP7MlQ7IrYopJrWQBYM7C0u8WbDAer/C5S+qjTUcGuSv8YvNGZy1erLqofmQfCd5F4csAD m0GRcawjJxKyKcusy+mUe8MVAGC4FaAISbyVy+mar3MCkwwXP3sWEEPJQJsxZlFslxi1TOzE40zO 5SywXqu6SmoG65zK7czKNgDP7xy2CavDjoIutCrL5lHGtTzGHSxB+9zGb0SDyTzQmKUIdaG91EsH pHGyMYydYsXCeXunMMx+08yxEWYw8vANO9s/00p00VWuzInJnEzSJd3J5wzA/1u1K23KWqzKDfDO 8SzT8dwKuIsswBDGety7vwnQZsyguwxmy8XRvxx564qVBs0gPkh4xzxyirhVNryUdurHAmSXjetQ nEIgC3WdSvD/yAUSLAZQTI8CYP0cMHGwxJn80ibdzuac0i2NygT70jMt1zM9DS7FdqdjkgqyvF/W ZSY2jKLzRHsNmHj0UBAEMcZUV9lrFXyIg9XMx5iX1BDJ0HfMtyvrnGRwA8o8yBSNWXHk19smF9rD MSZKWIFNLiFdKCMd02mt1mzd1ujs0nE917Nd09qkhrFCB7HM1xvoa+vQ24QN3HxX2qYt2MYYZoWN E68CuEDnGdg8skenKV2h0H/bwmQFlfSzx6Pi0X9c0XeWyENqIfRHPWYt0qvNyqzd2igN2+sd2zEN z5zw3vFN13YNSx03f8RJ3IQGzcXN30rhd8ctXaZzDJVoOJ6R/wz50CzO+x/RHb0cCridPYPX7DcN rab7faKALDD5Lct9NJ4RSt6prdrnLeLo3cDqzd5v7c7yreIqXtt2ezoPBaz9XWKBJtgfjInB7Tp4 CLTSDWEI3iwV3UHYmZhKGT+xFeF6zB9zwAXGukXbTdXbR7wBneHEq3kgfdYjjuUkbrsnjuJNLNsr DubwXNe2/eITdFr8JeMW3FDHSQlG0ebnONbJLRqXcBl07lvTkDMLtiAZkNCHYrJFflmDGylsVSgA ZVfoMtXCRaIsaNVSDqRacA6RLumtKelNS0dVLlMfzh8wneWdrspbzuWnLOpe7t5hruJcoTUu3j4x nuZRfnwa3v9Xb568rZ4U/Fy5LXd/N+h9FCaRFPVVfe6mb6am6EKn1yjRbTVMTq7oi3d9Oz3c8Drp 9YkJTUvt1Q7tlR5Nyp474Rzinv7pJR3qZyDuaN3ts22Gy1IJ6d4KCE40ib5arFbftP7TJMK2NS7r GvvfsmMWzJIPl4Dnuq7NUwnsnDfwgDc5Niu912jNFjM4UrAACzB63I0kv+jsmSo51Y7xGS/t0x7t +2ul2s68j8LHnG7u5v7tou4dD1DKTMNwa8iv+vq79L0qsETjIenPMCPvcI7jWVC52avVPItWKHtb EfFadUoZJvvg/EHQE6LGQpCZdB4AIM+DLowuWwSU2F7plp7/7RnP8dCkyB5f2lL/SgglkSSP7uqu 8lioVAj8PPhqqm8P96War21PyzJP82yX83fj245eNwDOIOBXAtLdS9OQfoRPfs9JDA12vYtN4yE9 Z3ksKw//9JMP9Ra+d2qazPd88Vxv6Tfw9Q5r8z4XXaItZqG6G6N6r6iPsKsv961/+q8P+8Vh93dv wSYWYnmP+2zB1bEj5xcJLHR6zXCcSy8c1dCb23+/P8bebL4C9ZdA+c4P/VG/fsGGQB0P7WAf+rz9 QI9+48AKK6mv+n0d/qnO+q4/9xyIHmQuZjW/24R1+58t5VPVKjKI4H9k+H/kvIf/oTyg+wDBQt0B OnakHWyx/yCbgS4GWNwIRMbeJYoBLF6smFHjDxYEPH4EGTKDNBAliZ1EGczhyo4tXbKEGXPby5kZ mCi5mRPnTh2xbMqkGVTkUJEljB6lsufFUqZJmz6FSiKqUqlrql7lltUqVqpYvH516lQoUaKZkPpB CkjtWrZZgLaFi2MdXLp139olS7ahuicN3aLxIG3akyf5NC1rEczD4nuJgz1+TCxYCRZ+h5BUTEaI kFp+K9dagFH0aI0VOeYtKqQFStZ2xr6WqZPn7J93Yd9GLVJJLQC9e1B2A2ar8ODFjQ8nnlw5cubN uU69VkM6Fdyo0cg9mh2vbbpq1snlwn27+NxlF/EV1BLA4/9Rc4TEYTwGscGCrEseAO7whr1bPDa/ t+cGTASUIjTSDrzIQIpOK88j34wahSCUyLmtJwtpu5C86jZscKjdsisBw+dGdK7E405EUSsVl+PQ POxAHO+v2t76bh3vNMQxxtx606y3DARCiD7HDrPvJMU0OeAWNLRgchFSClSwoigTRBBKKWq5ssAF c7wOxBKGOOEEEcdssUwzO9TNy7C6go5NN9uEk8QUTURTrRrV1DHD7saxkZIbc8xTR70A2CxEnwZq 7cj3CFJ0CMKszHJKKielNMFIJSWDwQYf5K1Lo84ENVRR0wTxTTnjNPVUVKEb1VOqfAv0xz37DO9P QG9FUxD/NAoVEMhEOdMCB76yhNRAYytFMFllA8hvUy/TwrXCMb/JkMxod8RTVW1X3bbbVq8Ly8dY gZJNjVp5EjTdOj/CKSJJAOgpkJQyI3YBKI9dNl99S7OXyVw5hXHUoKgleLYpCpZVRIEH5XTNVLn1 FmI5RaVVuAEzUWLc2B6+Vt1NY3EU3nAMKEETef7DN2VkV2Z52SsFvFjWDl1tWCidKkM32owvpJYh g3de2MNsJSa66GpTXRckcP8Cdy6P42JDRg30fLrqHZVAL2GVW+Z6Xypfjrncm1o8GGBYB+5J5J7X 9vHnGd+WmUagO2b4QYXntHhFE+emCm9vvyWOT8GttrNv/7oJnxnrQA5u0uuu9bUXbLt57uLimMme PGea1KY8bf12MrRsn2sL/aEpgl73Q1f1Zr1zmgync++JY69z7Lw1d+vwuHVHXGlBChP5Icgfr1Ry s7s0Z1pdbU986cpv3tyl033CyXTq+Y5l+tM5Z5zx16OuCXXfkQ9eW5xhpx1ntP9Ov7zOq+89d97j zwv06YV3XFJLiZ0c5+ObdtvIBIi5n3kveuoZ3c5ow70Ckmx79wuf+OqGvNbJ7nwVtOAFY4c+ih2N g/SbHwg7kryfpAd/+QtNGlTYqcydzWcNSx4AW0g1Z70Pe+pDIO5Il8AG3i2CPxSfDmT4Qb+1L4is S9qsLP8kwhAykV2LcN4JXbbCd/1AXC/0VP/KRr4CunCLu7taF232I+wp0IxnpBAafSjBCepwg4TQ YBExOMfZJXFPYGyiE0UoOil+jX8zVOMXlzRCLg7RftdbGgHfN0b4SQtuaiyhT3DIRvO4LoNGPCIm 3ZdHPXZSaDj5QeT+CEAbDhKLMaQgIbdIygAeUpFiC9oSI0lIHsKNkpWUpSbhqMtdypGXdpQfJz3p SVCy0IQeRCQfNYjKRooxl+ha3vJeCURh4rGaqUNiL2/pS25uc5jfBCaXBjhONy5SlaUUYDnJ9kxb etOd2PzlO7U5T3qGE5z3xGc707lPdlqylsjspyRjmUn/edqzngVFqEHzudDaBdOh1oToQ7+XMIle M6IJxWhGNapQhnaUoxYF6UZF+tGRltSjJzVpSlW6Upa2FKUvdWlMZTpTmpIUpjetaU51ulOe4tSn PbUpUIM6VKIW1ahHRWpSlbpUpjbVqU+FalSlOlWqVtWqV8VqVrW6Va521atfBWtYxTpWspbVrGdF a1rVula2ttWtSkUADCYw1irgAgZVMGhc5/pWvha1rnftK0cRgFcNwEADYKUBAgR7WKnSwLCB9Wpi QzJYhYpAsevSa1ATCwO5buqx5YkrYJU6Abtydq4X2GvSSAsDxVrWjqG9gINCKwIC/PWy7AotDT4i V87e//YjF+AsYcuz2s6qtreE3SxnP2JZzrJWuL8NrkdWu1fbQle0ZCHudRuEWjuu1rdJNC0BEDDX zX43nJ2dAG0nENu8rLdBpK0te5GKgPFK967aFUl9h0JaGthCsdxNHWsPS1n00ra117XselPLXNoW V7r/xcV7DYxfkOhXJMClrWs1oFjHXvYC+t2sbpdr4APTQASGtYVcU6ze1sp3KPSlrXgZ2yEKvxcX /TVvSDScl/Gm10G1/aw96ypd3daXuQSAL5JN61/ATjck/L2ALZLKXfp6hLebtW9xRetk8e41trhg rm5tu9kwV3jBGhgykkVMgBSvmcOfTeyJPWLhwuJVzv+gTS9/lRxbAG85vHqWLpsN22Mkz5W07MWF i3/75b3e1b1dRjIC/CtlolRZaXF1rAiYK2m9YrrNcVUyeePKZ85Ses5ePnSX//pg2ToYuqkl8kfB 7KDmXqAK7uWue++KV8O6FrgiUS5cT71hMLMWvr7mrWmRzerdDhbFNz6xbgU8a2ZPNsYgefScbXHn IUc7xQt+7J3dJ+nHxpkAjm5ueiFc50onWMaCJuyHdXNjx+q2zVpudJCLou9CC9jXE5C2YsF84vHS u7439sinrx1pxpp7165trmHvSmdaz5jJsM5rjHd8cE0/+7AQz3CQ40zto/rXyn+OMJVDXug5r5zZ 0Yb/L3fbfOfrUvwjdBaBoiueZmLbVbjyZniDJL3jXT/20bM+sbh1/GUDfzzCc9a5pJVM63pbWQQj xzi2n+7kJD8WsDTPecrJ22sX2zzodXbsYfus9g/nOK4LnzpJjQ7wuRZ9w4b2MMCbXHanwzW9QeZ4 mxk+WL3jNdssx3Xd5ypn9/L83HBn12d97KGJ59e3QCc5aoh7WcZflvBVV/DTgd1cw0e4uJm+NKXv /GHBy3nrohdJkoNu5ANLN7ZD5vjgMY7wC9++15f9OoTlmnV1Y/zwr93rirs89InTV651lbeKpb/m uhZZ50YFupX7O/zp15ncepe9vDme6tzT2dUgbnK8/+etaNJ+99iwr1/ebU9wgVs20/WWfYVjHOQk pxq3RK6+6iss8BNAs6O1sWs03WK9RKu/u0O74eMuFSs4SAOy3/ov1GItcpOy9So4TfuunGM51wK0 cKoyJhswqTs00lovuYKxcys455qs3lqqFEu3CoS+niMsARMv56orQ+sswHIuLqtBrbMz55uaKjux 5jK1/1suY9utvYorqQMtSiutHeTAq9PBKMxB+Xu0JDytiKO40iou4CouL5wzGWyv3vo6ozO2Hwwv ObvBTjM2x9JBIPPBL7xC6Ls1hLMr4/OwaYNBhYKtGYOs7jqu8lC6GBQwJnO1p6KscPor9MqxqkrE of+oxCTyLsjLlTosxEI8vq96O5Kqq0msKgBrr+vrxFSkqkRTRbZKu9xgxVaUxakKLfibxbAiw+eq NDS8xV70xV8ExmAUxmEkxmI0xmNExmRUxmVkRq9SgTLoq2dsxqKARlWMgRiYRpuKhMDaxmwEiW5M RXD0xpAogwRIAAIABXOcATYzx2p0kHZ8R3PEqnI8RzaLhAQoAwaAR3bZRyDYR1Wkx48AhXUkgHus RnqkBJBASI8wxwRIyKsKyIJUR3JYyHisRn+Ux66aAXzcyHwsR33MSIxcR4MsSHFEx2tkSCDwR4pc xwRQgY8og5Z8yRhggHDqyI6khI9syHgcSXksA5P/nAGUZMd8JICYJAeXhEmZLMia1KqbxMecdMid rK2JJMmfDImgJEiJrMmBpASXjAFoNEqP+MqixEYVyEo7YoByBIWP3Mig3MeAFEl/ZEqxFEqK/Iix DEuyPMqZnMuuYoAYcMl0vEZ8VAFp1EcKOUkVqEeRuMea7Eo/iUpQIACkZEjJRMp0lEy0BMyBTIDB LIPCPMfDpEvFJIrGZEh3RErKnEzLlEzM1Kq/DMzO7EjQZEfEDErSHArTRMdyDAmHjIRt/M27BM5t TEuTxKan7MxIUEsgQMlIyEqHzMtvdEiYrMbgDM7KXM3dzEyvMsoZgEbApBDn1MvKVM2Q0MfMpMdz /wRMcwSCu2zI9qxNYOrO76xH8czLzixPpUFKjOxMiWRP9/zP+Myq+ZTI8MTG+9xI+NQN1fTOb2zN hsxKxZxIhnxIO8LN1CRIl1xJulTOsihP8ZTQ/hTL93xHsJpOowzL1GTK2TxLclzMrgRH3nRRdnHH JDrRdUzRl5xOdCTMFlXIc0xHHqVOkZBRNqvRq7rR8VTREf1MH4XJxRRPsdxOrbzKHZ1MxLQjlFxJ 3DzMsWRI2cTSGYXJlxzRCvWIIk3LryLNID1Kx3RIfyxM54xKBQ0Js6zGdLzIj1QaPTXSKV2XNa3H 6TxMOGXOjexKOgUJOxXSBk1LKzXSHc1JP60qQP+lEEF9Uw2V00MtiwbFzqVExzPNz3vcTqsMJxQd yW7cyKIES8UcyCMVSE4VUlCd0kZlykj9qvUkSi4lzHYEAjytSVL9CF6dTBEtx0hIyFQt1mOd0Cxt x4TU1c/kVV8dz2B9SlCFzs5U1qLEVv90UqrCVWetR3+E1h6tVmD9UqK8R3lcT68kzNqcTR4V0XCC 0DMlyI2U0/6cSMU002Y9ymp918NMVm4Fq+g0KONsKoK1J4NtK4QNJ4WNKtzkKIflK0dtK4qdRovt Ky8dx0TF2LRKRzOdxo8FSIllRv6UVLQyWW9M2UJMz4112ZeF2ZiV2Zml2Zq12ZvF2ZzV2Z3l2Z7/ 9dmfBdqgFdqhJdqiNdqjRdqkVdqlZdqmddqnhdqoldqppdqqtdqrxdoO0Nqt5dqu9dqvBduwFdux JduyNduzRdu0Vdu1Zdu2dduuFYC4ldu5pdu6tdu7xdu81du95du+9du/BdzAFdzBJdzCNdzDRdzE VdzFZdzGddzHhdzIldzJpdzKtdzLxdzM1dzN5dzO9dzPBd3QFd3RJd3SNd3TRd3U1dsBGIC9RQbW Vd3Ofd3WFQPYjd3bxd3cFdwBqA9tEAO8rYAKAIEK+Nvgpd3FrQBkEFzlfdzgJYYK4N2C0N3ppV7d Zd3jRQY6kNvgvVvbvdvZxV5ieF1iKNwBCF7j/0UGZCDewOXdxzXfuM3e6l1d5gVc75Xf+93d5BWA +BUA7oVf37Vb8f3eAVBeEDhe/yVc9SVg9QWB9KVf0aUD2kVg/KXbCeZbBm7g1L3eDX5gvwXf351b Ao7dCA7huCWG48Xb9u1e+M3g/W1hwl3fuBXe0+VfAThhy93g6+3gvp3dEpZb9e3fGNZb7VXd1x1f EBbhv1Vf5RXeB5Ze1YUAId5fF2Ze+7XdKBYA+93f9YUAIs5iL95f711gAWbdB7bf4Z3bHq7b9KVd 2n3dH9biKoZfFF7juFXh7N1hxzViFc7iPM7b633h95VbLV5dMD5dCJBhL/bjP5bbk6BfOjDgIv9+ 4RAmYuHlYuctYEDu4PWlgxjuZDjm3fRtYujt3+gN4fA9YNaN5EGGAPOlXRDQBuElYgVuYFe+4Rn+ YruVZQnmYkOGXETuX0Wu3wKO4exFYSneWwsuXWC2YWY+ZQDuY2PeXmgWXl6e5P8FZc5VZhkm3ta9 YSCeWzTm47odXgLu4kfOZVUGZtgl4R8mXzuGZTvmZCFOXj5OXvXl5C8GYv8tiWlOY/2N52bmZspl 5k+uWytO33bWhlc+XleG4z4e5N99Yzi+4Tmm4yle6DlmZRB2XE9u3SReYkgOYwMm5e1l3vH9aOel ZDTmZlzW3FUm5zaO55Jm4SPu3ha25+SlA+b/RWBY3ubt9WIBDuI01gaDjmUTTmk8XmhpluYwptud zmUqRmqCrmmI3uLsJWLedWj47eaA9mb61enn3eIGluXtjWKvhl6xtuXWxWVBjuCfRtysNmA+JuNa FgOWDmEuvmtvLmpPzmQ7vmjMVeo1RmsXhuYv1l/g9eKepmmB/uIkxluWzumYtmOJjufnReE7bmEp FmT/1ezDhly5VuVGtmwjxutpvuOvrmxv/mitjmUu/uh35t9zRmR+XmzDBm3GJeEuxmZBVupx1uVm LuNVbmUTBmGh5tzBptv2/WvgNl5kDufjrejBZt6A9t9Fdu2oLuod/mZelmqMVuEmtupGZuiB/z7i RVbc3ZZtea5q4KZkGTZup9ZuXCbh2eZkmV7qSG7qiT5tPfZdo55q3MZivH3j4e1q351tuf7cpq5g 6EVksg5liL5h5F5uRW5haSZle9ZeQdZlr85gDp/b5yZvAo7kksZjCDBmQhZnkhZu83VwywVwx7bv FIZl6WZioCZvAS/v7YbnHv/uGD5nyoXpAB9whQ5uG57pSp7ngf5cABfhanbhncbqxJ5pzo5gqIbn 4r7rkuBpIC+JwB5rKY/yAT9oI//yLcdyE+bkNA/n4cXq/77lIZ9cOSfu+6ZxE2fxHBdwIm7hDB7s dg7vD1fe6oZuxo3wcM5n3O5eCd7xGdbq2v+u5NzGYZx25h/+YT8O6Et33bxFb6LW9O8F7Qfe4Ybm dGzG6FOv3ENv5ES/a0lnYWZ+c3cG4vCu5xL3aaa28JC+3viO8cbtYgM2YwOvYl8OZqNeX2MWZS53 5C/u9cyN3sYOXM8udAq23pOA7GCO4mHndDBW7ihn4jUn8XJmaUgG8b6Gc7DG5OTu9DkWdbpNX4xu d9nN4Xmn93rf4E4+a3vX933n9373938HeHtfdz0eeAK/6IIP9VGPaHdHeGr33Og1iYiX+Imn+Iq3 +IvH+IzX+I3n+I63+Ep3+JAX+cPF5/M1+ZNH+ZRX+ZVn+ZZ3+ZeH+ZiX+ZVv+JG3+ZvH+Zwx1/md 5/me9/mfB/qgF/qhJ/qiN/qjR/qkV/qlZ/qmd/qnh/qol/qpp/qqt/qrr9yAAAA7 ------=_NextPart_000_000E_01C8149E.2247AC90-- From MicahsanguinaryMarquez@switchboard.com Mon Oct 22 04:30:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsgO-00022s-0l for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 04:30:44 -0400 Received: from c-67-163-133-194.hsd1.pa.comcast.net ([67.163.133.194] helo=d9dwx321.hsd1.pa.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IjsgN-0008AI-PM for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 04:30:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host91980850.switchboard.com (8.13.1/8.13.1) with SMTP id aa37u3Ii19.387158.6P9.SoF.3531231257796 for ; Mon, 22 Oct 2007 04:30:21 +0500 Message-ID: <1e426601c81485$ce870460$c285a343@D9DWX321> From: "Trent Wilcox" To: Subject: Your order approved Date: Mon, 22 Oct 2007 04:30:21 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1E4262_01C81485.CE870460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1E4262_01C81485.CE870460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_1E4262_01C81485.CE870460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1E4262_01C81485.CE870460-- From DelmarassiduousWeeks@blinddogs.com Mon Oct 22 09:57:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxmg-0006EM-OH for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 09:57:34 -0400 Received: from [189.138.201.162] (helo=u67407) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ijxmd-00022b-9s for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 09:57:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host47581949.blinddogs.com (8.13.1/8.13.1) with SMTP id VaoAqYg548.770847.0E9.bHm.6394828247259 for ; Mon, 22 Oct 2007 08:57:34 +0600 Message-ID: <36fc01c814b3$855cc490$6413000a@U67407> From: "Carmelo Rush" To: Subject: Your order approved Date: Mon, 22 Oct 2007 08:57:34 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_36F8_01C814B3.855CC490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_36F8_01C814B3.855CC490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_36F8_01C814B3.855CC490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_36F8_01C814B3.855CC490-- From nfsv4-bounces@ietf.org Mon Oct 22 13:17:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0sd-0002qZ-F4; Mon, 22 Oct 2007 13:15:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0Pt-0006br-4K for nfsv4@ietf.org; Mon, 22 Oct 2007 12:46:13 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik0PZ-0004bj-Kw for nfsv4@ietf.org; Mon, 22 Oct 2007 12:46:13 -0400 X-IronPort-AV: E=Sophos;i="4.21,312,1188802800"; d="scan'208,217";a="115911049" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 22 Oct 2007 09:45:42 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9MGjft4006217 for ; Mon, 22 Oct 2007 09:45:41 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 09:45:41 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 09:45:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 Date: Mon, 22 Oct 2007 12:45:46 -0400 Message-ID: In-Reply-To: <044B81DE141D7443BCE91E8F44B3C1E206D8C987@exsvl02.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 Thread-Index: AcfqmKoCUfhDSgluQG6IsAoSHMwoLwqMUtXg From: "Noveck, Dave" To: "Khan, Saadia" , X-OriginalArrivalTime: 22 Oct 2007 16:45:41.0196 (UTC) FILETIME=[FB4A50C0:01C814CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 109b3073396ff24e8322e946f21b1450 X-Mailman-Approved-At: Mon, 22 Oct 2007 13:15:49 -0400 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1942094468==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============1942094468== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C814CA.FEBDCBA8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C814CA.FEBDCBA8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can anybody shed light on this comment from the locking review: Kustarz - General comment - It should be mentioned somewhere that when doing IO the order of checking stateids should be delegation/lock/open/special. I'm unclear about what situation is being referred to "when doing IO". Is the checking of stateids alluded to being done by the client or the server. Not clear where this proposed order is derived from from, or how a different order would affect the result. For example a stateid will be one of special, lock, delegation, or open, and if that is is so, the order that you check for thos is irrelevant. Not matter what order you check, you will at some point deal with the class of object the stateid designates. What am I missing here? =20 =20 -----Original Message----- From: Khan, Saadia=20 Sent: Wednesday, August 29, 2007 8:00 PM To: nfsv4@ietf.org Subject: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 =09 =09 The second review meeting for locking and directory delegations was held on August 27, 2007. =20 The roles in this meeting were: - moderator - Shepler - reader - Eisler - scribe - Khan - author - Noveck - inspectors: Erasani, Gordon, Kustarz In this meeting, we covered lines 8751 - 9446, 9530 - 9728, 10476 - 10519 from draft 13. I am listing the review comments received during the review by name, line number and comment. =20 lines 8751 - 9446 =20 Khan - L 8775 - It should be emphasized that the server must not allow reclaims to happen if it is not storing the lock information on stable storage in order to be spec compliant. =20 Kustarz - L 8781 - Clarify what 'false positives' means here. =20 Noveck - L 8826 - Another case missing here is the one for a persistent session where the state is lost and the client is asked to reclaim its state. =20 Kustarz - General Comment - All state related errors should be consolidated and explained together, maybe in a separate section. =20 Eisler - L 8834 - s/as discussed above/as discussed in section blah. =20 Eisler - L 8838 - These lines are not correct and need to clarify what some of the SEQUENCE flags do. =20 Noveck - General comment - The two edge conditions mentioned in 8.4.3 are only in terms of lease expiration and not in the context of server revocation of locks. That needs to be addressed either in this section or this section needs to be somehow part of 8.4.3. =20 Ersani/Eisler - General comment - In the desription of test_stateid, it should be mentioned that the client may do this op whenever it wants, but it should definitely do this when any locks have been revoked and the server should allow the client to issue this op multiple times. =20 Eisler - L 8899, 8917 - s/lock/lease =20 Eisler - L 8978 - server should ignore these fields and not return an error. =20 Noveck - L 8971 - Mention here that the cleintid in CREATE_SESSION and DESTROY_SESSION is not ignored. =20 Eisler - L 8984 - OPEN and CREATE should be in lower case. =20 Eisler - L 8994 - s/lock/byte range lock =20 Khan/Kustarz - L 9004 - byte range locks should either be referred to as byte range locks or record locks in all places, currently this is not consistent. Same for octet locks. =20 Noveck - L 9029 - This should be mentioned in the previous chapter. =20 Kustarz - General Comment - Clarify all references to owners to be specifically lock owner/open owner or state owner. =20 Eisler - L 9051 - special stateid section should be referenced here. =20 Noveck - L 9132 - s/OPEN/stateid =20 Gordon - Comment for this section - replace setattr for set size with write. =20 Eisler - L 9176 - remove the line. =20 Eisler - L 9157 - There is no difference between using special stateids or regular stateids for this scenario. =20 Eisler - L 9254 - This is not true, it should be clarified what the new behavior is. =20 Eisler - L 9318 - Needs clarification. =20 Eisler - L 9381 - Section on stateid creation should be referenced and explained what happens to the old stateid in this case. =20 Eisler - L 9403 - s/open/OPENs =20 Kustarz - L 9403 - reference to the section that discusses how parallel opens should be handled and implemented. =20 Eisler - L 9413 - s/ay/may =20 Eisler - L 9417 - inadvertently (typo) =20 Noveck - L 9435 - This needs to be discussed on the mailing list. There could be issues here with part of the request being processed by one server instance and part of it by another one. =20 lines 9530 - 9728 =20 Eisler - L 9554 - s/callback/back channel =20 Khan - L 9581 - Clarify that nfs4err_delay could be returned in this case as well. =20 Eisler - L 9620 - s/leases/lease =20 Khan - L 9651 - s/but/and =20 Eisler - L 9693 - s/reclaim a/reclaim via a =20 Eisler - L 9701 - remove quotes. =20 Gordon - L 9648 - CLAIM_DELEGATE_PREV_FH should be mentioned here as well. =20 Eisler - L 9705 - s/freeing/revocation =20 Eisler - L 9723 - Needs to be clarified if the state needs to be in stable storage, the proper section should be referenced here. =20 lines 10476 - 10519=20 =20 Noveck - L 10510 - Needs to be clarified. =20 Khan - L 10516 - s/leases/lease =20 Eisler - General comment - It should be mentioned somewhere that the client needs to look at the status flags returned from SEQUENCE because it might need to do some actions based on what it got. =20 Gordon - L 10504 - s/a reasonable time/atleast one lease period =20 Khan - L 10534 - It should be added here that any open/lock state subsumed by the delegation does not get revoked when the delegation gets revoked. =20 Kustarz - General comment - It should be mentioned somewhere that when doing IO the order of checking stateids should be delegation/lock/open/special. =20 =20 thanks. Saadia =20 =20 ------_=_NextPart_001_01C814CA.FEBDCBA8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Can anybody shed light on this comment from = the locking=20 review:<= /SPAN>=
Kustarz -=20 General comment - It should be mentioned somewhere that when doing IO = the=20 order of checking stateids should be=20 = delegation/lock/open/special.<= /SPAN>= <= /SPAN>
I'm unclear about what situation is being referred to "when = doing=20 IO".  Is the checking of stateids alluded to being done by the = client or=20 the server.  Not clear where this proposed order is derived from = from, or=20 how a different order would affect the result.  For example a = stateid will=20 be one of special, lock, delegation, or open, and if that is is so, the = order=20 that you check for thos is irrelevant.  Not matter what order you = check,=20 you will at some point deal with the class of object the stateid=20 designates.  What am I missing=20 here?<= /SPAN>= <= /SPAN>
<= /SPAN>= <= /SPAN>=  
<= /SPAN>= <= /SPAN>=  
-----Original Message-----
From: = Khan, Saadia=20
Sent: Wednesday, August 29, 2007 8:00 PM
To:=20 nfsv4@ietf.org
Subject: [nfsv4] Review comments for Locking = and=20 Directory DelegationsReview# 2

The = second review=20 meeting for locking and directory delegations was held on August 27,=20 2007.
 
The=20 roles in this meeting were:

- moderator - Shepler

- reader -=20 Eisler

- scribe - Khan

- author - Noveck

- inspectors: Erasani, Gordon, = Kustarz

In this=20 meeting, we covered lines 8751=20 - 9446, 9530 - 9728, 10476 - 10519 from=20 draft 13.

I am listing=20 the review comments received during the review by name, line number = and=20 comment.
 
lines 8751=20 - = 9446
 
Khan - L 8775 - It should be emphasized = that the server=20 must not allow reclaims to happen if it is not storing the lock = information on=20 stable storage in order to be spec = compliant.
 
Kustarz - L 8781 - Clarify what 'false = positives' means=20 here.
 
Noveck - L 8826 - Another case missing here is = the one for a=20 persistent session where the state is lost and the client is asked to = reclaim=20 its state.
 
Kustarz - General Comment - All state related = errors should=20 be consolidated and explained together, maybe = in a separate=20 section.
 
Eisler - L 8834 - s/as discussed above/as = discussed in=20 section blah.
 
Eisler - L 8838 - These lines are not correct = and need to=20 clarify what some of the SEQUENCE flags do.
 
Noveck - General comment - The two edge = conditions mentioned=20 in 8.4.3 are only in terms of lease expiration and not in the context = of=20 server revocation of locks. That needs to be addressed either in this = section=20 or this section needs to be somehow part of = 8.4.3.
 
Ersani/Eisler - General comment - In the = desription of=20 test_stateid, it should be mentioned that the client may do this op = whenever=20 it wants, but it should definitely do this when any locks have been = revoked=20 and the server should allow the client to issue this op multiple=20 times.
 
Eisler - L 8899, 8917 -=20 s/lock/lease
 
Eisler  - L 8978 - server should ignore these fields and = not=20 return an = error.
 
Noveck - L 8971 - Mention here that the cleintid in = CREATE_SESSION and=20 DESTROY_SESSION is not=20 ignored.
 
Eisler - L 8984 - OPEN and CREATE should be in lower=20 = case.
&= nbsp;
Eisler - L 8994 - s/lock/byte range=20 = lock
<= /SPAN> 
Khan/Kustarz - L 9004 - byte range locks should either be = referred to=20 as byte range locks or record locks in all places, currently this is = not=20 consistent. Same for=20 = octet locks.=
<= /SPAN> 
Noveck - L 9029 - This should be mentioned in the previous=20 = chapter.
<= /SPAN> 
Kustarz - General Comment - Clarify all references to owners = to be=20 specifically lock owner/open owner or state=20 = owner.
<= /SPAN> 
Eisler - L 9051 - special stateid section should be = referenced=20 = here.
<= /SPAN> 
Noveck - L 9132 -=20 = s/OPEN/stateid
<= /SPAN> 
Gordon - Comment for this section - replace setattr for set = size with=20 = write.
<= /SPAN> 
Eisler - L 9176 - remove the=20 = line.
<= /SPAN> 
Eisler - L 9157 - There is no difference between using = special stateids=20 or regular stateids for this=20 = scenario.<= /SPAN>
<= /SPAN> 
Eisler - L 9254 - This is not true, it should be clarified = what the new=20 behavior=20 = is.=
<= /SPAN>=  
Eisler  - L 9318 - Needs=20 = clarification.
<= /SPAN>=  
Eisler - L 9381 - Section on stateid creation should be = referenced and=20 explained what happens to the old stateid in this=20 = case.<= /SPAN>=
<= /SPAN>=  
Eisler  - L 9403 -=20 = s/open/OPENs<= /SPAN>=
<= /SPAN>= &n= bsp;
Kustarz - L 9403 - reference to the section that discusses = how parallel=20 opens should be handled and=20 = implemented.<= /SPAN>=
<= /SPAN> 
Eisler - L 9413 -=20 = s/ay/may
<= /SPAN> 
Eisler - L 9417 - inadvertently=20 = (typo)=
<= /SPAN> 
Noveck - L 9435 - This needs to be discussed on the mailing = list. There=20 could be issues here with part of the request being processed by = one=20 server instance and part of it by another=20 = one.
<= /SPAN>=  
lines 9530 -=20 = 9728=
 
Eisler - L 9554 - s/callback/back=20 = channel
<= /SPAN>=  
Khan - L 9581 - Clarify that nfs4err_delay could be returned = in this=20 case as=20 = well.<= /SPAN>
<= /SPAN>=  
Eisler - L 9620 -=20 = s/leases/lease
<= /SPAN>=  
Khan - L 9651 -=20 = s/but/and<= /SPAN>=
<= /SPAN>=  
Eisler - L 9693 - s/reclaim a/reclaim via=20 = a<= /DIV>
<= /SPAN>=  
Eisler - L 9701 - remove=20 = quotes.<= /SPAN>
<= /SPAN>= &n= bsp;
Gordon - L 9648 - CLAIM_DELEGATE_PREV_FH should be mentioned = here as=20 = well.<= /SPAN>=
=
<= /SPAN>= &n= bsp;
Eisler - L 9705 -=20 = s/freeing/revocation= <= /SPAN>=
<= /SPAN>= <= /SPAN> 
Eisler  - L 9723 - Needs to be clarified if the state = needs to be=20 in stable storage, the proper section should be referenced=20 = here.<= /SPAN>= <= /SPAN>=
<= /SPAN>= <= /SPAN>=  
lines 10476 - 10519=20 = <= /SPAN>
 
Noveck -  L 10510 - = Needs to be=20 = clarified.=
 
Khan - L 10516 -=20 = s/leases/lease
 
Eisler - = General comment - It=20 should be mentioned somewhere that the client needs to look at the = status=20 flags returned from SEQUENCE because it might need to do some actions = based on=20 what it=20 = got.<= /SPAN>
=  
Gordon - L 10504 - s/a reasonable = time/atleast one=20 lease=20 = period=
=  
Khan - L 10534 - It should be added here = that any=20 open/lock state subsumed by the delegation does not get revoked when = the=20 delegation gets=20 = revoked.<= /SPAN>
=  
Kustarz - = General comment -=20 It should be mentioned somewhere that when doing IO the order of = checking=20 stateids should be=20 = delegation/lock/open/special.<= /SPAN>= <= /SPAN>
= <= /SPAN>=  
= <= /SPAN>=  
thanks.= <= /SPAN>=
Saadia<= /SPAN>= <= /SPAN>=
= <= /SPAN>=  
= <= /SPAN>=  
=00 ------_=_NextPart_001_01C814CA.FEBDCBA8-- --===============1942094468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1942094468==-- From Homemeogx@majlergaard.dk Mon Oct 22 13:22:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0yy-0002tD-0a for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 13:22:28 -0400 Received: from cpc1-blfs8-0-0-cust448.belf.cable.ntl.com ([82.17.253.193]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik0yu-0002Mu-9d for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 13:22:24 -0400 Received: from user-r1q8x57wk7 ([101.156.152.93] helo=user-r1q8x57wk7) by cpc1-blfs8-0-0-cust448.belf.cable.ntl.com ( sendmail 8.13.3/8.13.1) with esmtpa id 1dcKwY-000NIQ-eH for nfsv4-archive@lists.ietf.org; Mon, 22 Oct 2007 18:22:20 +0100 Message-ID: <000901c814d0$14692f90$c1fd1152@userr1q8x57wk7> From: "Kaufmann Homem" To: Subject: 1daehraw Date: Mon, 22 Oct 2007 18:22:10 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C814D8.762D9790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C814D8.762D9790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello honey nfsv4-archive have her holding your enlarged cock with 2 hands http://ohberg.com/ Kaufmann Homem ------=_NextPart_000_0008_01C814D8.762D9790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello honey nfsv4-archive
have her holding your enlarged cock with 2=20 hands
http://ohberg.com/
Kaufmann Homem
------=_NextPart_000_0008_01C814D8.762D9790-- From nfsv4-bounces@ietf.org Mon Oct 22 13:34:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik19g-0002aZ-Cx; Mon, 22 Oct 2007 13:33:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik19f-0002YA-8O for nfsv4@ietf.org; Mon, 22 Oct 2007 13:33:31 -0400 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik19e-0002rL-5Q for nfsv4@ietf.org; Mon, 22 Oct 2007 13:33:31 -0400 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Ik19d-0004vb-Bz; Mon, 22 Oct 2007 19:33:29 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Ik19c-0006cj-KL; Mon, 22 Oct 2007 19:33:29 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ik19c-0006cV-2N; Mon, 22 Oct 2007 19:33:28 +0200 Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Mon, 22 Oct 2007 13:33:30 -0400 Message-Id: <1193074410.8781.8.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.093) X-UiO-Scanned: AEA1FA8756FF709CE0184DAB70AF2E8C13CEE3DB X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 518 total 4645424 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: "Khan, Saadia" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Mon, 2007-10-22 at 12:45 -0400, Noveck, Dave wrote: > Can anybody shed light on this comment from the locking review: > Kustarz - General comment - It should be mentioned somewhere > that when doing IO the order of checking stateids should be > delegation/lock/open/special. > I'm unclear about what situation is being referred to "when doing IO". > Is the checking of stateids alluded to being done by the client or the > server. Not clear where this proposed order is derived from from, or > how a different order would affect the result. For example a stateid > will be one of special, lock, delegation, or open, and if that is is > so, the order that you check for thos is irrelevant. Not matter what > order you check, you will at some point deal with the class of object > the stateid designates. What am I missing here? Wasn't that meant as advice for clients when selecting which stateid they should present to the server? In other words, if a client holds a delegation, then it should choose to present that to the server. Next it should check whether or not it holds a lock stateid, followed by an open stateid, etc... I seem to remember, though, we chose to change that ordering in the pNFS review. I believe that Mike Eisler asked that we deprecate use of the lock stateid in all cases except the one where the server is enforcing mandatory locks. Mike? Cheers, Trond > -----Original Message----- > From: Khan, Saadia > Sent: Wednesday, August 29, 2007 8:00 PM > To: nfsv4@ietf.org > Subject: [nfsv4] Review comments for Locking and Directory > DelegationsReview# 2 > > > The second review meeting for locking and directory > delegations was held on August 27, 2007. > > The roles in this meeting were: > - moderator - Shepler > > - reader - Eisler > > - scribe - Khan > > - author - Noveck > > - inspectors: Erasani, Gordon, Kustarz > > In this meeting, we covered lines 8751 - 9446, 9530 - 9728, > 10476 - 10519 from draft 13. > > I am listing the review comments received during the review by > name, line number and comment. > > lines 8751 - 9446 > > Khan - L 8775 - It should be emphasized that the server must > not allow reclaims to happen if it is not storing the lock > information on stable storage in order to be spec compliant. > > Kustarz - L 8781 - Clarify what 'false positives' means here. > > Noveck - L 8826 - Another case missing here is the one for a > persistent session where the state is lost and the client is > asked to reclaim its state. > > Kustarz - General Comment - All state related errors should be > consolidated and explained together, maybe in a separate > section. > > Eisler - L 8834 - s/as discussed above/as discussed in section > blah. > > Eisler - L 8838 - These lines are not correct and need to > clarify what some of the SEQUENCE flags do. > > Noveck - General comment - The two edge conditions mentioned > in 8.4.3 are only in terms of lease expiration and not in the > context of server revocation of locks. That needs to be > addressed either in this section or this section needs to be > somehow part of 8.4.3. > > Ersani/Eisler - General comment - In the desription of > test_stateid, it should be mentioned that the client may do > this op whenever it wants, but it should definitely do this > when any locks have been revoked and the server should allow > the client to issue this op multiple times. > > Eisler - L 8899, 8917 - s/lock/lease > > Eisler - L 8978 - server should ignore these fields and not > return an error. > > Noveck - L 8971 - Mention here that the cleintid in > CREATE_SESSION and DESTROY_SESSION is not ignored. > > Eisler - L 8984 - OPEN and CREATE should be in lower case. > > Eisler - L 8994 - s/lock/byte range lock > > Khan/Kustarz - L 9004 - byte range locks should either be > referred to as byte range locks or record locks in all places, > currently this is not consistent. Same for octet locks. > > Noveck - L 9029 - This should be mentioned in the previous > chapter. > > Kustarz - General Comment - Clarify all references to owners > to be specifically lock owner/open owner or state owner. > > Eisler - L 9051 - special stateid section should be referenced > here. > > Noveck - L 9132 - s/OPEN/stateid > > Gordon - Comment for this section - replace setattr for set > size with write. > > Eisler - L 9176 - remove the line. > > Eisler - L 9157 - There is no difference between using special > stateids or regular stateids for this scenario. > > Eisler - L 9254 - This is not true, it should be clarified > what the new behavior is. > > Eisler - L 9318 - Needs clarification. > > Eisler - L 9381 - Section on stateid creation should be > referenced and explained what happens to the old stateid in > this case. > > Eisler - L 9403 - s/open/OPENs > > Kustarz - L 9403 - reference to the section that discusses how > parallel opens should be handled and implemented. > > Eisler - L 9413 - s/ay/may > > Eisler - L 9417 - inadvertently (typo) > > Noveck - L 9435 - This needs to be discussed on the mailing > list. There could be issues here with part of the request > being processed by one server instance and part of it by > another one. > > lines 9530 - 9728 > > Eisler - L 9554 - s/callback/back channel > > Khan - L 9581 - Clarify that nfs4err_delay could be returned > in this case as well. > > Eisler - L 9620 - s/leases/lease > > Khan - L 9651 - s/but/and > > Eisler - L 9693 - s/reclaim a/reclaim via a > > Eisler - L 9701 - remove quotes. > > Gordon - L 9648 - CLAIM_DELEGATE_PREV_FH should be mentioned > here as well. > > Eisler - L 9705 - s/freeing/revocation > > Eisler - L 9723 - Needs to be clarified if the state needs to > be in stable storage, the proper section should be referenced > here. > > lines 10476 - 10519 > > Noveck - L 10510 - Needs to be clarified. > > Khan - L 10516 - s/leases/lease > > Eisler - General comment - It should be mentioned somewhere > that the client needs to look at the status flags returned > from SEQUENCE because it might need to do some actions based > on what it got. > > Gordon - L 10504 - s/a reasonable time/atleast one lease > period > > Khan - L 10534 - It should be added here that any open/lock > state subsumed by the delegation does not get revoked when the > delegation gets revoked. > > Kustarz - General comment - It should be mentioned somewhere > that when doing IO the order of checking stateids should be > delegation/lock/open/special. > > > thanks. > Saadia > > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 22 13:35:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1BR-0004Lx-IM; Mon, 22 Oct 2007 13:35:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1BP-0004KS-Up for nfsv4@ietf.org; Mon, 22 Oct 2007 13:35:20 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik1BP-0002wb-2S for nfsv4@ietf.org; Mon, 22 Oct 2007 13:35:19 -0400 Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9MHZI3N014956; Mon, 22 Oct 2007 17:35:18 GMT Received: from [10.7.250.131] (punchin-client-10-7-250-131.SFBay.Sun.COM [10.7.250.131]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9MHZG75325196; Mon, 22 Oct 2007 10:35:17 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <698179A7-7C76-4ECC-B492-0A84B293B1BA@sun.com> Content-Transfer-Encoding: 7bit From: eric kustarz Subject: Re: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 Date: Mon, 22 Oct 2007 10:35:20 -0700 To: "Noveck, Dave" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: "Khan, Saadia" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 22, 2007, at 9:45 AM, Noveck, Dave wrote: > Can anybody shed light on this comment from the locking review: > Kustarz - General comment - It should be mentioned somewhere that > when doing IO the order of checking stateids should be delegation/ > lock/open/special. > I'm unclear about what situation is being referred to "when doing > IO". Is the checking of stateids alluded to being done by the > client or the server. Not clear where this proposed order is > derived from from, or how a different order would affect the > result. For example a stateid will be one of special, lock, > delegation, or open, and if that is is so, the order that you check > for thos is irrelevant. Not matter what order you check, you will > at some point deal with the class of object the stateid > designates. What am I missing here? This is referring to the client side. If the client is doing a read/ write, we should be clear about which stateid it should send OTW. In Solaris (and i believe everyone else is doing the same), the client will send over the first stateid that it has in the order: delegation, then lock, then open, then special. Check out at nfs4_get_stateid(): http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/ common/fs/nfs/nfs4_client_state.c eric > > > -----Original Message----- > From: Khan, Saadia > Sent: Wednesday, August 29, 2007 8:00 PM > To: nfsv4@ietf.org > Subject: [nfsv4] Review comments for Locking and Directory > DelegationsReview# 2 > > The second review meeting for locking and directory delegations was > held on August 27, 2007. > > The roles in this meeting were: > - moderator - Shepler > > - reader - Eisler > > - scribe - Khan > > - author - Noveck > > - inspectors: Erasani, Gordon, Kustarz > > In this meeting, we covered lines 8751 - 9446, 9530 - 9728, 10476 - > 10519 from draft 13. > > I am listing the review comments received during the review by > name, line number and comment. > > lines 8751 - 9446 > > Khan - L 8775 - It should be emphasized that the server must not > allow reclaims to happen if it is not storing the lock information > on stable storage in order to be spec compliant. > > Kustarz - L 8781 - Clarify what 'false positives' means here. > > Noveck - L 8826 - Another case missing here is the one for a > persistent session where the state is lost and the client is asked > to reclaim its state. > > Kustarz - General Comment - All state related errors should be > consolidated and explained together, maybe in a separate section. > > Eisler - L 8834 - s/as discussed above/as discussed in section blah. > > Eisler - L 8838 - These lines are not correct and need to clarify > what some of the SEQUENCE flags do. > > Noveck - General comment - The two edge conditions mentioned in > 8.4.3 are only in terms of lease expiration and not in the context > of server revocation of locks. That needs to be addressed either in > this section or this section needs to be somehow part of 8.4.3. > > Ersani/Eisler - General comment - In the desription of > test_stateid, it should be mentioned that the client may do this op > whenever it wants, but it should definitely do this when any locks > have been revoked and the server should allow the client to issue > this op multiple times. > > Eisler - L 8899, 8917 - s/lock/lease > > Eisler - L 8978 - server should ignore these fields and not return > an error. > > Noveck - L 8971 - Mention here that the cleintid in CREATE_SESSION > and DESTROY_SESSION is not ignored. > > Eisler - L 8984 - OPEN and CREATE should be in lower case. > > Eisler - L 8994 - s/lock/byte range lock > > Khan/Kustarz - L 9004 - byte range locks should either be referred > to as byte range locks or record locks in all places, currently > this is not consistent. Same for octet locks. > > Noveck - L 9029 - This should be mentioned in the previous chapter. > > Kustarz - General Comment - Clarify all references to owners to be > specifically lock owner/open owner or state owner. > > Eisler - L 9051 - special stateid section should be referenced here. > > Noveck - L 9132 - s/OPEN/stateid > > Gordon - Comment for this section - replace setattr for set size > with write. > > Eisler - L 9176 - remove the line. > > Eisler - L 9157 - There is no difference between using special > stateids or regular stateids for this scenario. > > Eisler - L 9254 - This is not true, it should be clarified what the > new behavior is. > > Eisler - L 9318 - Needs clarification. > > Eisler - L 9381 - Section on stateid creation should be referenced > and explained what happens to the old stateid in this case. > > Eisler - L 9403 - s/open/OPENs > > Kustarz - L 9403 - reference to the section that discusses how > parallel opens should be handled and implemented. > > Eisler - L 9413 - s/ay/may > > Eisler - L 9417 - inadvertently (typo) > > Noveck - L 9435 - This needs to be discussed on the mailing list. > There could be issues here with part of the request being processed > by one server instance and part of it by another one. > > lines 9530 - 9728 > > Eisler - L 9554 - s/callback/back channel > > Khan - L 9581 - Clarify that nfs4err_delay could be returned in > this case as well. > > Eisler - L 9620 - s/leases/lease > > Khan - L 9651 - s/but/and > > Eisler - L 9693 - s/reclaim a/reclaim via a > > Eisler - L 9701 - remove quotes. > > Gordon - L 9648 - CLAIM_DELEGATE_PREV_FH should be mentioned here > as well. > > Eisler - L 9705 - s/freeing/revocation > > Eisler - L 9723 - Needs to be clarified if the state needs to be > in stable storage, the proper section should be referenced here. > > lines 10476 - 10519 > > Noveck - L 10510 - Needs to be clarified. > > Khan - L 10516 - s/leases/lease > > Eisler - General comment - It should be mentioned somewhere that > the client needs to look at the status flags returned from SEQUENCE > because it might need to do some actions based on what it got. > > Gordon - L 10504 - s/a reasonable time/atleast one lease period > > Khan - L 10534 - It should be added here that any open/lock state > subsumed by the delegation does not get revoked when the delegation > gets revoked. > > Kustarz - General comment - It should be mentioned somewhere that > when doing IO the order of checking stateids should be delegation/ > lock/open/special. > > > thanks. > Saadia > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 22 13:58:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1Wr-0005pf-Nt; Mon, 22 Oct 2007 13:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1Wq-0005kN-4X for nfsv4@ietf.org; Mon, 22 Oct 2007 13:57:28 -0400 Received: from web38111.mail.mud.yahoo.com ([209.191.124.138]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ik1Wg-0008EZ-Mh for nfsv4@ietf.org; Mon, 22 Oct 2007 13:57:28 -0400 Received: (qmail 94495 invoked by uid 60001); 22 Oct 2007 17:57:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=iMeIo4bZWY6/XxcftgeDcyQ+Aott82Xr4+OKTGSygvWjyzZzJkw+eT6LYTwP0oOlkYLUnYgqgYa4xerCW8HhTv9sysRTwblTmS9In/rV9KzG+Gf3yzeoN/N/fWOynA1K1GANpW5BdlDl2Uh44GU0pHogfiwzp0UYrH4LESpncIs=; X-YMail-OSG: q04fPfgVM1mybr4me3aZhXmaV_TJgwwzPcdHyeL_5.bc7Wku5pWQ3veUHDGUlkhEGU7JZQ-- Received: from [198.95.226.230] by web38111.mail.mud.yahoo.com via HTTP; Mon, 22 Oct 2007 10:57:03 PDT Date: Mon, 22 Oct 2007 10:57:03 -0700 (PDT) From: Mike Eisler Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 To: Trond Myklebust , "Noveck, Dave" In-Reply-To: <1193074410.8781.8.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <204670.94432.qm@web38111.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "Khan, Saadia" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Trond Myklebust wrote: > I seem to remember, though, we chose to change that ordering in the > pNFS > review. I believe that Mike Eisler asked that we deprecate use of the > lock stateid in all cases except the one where the server is > enforcing > mandatory locks. Mike? On the theory that the data server to metadata server handshake will be simpler (and less chatty) if the data server is not cracking octet range record locks, yes, the spec should advise clients to not use record lock stateids when accessing data servers, unless mandatory locking is in force. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 22 19:05:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6JC-0005wm-UD; Mon, 22 Oct 2007 19:03:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6JA-0005wR-B7 for nfsv4@ietf.org; Mon, 22 Oct 2007 19:03:40 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik6J9-0003EN-Vm for nfsv4@ietf.org; Mon, 22 Oct 2007 19:03:40 -0400 X-IronPort-AV: E=Sophos;i="4.21,313,1188802800"; d="scan'208";a="115999901" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 22 Oct 2007 16:03:23 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9MN3MPB021309; Mon, 22 Oct 2007 16:03:22 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 16:03:22 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 16:03:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 Date: Mon, 22 Oct 2007 19:03:19 -0400 Message-ID: In-Reply-To: <204670.94432.qm@web38111.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 Thread-Index: AcgU1QJvT1obWMJcTGm1zOCrJAdymwAKgOzQ From: "Noveck, Dave" To: , "Trond Myklebust" X-OriginalArrivalTime: 22 Oct 2007 23:03:21.0774 (UTC) FILETIME=[BE0C1CE0:01C814FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Khan, Saadia" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org How does the client know whether mandatory locking is in force. The spec says you can find out when you get NFS4ERR_LOCKED that mandatory locking is in effect, but that doesn't give you any way to find out that mandatory locking is not in effect. So how is a client going to find out that he should not put record lock stateids into reads and writes? =20 -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Monday, October 22, 2007 1:57 PM To: Trond Myklebust; Noveck, Dave Cc: Khan, Saadia; nfsv4@ietf.org Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 --- Trond Myklebust wrote: > I seem to remember, though, we chose to change that ordering in the=20 > pNFS review. I believe that Mike Eisler asked that we deprecate use of > the lock stateid in all cases except the one where the server is=20 > enforcing mandatory locks. Mike? On the theory that the data server to metadata server handshake will be simpler (and less chatty) if the data server is not cracking octet range record locks, yes, the spec should advise clients to not use record lock stateids when accessing data servers, unless mandatory locking is in force. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 22 20:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik7sd-0005ZN-QJ; Mon, 22 Oct 2007 20:44:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik7sc-0005Z5-1F for nfsv4@ietf.org; Mon, 22 Oct 2007 20:44:22 -0400 Received: from web38101.mail.mud.yahoo.com ([209.191.124.128]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ik7sb-00010a-Kq for nfsv4@ietf.org; Mon, 22 Oct 2007 20:44:21 -0400 Received: (qmail 87119 invoked by uid 60001); 23 Oct 2007 00:37:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=JUVkF8MjgUyaltgtCz7WVmTtbTfGbvnO2XUB14cHisNXf/mB/d0DX5pFU+Nb9MH098B/NSfLsokzHuSvjvJ5lbs771LWaGgNGbN6BZIEuhxTrL82n2cs1zDo12t62QxsgJFbjXOkYNZ8eM+kmwWjNqX+uPQJ0fu80Y4tyGGXeIA=; X-YMail-OSG: pgplBecVM1k8kNXriyt6Qrk.Ymb.lus6zOBFgADfSnqql2OWHEKRED9L7YwYlfEcSH.rQWCTVQ-- Received: from [198.95.226.230] by web38101.mail.mud.yahoo.com via HTTP; Mon, 22 Oct 2007 17:37:40 PDT Date: Mon, 22 Oct 2007 17:37:40 -0700 (PDT) From: Mike Eisler Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <29318.86971.qm@web38101.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > How does the client know whether mandatory locking is in force. The > spec says you can find out when you get NFS4ERR_LOCKED that mandatory > locking is in effect, but that doesn't give you any way to find out > that > mandatory locking is not in effect. So how is a client going to find > out that he should not put record lock stateids into reads and > writes? The data servers should know whether a file requires mandatory locking or not. Whether a file requires mandatory locking or not is a property of the operating environment of the NFS server (which might be dependent on the presence of a file attribute). If a file requires mandatory locking, and the client uses an OPEN stateid, then the data server -- whether the file has a conflicting lock or not -- can return NFS4ERR_LOCKED to READ or WRITE. The client then issues LOCK to the MDS, gets a record lock stateid, and uses that stateid for the READ or WRITE. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From PorfirioshenandoahTalley@people.com Tue Oct 23 04:34:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFDi-0004oC-3Q for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 04:34:38 -0400 Received: from 84.123.254.207.dyn.user.ono.com ([84.123.254.207] helo=ale) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IkFDh-0004S2-K9 for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 04:34:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host69110920.people.com (8.13.1/8.13.1) with SMTP id v3gcVXzl55.094899.zVS.dzb.2324874834302 for ; Tue, 23 Oct 2007 10:33:51 -0100 Message-ID: <119f3201c8154f$950fcee0$cffe7b54@ale> From: "Donn Emerson" To: Subject: Your order approved Date: Tue, 23 Oct 2007 10:33:51 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_119F2E_01C8154F.950FCEE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_119F2E_01C8154F.950FCEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_119F2E_01C8154F.950FCEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_119F2E_01C8154F.950FCEE0-- From JanelleflightCordero@burgosguitar.com Tue Oct 23 05:47:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkGM4-0008BT-VV for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 05:47:21 -0400 Received: from pool-70-104-147-228.lsanca.fios.verizon.net ([70.104.147.228] helo=your4dacd0ea75.domainnotset.invalid) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IkGM0-00078R-7K for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 05:47:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host14400993.burgosguitar.com (8.13.1/8.13.1) with SMTP id cFUtRe2p07.842106.HlQ.VWp.6568241267000 for ; Tue, 23 Oct 2007 02:46:07 +0800 Message-ID: From: "Helene Horner" To: Subject: Your family Date: Tue, 23 Oct 2007 02:46:07 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_DC1B1_01C81559.AC3BC510" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_DC1B1_01C81559.AC3BC510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_DC1B1_01C81559.AC3BC510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_DC1B1_01C81559.AC3BC510-- From DerekmodularRay@billion.fr Tue Oct 23 11:04:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLIk-0001ux-1b for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 11:04:14 -0400 Received: from 116.65.219.87.dynamic.jazztel.es ([87.219.65.116] helo=marc8phsgxlzfi) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkLIf-0004dO-MH for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 11:04:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host68441038.billion.fr (8.13.1/8.13.1) with SMTP id ci1pDji798.982919.iQ8.pHP.7875755043522 for ; Tue, 23 Oct 2007 17:02:57 -0100 Message-ID: <5a50f01c81585$edef0f40$6e01a8c0@marc8phsgxlzfi> From: "Lewis Stephens" To: Subject: Your health Date: Tue, 23 Oct 2007 17:02:57 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_5A50B_01C81585.EDEF0F40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_5A50B_01C81585.EDEF0F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_5A50B_01C81585.EDEF0F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_5A50B_01C81585.EDEF0F40-- From nfsv4-bounces@ietf.org Tue Oct 23 14:14:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOFA-0000CP-Pl; Tue, 23 Oct 2007 14:12:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOF8-0000Ab-HA for nfsv4@ietf.org; Tue, 23 Oct 2007 14:12:42 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkOF8-0002px-0I for nfsv4@ietf.org; Tue, 23 Oct 2007 14:12:42 -0400 X-IronPort-AV: E=Sophos;i="4.21,318,1188802800"; d="scan'208";a="116217743" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 23 Oct 2007 11:12:41 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9NICd3M026575; Tue, 23 Oct 2007 11:12:40 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 11:12:39 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 11:12:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 Date: Tue, 23 Oct 2007 14:12:37 -0400 Message-ID: In-Reply-To: <204670.94432.qm@web38111.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 Thread-Index: AcgU1QJvT1obWMJcTGm1zOCrJAdymwAypnjg From: "Noveck, Dave" To: , "Trond Myklebust" X-OriginalArrivalTime: 23 Oct 2007 18:12:39.0229 (UTC) FILETIME=[4BE4B6D0:01C815A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "Khan, Saadia" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org So what we want here is: If you are doing IO to the metadata server, then you use a lock=20 stateid if the current lockowner has one, and only use an open stateid if the there is no current lock stateid for the current=20 lockowner. If you are doing IO to the data server (pnfs files), you don't=20 use a lock stateid unless you get back NFS4ERR_LOCKED back from the data server. I this correct? -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Monday, October 22, 2007 1:57 PM To: Trond Myklebust; Noveck, Dave Cc: Khan, Saadia; nfsv4@ietf.org Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 --- Trond Myklebust wrote: > I seem to remember, though, we chose to change that ordering in the > pNFS > review. I believe that Mike Eisler asked that we deprecate use of the > lock stateid in all cases except the one where the server is > enforcing > mandatory locks. Mike? On the theory that the data server to metadata server handshake will be simpler (and less chatty) if the data server is not cracking octet range record locks, yes, the spec should advise clients to not use record lock stateids when accessing data servers, unless mandatory locking is in force. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Oct 23 14:27:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOT6-0004Pz-KX; Tue, 23 Oct 2007 14:27:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOT5-0004MM-Mj for nfsv4@ietf.org; Tue, 23 Oct 2007 14:27:07 -0400 Received: from web38102.mail.mud.yahoo.com ([209.191.124.129]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IkOT5-0003NM-9L for nfsv4@ietf.org; Tue, 23 Oct 2007 14:27:07 -0400 Received: (qmail 26487 invoked by uid 60001); 23 Oct 2007 18:27:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=LnIu2LuLE1u8ByHVTpmT/t9GxA9mPg+uHR6pwF5ewlOP0T3bB2b00tSC9RHE/UxXMvmC4R8UWFAgZPc3HnL6HoKAsR5r06uctCn7nghmgwqlck9mJtqdsIAbkvqoLDpUc/MM6wh18zb78PSmSWd8SUJAlBKXeTt/pM3rGwZMb6I=; X-YMail-OSG: bs.SF8UVM1mUmVC6Bj7aQrKmPLzuE3viwyODRO0lgMR1PejOWcAaKrW2upwbZum__7CZQotwH9RnW0yTGphPJezGTYnaryhNDFV3tUhN_suV7gc- Received: from [198.95.226.230] by web38102.mail.mud.yahoo.com via HTTP; Tue, 23 Oct 2007 11:27:06 PDT Date: Tue, 23 Oct 2007 11:27:06 -0700 (PDT) From: Mike Eisler Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 To: "Noveck, Dave" , email2mre-ietf@yahoo.com, Trond Myklebust In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <721026.26083.qm@web38102.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "Khan, Saadia" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Looks good. --- "Noveck, Dave" wrote: > So what we want here is: > > If you are doing IO to the metadata server, then you use a lock > stateid if the current lockowner has one, and only use an open > stateid if the there is no current lock stateid for the current > lockowner. > > If you are doing IO to the data server (pnfs files), you don't > use a lock stateid unless you get back NFS4ERR_LOCKED back from > the data server. > > I this correct? > > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Monday, October 22, 2007 1:57 PM > To: Trond Myklebust; Noveck, Dave > Cc: Khan, Saadia; nfsv4@ietf.org > Subject: RE: [nfsv4] Review comments for Locking and Directory > DelegationsReview# 2 > > > > --- Trond Myklebust wrote: > > > > I seem to remember, though, we chose to change that ordering in the > > pNFS > > review. I believe that Mike Eisler asked that we deprecate use of > the > > lock stateid in all cases except the one where the server is > > enforcing > > mandatory locks. Mike? > > On the theory that the data server to metadata server handshake will > be > simpler (and less chatty) > if the data server is not cracking octet range record locks, > yes, the spec should advise clients to not use record lock stateids > when accessing data servers, unless mandatory locking is in force. > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Oct 23 14:30:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOVx-0001jQ-IF; Tue, 23 Oct 2007 14:30:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOVw-0001fq-0t for nfsv4@ietf.org; Tue, 23 Oct 2007 14:30:04 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkOVq-0006Er-Ex for nfsv4@ietf.org; Tue, 23 Oct 2007 14:30:04 -0400 Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IkOVg-0005W8-JR; Tue, 23 Oct 2007 20:29:48 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx4.uio.no) by mail-mx4.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IkOVg-00057Z-57; Tue, 23 Oct 2007 20:29:48 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx4.uio.no with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IkOVf-00057G-Nx; Tue, 23 Oct 2007 20:29:48 +0200 Subject: RE: [nfsv4] Review comments for Locking and Directory DelegationsReview# 2 From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Tue, 23 Oct 2007 14:30:37 -0400 Message-Id: <1193164237.20475.9.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.2, required=12.0, autolearn=disabled, AWL=-0.161) X-UiO-Scanned: 194D527906C34F5866D196B1FDCEE5AF1363AA08 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -1 maxlevel 200 minaction 2 bait 0 mail/h: 457 total 4673620 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: email2mre-ietf@yahoo.com, "Khan, Saadia" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Tue, 2007-10-23 at 14:12 -0400, Noveck, Dave wrote: > So what we want here is: > > If you are doing IO to the metadata server, then you use a lock > stateid if the current lockowner has one, and only use an open > stateid if the there is no current lock stateid for the current > lockowner. Yes, but you should prefer the delegation over the lock stateid if you have one. > If you are doing IO to the data server (pnfs files), you don't > use a lock stateid unless you get back NFS4ERR_LOCKED back from > the data server. > > I this correct? Yes, although again I assume that the delegation is to be preferred over the open stateid. Cheers Trond > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Monday, October 22, 2007 1:57 PM > To: Trond Myklebust; Noveck, Dave > Cc: Khan, Saadia; nfsv4@ietf.org > Subject: RE: [nfsv4] Review comments for Locking and Directory > DelegationsReview# 2 > > > > --- Trond Myklebust wrote: > > > > I seem to remember, though, we chose to change that ordering in the > > pNFS > > review. I believe that Mike Eisler asked that we deprecate use of the > > lock stateid in all cases except the one where the server is > > enforcing > > mandatory locks. Mike? > > On the theory that the data server to metadata server handshake will be > simpler (and less chatty) > if the data server is not cracking octet range record locks, > yes, the spec should advise clients to not use record lock stateids > when accessing data servers, unless mandatory locking is in force. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From EdgaraugustanOliver@rulers.org Tue Oct 23 15:12:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPAi-0003tT-NL for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 15:12:12 -0400 Received: from 20151204165.user.veloxzone.com.br ([201.51.204.165] helo=servidor) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkPAf-0000DB-Qm for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 15:12:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host66695015.rulers.org (8.13.1/8.13.1) with SMTP id cAQvgcUo25.043962.j4D.6Iv.0527528680432 for ; Tue, 23 Oct 2007 16:10:57 +0300 Message-ID: <14cf3701c815a8$9663c8b0$04fea8c0@servidor> From: "Edgar Ryan" To: Subject: Your order approved Date: Tue, 23 Oct 2007 16:10:57 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_14CF33_01C815A8.9663C8B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.5 (+++) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_14CF33_01C815A8.9663C8B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_14CF33_01C815A8.9663C8B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_14CF33_01C815A8.9663C8B0-- From kiang5peyton@arkestal.se Tue Oct 23 15:51:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkPmk-00057P-As for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 15:51:30 -0400 Received: from h69-131-48-58.69-131.unk.tds.net ([69.131.48.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkPmg-0002GT-Ni for nfsv4-archive@lists.ietf.org; Tue, 23 Oct 2007 15:51:28 -0400 Received: from [69.131.48.58] by xwtlafi.arkestal.se; Tue, 23 Oct 2007 19:53:38 +0000 Message-ID: <000a01c815ae$06c5d282$1ca1dc88@pnqjmwkg> From: "keefer shelby" To: "Alma Pack" Subject: Top-notch customer service Date: Tue, 23 Oct 2007 18:06:16 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C815AE.06C41C64" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C815AE.06C41C64 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life Should be Full of Luxuries, yet, only a handful of people can = afford the finest products, the luxuries of the elite. We are committed to bringing you the finest products, at prices = incomparably lower. Perfectly crafted luxury timepieces, all at = affordable prices. Thousands of different models to choose from! http://catagena.com.cn/ ------=_NextPart_000_0007_01C815AE.06C41C64 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life Should be Full of Luxuries, yet, only a handful of people can = afford the finest products,=20 the luxuries of the elite.
We are committed to bringing you the = finest products, at prices=20 incomparably lower. Perfectly crafted luxury timepieces, all at = affordable prices. Thousands=20 of different models to choose from!

http://catagena.com.cn/ ------=_NextPart_000_0007_01C815AE.06C41C64-- From nfsv4-bounces@ietf.org Tue Oct 23 16:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQ11-0002fW-6L; Tue, 23 Oct 2007 16:06:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkQ0z-0002Uv-2Z for nfsv4@ietf.org; Tue, 23 Oct 2007 16:06:13 -0400 Received: from p01c11o142.mxlogic.net ([208.65.144.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkQ0t-0007n8-CY for nfsv4@ietf.org; Tue, 23 Oct 2007 16:06:07 -0400 Received: from unknown [63.110.244.103] (EHLO us-email.terastack.bluearc.com) by p01c11o142.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id f245e174.1693109168.37735.00-019.p01c11o142.mxlogic.net (envelope-from ); Tue, 23 Oct 2007 14:06:07 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Oct 2007 13:06:05 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Layout Range. Thread-Index: AcgVsCUJWBcDgDfKRCu6r6uimoTIPg== From: "Anatoly Pinchuk" To: X-Spam: [F=0.0100000000; S=0.010(2007101601); SS=0.500] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Subject: [nfsv4] Layout Range. X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0100383978==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============0100383978== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C815B0.251F08BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C815B0.251F08BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable According to the description of the LAYOUTGET operation =20 (Page 453, http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-14.tx t ) As well, the metadata server may adjust the range of the returned layout based on striping patterns and usage implied by the loga_iomode. The client must be prepared to get a layout that does not line up exactly with its request; there MUST be at least an overlap of loga_minlength between the layout returned by the server and the client's request, or the server SHOULD reject the request. See Section 13.5.2 for more details. =20 there is a possibility that the server returns layout for just a sub-range of the range requested by the client. In other words, if the client requested a layout for [min, max] range, the server, generally, can return layout applicable to only [min + p, max - q] one, where p>=3D0, q>=3D0; min, p, max, and q have to satisfy some = consistency rules. For example, if the client requested the layout for range [1027, 0x40000000], the server can return one for [0x10000000, 0x30000000] range. =20 If so, the returned layout should be limited to the range indicated by the server ([0x10000000, 0x30000000] in the example above ). It is not clear how nfsv4_1_file_layout4 structure does that. It would be great if somebody provides a clarification. =20 Thanks, Anatoly =20 ------_=_NextPart_001_01C815B0.251F08BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

According to the = description of the LAYOUTGET operation

 

(Page 453, http://www.ietf.org/internet-drafts/draft-ietf= -nfsv4-minorversion1-14.txt)

   As = well, the metadata server may adjust the range of the = returned

   layout = based on striping patterns and usage implied by the

   loga_iomode.  The client must be prepared to get a layout that = does

   not = line up exactly with its request; there MUST be at least = an

   = overlap of loga_minlength between the layout returned by the = server

   and = the client's request, or the server SHOULD reject the = request.

   See = Section 13.5.2 for more details.

 

there is a = possibility that the server returns layout for just a sub-range of the = range

requested by the = client. In other words, if the client requested a layout for [min, = max]

range, the server, generally, can return layout applicable to only [min + p, max - q] = one,

where p>=3D0, = q>=3D0; min, p, max, and q have to satisfy some consistency = rules.

For example, if the = client requested the layout for range [1027, = 0x40000000],

the server can = return one for [0x10000000, 0x30000000] range.

 

If so, the returned = layout should be limited to the range indicated by the = server

([0x10000000, = 0x30000000] in the example above ). It is not clear how

nfsv4_1_file_layout4 structure does that. It would be great if somebody provides a = clarification.

 

Thanks,

Anatoly

 

------_=_NextPart_001_01C815B0.251F08BD-- --===============0100383978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============0100383978==-- From nfsv4-bounces@ietf.org Tue Oct 23 20:24:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkU0h-0005MK-47; Tue, 23 Oct 2007 20:22:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkU0f-0005Ev-HV for nfsv4@ietf.org; Tue, 23 Oct 2007 20:22:09 -0400 Received: from web38113.mail.mud.yahoo.com ([209.191.124.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkU0Z-0004ex-Az for nfsv4@ietf.org; Tue, 23 Oct 2007 20:22:09 -0400 Received: (qmail 19435 invoked by uid 60001); 24 Oct 2007 00:21:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ws5eTCkH2DgT40oyvIrHRfuwd2Jhp3k7ILUJzKe0aD9am+DAtqN25tOukGQMWkBvPQfONe9tIHQB88tZa8CKrvORdL90J6ZSsikFWMG/g61SUYTXZMLj1DA9mmfj4+zmnw8k2//ChipWAnTXubFn6OtqSqao88zOWf7W2fOLFzY=; X-YMail-OSG: pxXb1tgVM1lyRG3yepR57VTmFJhPNqJDvMO5VygDy63FugSGozNCJ74HXwJ9Mk5YgJ7LKV0NuDB4HkxZIe1yKNcDxsjKu7wS6tOMOrRJNANJxb8- Received: from [198.95.226.230] by web38113.mail.mud.yahoo.com via HTTP; Tue, 23 Oct 2007 17:21:47 PDT Date: Tue, 23 Oct 2007 17:21:47 -0700 (PDT) From: Mike Eisler Subject: Re: [nfsv4] Question on file layout! To: Lisa Week In-Reply-To: <9EEE37F4-E464-457E-8471-62A316972801@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <811739.18988.qm@web38113.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I've committed changes to drsft-15 to implement the below proposal, as well as emphasizing the need for dense packing to use different file handles. > > The simplest is to re-define nfl_fh_list to be the > > same length as nflda_stripe_indices and have nfl_fh_list[X] > > correspond to nflda_stripe_indices[X]. > > > > However, for SPARSE packing, combined with long index arrays, > > this makes layouts not very economical. > > > > So I think what we want is for SPARSE packing, > > state that fh list to corresponds to the ds list > > (same number of elements as the ds list, one element, or > > zero elements in the fh list as in draft -14), and for > > DENSE packing state that the fh list must be the same > > length as the index array, and fh list[X] corresponds to > indices[X]. > > > > The algorithm for determining the file handle in the DENSE packing > > case is thus: > > > > stripe_count = number of elements in nflda_stripe_indices; > > > > fh_idx = > > ( SUi + nfl_first_stripe_index ) % stripe_count; > > > > fh = nfl_fh_list[fh_idx]; > > > > For dense packing, we use the same example, with the same > > index and data server arrays, but change the fh list from, > > > > 36 87 67 > > to, > > > > 67 37 87 36 > > > > The result is: > > > > SUi fh data servers > > 0 87 E > > 1 36 A,B,C,D > > 2 67 F,G > > 3 37 A,B,C,D > > 4 87 E > > 5 36 A,B,C,D > > 6 67 F,G > > 7 37 A,B,C,D > > 8 87 E > > 9 36 A,B,C,D > > 10 67 F,G > > 11 37 A,B,C,D > > 12 87 E > > > Yes, I think this is a good solution. > > Thanks, > Lisa > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Oct 23 20:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkUay-0000v0-FI; Tue, 23 Oct 2007 20:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkUax-0000ro-3i for nfsv4@ietf.org; Tue, 23 Oct 2007 20:59:39 -0400 Received: from web38111.mail.mud.yahoo.com ([209.191.124.138]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkUaq-0005uJ-Rc for nfsv4@ietf.org; Tue, 23 Oct 2007 20:59:39 -0400 Received: (qmail 3794 invoked by uid 60001); 24 Oct 2007 00:59:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=br/K7s/5ukNxaOdETnm4tWUtQKtReg/hRsPJx71vZ9ORYyXhAt/oEma3FGpKopgDuZ60SvrieA1D3qr1ly10VAFU4XHsaycqkuojHwkIe92TpIUInMeaAwISbvC8N6YX4ZNKGRWyVRI2Zzu/ujQoSBMVmF7c4zLU8s7SWzonYKU=; X-YMail-OSG: Rujp6QwVM1ngMSpmbEQz1qyygZukzGz7ul6E8kefn7U6_8CxZQEgg.._noNgikg7yw-- Received: from [198.95.226.230] by web38111.mail.mud.yahoo.com via HTTP; Tue, 23 Oct 2007 17:59:17 PDT Date: Tue, 23 Oct 2007 17:59:17 -0700 (PDT) From: Mike Eisler Subject: Re: [nfsv4] Layout Range. To: Anatoly Pinchuk , nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <344957.1471.qm@web38111.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Great minds apparently worry about the same issues at the same time. :-) It was pointed out to me that some file systems or pNFS servers might have multiple, very distinct striping patterns per file. To take Anatoly's example: [1027, 0x0x99999999] might be striped over 4 data servers, [0x10000000, 0x30000000] might striped over 6 servers, and [0x30000001, 0x40000000] might striped over 5 servers, and each group of data servers might be different. We have at leats two ways to go: - Explicitly allow LAYOUTGET to return a subset of the requested range, and include some information about why this was done (e.g. two flags that indicates that the low end and/or high end of the requested range has a different striping pattern - change LAYOUTGET to return an array of what it currently returns. Regarding: > For example, if the client requested the layout for range [1027, > 0x40000000], the server can return one for [0x10000000, 0x30000000] range. > > If so, the returned layout should be limited to the range indicated > by the server > > ([0x10000000, 0x30000000] in the example above ). It is not clear how > nfsv4_1_file_layout4 structure does that. It would be great if > somebody provides a clarification. I didn't understand the question ... or rather didn't understand what had to be clarified. /* Encoded in the loc_body field of type layout_content4: */ struct nfsv4_1_file_layout4 { deviceid4 nfl_deviceid; nfl_util4 nfl_util; uint32_t nfl_first_stripe_index; nfs_fh4 nfl_fh_list<>; }; struct layout4 { offset4 lo_offset; length4 lo_length; layoutiomode4 lo_iomode; layout_content4 lo_content; }; The idea is that from lo_offset though lo_offset + lo_length - 1. In this case we chop that range into stripe unit sizes as encoded in nfl_util. --- Anatoly Pinchuk wrote: > According to the description of the LAYOUTGET operation > > > > (Page 453, > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-14.tx > t > xt> ) > > As well, the metadata server may adjust the range of the returned > > layout based on striping patterns and usage implied by the > > loga_iomode. The client must be prepared to get a layout that > does > > not line up exactly with its request; there MUST be at least an > > overlap of loga_minlength between the layout returned by the > server > > and the client's request, or the server SHOULD reject the request. > > See Section 13.5.2 for more details. > > > > there is a possibility that the server returns layout for just a > sub-range of the range > > requested by the client. In other words, if the client requested a > layout for [min, max] > > range, the server, generally, can return layout applicable to only > [min > + p, max - q] one, > > where p>=0, q>=0; min, p, max, and q have to satisfy some consistency > rules. > > For example, if the client requested the layout for range [1027, > 0x40000000], > > the server can return one for [0x10000000, 0x30000000] range. > > > > If so, the returned layout should be limited to the range indicated > by > the server > > ([0x10000000, 0x30000000] in the example above ). It is not clear how > > nfsv4_1_file_layout4 structure does that. It would be great if > somebody > provides a clarification. > > > > Thanks, > > Anatoly > > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Oct 23 22:54:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWLy-0000Jt-OH; Tue, 23 Oct 2007 22:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWLx-00085x-Ed for nfsv4@ietf.org; Tue, 23 Oct 2007 22:52:17 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkWLn-0001YP-1K for nfsv4@ietf.org; Tue, 23 Oct 2007 22:52:13 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9O2p5NP000922 for ; Wed, 24 Oct 2007 02:51:06 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQE00901AH7U900@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 23 Oct 2007 20:51:05 -0600 (MDT) Received: from [10.0.252.254] ([12.5.154.21]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQE000P1AKSYP00@mail-amer.sun.com>; Tue, 23 Oct 2007 20:50:52 -0600 (MDT) Date: Tue, 23 Oct 2007 21:50:51 -0500 From: Spencer Shepler Subject: Re: [nfsv4] ACL section revisions In-reply-to: <20071011223617.GG22823@fieldses.org> To: "J. Bruce Fields" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20071011223617.GG22823@fieldses.org> X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nfsv4@ietf.org, Lisa Week X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 11, 2007, at 5:36 PM, J. Bruce Fields wrote: > The following acl section revisions are leftover from the acl review. > There's no substantive change to the ACL model, and nothing > particularly > contraversial--the goal is just to make the section easier to read, > provide some better guidance here and there, and fix some minor bugs. > > I've also incorporated feedback from Sam, who reviewed this. > (Thanks!) Thank you for the updates and the work that went into them. Seeing no discussion, I am assuming we have consensus on these changes and they have been incorporated into the I-D and will arrive in draft 15. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Oct 23 22:54:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWO8-0006Xs-FL; Tue, 23 Oct 2007 22:54:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWO7-0006DW-ON for nfsv4@ietf.org; Tue, 23 Oct 2007 22:54:31 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkWNv-0004JQ-Do for nfsv4@ietf.org; Tue, 23 Oct 2007 22:54:19 -0400 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IkWNu-0002GJ-0C; Tue, 23 Oct 2007 22:54:18 -0400 Date: Tue, 23 Oct 2007 22:54:17 -0400 To: Spencer Shepler Subject: Re: [nfsv4] ACL section revisions Message-ID: <20071024025417.GC2691@fieldses.org> References: <20071011223617.GG22823@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: nfsv4@ietf.org, Lisa Week X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Tue, Oct 23, 2007 at 09:50:51PM -0500, Spencer Shepler wrote: > > On Oct 11, 2007, at 5:36 PM, J. Bruce Fields wrote: > >> The following acl section revisions are leftover from the acl review. >> There's no substantive change to the ACL model, and nothing particularly >> contraversial--the goal is just to make the section easier to read, >> provide some better guidance here and there, and fix some minor bugs. >> >> I've also incorporated feedback from Sam, who reviewed this. (Thanks!) > > Thank you for the updates and the work that went into them. > > Seeing no discussion, I am assuming we have consensus on these > changes and they have been incorporated into the I-D and will > arrive in draft 15. OK; thanks!--b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Oct 23 23:03:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWWe-0005Sm-4n; Tue, 23 Oct 2007 23:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWWc-0005Lt-EX for nfsv4@ietf.org; Tue, 23 Oct 2007 23:03:18 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkWWP-0001uS-43 for nfsv4@ietf.org; Tue, 23 Oct 2007 23:03:10 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9O32oiC019784 for ; Wed, 24 Oct 2007 03:02:50 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQE00E01B2HEK00@mail-amer.sun.com> (original mail from Lisa.Week@Sun.COM) for nfsv4@ietf.org; Tue, 23 Oct 2007 21:02:50 -0600 (MDT) Received: from [192.168.1.101] (c-24-8-86-213.hsd1.co.comcast.net [24.8.86.213]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQE001JPB4P6P00@mail-amer.sun.com>; Tue, 23 Oct 2007 21:02:50 -0600 (MDT) Date: Tue, 23 Oct 2007 21:02:26 -0600 From: Lisa Week Subject: Re: [nfsv4] Question on file layout! In-reply-to: <811739.18988.qm@web38113.mail.mud.yahoo.com> To: email2mre-ietf@yahoo.com Message-id: <200F7B2F-6DD0-4A4D-9E3E-BCF668E9AD67@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <811739.18988.qm@web38113.mail.mud.yahoo.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 23, 2007, at 6:21 PM, Mike Eisler wrote: > I've committed changes to drsft-15 to implement the below proposal, > as well as emphasizing the need for dense packing to use different > file handles. Great, thanks. - Lisa > > >>> The simplest is to re-define nfl_fh_list to be the >>> same length as nflda_stripe_indices and have nfl_fh_list[X] >>> correspond to nflda_stripe_indices[X]. >>> >>> However, for SPARSE packing, combined with long index arrays, >>> this makes layouts not very economical. >>> >>> So I think what we want is for SPARSE packing, >>> state that fh list to corresponds to the ds list >>> (same number of elements as the ds list, one element, or >>> zero elements in the fh list as in draft -14), and for >>> DENSE packing state that the fh list must be the same >>> length as the index array, and fh list[X] corresponds to >> indices[X]. >>> >>> The algorithm for determining the file handle in the DENSE packing >>> case is thus: >>> >>> stripe_count = number of elements in nflda_stripe_indices; >>> >>> fh_idx = >>> ( SUi + nfl_first_stripe_index ) % stripe_count; >>> >>> fh = nfl_fh_list[fh_idx]; >>> >>> For dense packing, we use the same example, with the same >>> index and data server arrays, but change the fh list from, >>> >>> 36 87 67 >>> to, >>> >>> 67 37 87 36 >>> >>> The result is: >>> >>> SUi fh data servers >>> 0 87 E >>> 1 36 A,B,C,D >>> 2 67 F,G >>> 3 37 A,B,C,D >>> 4 87 E >>> 5 36 A,B,C,D >>> 6 67 F,G >>> 7 37 A,B,C,D >>> 8 87 E >>> 9 36 A,B,C,D >>> 10 67 F,G >>> 11 37 A,B,C,D >>> 12 87 E >> >> >> Yes, I think this is a good solution. >> >> Thanks, >> Lisa >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 >> > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Henning.McCain@ssnp.com Wed Oct 24 01:00:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkYLf-0003a3-7X for nfsv4-archive@lists.ietf.org; Wed, 24 Oct 2007 01:00:07 -0400 Received: from mail209b.gmnews.co.uk ([194.69.203.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkYLZ-0005Em-0u for nfsv4-archive@lists.ietf.org; Wed, 24 Oct 2007 01:00:07 -0400 Received: from fpmanager by ssnp.com with ASMTP id 060E5959 for ; Wed, 24 Oct 2007 06:13:37 +0100 Received: from fpmanager ([139.196.167.171]) by ssnp.com with ESMTP id 9E948B01F347 for ; Wed, 24 Oct 2007 06:13:37 +0100 Message-ID: <000401c815fc$8a960ad0$1ecb45c2@fpmanager> From: "Henning McCain" To: Subject: sowl Date: Wed, 24 Oct 2007 06:12:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C81604.EC5A72D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.7 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C81604.EC5A72D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How's tricks? nfsv4-archive trust us, she really wants your dick bigger http://penaber.com/ Henning McCain ------=_NextPart_000_0005_01C81604.EC5A72D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How's tricks? nfsv4-archive
trust us, she really wants your dick = bigger
http://penaber.com/
Henning McCain
------=_NextPart_000_0005_01C81604.EC5A72D0-- From nfsv4-bounces@ietf.org Wed Oct 24 06:20:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdJO-0006Xa-MX; Wed, 24 Oct 2007 06:18:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdJN-0006La-7f for nfsv4@ietf.org; Wed, 24 Oct 2007 06:18:05 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkdJH-000851-KJ for nfsv4@ietf.org; Wed, 24 Oct 2007 06:18:00 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l9OAI64S008117; Wed, 24 Oct 2007 06:18:06 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 24 Oct 2007 06:18:06 -0400 Received: from bh-buildlin1.bhalevy.com ([172.17.28.148]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 06:17:16 -0400 Message-ID: <471F1BD0.2030509@panasas.com> Date: Wed, 24 Oct 2007 12:17:52 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] Layout Range. References: <344957.1471.qm@web38111.mail.mud.yahoo.com> In-Reply-To: <344957.1471.qm@web38111.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2007 10:17:16.0926 (UTC) FILETIME=[0DB069E0:01C81627] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Anatoly Pinchuk , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Interestingly enough we discussed this issue also during the Bakeathon. The common interpretation of the current spec amongst the people I asked was that if the server returns a different range than what was requested then it must cover [loga_offset, loga_offset + loga_minlength - 1] i.e. loga_minlength refers to bytes following the requested offset. This will provide for a simple client implementation that sweeps through the desired range. Benny On Oct. 24, 2007, 2:59 +0200, Mike Eisler wrote: > Great minds apparently worry about the same issues at the same time. > :-) > > It was pointed out to me that some file systems or pNFS servers > might have multiple, very distinct striping patterns per file. > > To take Anatoly's example: > > [1027, 0x0x99999999] might be striped over 4 data servers, > [0x10000000, 0x30000000] might striped over 6 servers, and > [0x30000001, 0x40000000] might striped over 5 servers, and each > group of data servers might be different. > > We have at leats two ways to go: > > - Explicitly allow LAYOUTGET to return a subset of the requested range, > and include some information about why this was done (e.g. two > flags that indicates that the low end and/or high end of the > requested > range has a different striping pattern > > - change LAYOUTGET to return an array of what it currently returns. > > Regarding: > >> For example, if the client requested the layout for range [1027, >> 0x40000000], the server can return one for [0x10000000, 0x30000000] > range. >> If so, the returned layout should be limited to the range indicated >> by the server >> >> ([0x10000000, 0x30000000] in the example above ). It is not clear how >> nfsv4_1_file_layout4 structure does that. It would be great if >> somebody provides a clarification. > > I didn't understand the question ... or rather didn't understand > what had to be clarified. > > /* Encoded in the loc_body field of type layout_content4: */ > struct nfsv4_1_file_layout4 { > deviceid4 nfl_deviceid; > nfl_util4 nfl_util; > uint32_t nfl_first_stripe_index; > nfs_fh4 nfl_fh_list<>; > }; > > struct layout4 { > offset4 lo_offset; > length4 lo_length; > layoutiomode4 lo_iomode; > layout_content4 lo_content; > }; > > The idea is that from lo_offset though lo_offset + lo_length - 1. > In this case we chop that range into stripe unit sizes as encoded > in nfl_util. > > --- Anatoly Pinchuk wrote: > >> According to the description of the LAYOUTGET operation >> >> >> >> (Page 453, >> > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-14.tx >> t >> > > xt> ) >> >> As well, the metadata server may adjust the range of the returned >> >> layout based on striping patterns and usage implied by the >> >> loga_iomode. The client must be prepared to get a layout that >> does >> >> not line up exactly with its request; there MUST be at least an >> >> overlap of loga_minlength between the layout returned by the >> server >> >> and the client's request, or the server SHOULD reject the request. >> >> See Section 13.5.2 for more details. >> >> >> >> there is a possibility that the server returns layout for just a >> sub-range of the range >> >> requested by the client. In other words, if the client requested a >> layout for [min, max] >> >> range, the server, generally, can return layout applicable to only >> [min >> + p, max - q] one, >> >> where p>=0, q>=0; min, p, max, and q have to satisfy some consistency >> rules. >> >> For example, if the client requested the layout for range [1027, >> 0x40000000], >> >> the server can return one for [0x10000000, 0x30000000] range. >> >> >> >> If so, the returned layout should be limited to the range indicated >> by >> the server >> >> ([0x10000000, 0x30000000] in the example above ). It is not clear how >> >> nfsv4_1_file_layout4 structure does that. It would be great if >> somebody >> provides a clarification. >> >> >> >> Thanks, >> >> Anatoly >> >> >> >>> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 >> > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 24 12:23:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkizF-0004dY-M9; Wed, 24 Oct 2007 12:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkizE-0004Yp-9u for nfsv4@ietf.org; Wed, 24 Oct 2007 12:21:40 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikiz4-0004Py-7m for nfsv4@ietf.org; Wed, 24 Oct 2007 12:21:40 -0400 X-IronPort-AV: E=Sophos;i="4.21,325,1188802800"; d="scan'208";a="116460143" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 Oct 2007 09:21:04 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9OGL13v003100; Wed, 24 Oct 2007 09:21:01 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 09:21:01 -0700 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 09:21:01 -0700 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 09:21:00 -0700 Message-ID: <471F70EC.3020800@netapp.com> Date: Wed, 24 Oct 2007 09:21:00 -0700 From: Garth Goodson User-Agent: Icedove 1.5.0.12 (X11/20070730) MIME-Version: 1.0 To: Benny Halevy Subject: Re: [nfsv4] Layout Range. References: <344957.1471.qm@web38111.mail.mud.yahoo.com> <471F1BD0.2030509@panasas.com> In-Reply-To: <471F1BD0.2030509@panasas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2007 16:21:00.0740 (UTC) FILETIME=[DDB22840:01C81659] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: email2mre-ietf@yahoo.com, Anatoly Pinchuk , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Benny Halevy wrote: > Interestingly enough we discussed this issue also during the Bakeathon. > The common interpretation of the current spec amongst the people I > asked was that if the server returns a different range than what was > requested then it must cover [loga_offset, loga_offset + loga_minlength - 1] > i.e. loga_minlength refers to bytes following the requested offset. > This will provide for a simple client implementation that sweeps > through the desired range. > > Benny Right. LAYOUTGET was designed to return a single range starting at the offset returned covering the length returned. I believe it is stated that the returned layout must overlap by at least loga_minlength bytes (which must be at least 1) the requested range. If the minlength requirement can not be met in a single layout an error is returned and the client is currently responsible for splitting that range and retrying. If there are different striping patterns these should be returned via multiple layoutgets in separate layouts. -Garth > > On Oct. 24, 2007, 2:59 +0200, Mike Eisler wrote: >> Great minds apparently worry about the same issues at the same time. >> :-) >> >> It was pointed out to me that some file systems or pNFS servers >> might have multiple, very distinct striping patterns per file. >> >> To take Anatoly's example: >> >> [1027, 0x0x99999999] might be striped over 4 data servers, >> [0x10000000, 0x30000000] might striped over 6 servers, and >> [0x30000001, 0x40000000] might striped over 5 servers, and each >> group of data servers might be different. >> >> We have at leats two ways to go: >> >> - Explicitly allow LAYOUTGET to return a subset of the requested range, >> and include some information about why this was done (e.g. two >> flags that indicates that the low end and/or high end of the >> requested >> range has a different striping pattern >> >> - change LAYOUTGET to return an array of what it currently returns. >> >> Regarding: >> >>> For example, if the client requested the layout for range [1027, >>> 0x40000000], the server can return one for [0x10000000, 0x30000000] >> range. >>> If so, the returned layout should be limited to the range indicated >>> by the server >>> >>> ([0x10000000, 0x30000000] in the example above ). It is not clear how >>> nfsv4_1_file_layout4 structure does that. It would be great if >>> somebody provides a clarification. >> I didn't understand the question ... or rather didn't understand >> what had to be clarified. >> >> /* Encoded in the loc_body field of type layout_content4: */ >> struct nfsv4_1_file_layout4 { >> deviceid4 nfl_deviceid; >> nfl_util4 nfl_util; >> uint32_t nfl_first_stripe_index; >> nfs_fh4 nfl_fh_list<>; >> }; >> >> struct layout4 { >> offset4 lo_offset; >> length4 lo_length; >> layoutiomode4 lo_iomode; >> layout_content4 lo_content; >> }; >> >> The idea is that from lo_offset though lo_offset + lo_length - 1. >> In this case we chop that range into stripe unit sizes as encoded >> in nfl_util. >> >> --- Anatoly Pinchuk wrote: >> >>> According to the description of the LAYOUTGET operation >>> >>> >>> >>> (Page 453, >>> >> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-14.tx >>> t >>> >> >> xt> ) >>> >>> As well, the metadata server may adjust the range of the returned >>> >>> layout based on striping patterns and usage implied by the >>> >>> loga_iomode. The client must be prepared to get a layout that >>> does >>> >>> not line up exactly with its request; there MUST be at least an >>> >>> overlap of loga_minlength between the layout returned by the >>> server >>> >>> and the client's request, or the server SHOULD reject the request. >>> >>> See Section 13.5.2 for more details. >>> >>> >>> >>> there is a possibility that the server returns layout for just a >>> sub-range of the range >>> >>> requested by the client. In other words, if the client requested a >>> layout for [min, max] >>> >>> range, the server, generally, can return layout applicable to only >>> [min >>> + p, max - q] one, >>> >>> where p>=0, q>=0; min, p, max, and q have to satisfy some consistency >>> rules. >>> >>> For example, if the client requested the layout for range [1027, >>> 0x40000000], >>> >>> the server can return one for [0x10000000, 0x30000000] range. >>> >>> >>> >>> If so, the returned layout should be limited to the range indicated >>> by >>> the server >>> >>> ([0x10000000, 0x30000000] in the example above ). It is not clear how >>> >>> nfsv4_1_file_layout4 structure does that. It would be great if >>> somebody >>> provides a clarification. >>> >>> >>> >>> Thanks, >>> >>> Anatoly >>> >>> >>> >>>> _______________________________________________ >>> nfsv4 mailing list >>> nfsv4@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nfsv4 >>> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Maureen_McCoin@deltaef.com Wed Oct 24 12:34:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkjBQ-0003IP-5C for nfsv4-archive@lists.ietf.org; Wed, 24 Oct 2007 12:34:16 -0400 Received: from [86.158.132.218] (helo=host86-158-132-218.range86-158.btcentralplus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkjBK-0004ts-Lz for nfsv4-archive@lists.ietf.org; Wed, 24 Oct 2007 12:34:11 -0400 Received: from davies ([121.150.16.38] helo=davies) by host86-158-132-218.range86-158.btcentralplus.com ( sendmail 8.13.3/8.13.1) with esmtpa id 1exebN-000XVF-RD for nfsv4-archive@lists.ietf.org; Wed, 24 Oct 2007 17:34:22 +0100 Message-ID: <000301c8165b$b1434530$da849e56@davies> From: "Maureen McCoin" To: Subject: etthcams Date: Wed, 24 Oct 2007 17:34:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C81664.1307AD30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0004_01C81664.1307AD30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hallo nfsv4-archive hold on, big dicks get sucked dry so you better make it big! http://roish.com/ Maureen McCoin ------=_NextPart_000_0004_01C81664.1307AD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hallo nfsv4-archive
hold on, big dicks get sucked dry so you = better make it=20 big!
http://roish.com/
Maureen McCoin
------=_NextPart_000_0004_01C81664.1307AD30-- From nfsv4-bounces@ietf.org Wed Oct 24 17:20:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkncL-0004rw-8R; Wed, 24 Oct 2007 17:18:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkncK-0004rr-0l for nfsv4@ietf.org; Wed, 24 Oct 2007 17:18:20 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkncJ-0002E4-LS for nfsv4@ietf.org; Wed, 24 Oct 2007 17:18:19 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9OLIDrn003879 for ; Wed, 24 Oct 2007 21:18:13 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQF00B01OQ3OC00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Wed, 24 Oct 2007 15:18:13 -0600 (MDT) Received: from [10.0.1.195] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQF008GJPU4AH80@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 24 Oct 2007 15:18:05 -0600 (MDT) Date: Wed, 24 Oct 2007 16:18:04 -0500 From: Robert Gordon Subject: Re: [nfsv4] Layout Range. In-reply-to: <471F70EC.3020800@netapp.com> To: NFSv4 Message-id: <29CD78A2-9431-48C4-9326-36B6132145E3@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <344957.1471.qm@web38111.mail.mud.yahoo.com> <471F1BD0.2030509@panasas.com> <471F70EC.3020800@netapp.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 24, 2007, at 11:21 AM, Garth Goodson wrote: > Right. LAYOUTGET was designed to return a single range starting > at the offset returned covering the length returned. I believe > it is stated that the returned layout must overlap by at least > loga_minlength bytes (which must be at least 1) the requested range. > If the minlength requirement can not be met in a single layout an > error is returned and the client is currently responsible for > splitting > that range and retrying. I think that error would be NFS4ERR_LAYOUTTRYLATER, however we do not indicate it this is a transient issue or if the client needs to split the range and try again. > > If there are different striping patterns these should be returned > via multiple layoutgets in separate layouts. It would seem easier to make LAYOUTGET4resok.logr_layout an array, as mike suggested. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 24 17:23:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikngg-0006e9-OC; Wed, 24 Oct 2007 17:22:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iknge-0006e1-Ms for nfsv4@ietf.org; Wed, 24 Oct 2007 17:22:48 -0400 Received: from p01c11o141.mxlogic.net ([208.65.144.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikngd-0002L1-Mj for nfsv4@ietf.org; Wed, 24 Oct 2007 17:22:48 -0400 Received: from unknown [63.110.244.103] (EHLO us-email.terastack.bluearc.com) by p01c11o141.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id 7a7bf174.156076976.94513.00-004.p01c11o141.mxlogic.net (envelope-from ); Wed, 24 Oct 2007 15:22:47 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Oct 2007 14:22:45 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on stripe unit size in file layout Thread-Index: AcgWhATrFrSB5UBoTVOfPz1hNp2ymg== From: "Suchit Kaura" To: X-Spam: [F=0.0100000000; S=0.010(2007101601); SS=0.500] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Subject: [nfsv4] Question on stripe unit size in file layout X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2140152766==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============2140152766== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81684.053316E9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81684.053316E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I just wanted to get some more clarifications in this regard. Looking at the issue from a pNfs client perspective: The client has a set of ranges AKA layouts that define parts of the user defined file, that it has obtained from the metadata server. Thus, a clients view of a file could be: 0 to Oa-1 : No Layout Available Oa to Ob -1 : Layout 1 Ob to Oc -1 : Layout 2 Oc to Od -1 : No Layout Available Od to EOF : Layout 3, loga_length field with all bits set to 1 (one) per specification. Oa, Ob, Oc, Od represent offsets within the file. EOF is end of file. An IO to a file has a file offset and a length. The first thing the client needs to do is to map the IO i.e. Offset O Length L into the several (1 to n) layouts that are needed to satisfy the request (This could involve requesting some layouts from the Metadata server). The client would then need to process the applicable offset, length contained within a given layout to determine where exactly to send the IO. Thus, in general a client would need to resolve a offset, length range present within a layout to several ranges AKA stripe units.=20 For a given file a pNfs client can indicate the preferred stripe unit size using the layouthint structure. The metadata server however can return a different size for the requested layout. =20 http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-13 page 272 ---- /* Encoded in the loc_body field of type layout_content4: */ struct nfsv4_1_file_layout4 { deviceid4 nfl_deviceid; nfl_util4 nfl_util; uint32_t nfl_first_stripe_index; nfs_fh4 nfl_fh_list<>; }; The nfsv4_1_file_layout4 data type represents the layout. It is composed of four fields: 1. nfl_deviceid: The device ID which maps to a value of type nfsv4_1_file_layout_ds_addr4. 2. nfl_util: Like the nflh_util field of data type nfsv4_1_file_layouthint4, a compact representation of how the data on a file on each data server is packed, whether the client should send COMMIT operations to the metadata server or data server, and the stripe unit size. ---- A couple of questions: Do we imagine then that different layouts can have different stripe unit sizes or is this explicitly forbidden for a metadata server to return different stripe unit sizes for the same file? =20 In general if we are writing a client can we use file_offset - layout->lo_offset instead of file_offset for dense layouts calculation? layout->lo_offset represents the base offset within a particular layout returned by the metadata server. http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-13 page 276 ------------- The calculation to determine the octet offset within the data file for dense data server layouts is: stripe_width =3D stripe_unit_size * N; where N =3D number of elements in nflda_stripe_indices. data_file_offset =3D floor(file_offset / stripe_width) * stripe_unit_size + file_offset % stripe_unit_size -------------- Once again thanks for all the clarifications. Regards, Suchit ------_=_NextPart_001_01C81684.053316E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I just wanted to get some more = clarifications in this=20 regard.

Looking at the issue from a pNfs client=20 perspective:

The client has a set of ranges AKA layouts that define parts of the user defined file, that it has obtained from the metadata=20 server.

Thus, a clients view of a file could be:

to =20 Oa-1   : No Layout Available

Oa to O-1=20 : Layout 1

Ob to Oc = -1 : Layout = 2

Oc to Od = -1 : No Layout=20 Available

Od to EOF : Layout 3, loga_length field with all = bits set=20 to 1 (one) per = specification.

Oa, Ob, = Oc, Od=20 represent offsets within the file. EOF is end of file.

An IO to a file has a file offset and a = length.=20 The first thing the client needs to do is to map the IO i.e. Offset O Length L into the several (1 to n) layouts that are = needed to=20 satisfy the request (This could involve requesting some layouts from the Metadata = server). = The client would then need to process the applicable = offset,=20 length contained within a = given=20 layout to determine where exactly to send the IO.

Thus, in general a client would need to resolve a = offset,=20 length range present within a layout to several ranges=20 AKA stripe units. =

For a given file a pNfs client can = indicate the=20 preferred stripe unit size using the layouthint structure. The metadata = server=20 however can return a different size for the requested layout.

 

http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-13 page=20 272

----

/* Encoded in the loc_body field of type=20 layout_content4: */

struct nfsv4_1_file_layout4 {

deviceid4 nfl_deviceid;

nfl_util4 nfl_util;

uint32_t = nfl_first_stripe_index;

nfs_fh4 nfl_fh_list<>;

};

The nfsv4_1_file_layout4 data type = represents the=20 layout. It is

composed of four fields:

1. nfl_deviceid: The device ID which maps = to a value=20 of type

nfsv4_1_file_layout_ds_addr4.

2. nfl_util: Like the nflh_util field of = data=20 type

nfsv4_1_file_layouthint4, a compact = representation of=20 how the

data on a file on each data server is = packed, whether=20 the client

should send COMMIT operations to the = metadata server=20 or data

server, and the stripe unit = size.

----

A couple = of=20 questions:

Do we imagine then that different = layouts can=20 have different stripe unit sizes or is this explicitly forbidden for a = metadata=20 server to return different stripe = unit sizes=20 for the same file=20

In = general if we are writing a client = can we=20 use file_offset - layout->lo_offset instead of file_offset for dense = layouts calculation?

layout->lo_offset=20 represents the base offset within a particular = layout=20 returned by the metadata server.

http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-13 page = 276

-------------

   The calculation to determine the octet offset = within the=20 data file
   for dense data server layouts=20 is:

      stripe_width =3D = stripe_unit_size *=20 N;
         where N =3D = number of=20 elements in nflda_stripe_indices.

     =20 data_file_offset =3D floor(file_offset /=20 stripe_width)
         *=20 stripe_unit_size
         +=20 file_offset % stripe_unit_size
--------------

=

Once again thanks for all the=20 clarifications.

Regards,

Suchit

------_=_NextPart_001_01C81684.053316E9-- --===============2140152766== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============2140152766==-- From nfsv4-bounces@ietf.org Wed Oct 24 17:37:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iknuh-0003W8-Eb; Wed, 24 Oct 2007 17:37:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iknuf-0003Sd-Ca for nfsv4@ietf.org; Wed, 24 Oct 2007 17:37:17 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iknue-0002fG-W6 for nfsv4@ietf.org; Wed, 24 Oct 2007 17:37:17 -0400 X-IronPort-AV: E=Sophos;i="4.21,326,1188802800"; d="scan'208";a="116536708" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 Oct 2007 14:37:16 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9OLbFUC022522; Wed, 24 Oct 2007 14:37:15 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 14:37:15 -0700 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 14:37:15 -0700 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 14:37:15 -0700 Message-ID: <471FBB09.1060508@netapp.com> Date: Wed, 24 Oct 2007 14:37:13 -0700 From: Garth Goodson User-Agent: Icedove 1.5.0.12 (X11/20070730) MIME-Version: 1.0 To: Robert Gordon Subject: Re: [nfsv4] Layout Range. References: <344957.1471.qm@web38111.mail.mud.yahoo.com> <471F1BD0.2030509@panasas.com> <471F70EC.3020800@netapp.com> <29CD78A2-9431-48C4-9326-36B6132145E3@Sun.COM> In-Reply-To: <29CD78A2-9431-48C4-9326-36B6132145E3@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2007 21:37:15.0370 (UTC) FILETIME=[0B74ECA0:01C81686] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Robert Gordon wrote: > > On Oct 24, 2007, at 11:21 AM, Garth Goodson wrote: > >> Right. LAYOUTGET was designed to return a single range starting >> at the offset returned covering the length returned. I believe >> it is stated that the returned layout must overlap by at least >> loga_minlength bytes (which must be at least 1) the requested range. >> If the minlength requirement can not be met in a single layout an >> error is returned and the client is currently responsible for splitting >> that range and retrying. > > I think that error would be NFS4ERR_LAYOUTTRYLATER, however we > do not indicate it this is a transient issue or if the client > needs to split the range and try again. > TRYLATER is a transient error and I think should not be returned if a range needs to be split due to striping issues, rather than some type of locking issue over a portion of the range. >> >> If there are different striping patterns these should be returned >> via multiple layoutgets in separate layouts. > > It would seem easier to make LAYOUTGET4resok.logr_layout an array, > as mike suggested. > I have no objection to returning an array, however I believe that a client will still have to handle the corner case of not retrieving the entire range at once (even if multiple layouts are returned), since there could be other factors; e.g., max_count is too small to return all layouts that cover that range. -Garth > Robert. > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Reidt@sdatek.de Thu Oct 25 05:07:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikygu-0006wx-CQ for nfsv4-archive@lists.ietf.org; Thu, 25 Oct 2007 05:07:48 -0400 Received: from host35-151-dynamic.54-82-r.retail.telecomitalia.it ([82.54.151.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikygt-0000Gb-Nm for nfsv4-archive@lists.ietf.org; Thu, 25 Oct 2007 05:07:48 -0400 Received: from eurotel-fa4b57e ([150.196.46.78] helo=eurotel-fa4b57e) by host35-151-dynamic.54-82-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1hKWCy-000GHH-tB for nfsv4-archive@lists.ietf.org; Thu, 25 Oct 2007 11:08:59 +0200 Message-ID: <000c01c816e6$9a744760$23973652@eurotelfa4b57e> From: "mansur Reidt" To: Subject: aniohar{ Date: Thu, 25 Oct 2007 11:08:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C816F7.5DFD1760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C816F7.5DFD1760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello babe nfsv4-archive its not about how you use it, its about how big your dick is http://www.ruedauto.com/ mansur Reidt ------=_NextPart_000_0009_01C816F7.5DFD1760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello babe nfsv4-archive
its not about how you use it, its about how = big your=20 dick is
http://www.ruedauto.com/
mansur Reidt
------=_NextPart_000_0009_01C816F7.5DFD1760-- From nfsv4-bounces@ietf.org Thu Oct 25 09:34:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2pX-0000Qs-Mg; Thu, 25 Oct 2007 09:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2pW-0000Lb-EH for nfsv4@ietf.org; Thu, 25 Oct 2007 09:32:58 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il2pN-0003Uw-9L for nfsv4@ietf.org; Thu, 25 Oct 2007 09:32:55 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l9PDWsBA023302; Thu, 25 Oct 2007 09:32:54 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 25 Oct 2007 09:32:54 -0400 Received: from bh-buildlin1.bhalevy.com ([172.17.28.148]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 09:31:50 -0400 Message-ID: <47209AEB.6010907@panasas.com> Date: Thu, 25 Oct 2007 15:32:27 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Garth Goodson Subject: Re: [nfsv4] Layout Range. References: <344957.1471.qm@web38111.mail.mud.yahoo.com> <471F1BD0.2030509@panasas.com> <471F70EC.3020800@netapp.com> <29CD78A2-9431-48C4-9326-36B6132145E3@Sun.COM> <471FBB09.1060508@netapp.com> In-Reply-To: <471FBB09.1060508@netapp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2007 13:31:51.0323 (UTC) FILETIME=[6695C6B0:01C8170B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Robert Gordon , NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct. 24, 2007, 23:37 +0200, Garth Goodson wrote: > > Robert Gordon wrote: >> On Oct 24, 2007, at 11:21 AM, Garth Goodson wrote: >> >>> Right. LAYOUTGET was designed to return a single range starting >>> at the offset returned covering the length returned. I believe >>> it is stated that the returned layout must overlap by at least >>> loga_minlength bytes (which must be at least 1) the requested range. >>> If the minlength requirement can not be met in a single layout an >>> error is returned and the client is currently responsible for splitting >>> that range and retrying. >> I think that error would be NFS4ERR_LAYOUTTRYLATER, however we >> do not indicate it this is a transient issue or if the client >> needs to split the range and try again. >> > TRYLATER is a transient error and I think should not be returned if a > range needs to be split due to striping issues, rather than some type of > locking issue over a portion of the range. > >>> If there are different striping patterns these should be returned >>> via multiple layoutgets in separate layouts. >> It would seem easier to make LAYOUTGET4resok.logr_layout an array, >> as mike suggested. >> > > I have no objection to returning an array, however I believe that a > client will still have to handle the corner case of not retrieving the > entire range at once (even if multiple layouts are returned), since > there could be other factors; e.g., max_count is too small to return all > layouts that cover that range. Agreed. Benny > > -Garth > >> Robert. >> _______________________________________________ _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Oct 25 13:24:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6Qq-0005Zb-98; Thu, 25 Oct 2007 13:23:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il6Qo-0005Xw-EB for nfsv4@ietf.org; Thu, 25 Oct 2007 13:23:42 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il6QZ-0004xz-2W for nfsv4@ietf.org; Thu, 25 Oct 2007 13:23:42 -0400 X-IronPort-AV: E=Sophos;i="4.21,329,1188802800"; d="scan'208";a="116781782" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 25 Oct 2007 10:23:13 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9PHKd4w027492; Thu, 25 Oct 2007 10:22:40 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 10:20:16 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 10:20:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Review Comments for The 4th Review Meeting for Locking and Directory Delegations Date: Thu, 25 Oct 2007 13:20:27 -0400 Message-ID: In-Reply-To: <7619F3097FAB384287CF636FF92D0CA10AD8E7BB@exsvl01.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Review Comments for The 4th Review Meeting for Locking and Directory Delegations Thread-Index: Acf3F3nadrLmCGYDTKezznslo8yNoAgEUfaA From: "Noveck, Dave" To: "Weaver, Amy" , "Eisler, Michael" , , , , "Erasani, Pranoop" X-OriginalArrivalTime: 25 Oct 2007 17:20:16.0463 (UTC) FILETIME=[4F7C2DF0:01C8172B] X-Spam-Score: -4.0 (----) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > 26901-26903 Mike Needs clarification =20 > 26901 The server MUST send in cpda_delegation a delegation corresponding to > 26902 the type of what the client requested in the OPEN, WANT_DELEGATION, > 26903 or GET_DIR_DELEGATION request. I recall that we had a discussion about whether CB_PUSH_DELEG could in fact propagate a delegation requested by GET_DIR_DELEGATION, as opposed to delegation for non-directory types of objects. I guess there was also implicitly a question about whether it should be able to do so. So on the first point, the answer seems to be "No" since CB_PUSH_DELEGargs contains an open_delegation4, which doesn't have a provision for a lot of the data returned in a GET_DIR_DELEGATION4resok. Since this information is not provided on the response to the GET_DIR_DELEGATION or in the CB_PUSH_DELEG, it doesn't seem that there is a current provision for CB_PUSH_DELEG to=20 deliver a directory delegation. In fact, there is no provision currently for GET_DIR_DELEGATION to promise to deliver a directory delegation when the delgation is available (i.e. there is no conflict on that specific object), which would call for CB_PUSH_DELEG or something like it. The only provision in which it promises to signal you is when there is resources unavailable, i.e. something will be resolved by CB_RECALLABLE_OBJ_AVAIL.=20 I'm supposing that this structure derives from the fact that there are no write directory delegations and it is thus impossible for there to be a=20 hard conflict that would not allow a directory delegation to be granted. I'm not sure if this logic is valid since it is possible for a server not to grant a directory delegation because frequent directory changes makes this not an efficient way to go. And if that could cause a delegation to be denied, the situation might be changed when those changes stop. Anyway, what I am going to do now is to change CB_PUSH_DELEG so it doens't reference GET_DIR_DELEGATION and if we want to extend GET_DIR_DELEGATION and CB_PUSH_DELEG to support this, we can handle that separately from the review of the locking chapters. -----Original Message----- From: Weaver, Amy=20 Sent: Friday, September 14, 2007 5:38 PM To: Eisler, Michael; Noveck, Dave; spencer.shepler@sun.com; Eric.Kustarz@Sun.COM; Robert.Gordon@sun.com Cc: Weaver, Amy; Erasani, Pranoop Subject: [nfsv4] Review Comments for The 4th Review Meeting for Locking and Directory Delegations What: The 4th Review Meeting for Locking and Directory Delegations When: September 14, 2007, 12:00 - 2:00 PST Attendees and roles: Name Company Role ------------------------------------------------------------------ Mike Eisler Network Appliance Reader/Editor Dave Noveck Network Appliance Editor Amy Weaver Network Appliance Recorder Spencer Sheple Sun Microsystems Editor Robert Gordon Sun Microsystems Editor/Inspector=20 Eric Kustarz Sun Microsystems Editor/Inspector=20 Items/lines to be reviewed: Directory Notification Attributes 6057-6079 CB_NOTIFY CB_PUSH_DELEG CB_RECALL_ANY CB_RECALLABLE_OBJ_ANY 26670-27121 CB_WANTS_CANCELLED CB_NOTIFY_LOCK 27340-27452=20 Review Comments: Line# Raised by Comment=20 ----- --------- ---------=20 6060 Amy add "to" after free 6064 - 6066 Mike/Dave Remove "^M", clarify whether server is free to return result=20 which is in conflict what getattr returns 6069, 6071 Amy dir_notif_delay and dir_notify_delay inconsistent 26740-26753 Mike Change to bitmap 26740-26753 Dave Why? Similar attributes uses bit map, for extensibility without extending the union 26758 Mike notify4 has to be a bit map 26782 Mike Describe pNFS mapping as well 26815 Mike/Dave Do we want to distinguish between renaming/removing a file across directories Creating a hard link is considered adding a file, should be discussed in Adding a file. Question: distinguish between creating a hard link vs. a file 26831 Mike Clarify that this is get_dir_delegation 26835 Mike any file -> any file's 26837 Mike per file -> a specific file 26854 Mike Delete 20.4.5 26857 Mike Add one line summary 26898 Dave/Robert Want to have specific error to reject delegation, for all other error codes, the inspection team has to meet to define the action for each error as what=20 to do with this delegation. If permanently rejected the delegation, the=20 WANT in WANT_DELEGATION is permanently deleted by the server. =20 26901-26903 Mike Needs clarification =20 26911-26913 Mike To be deleted. 27007 Mike sixteen -> number of 27068-27077 Mike/Dave Move under implementation 27081 Mike One line summary 27085 Mike Actual synopsis 27115-27120 Mike/Dave 1. objects to keep -> something else 2. Argument means that the client will be allowed to request that many objects=20 27122-27124 Mike Delete implementation 27341 Mike One line summary 27344 Mike Synopsis completely wrong =20 27373 Amy Add "to" in front of grant 27338 Mike Implementation - how to deal with races between this operation and operation on the fore=20 channel that asks for delegations or layouts 27392 Mike One line summary 27400-27401 Mike/Dave Reverse the arguments order 27414 Mike/Dave may -> can 27415 Mike/Dave may -> might be available 27426 Mike/Dave must not -> MUST NOT 27427 Mike lock -> LOCK 27412 Mike Needs to clarify that the client must previously issued unsuccessful lock operation 27434 Mike Requires cross reference 27445,27446 Mike "must not" -> "MUST NOT" 27448 Amy/Mike "should" -> "SHOULD" or "MUST" =20 27452 Mike add "to" before poll 27448-27452 Mike/Dave Add the following: In the event of OPEN_UPGRADE, if the value of may notify flag changes, then the last result wins. Spencer Move to the description at line 27423 =20 Regards, Amy Weaver Amy.Weaver@netapp.com 408.822.1532 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Oct 25 14:43:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il7fH-00062o-5S; Thu, 25 Oct 2007 14:42:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il7fG-0005iJ-5R for nfsv4@ietf.org; Thu, 25 Oct 2007 14:42:42 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il7et-00023L-IO for nfsv4@ietf.org; Thu, 25 Oct 2007 14:42:19 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9PIgIub016289 for ; Thu, 25 Oct 2007 18:42:18 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQH00F01CQMI100@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Thu, 25 Oct 2007 12:42:18 -0600 (MDT) Received: from [10.0.1.195] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQH00GL5DAFV540@mail-amer.sun.com>; Thu, 25 Oct 2007 12:42:17 -0600 (MDT) Date: Thu, 25 Oct 2007 13:42:15 -0500 From: Robert Gordon Subject: Re: [nfsv4] Review Comments for The 4th Review Meeting for Locking and Directory Delegations In-reply-to: To: "Noveck, Dave" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "Erasani, Pranoop" , nfsv4@ietf.org, Eric.Kustarz@Sun.COM, "Eisler, Michael" , Spencer.Shepler@Sun.COM, "Weaver, Amy" X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 25, 2007, at 12:20 PM, Noveck, Dave wrote: > Anyway, what I am going to do now is to change CB_PUSH_DELEG so it > doesn't reference GET_DIR_DELEGATION and if we want to extend > GET_DIR_DELEGATION > and CB_PUSH_DELEG to support this, we can handle that separately from > the review of the locking chapters. I agree. We might want to consider renaming CB_PUSH_DELEG to CB_PUSH_FILE_DELEG. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Igorsmarszalkowski@rivaoscar.it Fri Oct 26 04:33:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKcp-0004d6-S3 for nfsv4-archive@lists.ietf.org; Fri, 26 Oct 2007 04:33:03 -0400 Received: from c138088.adsl.hansenet.de ([213.39.138.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlKce-0002jg-Co for nfsv4-archive@lists.ietf.org; Fri, 26 Oct 2007 04:32:58 -0400 Received: from home-f9dluzu098 ([198.130.167.12]:23297 "EHLO home-f9dluzu098" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by c138088.adsl.hansenet.de with ESMTP id S22QEMDPRNWFYSYK (ORCPT ); Fri, 26 Oct 2007 10:33:25 +0200 Message-ID: <000901c817aa$ca4b22a0$588a27d5@homef9dluzu098> From: "Igors marszalkowski" To: Subject: meseoizn Date: Fri, 26 Oct 2007 10:32:48 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C817BB.8DD3F2A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C817BB.8DD3F2A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable wots up nfsv4-archive be the talk among your peers once they hear about your penis http://www.runcsepa.com/ Igors marszalkowski ------=_NextPart_000_0007_01C817BB.8DD3F2A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
wots up nfsv4-archive
be the talk among your peers once they hear = about your=20 penis
http://www.runcsepa.com/
Igors marszalkowski
------=_NextPart_000_0007_01C817BB.8DD3F2A0-- From stockley@simtaxusa.com Sat Oct 27 08:35:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilkt5-0000WI-V0 for nfsv4-archive@lists.ietf.org; Sat, 27 Oct 2007 08:35:35 -0400 Received: from aclermont-ferrand-256-1-119-183.w90-10.abo.wanadoo.fr ([90.10.190.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ilksz-0003vQ-Dt for nfsv4-archive@lists.ietf.org; Sat, 27 Oct 2007 08:35:35 -0400 Received: from nom-6223ba19add ([155.130.58.53]:19460 "EHLO nom-6223ba19add" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [90.10.190.183] with ESMTP id S22LIRQVEQLQJQGA (ORCPT ); Sat, 27 Oct 2007 14:36:02 +0200 Message-ID: <000801c81895$dc1b4eb0$b7be0a5a@nom6223ba19add> From: "jinshan stockley" To: Subject: 0ayogan Date: Sat, 27 Oct 2007 14:35:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C818A6.9FA41EB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C818A6.9FA41EB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello moto nfsv4-archive her pussy is screaming for some seriously big dick http://www.teezrus.com/ jinshan stockley ------=_NextPart_000_0007_01C818A6.9FA41EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello moto nfsv4-archive
her pussy is screaming for some seriously big=20 dick
http://www.teezrus.com/
jinshan stockley
------=_NextPart_000_0007_01C818A6.9FA41EB0-- From nfsv4-bounces@ietf.org Sun Oct 28 10:22:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im8yS-0003fn-3A; Sun, 28 Oct 2007 10:18:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im8yQ-0003fa-HM for nfsv4@ietf.org; Sun, 28 Oct 2007 10:18:42 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Im8yQ-00069H-04 for nfsv4@ietf.org; Sun, 28 Oct 2007 10:18:42 -0400 X-IronPort-AV: E=Sophos;i="4.21,338,1188802800"; d="scan'208";a="117515830" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 28 Oct 2007 07:18:32 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9SEIWCr010181 for ; Sun, 28 Oct 2007 07:18:32 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Oct 2007 07:18:32 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Oct 2007 07:18:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 28 Oct 2007 10:18:30 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How clients should deal with server reboot in v4.1 Thread-Index: AcgZbWo4CO2MTzxuRuuEodjhbO5J1w== From: "Noveck, Dave" To: X-OriginalArrivalTime: 28 Oct 2007 14:18:32.0453 (UTC) FILETIME=[6B6D8B50:01C8196D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [nfsv4] How clients should deal with server reboot in v4.1 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org As a result of looking at the locking sections of the spec as part of addressing the review comments, and thinking about the error list review, I've come to the conclusion that we can (and should) simplify the logic for the client to take note of server reboot events. I think we can take advantage of sessions so that the client will only note server reboot events after doing session recovery and getting a STALE_CLIENTID error. STALE_STATEID errors will go away away as will STALE_CLIENTID errors that occur for an existing session. This would also to apply to persistent sessions and reclaim would not occur due to SEQ4_STATUS_RESTART_RECLAIM_NEEDED. Reclaim in the peristent session case would happen just as it does in the non-persistent case, after a new session with a new clietid is established. The reason we can do this derives from the fact that stateid's are always tied to client IDs. Every stateid is interpreted in the context of a session and so we don't have the issue of recognizing stale stateids as we do in v4.0. We have the stale clientid/sessionid that serves the purpose and once we know that is invalid, we have enough information to indicate to the client that he has lost locking context. We don't need a separate STALE_STATEID error. If there has been a server reboot, then the session is gone and thus no separate STALE_CLIENTID error (see below for the persistent session case). The biggest conceptual change involves persistent sessions. The spec is currently inconsistent about recovery in this situation. In some places we stress that after reboot, such a session is dead. You can use it to retry operations that were in flight after a disconnection, to mine the persistent replay cache and find operations that were done before the server reboot, but not to start new ones. In other places it assumes that you will continue=20 To summarize, I propose: STALE_STATEID vanishes. From the minor version point of view it=20 remains a defined error but no v4.1 op can return it. In any=20 situation in which the server will be presented with stale=20 stateid/clientid co-ordinates, a BAD_SESSION or DEAD_SESSION=20 error will result. STALE_CLIENTID is limited to ops where we explicitly send a=20 clientid, rather than using one derived from a session=20 (CREATE_SESSION and DESTROY_CLIENTID). Thus, any situation=20 in which a client will attempt to manipulate locking state=20 and find out about a reboot, will first manifest as a BADSESSION or DEADSESSION and only when attempting to recover from that=20 would there be a STALE_CLIENTID. DEADSESSION would be returnable on all forward ops that can be=20 part of a session (all except EXCHANGE_ID) plus CB_SEQUENCE. =20 It needs to be added to the forward ops because you can have=20 a server reboot in which some COMPOUNDs are partially executed=20 and reissuing them on the persistent session will result in=20 a situation in which you recover status from the SEQUENCE and=20 some other ops in the COMPOUND but then reach some not executed=20 before the server failure. The status bit SEQ4_STATUS_RESTART_RECLAIM_NEEDED goes away=20 since you find out about server reboot for persistent sessions=20 in essentially the same way as you do for non-persistent=20 sessions. In light of this, all the stuff about needing to=20 do a TEST_STATEID when going a open-ecaim that might involve=20 an upgrade, also can go away. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Deon_rumbolt@sumfinstrat.com.au Mon Oct 29 06:52:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImSDx-00031X-2s for nfsv4-archive@lists.ietf.org; Mon, 29 Oct 2007 06:52:01 -0400 Received: from abgr156.neoplus.adsl.tpnet.pl ([83.7.81.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImSDt-0003Zh-QT for nfsv4-archive@lists.ietf.org; Mon, 29 Oct 2007 06:51:58 -0400 Received: from dom-875d77qebzg ([102.132.5.29] helo=dom-875d77qebzg) by abgr156.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1IgDcT-000QEU-pL for nfsv4-archive@lists.ietf.org; Mon, 29 Oct 2007 11:53:04 +0100 Message-ID: <000901c81a19$d009d8f0$9c510753@dom875d77qebzg> From: "Deon rumbolt" To: Subject: sopuun Date: Mon, 29 Oct 2007 11:52:34 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C81A22.31CE40F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C81A22.31CE40F0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable hello love nfsv4-archive take some advice, if she wants your cock bigger just do it http://www.uapoetal.com/ Deon rumbolt ------=_NextPart_000_0005_01C81A22.31CE40F0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
hello love nfsv4-archive
take some advice, if she wants your cock = bigger just do=20 it
http://www.uapoetal.com/
Deon rumbolt
------=_NextPart_000_0005_01C81A22.31CE40F0-- From nfsv4-bounces@ietf.org Mon Oct 29 08:33:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTlz-0000n1-SW; Mon, 29 Oct 2007 08:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImTly-0000kI-Kk for nfsv4@ietf.org; Mon, 29 Oct 2007 08:31:14 -0400 Received: from [72.32.189.38] (helo=mail.reqall.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImTls-0003nt-GI for nfsv4@ietf.org; Mon, 29 Oct 2007 08:31:14 -0400 Received: from [192.168.5.30] (unknown [124.30.147.166]) by mail.reqall.com (Postfix) with ESMTP id A05D2A2C52F for ; Mon, 29 Oct 2007 07:30:52 -0500 (CDT) Message-ID: <4725D25D.5050301@gmail.com> Date: Mon, 29 Oct 2007 18:00:21 +0530 From: "D.Saikrishna" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nfsv4@ietf.org. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [nfsv4] nfsv4 failover X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Hi , I am using nfsv4 in my testing setup. i have done a setup on 3 machines . i used one machine as a nfs4 server and remaining two as nfs4 clients. if nfs link is down between the clinet and server then some data is stored on client mount point then is it possible to store same data into server when the link is back/up. please let me know if any one solved this issue . thanks in advance --Sai _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 29 11:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWnn-0005gx-3X; Mon, 29 Oct 2007 11:45:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWnm-0005gp-Ds for nfsv4@ietf.org; Mon, 29 Oct 2007 11:45:18 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImWnl-0006Co-3T for nfsv4@ietf.org; Mon, 29 Oct 2007 11:45:18 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l9TFkMKM024492; Mon, 29 Oct 2007 11:46:22 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 29 Oct 2007 11:46:22 -0400 Received: from bh-buildlin1.bhalevy.com ([172.17.28.148]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Oct 2007 11:44:28 -0400 Message-ID: <47260003.8050400@panasas.com> Date: Mon, 29 Oct 2007 17:45:07 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Robert Gordon , Marc Eshel Subject: Re: [nfsv4] Device stateids References: <46B9E831.9030608@panasas.com> <46BAC0CA.8040208@panasas.com> In-Reply-To: <46BAC0CA.8040208@panasas.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2007 15:44:28.0415 (UTC) FILETIME=[9708A8F0:01C81A42] X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org During the most recent bakeathon concern has been raised about the global device ID namespace and Marc Eshel from IBM requested that we retain the ability to recall devices per-fsid. To satisfy this requirement as well as the requirement for a simple global device ID namespace the updated proposal below introduces a device-set identifier (devsetid) that qualifies the device ID. This provides for a more flexible deviceid namespace topology that can cover either a global deviceid namespace, per-fsid namespace, or anything in between (e.g. when several filesystems reside on (and are confined to) a set of devices, like in EMC or Panasas' cases). The proposal also introduces new operations to manage device mapping state rather than unnecessarily overloading existing operations. Plus, I simplified the proposal by not requiring any new sequence flags as the server should use the proposed callback operation to recall device mappings and use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED and SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the same it may use them for other recallable state objects (locks and layouts). One last change is providing for a "wildcard" value (0) for device ID that specifies all the device IDs in a devset. This means that the server MUST NOT return a zero device ID in GETDEVICELIST or in any layout and it must reject it as invalid in GETDEVICEINFO. I guess that this won't be an issue for anyone; otherwise, please holler. Benny -- 1. Introduction The NFS client maintains a mapping of device IDs contained in a layout to the corresponding storage device address. Device IDs and filesystem IDs are associated with device set IDs such that each fsid is associated with a single devsetid as indicated by a new, recommended filesystem attribute, and each deviceid is associated with a single devsetid. The state of the mapping is represented by a recallable device stateid (devstateid). There is at most one devstateid per { client ID, layout type, devsetid } nexus. A recommended filesystem attribute - devsetid is introduced. All deviceids associated with any file in the filesystem are associated with this devsetid. If the server does not support device sets, it can omit this attribute, making the deviceid namespace global and implicitly associating all deviceids with the default devset (having the implicit devsetid ID of 0) 2. Getting device information GETDEVICEINFO SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, notify_ask -> devstateid, notify_ack, device_addr GETDEVICELIST SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, cookieverf, notify_ask -> devstateid, notify_ack, cookie, cookieverf, device info list<> GETDEVICEINFO and GETDEVICELIST each take the a devstateid, a devsetid, and the layout type, and return a non-zero devstateid. In case the client holds a valid devstateid it MUST use it for subsequent GETDEVICEINFO and GETDEVICELIST that update the device ID mappings. The devstateid argument must be set to zero whenever the client has no valid devstateid (e.g. after reboot or after the devstateid was previously returned via DEVICERETURN). GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally asking for device notifications and return a corresponding flag confirming the notification. 3. Returning device IDs DEVICERETURN SYNOPSIS: devstateid, devsetid, deviceid -> devstateid DEVICERETURN returns a device ID mapping. When called, this client MUST guarantee not to make further use of that device ID mapping. If the deviceid argument is set to zero, all device ID mappings in the referred devset are returned. The server updates the devstateid and returns the updated value. 4. Sequencing rules Device stateids follow the sequencing and use rules of all other stateid types. The devstateid is invalidated when all devices associated with it are returned via DEVICERETURN. The client can then "forget" about that devstateid and use a value of zero for the devstateid for any subsequent operation that takes a devstateid argument and allows the uninitialized value. 5. Recalling device IDs CB_DEVICERECALL SYNOPSIS: devstateid, devsetid, deviceid, deleted -> CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify the client it needs to return the specified deviceid (when non-zero) or all device IDs in the devsetid when the deviceid is set to zero, by using a respective DEVICERETURN. CB_DEVICERECALL does not change the device stateid. All layouts using the affected device IDs remain in force, but the server SHOULD fence the client from accessing the affected devices until the client has returned the recalled device IDs. When the "deleted" boolean flag is set to false the client MAY use GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if it has valid layouts the refer to the changed deviceid. If the "deleted" flag is set to true the specified deviceid will not be reused by the server and all outstanding layouts referring to it are expected to be recalled via CB_LAYOUTRECALL; hence the client SHOULD NOT attempt to call GETDEVICEINFO or GETDEVICELIST for the specified deviceid. However, if it does do so the server MUST return a NFS4ERR_INVAL error. 6. Device notification CB_DEVICENOTIFY SYNOPSIS: devstateid, devsetid, deviceid -> If the server supports CB_DEVICENOTIFY for devices and the client has requested device id notifications via GETDEVICEINFO or GETDEVICELIST the server can inform the client of additional deviceids that were not previously returned by GETDEVICELIST. The purpose of this operation is to reduce the latency for getting new device mappings. Rather than waiting until the client accesses a file that uses the new device ID, issue a LAYOUTGET, and then a GETDEVICEINFO on the new device, the server can notify the client of any new device ID in advance and have the client get the device address mapping by calling GETDEVICEINFO at its convenience. CB_DEVICENOTIFY takes a device stateid, a device set ID and a device ID in the device set for a device ID that was not returned in a previous series GETDEVICELIST calls (where the series ended in gdlr_eof == TRUE). The client calls GETDEVICEINFO or GETDEVICELIST to determine the mappings for the new device ID. CB_DEVICENOTIFY does not change the device stateid. If the client has already issued a GETDEVICEINFO for the specified deviceid then it SHOULD just ignore the device id notification. Updating an existing device ID mapping should be done using a sequence of CB_DEVICERECALL, DEVICERETURN, and GETDEVICEINFO (or GETDEVICELIST). 7. SEQUENCE flags In addition to informing the client of mapping changes via CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag to indicate that one or more device IDs have been revoked without expiration of the lease period, due to the client's failure to return them when recalled. This status bit remains set on all SEQUENCE replies until the loss of all such device ID mappings has been acknowledged by use of DEVICERETURN. On Aug. 09, 2007, 10:22 +0300, Benny Halevy wrote: > Robert Gordon wrote: >> In general i think this is good. >> >> I've started to think that the SEQUENCE status flags could just be >> two bits. >> >> SEQ4_STATUS_DEVID_DELETED_ALL >> This flag stays on until the client issues a DELEGRETURN >> using the devstateid. >> >> SEQ_STATUS_DEVID_CHANGED >> This flag stay on until a GETDEVICELIST or GETDEVICEINFO >> (if using CB_NOTIFY) gets the affected mappings. > > The DEVID_DELETED cases should be covered by CHANGED as the client will > have to revalidate all the device mappings anyway to see what actually changed > and should either not see the deleted deviceid returned by GETDEVICELIST > or get an error from GETDEVICEINFO for that deviceid. > > The DEVID_ADDED case is covered if the client is doing GETDEVICELIST > and the server supports it. If the server does not support GETDEVICELIST > is must not set SEQ_STATUS_DEVID_CHANGED for added devices as the client > has no way to get the new device ID. These will be discovered only > when the client will get new layouts referring to the new devices > (which is perfectly fine) > >> Robert. >> >> On Aug 8, 2007, at 10:58 AM, Benny Halevy wrote: >> >>> The NFS client maintains a mapping of device ids contained >>> in a layout, to the corresponding storage device address. >>> The state of the mapping is represented by a single >>> recallable device stateid (devstateid). There is at most >>> one devstateid per { client ID, layout type } pair. >>> >>> GETDEVICEINFO and GETDEVICELIST each take the layout type and >>> an optional devstateid and return the devstateid. In case >>> the client holds a valid devstateid it MUST use it for subsequent >>> GETDEVICEINFO and GETDEVICELIST that update the device ID >>> mappings. The devstateid argument is invalid whenever the >>> client has no valid devstateid (e.g. after reboot or after >>> the devstateid was previously returned via DELEGRETURN). >>> GETDEVICEINFO or GETDEVICELIST that operate on a device stateid >>> that was already recalled via CB_RECALL MUST be rejected by the >>> server with NFS4ERR_BADSTATEID. >>> >>> GETDEVICEINFO and GETDEVICELIST also take a boolean flag >>> optionally asking for device notifications and return a >>> corresponding flag confirming the notification. >>> >>> Device stateids follow the sequencing and use rules of all other >>> stateid types. The mappings are invalidated when the devstateid is >>> returned via CB_DELEGRETURN or explicitly deleted via CB_NOTIFY. >>> >>> All layouts using the device IDs remain in force, but the >>> server MUST fence the client from accessing the affected >>> devices until the client has obtained the re-mapped device >>> IDs via GETDEVICEINFO or GETDEVICELIST. >>> >>> CB_RECALL takes a devstateid to notify the client it needs >>> to return all device IDs identified by the devstateid. The >>> filehandle argument has no use in this case. It does not change >>> the device stateid. >>> >>> DELEGRETURN takes a devstateid to return all device IDs associated >>> with the devstateid. The current filehandle has no use in this case. >>> >>> If the server supports CB_NOTIFY for devices and the Client has >>> requested device id notifications via GETDEVICEINFO >>> or GETDEVICELIST; The server can inform the client >>> of a delete, add, or change mapping. >>> >>> CB_NOTIFY takes a device stateid qualifying a device ID >>> for the following device notifications: >>> >>> NOTIFY4_DELETE_DEVICE_ID >>> Deletes all mappings using the specified device ID. >>> The server MUST stop using the device ID. Any >>> layouts remain in force, but aren't useful until >>> new mappings are available. The server fences the >>> client from the affected data server until all >>> layouts with the device ID are returned, or the >>> client obtains new mappings. The server provides >>> a hint as to whether new mappings will arrive and >>> if so how long. >>> >>> NOTIFY4_ADD_DEVICE_ID >>> Adds a device ID to address mapping. This is >>> for a device ID the that was not returned in a >>> previous series GETDEVICELIST calls (where the >>> series ended in gdlr_eof == TRUE). The client >>> calls GETDEVICEINFO or GETDEVICELIST to determine >>> the mappings for the new device ID. >>> >>> NOTIFY4_CHANGE_DEVICE_ID >>> The client call GETDEVICEINFO or GETDEVICELIST >>> to get updated device addresses for the device >>> ID. Layouts remain in force. The client is fenced >>> from any devices that were in the old address list, >>> but not the new address list. >>> >>> CB_NOTIFY does not change the device stateid. >>> >>> In addition to informing the client of mapping changes via >>> CB_NOTIFY and CB_RECALL, SEQUENCE carries status flags to >>> indicate that device mappings have changed. >>> >>> The flags are :- >>> >>> SEQ4_STATUS_DEVID_DELETED >>> Mapping has been partially deleted. If the client is >>> using CB_NOTIFY it may issue a GETDEVICEINFO for each >>> notified deletion or GETDEVICELIST to refresh the entire >>> map. This flag stays on until the client responds to >>> any and all _DELETE notifications, or it has issued a >>> GETDEVICELIST. >>> >>> SEQ4_STATUS_DEVID_DELETED_ALL >>> This flag stays on until the client issues a DELEGRETURN >>> using the devstateid. >>> >>> SEQ4_STATUS_DEVID_CHANGED >>> SEQ4_STATUS_DEVID_ADDED >>> These flags stay on until a GETDEVICELIST or GETDEVICEINFO >>> (if using CB_NOTIFY) gets the affected mappings. >>> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 29 12:21:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXLl-0001rJ-Ny; Mon, 29 Oct 2007 12:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXLj-0001r8-DO for nfsv4@ietf.org; Mon, 29 Oct 2007 12:20:23 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImXLd-0007os-77 for nfsv4@ietf.org; Mon, 29 Oct 2007 12:20:23 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l9TGLC1T025631; Mon, 29 Oct 2007 12:21:14 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 29 Oct 2007 12:21:12 -0400 Received: from bh-buildlin1.bhalevy.com ([172.17.28.148]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Oct 2007 12:19:18 -0400 Message-ID: <4726082D.5000100@panasas.com> Date: Mon, 29 Oct 2007 18:19:57 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "D.Saikrishna" Subject: Re: [nfsv4] nfsv4 failover References: <4725D25D.5050301@gmail.com> In-Reply-To: <4725D25D.5050301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2007 16:19:18.0453 (UTC) FILETIME=[74CB2650:01C81A47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct. 29, 2007, 14:30 +0200, "D.Saikrishna" wrote: > Hi , > > I am using nfsv4 in my testing setup. i have done a setup on 3 machines > . i used one machine as a nfs4 server and remaining two as nfs4 clients. > > if nfs link is down between the clinet and server then some data is > stored on client mount point then is it possible to store same data into > server when the link is back/up. > > please let me know if any one solved this issue . thanks in advance This is theoretically possible but you should ask your operating system's vendor. (e.g. for linux you can try nfsv4@linux-nfs.org) > > --Sai > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 29 15:58:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImakD-0002Wv-Ke; Mon, 29 Oct 2007 15:57:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImakB-0002Wp-U9 for nfsv4@ietf.org; Mon, 29 Oct 2007 15:57:52 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imak9-0002aV-Tr for nfsv4@ietf.org; Mon, 29 Oct 2007 15:57:51 -0400 X-IronPort-AV: E=Sophos;i="4.21,343,1188802800"; d="scan'208";a="117840053" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 29 Oct 2007 12:57:46 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9TJvk69006769; Mon, 29 Oct 2007 12:57:46 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 12:57:46 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 12:57:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Device stateids Date: Mon, 29 Oct 2007 15:57:44 -0400 Message-ID: In-Reply-To: <47260003.8050400@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Device stateids Thread-Index: AcgaRGaqw2ZVagnCR0OblKBOuxFYvAAE1z+g From: "Noveck, Dave" To: "Benny Halevy" , "Robert Gordon" , "Marc Eshel" X-OriginalArrivalTime: 29 Oct 2007 19:57:46.0303 (UTC) FILETIME=[F9AE54F0:01C81A65] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org =20 I've been hearing a lot talk about getting together a spec by 11/19 (final final deadline for next ietf) that would serve as the basis for a group last-call, although I've been saying "how about 'group penultimate-call'". As part of that, I'm trying to get to closure on the op to error mapping and I didn't expect to see a proposal at this point that would add 3 new ops, and a whole bunch of errors to two existing ops. If this is really needed, then we'll do what we have to do, but I'm not clear on the justification for something so different from what had been previously agreed to.=20 Is this stuff really a requirement, or is this a case of preferring to have bells and whistles, that we can do without? -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Monday, October 29, 2007 11:45 AM To: Robert Gordon; Marc Eshel Cc: NFSv4 Subject: Re: [nfsv4] Device stateids During the most recent bakeathon concern has been raised about the global device ID namespace and Marc Eshel from IBM requested that we retain the ability to recall devices per-fsid. To satisfy this requirement as well as the requirement for a simple global device ID namespace the updated proposal below introduces a device-set identifier (devsetid) that qualifies the device ID. This provides for a more flexible deviceid namespace topology that can cover either a global deviceid namespace, per-fsid namespace, or anything in between (e.g. when several filesystems reside on (and are confined to) a set of devices, like in EMC or Panasas' cases). The proposal also introduces new operations to manage device mapping state rather than unnecessarily overloading existing operations. Plus, I simplified the proposal by not requiring any new sequence flags as the server should use the proposed callback operation to recall device mappings and use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED and=20 SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the same it may use them for other recallable state objects (locks and layouts). One last change is providing for a "wildcard" value (0) for device ID that specifies all the device IDs in a devset. This means that the server MUST NOT return a zero device ID in GETDEVICELIST or in any layout and it must reject it as invalid in GETDEVICEINFO. I guess that this won't be an issue for anyone; otherwise, please holler. Benny -- 1. Introduction The NFS client maintains a mapping of device IDs contained in a layout to the corresponding storage device address. Device IDs and filesystem IDs are associated with device set IDs such that each fsid is associated with a single devsetid as indicated by a new, recommended filesystem attribute, and each deviceid is associated with a single devsetid. The state of the mapping is represented by a recallable device stateid (devstateid). There is at most one devstateid per { client ID, layout type, devsetid } nexus. A recommended filesystem attribute - devsetid is introduced. All deviceids associated with any file in the filesystem are associated with this devsetid.=20 If the server does not support device sets, it can omit this attribute, making the deviceid namespace global and implicitly associating all deviceids with the default devset (having the implicit devsetid ID of 0) 2. Getting device information GETDEVICEINFO SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, notify_ask -> devstateid, notify_ack, device_addr GETDEVICELIST SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, cookieverf, notify_ask -> devstateid, notify_ack, cookie, cookieverf, device info list<> GETDEVICEINFO and GETDEVICELIST each take the a devstateid, a devsetid, and the layout type, and return a non-zero devstateid. In case the client holds a valid devstateid it MUST use it for subsequent GETDEVICEINFO and GETDEVICELIST that update the device ID mappings. The devstateid argument must be set to zero whenever the client has no valid devstateid (e.g. after reboot or after the devstateid was previously returned via DEVICERETURN). GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally asking for device notifications and return a corresponding flag confirming the notification. 3. Returning device IDs DEVICERETURN SYNOPSIS: devstateid, devsetid, deviceid -> devstateid DEVICERETURN returns a device ID mapping. When called, this client MUST guarantee not to make further use of that device ID mapping. If the deviceid argument is set to zero, all device ID mappings in the referred devset are returned. The server updates the devstateid and returns the updated value. 4. Sequencing rules Device stateids follow the sequencing and use rules of all other stateid types. The devstateid is invalidated when all devices associated with it are returned via DEVICERETURN. The client can then "forget" about that devstateid and use a value of zero for the devstateid for any subsequent operation that takes a devstateid argument and allows the uninitialized value. 5. Recalling device IDs CB_DEVICERECALL SYNOPSIS: devstateid, devsetid, deviceid, deleted -> CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify the client it needs to return the specified deviceid (when non-zero) or all device IDs in the devsetid when the deviceid is set to zero, by using a respective DEVICERETURN. CB_DEVICERECALL does not change the device stateid. All layouts using the affected device IDs remain in force, but the server SHOULD fence the client from accessing the affected devices until the client has returned the recalled device IDs. When the "deleted" boolean flag is set to false the client MAY use GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if it has valid layouts the refer to the changed deviceid. If the "deleted" flag is set to true the specified deviceid will not be reused by the server and all outstanding layouts referring to it are expected to be recalled via CB_LAYOUTRECALL; hence the client SHOULD NOT attempt to call GETDEVICEINFO or GETDEVICELIST for the specified deviceid. However, if it does do so the server MUST return a NFS4ERR_INVAL error. 6. Device notification CB_DEVICENOTIFY SYNOPSIS: devstateid, devsetid, deviceid -> If the server supports CB_DEVICENOTIFY for devices and the client has requested device id notifications via GETDEVICEINFO or GETDEVICELIST the server can inform the client of additional deviceids that were not previously returned by GETDEVICELIST. The purpose of this operation is to reduce the latency for getting new device mappings. Rather than waiting until the client accesses a file that uses the new device ID, issue a LAYOUTGET, and then a GETDEVICEINFO on the new device, the server can notify the client of any new device ID in advance and have the client get the device address mapping by calling GETDEVICEINFO at its convenience. CB_DEVICENOTIFY takes a device stateid, a device set ID and a device ID in the device set for a device ID that was not returned in a previous series GETDEVICELIST calls (where the series ended in gdlr_eof =3D=3D TRUE). The client calls GETDEVICEINFO or GETDEVICELIST to determine the mappings for the new device ID. CB_DEVICENOTIFY does not change the device stateid. If the client has already issued a GETDEVICEINFO for the specified deviceid then it SHOULD just ignore the device id notification. Updating an existing device ID mapping should be done using a sequence of CB_DEVICERECALL, DEVICERETURN, and GETDEVICEINFO (or GETDEVICELIST). 7. SEQUENCE flags In addition to informing the client of mapping changes via CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag to indicate that one or more device IDs have been revoked without expiration of the lease period, due to the client's failure to return them when recalled. This status bit remains set on all SEQUENCE replies until the loss of all such device ID mappings has been acknowledged by use of DEVICERETURN. On Aug. 09, 2007, 10:22 +0300, Benny Halevy wrote: > Robert Gordon wrote: >> In general i think this is good. >> >> I've started to think that the SEQUENCE status flags could just be >> two bits. >> >> SEQ4_STATUS_DEVID_DELETED_ALL >> This flag stays on until the client issues a DELEGRETURN >> using the devstateid. >> >> SEQ_STATUS_DEVID_CHANGED >> This flag stay on until a GETDEVICELIST or GETDEVICEINFO >> (if using CB_NOTIFY) gets the affected mappings. >=20 > The DEVID_DELETED cases should be covered by CHANGED as the client will > have to revalidate all the device mappings anyway to see what actually changed > and should either not see the deleted deviceid returned by GETDEVICELIST > or get an error from GETDEVICEINFO for that deviceid. >=20 > The DEVID_ADDED case is covered if the client is doing GETDEVICELIST > and the server supports it. If the server does not support GETDEVICELIST > is must not set SEQ_STATUS_DEVID_CHANGED for added devices as the client > has no way to get the new device ID. These will be discovered only > when the client will get new layouts referring to the new devices > (which is perfectly fine) >=20 >> Robert. >> >> On Aug 8, 2007, at 10:58 AM, Benny Halevy wrote: >> >>> The NFS client maintains a mapping of device ids contained >>> in a layout, to the corresponding storage device address. >>> The state of the mapping is represented by a single >>> recallable device stateid (devstateid). There is at most >>> one devstateid per { client ID, layout type } pair. >>> >>> GETDEVICEINFO and GETDEVICELIST each take the layout type and >>> an optional devstateid and return the devstateid. In case >>> the client holds a valid devstateid it MUST use it for subsequent >>> GETDEVICEINFO and GETDEVICELIST that update the device ID >>> mappings. The devstateid argument is invalid whenever the >>> client has no valid devstateid (e.g. after reboot or after >>> the devstateid was previously returned via DELEGRETURN). >>> GETDEVICEINFO or GETDEVICELIST that operate on a device stateid >>> that was already recalled via CB_RECALL MUST be rejected by the >>> server with NFS4ERR_BADSTATEID. >>> >>> GETDEVICEINFO and GETDEVICELIST also take a boolean flag >>> optionally asking for device notifications and return a >>> corresponding flag confirming the notification. >>> >>> Device stateids follow the sequencing and use rules of all other >>> stateid types. The mappings are invalidated when the devstateid is >>> returned via CB_DELEGRETURN or explicitly deleted via CB_NOTIFY. >>> >>> All layouts using the device IDs remain in force, but the >>> server MUST fence the client from accessing the affected >>> devices until the client has obtained the re-mapped device >>> IDs via GETDEVICEINFO or GETDEVICELIST. >>> >>> CB_RECALL takes a devstateid to notify the client it needs >>> to return all device IDs identified by the devstateid. The >>> filehandle argument has no use in this case. It does not change >>> the device stateid. >>> >>> DELEGRETURN takes a devstateid to return all device IDs associated >>> with the devstateid. The current filehandle has no use in this case. >>> >>> If the server supports CB_NOTIFY for devices and the Client has >>> requested device id notifications via GETDEVICEINFO >>> or GETDEVICELIST; The server can inform the client >>> of a delete, add, or change mapping. >>> >>> CB_NOTIFY takes a device stateid qualifying a device ID >>> for the following device notifications: >>> >>> NOTIFY4_DELETE_DEVICE_ID >>> Deletes all mappings using the specified device ID. >>> The server MUST stop using the device ID. Any >>> layouts remain in force, but aren't useful until >>> new mappings are available. The server fences the >>> client from the affected data server until all >>> layouts with the device ID are returned, or the >>> client obtains new mappings. The server provides >>> a hint as to whether new mappings will arrive and >>> if so how long. >>> >>> NOTIFY4_ADD_DEVICE_ID >>> Adds a device ID to address mapping. This is >>> for a device ID the that was not returned in a >>> previous series GETDEVICELIST calls (where the >>> series ended in gdlr_eof =3D=3D TRUE). The client >>> calls GETDEVICEINFO or GETDEVICELIST to determine >>> the mappings for the new device ID. >>> >>> NOTIFY4_CHANGE_DEVICE_ID >>> The client call GETDEVICEINFO or GETDEVICELIST >>> to get updated device addresses for the device >>> ID. Layouts remain in force. The client is fenced >>> from any devices that were in the old address list, >>> but not the new address list. >>> >>> CB_NOTIFY does not change the device stateid. >>> >>> In addition to informing the client of mapping changes via >>> CB_NOTIFY and CB_RECALL, SEQUENCE carries status flags to >>> indicate that device mappings have changed. >>> >>> The flags are :- >>> >>> SEQ4_STATUS_DEVID_DELETED >>> Mapping has been partially deleted. If the client is >>> using CB_NOTIFY it may issue a GETDEVICEINFO for each >>> notified deletion or GETDEVICELIST to refresh the entire >>> map. This flag stays on until the client responds to >>> any and all _DELETE notifications, or it has issued a >>> GETDEVICELIST. >>> >>> SEQ4_STATUS_DEVID_DELETED_ALL >>> This flag stays on until the client issues a DELEGRETURN >>> using the devstateid. >>> >>> SEQ4_STATUS_DEVID_CHANGED >>> SEQ4_STATUS_DEVID_ADDED >>> These flags stay on until a GETDEVICELIST or GETDEVICEINFO >>> (if using CB_NOTIFY) gets the affected mappings. >>> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 29 16:49:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImbWW-0002B9-TF; Mon, 29 Oct 2007 16:47:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImbWV-00021v-1q for nfsv4@ietf.org; Mon, 29 Oct 2007 16:47:47 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImbWS-0006CW-Sk for nfsv4@ietf.org; Mon, 29 Oct 2007 16:47:46 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1508275rvb for ; Mon, 29 Oct 2007 13:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XWErEg+YoS92FJwP0jLbv2IIw37NJIgAyV0/8cE1rNs=; b=S36Q/aFjKLpsWYFL55fREYay4exi17VX4Z/D8TmzFEYXbeOLvYZZTPEZ9ieP/HUqrrHS2NxDpWgaKwyesW9PrJZK0Ko/9e00T0SaOKaemZvSRf8HITwumR62jiPmNr7Arg7vL12/Z40o4HSlsXI3hbluI8CHWOOW1dCoWCCQqEA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FCjPpMUUEQkBLjrMahKMmZZBaJ3aRakeNgD93Ix5SDMew/bLlnJ63mu3kOzF3xcebvY4U/l8zrlvrnYsAsbbKQfjfh/VdoZMShKevJfsdFLBhbQvUQMrBxjQAOzDuiLSQdWmK+ULiTzBHmxV8FiuzSiB9uCTDjSyHwAUDo8qAUQ= Received: by 10.114.57.1 with SMTP id f1mr7492670waa.1193690862233; Mon, 29 Oct 2007 13:47:42 -0700 (PDT) Received: by 10.114.102.6 with HTTP; Mon, 29 Oct 2007 13:47:42 -0700 (PDT) Message-ID: Date: Mon, 29 Oct 2007 13:47:42 -0700 From: "dean hildebrand" To: "Noveck, Dave" Subject: Re: [nfsv4] Device stateids In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47260003.8050400@panasas.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: Benny Halevy , Marc Eshel , NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On 10/29/07, Noveck, Dave wrote: > > I've been hearing a lot talk about getting together a spec by 11/19 > (final final deadline for next ietf) that would serve as the basis for a > group last-call, although I've been saying "how about 'group > penultimate-call'". As part of that, I'm trying to get to closure on > the op to error mapping and I didn't expect to see a proposal at this > point that would add 3 new ops, and a whole bunch of errors to two > existing ops. If this is really needed, then we'll do what we have to > do, but I'm not clear on the justification for something so different > from what had been previously agreed to. I'm probably behind the times, but what is the previous agreement? Leave draft 14 devices as is? The changes suggested in the other post included below Benny's? Dean > > Is this stuff really a requirement, or is this a case of preferring to > have bells and whistles, that we can do without? > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Monday, October 29, 2007 11:45 AM > To: Robert Gordon; Marc Eshel > Cc: NFSv4 > Subject: Re: [nfsv4] Device stateids > > > During the most recent bakeathon concern has been raised > about the global device ID namespace and Marc Eshel from > IBM requested that we retain the ability to recall > devices per-fsid. To satisfy this requirement as well > as the requirement for a simple global device ID namespace > the updated proposal below introduces a device-set identifier > (devsetid) that qualifies the device ID. > > This provides for a more flexible deviceid namespace topology that > can cover either a global deviceid namespace, per-fsid namespace, or > anything in between (e.g. when several filesystems reside on (and are > confined to) a set of devices, like in EMC or Panasas' cases). > > The proposal also introduces new operations to manage device mapping > state rather than unnecessarily overloading existing operations. > > Plus, I simplified the proposal by not requiring any new sequence flags > as the server should use the proposed callback operation to recall > device mappings and use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED and > SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the same it > may use them for other recallable state objects (locks and layouts). > > One last change is providing for a "wildcard" value (0) for device ID > that specifies all the device IDs in a devset. This means that > the server MUST NOT return a zero device ID in GETDEVICELIST > or in any layout and it must reject it as invalid in GETDEVICEINFO. > I guess that this won't be an issue for anyone; otherwise, please > holler. > > Benny > > -- > 1. Introduction > > The NFS client maintains a mapping of device IDs contained > in a layout to the corresponding storage device address. > Device IDs and filesystem IDs are associated with device set > IDs such that each fsid is associated with a single devsetid > as indicated by a new, recommended filesystem attribute, and > each deviceid is associated with a single devsetid. > > The state of the mapping is represented by a recallable device > stateid (devstateid). There is at most one devstateid per > { client ID, layout type, devsetid } nexus. > > A recommended filesystem attribute - devsetid is introduced. > All deviceids associated with any file in the filesystem are > associated with this devsetid. > If the server does not support device sets, it can omit this attribute, > making the deviceid namespace global and implicitly associating all > deviceids with the default devset (having the implicit devsetid > ID of 0) > > 2. Getting device information > > GETDEVICEINFO > SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, > notify_ask -> > devstateid, notify_ack, device_addr > > GETDEVICELIST > SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, > cookieverf, notify_ask -> > devstateid, notify_ack, cookie, cookieverf, device info list<> > > GETDEVICEINFO and GETDEVICELIST each take the a devstateid, > a devsetid, and the layout type, and return a non-zero devstateid. > In case the client holds a valid devstateid it MUST use it for > subsequent GETDEVICEINFO and GETDEVICELIST that update the device ID > mappings. The devstateid argument must be set to zero whenever the > client has no valid devstateid (e.g. after reboot or after > the devstateid was previously returned via DEVICERETURN). > > GETDEVICEINFO and GETDEVICELIST also take a boolean flag > optionally asking for device notifications and return a > corresponding flag confirming the notification. > > 3. Returning device IDs > > DEVICERETURN > SYNOPSIS: devstateid, devsetid, deviceid -> devstateid > > DEVICERETURN returns a device ID mapping. When called, this > client MUST guarantee not to make further use of that device ID mapping. > If the deviceid argument is set to zero, all device ID mappings > in the referred devset are returned. The server updates the devstateid > and returns the updated value. > > 4. Sequencing rules > > Device stateids follow the sequencing and use rules of all other > stateid types. The devstateid is invalidated when all devices > associated with it are returned via DEVICERETURN. The client can > then "forget" about that devstateid and use a value of zero for > the devstateid for any subsequent operation that takes a devstateid > argument and allows the uninitialized value. > > 5. Recalling device IDs > > CB_DEVICERECALL > SYNOPSIS: devstateid, devsetid, deviceid, deleted -> > > CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify > the client it needs to return the specified deviceid (when non-zero) or > all device > IDs in the devsetid when the deviceid is set to zero, by using a > respective > DEVICERETURN. CB_DEVICERECALL does not change the device stateid. > > All layouts using the affected device IDs remain in force, but the > server SHOULD fence the client from accessing the affected > devices until the client has returned the recalled device IDs. > > When the "deleted" boolean flag is set to false the client MAY use > GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if it > has valid layouts the refer to the changed deviceid. If the "deleted" > flag > is set to true the specified deviceid will not be reused by the server > and > all outstanding layouts referring to it are expected to be recalled via > CB_LAYOUTRECALL; hence the client SHOULD NOT attempt to call > GETDEVICEINFO or > GETDEVICELIST for the specified deviceid. However, if it does do so the > server > MUST return a NFS4ERR_INVAL error. > > 6. Device notification > > CB_DEVICENOTIFY > SYNOPSIS: devstateid, devsetid, deviceid -> > > If the server supports CB_DEVICENOTIFY for devices and the client has > requested device id notifications via GETDEVICEINFO or GETDEVICELIST > the server can inform the client of additional deviceids that were > not previously returned by GETDEVICELIST. > > The purpose of this operation is to reduce the latency for getting > new device mappings. Rather than waiting until the client accesses > a file that uses the new device ID, issue a LAYOUTGET, and then a > GETDEVICEINFO on the new device, the server can notify the client > of any new device ID in advance and have the client get the device > address mapping by calling GETDEVICEINFO at its convenience. > > CB_DEVICENOTIFY takes a device stateid, a device set ID > and a device ID in the device set for a device ID that was not > returned in a previous series GETDEVICELIST calls (where the > series ended in gdlr_eof == TRUE). The client calls GETDEVICEINFO > or GETDEVICELIST to determine the mappings for the new device ID. > CB_DEVICENOTIFY does not change the device stateid. > > If the client has already issued a GETDEVICEINFO for the specified > deviceid > then it SHOULD just ignore the device id notification. > Updating an existing device ID mapping should be done using a sequence > of > CB_DEVICERECALL, DEVICERETURN, and GETDEVICEINFO (or GETDEVICELIST). > > 7. SEQUENCE flags > > In addition to informing the client of mapping changes via > CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use > the SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag > to indicate that one or more device IDs have been > revoked without expiration of the lease period, due to the > client's failure to return them when recalled. This status bit > remains set on all SEQUENCE replies until the loss of all such > device ID mappings has been acknowledged by use of DEVICERETURN. > > On Aug. 09, 2007, 10:22 +0300, Benny Halevy wrote: > > Robert Gordon wrote: > >> In general i think this is good. > >> > >> I've started to think that the SEQUENCE status flags could just be > >> two bits. > >> > >> SEQ4_STATUS_DEVID_DELETED_ALL > >> This flag stays on until the client issues a DELEGRETURN > >> using the devstateid. > >> > >> SEQ_STATUS_DEVID_CHANGED > >> This flag stay on until a GETDEVICELIST or GETDEVICEINFO > >> (if using CB_NOTIFY) gets the affected mappings. > > > > The DEVID_DELETED cases should be covered by CHANGED as the client > will > > have to revalidate all the device mappings anyway to see what actually > changed > > and should either not see the deleted deviceid returned by > GETDEVICELIST > > or get an error from GETDEVICEINFO for that deviceid. > > > > The DEVID_ADDED case is covered if the client is doing GETDEVICELIST > > and the server supports it. If the server does not support > GETDEVICELIST > > is must not set SEQ_STATUS_DEVID_CHANGED for added devices as the > client > > has no way to get the new device ID. These will be discovered only > > when the client will get new layouts referring to the new devices > > (which is perfectly fine) > > > >> Robert. > >> > >> On Aug 8, 2007, at 10:58 AM, Benny Halevy wrote: > >> > >>> The NFS client maintains a mapping of device ids contained > >>> in a layout, to the corresponding storage device address. > >>> The state of the mapping is represented by a single > >>> recallable device stateid (devstateid). There is at most > >>> one devstateid per { client ID, layout type } pair. > >>> > >>> GETDEVICEINFO and GETDEVICELIST each take the layout type and > >>> an optional devstateid and return the devstateid. In case > >>> the client holds a valid devstateid it MUST use it for subsequent > >>> GETDEVICEINFO and GETDEVICELIST that update the device ID > >>> mappings. The devstateid argument is invalid whenever the > >>> client has no valid devstateid (e.g. after reboot or after > >>> the devstateid was previously returned via DELEGRETURN). > >>> GETDEVICEINFO or GETDEVICELIST that operate on a device stateid > >>> that was already recalled via CB_RECALL MUST be rejected by the > >>> server with NFS4ERR_BADSTATEID. > >>> > >>> GETDEVICEINFO and GETDEVICELIST also take a boolean flag > >>> optionally asking for device notifications and return a > >>> corresponding flag confirming the notification. > >>> > >>> Device stateids follow the sequencing and use rules of all other > >>> stateid types. The mappings are invalidated when the devstateid is > >>> returned via CB_DELEGRETURN or explicitly deleted via CB_NOTIFY. > >>> > >>> All layouts using the device IDs remain in force, but the > >>> server MUST fence the client from accessing the affected > >>> devices until the client has obtained the re-mapped device > >>> IDs via GETDEVICEINFO or GETDEVICELIST. > >>> > >>> CB_RECALL takes a devstateid to notify the client it needs > >>> to return all device IDs identified by the devstateid. The > >>> filehandle argument has no use in this case. It does not change > >>> the device stateid. > >>> > >>> DELEGRETURN takes a devstateid to return all device IDs associated > >>> with the devstateid. The current filehandle has no use in this case. > >>> > >>> If the server supports CB_NOTIFY for devices and the Client has > >>> requested device id notifications via GETDEVICEINFO > >>> or GETDEVICELIST; The server can inform the client > >>> of a delete, add, or change mapping. > >>> > >>> CB_NOTIFY takes a device stateid qualifying a device ID > >>> for the following device notifications: > >>> > >>> NOTIFY4_DELETE_DEVICE_ID > >>> Deletes all mappings using the specified device ID. > >>> The server MUST stop using the device ID. Any > >>> layouts remain in force, but aren't useful until > >>> new mappings are available. The server fences the > >>> client from the affected data server until all > >>> layouts with the device ID are returned, or the > >>> client obtains new mappings. The server provides > >>> a hint as to whether new mappings will arrive and > >>> if so how long. > >>> > >>> NOTIFY4_ADD_DEVICE_ID > >>> Adds a device ID to address mapping. This is > >>> for a device ID the that was not returned in a > >>> previous series GETDEVICELIST calls (where the > >>> series ended in gdlr_eof == TRUE). The client > >>> calls GETDEVICEINFO or GETDEVICELIST to determine > >>> the mappings for the new device ID. > >>> > >>> NOTIFY4_CHANGE_DEVICE_ID > >>> The client call GETDEVICEINFO or GETDEVICELIST > >>> to get updated device addresses for the device > >>> ID. Layouts remain in force. The client is fenced > >>> from any devices that were in the old address list, > >>> but not the new address list. > >>> > >>> CB_NOTIFY does not change the device stateid. > >>> > >>> In addition to informing the client of mapping changes via > >>> CB_NOTIFY and CB_RECALL, SEQUENCE carries status flags to > >>> indicate that device mappings have changed. > >>> > >>> The flags are :- > >>> > >>> SEQ4_STATUS_DEVID_DELETED > >>> Mapping has been partially deleted. If the client is > >>> using CB_NOTIFY it may issue a GETDEVICEINFO for each > >>> notified deletion or GETDEVICELIST to refresh the entire > >>> map. This flag stays on until the client responds to > >>> any and all _DELETE notifications, or it has issued a > >>> GETDEVICELIST. > >>> > >>> SEQ4_STATUS_DEVID_DELETED_ALL > >>> This flag stays on until the client issues a DELEGRETURN > >>> using the devstateid. > >>> > >>> SEQ4_STATUS_DEVID_CHANGED > >>> SEQ4_STATUS_DEVID_ADDED > >>> These flags stay on until a GETDEVICELIST or GETDEVICEINFO > >>> (if using CB_NOTIFY) gets the affected mappings. > >>> > >> > >> _______________________________________________ > >> nfsv4 mailing list > >> nfsv4@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www1.ietf.org/mailman/listinfo/nfsv4 > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 29 17:29:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcAW-0005jZ-Lf; Mon, 29 Oct 2007 17:29:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcAU-0005i2-Sm for nfsv4@ietf.org; Mon, 29 Oct 2007 17:29:06 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImcAT-0000ih-9G for nfsv4@ietf.org; Mon, 29 Oct 2007 17:29:06 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9TLUDN3018914 for ; Mon, 29 Oct 2007 17:30:13 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9TLSddU138352 for ; Mon, 29 Oct 2007 17:28:39 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9TLSdth028266 for ; Mon, 29 Oct 2007 17:28:39 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9TLSdWF028255; Mon, 29 Oct 2007 17:28:39 -0400 MIME-Version: 1.0 In-Reply-To: To: "Noveck, Dave" Subject: RE: [nfsv4] Device stateids X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Marc Eshel Date: Mon, 29 Oct 2007 14:28:36 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 8.0|August 02, 2007) at 10/29/2007 17:28:39, Serialize complete at 10/29/2007 17:28:39 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: Benny Halevy , NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Yes, we all want to get to a final draft but it can not be an excuse to selectively choose changes. The last set of changes to getdevicelist and layoutget were a major changes that some how got in very late and in the last bakeathon I did not find one person that was happy with those changes, so I am not sure how the decision are made. I explicitly requested that the ability to recall devices per-fsid will be maintained, but some how it was dropped without general agreement. So I think we should consider this proposal or undo some changes that took away some functionality that we had in previous drafts. In general the approach on the Linux server side is to allow the different implementation as much flexibility as possible and this proposal helps us to do that. Marc. "Noveck, Dave" wrote on 10/29/2007 12:57:44 PM: > > I've been hearing a lot talk about getting together a spec by 11/19 > (final final deadline for next ietf) that would serve as the basis for a > group last-call, although I've been saying "how about 'group > penultimate-call'". As part of that, I'm trying to get to closure on > the op to error mapping and I didn't expect to see a proposal at this > point that would add 3 new ops, and a whole bunch of errors to two > existing ops. If this is really needed, then we'll do what we have to > do, but I'm not clear on the justification for something so different > from what had been previously agreed to. > > Is this stuff really a requirement, or is this a case of preferring to > have bells and whistles, that we can do without? > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Monday, October 29, 2007 11:45 AM > To: Robert Gordon; Marc Eshel > Cc: NFSv4 > Subject: Re: [nfsv4] Device stateids > > > During the most recent bakeathon concern has been raised > about the global device ID namespace and Marc Eshel from > IBM requested that we retain the ability to recall > devices per-fsid. To satisfy this requirement as well > as the requirement for a simple global device ID namespace > the updated proposal below introduces a device-set identifier > (devsetid) that qualifies the device ID. > > This provides for a more flexible deviceid namespace topology that > can cover either a global deviceid namespace, per-fsid namespace, or > anything in between (e.g. when several filesystems reside on (and are > confined to) a set of devices, like in EMC or Panasas' cases). > > The proposal also introduces new operations to manage device mapping > state rather than unnecessarily overloading existing operations. > > Plus, I simplified the proposal by not requiring any new sequence flags > as the server should use the proposed callback operation to recall > device mappings and use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED and > SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the same it > may use them for other recallable state objects (locks and layouts). > > One last change is providing for a "wildcard" value (0) for device ID > that specifies all the device IDs in a devset. This means that > the server MUST NOT return a zero device ID in GETDEVICELIST > or in any layout and it must reject it as invalid in GETDEVICEINFO. > I guess that this won't be an issue for anyone; otherwise, please > holler. > > Benny > > -- > 1. Introduction > > The NFS client maintains a mapping of device IDs contained > in a layout to the corresponding storage device address. > Device IDs and filesystem IDs are associated with device set > IDs such that each fsid is associated with a single devsetid > as indicated by a new, recommended filesystem attribute, and > each deviceid is associated with a single devsetid. > > The state of the mapping is represented by a recallable device > stateid (devstateid). There is at most one devstateid per > { client ID, layout type, devsetid } nexus. > > A recommended filesystem attribute - devsetid is introduced. > All deviceids associated with any file in the filesystem are > associated with this devsetid. > If the server does not support device sets, it can omit this attribute, > making the deviceid namespace global and implicitly associating all > deviceids with the default devset (having the implicit devsetid > ID of 0) > > 2. Getting device information > > GETDEVICEINFO > SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, > notify_ask -> > devstateid, notify_ack, device_addr > > GETDEVICELIST > SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, > cookieverf, notify_ask -> > devstateid, notify_ack, cookie, cookieverf, device info list<> > > GETDEVICEINFO and GETDEVICELIST each take the a devstateid, > a devsetid, and the layout type, and return a non-zero devstateid. > In case the client holds a valid devstateid it MUST use it for > subsequent GETDEVICEINFO and GETDEVICELIST that update the device ID > mappings. The devstateid argument must be set to zero whenever the > client has no valid devstateid (e.g. after reboot or after > the devstateid was previously returned via DEVICERETURN). > > GETDEVICEINFO and GETDEVICELIST also take a boolean flag > optionally asking for device notifications and return a > corresponding flag confirming the notification. > > 3. Returning device IDs > > DEVICERETURN > SYNOPSIS: devstateid, devsetid, deviceid -> devstateid > > DEVICERETURN returns a device ID mapping. When called, this > client MUST guarantee not to make further use of that device ID mapping. > If the deviceid argument is set to zero, all device ID mappings > in the referred devset are returned. The server updates the devstateid > and returns the updated value. > > 4. Sequencing rules > > Device stateids follow the sequencing and use rules of all other > stateid types. The devstateid is invalidated when all devices > associated with it are returned via DEVICERETURN. The client can > then "forget" about that devstateid and use a value of zero for > the devstateid for any subsequent operation that takes a devstateid > argument and allows the uninitialized value. > > 5. Recalling device IDs > > CB_DEVICERECALL > SYNOPSIS: devstateid, devsetid, deviceid, deleted -> > > CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify > the client it needs to return the specified deviceid (when non-zero) or > all device > IDs in the devsetid when the deviceid is set to zero, by using a > respective > DEVICERETURN. CB_DEVICERECALL does not change the device stateid. > > All layouts using the affected device IDs remain in force, but the > server SHOULD fence the client from accessing the affected > devices until the client has returned the recalled device IDs. > > When the "deleted" boolean flag is set to false the client MAY use > GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if it > has valid layouts the refer to the changed deviceid. If the "deleted" > flag > is set to true the specified deviceid will not be reused by the server > and > all outstanding layouts referring to it are expected to be recalled via > CB_LAYOUTRECALL; hence the client SHOULD NOT attempt to call > GETDEVICEINFO or > GETDEVICELIST for the specified deviceid. However, if it does do so the > server > MUST return a NFS4ERR_INVAL error. > > 6. Device notification > > CB_DEVICENOTIFY > SYNOPSIS: devstateid, devsetid, deviceid -> > > If the server supports CB_DEVICENOTIFY for devices and the client has > requested device id notifications via GETDEVICEINFO or GETDEVICELIST > the server can inform the client of additional deviceids that were > not previously returned by GETDEVICELIST. > > The purpose of this operation is to reduce the latency for getting > new device mappings. Rather than waiting until the client accesses > a file that uses the new device ID, issue a LAYOUTGET, and then a > GETDEVICEINFO on the new device, the server can notify the client > of any new device ID in advance and have the client get the device > address mapping by calling GETDEVICEINFO at its convenience. > > CB_DEVICENOTIFY takes a device stateid, a device set ID > and a device ID in the device set for a device ID that was not > returned in a previous series GETDEVICELIST calls (where the > series ended in gdlr_eof == TRUE). The client calls GETDEVICEINFO > or GETDEVICELIST to determine the mappings for the new device ID. > CB_DEVICENOTIFY does not change the device stateid. > > If the client has already issued a GETDEVICEINFO for the specified > deviceid > then it SHOULD just ignore the device id notification. > Updating an existing device ID mapping should be done using a sequence > of > CB_DEVICERECALL, DEVICERETURN, and GETDEVICEINFO (or GETDEVICELIST). > > 7. SEQUENCE flags > > In addition to informing the client of mapping changes via > CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use > the SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag > to indicate that one or more device IDs have been > revoked without expiration of the lease period, due to the > client's failure to return them when recalled. This status bit > remains set on all SEQUENCE replies until the loss of all such > device ID mappings has been acknowledged by use of DEVICERETURN. > > On Aug. 09, 2007, 10:22 +0300, Benny Halevy wrote: > > Robert Gordon wrote: > >> In general i think this is good. > >> > >> I've started to think that the SEQUENCE status flags could just be > >> two bits. > >> > >> SEQ4_STATUS_DEVID_DELETED_ALL > >> This flag stays on until the client issues a DELEGRETURN > >> using the devstateid. > >> > >> SEQ_STATUS_DEVID_CHANGED > >> This flag stay on until a GETDEVICELIST or GETDEVICEINFO > >> (if using CB_NOTIFY) gets the affected mappings. > > > > The DEVID_DELETED cases should be covered by CHANGED as the client > will > > have to revalidate all the device mappings anyway to see what actually > changed > > and should either not see the deleted deviceid returned by > GETDEVICELIST > > or get an error from GETDEVICEINFO for that deviceid. > > > > The DEVID_ADDED case is covered if the client is doing GETDEVICELIST > > and the server supports it. If the server does not support > GETDEVICELIST > > is must not set SEQ_STATUS_DEVID_CHANGED for added devices as the > client > > has no way to get the new device ID. These will be discovered only > > when the client will get new layouts referring to the new devices > > (which is perfectly fine) > > > >> Robert. > >> > >> On Aug 8, 2007, at 10:58 AM, Benny Halevy wrote: > >> > >>> The NFS client maintains a mapping of device ids contained > >>> in a layout, to the corresponding storage device address. > >>> The state of the mapping is represented by a single > >>> recallable device stateid (devstateid). There is at most > >>> one devstateid per { client ID, layout type } pair. > >>> > >>> GETDEVICEINFO and GETDEVICELIST each take the layout type and > >>> an optional devstateid and return the devstateid. In case > >>> the client holds a valid devstateid it MUST use it for subsequent > >>> GETDEVICEINFO and GETDEVICELIST that update the device ID > >>> mappings. The devstateid argument is invalid whenever the > >>> client has no valid devstateid (e.g. after reboot or after > >>> the devstateid was previously returned via DELEGRETURN). > >>> GETDEVICEINFO or GETDEVICELIST that operate on a device stateid > >>> that was already recalled via CB_RECALL MUST be rejected by the > >>> server with NFS4ERR_BADSTATEID. > >>> > >>> GETDEVICEINFO and GETDEVICELIST also take a boolean flag > >>> optionally asking for device notifications and return a > >>> corresponding flag confirming the notification. > >>> > >>> Device stateids follow the sequencing and use rules of all other > >>> stateid types. The mappings are invalidated when the devstateid is > >>> returned via CB_DELEGRETURN or explicitly deleted via CB_NOTIFY. > >>> > >>> All layouts using the device IDs remain in force, but the > >>> server MUST fence the client from accessing the affected > >>> devices until the client has obtained the re-mapped device > >>> IDs via GETDEVICEINFO or GETDEVICELIST. > >>> > >>> CB_RECALL takes a devstateid to notify the client it needs > >>> to return all device IDs identified by the devstateid. The > >>> filehandle argument has no use in this case. It does not change > >>> the device stateid. > >>> > >>> DELEGRETURN takes a devstateid to return all device IDs associated > >>> with the devstateid. The current filehandle has no use in this case. > >>> > >>> If the server supports CB_NOTIFY for devices and the Client has > >>> requested device id notifications via GETDEVICEINFO > >>> or GETDEVICELIST; The server can inform the client > >>> of a delete, add, or change mapping. > >>> > >>> CB_NOTIFY takes a device stateid qualifying a device ID > >>> for the following device notifications: > >>> > >>> NOTIFY4_DELETE_DEVICE_ID > >>> Deletes all mappings using the specified device ID. > >>> The server MUST stop using the device ID. Any > >>> layouts remain in force, but aren't useful until > >>> new mappings are available. The server fences the > >>> client from the affected data server until all > >>> layouts with the device ID are returned, or the > >>> client obtains new mappings. The server provides > >>> a hint as to whether new mappings will arrive and > >>> if so how long. > >>> > >>> NOTIFY4_ADD_DEVICE_ID > >>> Adds a device ID to address mapping. This is > >>> for a device ID the that was not returned in a > >>> previous series GETDEVICELIST calls (where the > >>> series ended in gdlr_eof == TRUE). The client > >>> calls GETDEVICEINFO or GETDEVICELIST to determine > >>> the mappings for the new device ID. > >>> > >>> NOTIFY4_CHANGE_DEVICE_ID > >>> The client call GETDEVICEINFO or GETDEVICELIST > >>> to get updated device addresses for the device > >>> ID. Layouts remain in force. The client is fenced > >>> from any devices that were in the old address list, > >>> but not the new address list. > >>> > >>> CB_NOTIFY does not change the device stateid. > >>> > >>> In addition to informing the client of mapping changes via > >>> CB_NOTIFY and CB_RECALL, SEQUENCE carries status flags to > >>> indicate that device mappings have changed. > >>> > >>> The flags are :- > >>> > >>> SEQ4_STATUS_DEVID_DELETED > >>> Mapping has been partially deleted. If the client is > >>> using CB_NOTIFY it may issue a GETDEVICEINFO for each > >>> notified deletion or GETDEVICELIST to refresh the entire > >>> map. This flag stays on until the client responds to > >>> any and all _DELETE notifications, or it has issued a > >>> GETDEVICELIST. > >>> > >>> SEQ4_STATUS_DEVID_DELETED_ALL > >>> This flag stays on until the client issues a DELEGRETURN > >>> using the devstateid. > >>> > >>> SEQ4_STATUS_DEVID_CHANGED > >>> SEQ4_STATUS_DEVID_ADDED > >>> These flags stay on until a GETDEVICELIST or GETDEVICEINFO > >>> (if using CB_NOTIFY) gets the affected mappings. > >>> > >> > >> _______________________________________________ > >> nfsv4 mailing list > >> nfsv4@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www1.ietf.org/mailman/listinfo/nfsv4 > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 29 18:04:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imcgt-0003SC-20; Mon, 29 Oct 2007 18:02:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imcgr-0003Rs-KI for nfsv4@ietf.org; Mon, 29 Oct 2007 18:02:33 -0400 Received: from web38111.mail.mud.yahoo.com ([209.191.124.138]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Imcgr-0002kb-6t for nfsv4@ietf.org; Mon, 29 Oct 2007 18:02:33 -0400 Received: (qmail 13918 invoked by uid 60001); 29 Oct 2007 21:55:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=C2vSG5808/Jv382pld+OOk+d+ydpSlK9m6BxK7VerjznnPjkciZEEB8jcD8by43mTnJIXoTMFKffyQyGpHPx7tPE3LRTF6zty8yJyRNCP2fK/n1dwsLY8K0f8BsxpMl/Ht5Heu1vj9dt1knue/1HazVGysoCkFt3EryAgcesaDQ=; X-YMail-OSG: qMVvtZ0VM1m_oG3XBc8ohdb5xu1sKxJ73EZX9sL.8xRvTfD9LvWfCUzdxyeULtOGd9Ho2c1PjA-- Received: from [198.95.226.230] by web38111.mail.mud.yahoo.com via HTTP; Mon, 29 Oct 2007 14:55:10 PDT Date: Mon, 29 Oct 2007 14:55:10 -0700 (PDT) From: Mike Eisler Subject: Re: [nfsv4] Question on stripe unit size in file layout To: Suchit Kaura , nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <401772.13562.qm@web38111.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Suchit Kaura wrote: > A couple of questions: > > Do we imagine then that different layouts can have different stripe > unit > sizes or is this explicitly forbidden for a metadata server to return > different stripe unit sizes for the same file? As currently specified, in the same filer, different layouts can have different stripe unit sizes. If a server uses different stripe unit sizes for different layouts on the file, and the layouts overlap, the consequences are unspecified. > In general if we are writing a client can we use file_offset - > layout->lo_offset instead of file_offset for dense layouts > calculation? I'm not understanding the question. The offset calculation for dense packing is: data_file_offset = floor(file_offset / stripe_width) * stripe_unit_size + file_offset % stripe_unit_size and file_offset comes from the argument to the client's programming interfsce (e.g. a vnode switch's _read or _write entry point, or what POSIX lseek() returns). _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Oct 29 20:56:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImfMt-0001EH-O7; Mon, 29 Oct 2007 20:54:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImfMs-0001CC-55 for nfsv4@ietf.org; Mon, 29 Oct 2007 20:54:06 -0400 Received: from p01c11o144.mxlogic.net ([208.65.144.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImfMr-00049p-KT for nfsv4@ietf.org; Mon, 29 Oct 2007 20:54:06 -0400 Received: from unknown [63.110.244.103] (EHLO p01c11o144.mxlogic.net) by p01c11o144.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id da086274.2658368432.8858.00-545.p01c11o144.mxlogic.net (envelope-from ); Mon, 29 Oct 2007 18:54:05 -0600 (MDT) Received: from unknown [63.110.244.103] by p01c11o144.mxlogic.net (mxl_mta-5.2.0-1) with SMTP id e9d56274.2271108016.119075.00-018.p01c11o144.mxlogic.net (envelope-from ); Mon, 29 Oct 2007 16:24:30 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Question on stripe unit size in file layout Date: Mon, 29 Oct 2007 15:24:27 -0700 Message-ID: In-Reply-To: <401772.13562.qm@web38111.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Question on stripe unit size in file layout Thread-Index: AcgadmLCOXm730F6TAmzB/HZidLf6wAAyBSA References: <401772.13562.qm@web38111.mail.mud.yahoo.com> From: "Suchit Kaura" To: , X-Spam: [F=0.0746917490; S=0.074(2007101601); SS=0.500] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I guess an example would help. Let's imagine a user file of length 7KB defined with the following 2 layouts 1st layout File Offset =3D 0, length =3D 3KB, stripe unit size =3D 1KB, stripe = width =3D 3KB=20 2nd layout=20 File Offset =3D 3KB length =3D 4KB stripe unit size =3D 2KB, stripe = width =3D 4KB Now if we consider the formula provided=20 data_file_offset =3D floor(file_offset / stripe_width) * stripe_unit_size + file_offset % stripe_unit_size It really would start giving us incorrect results based on which unit size and width we applied to it. It is probably better to have a formula that uses a relative offset from the start of the layout. For e.g. if we use the stripe width of 4KB and stripe unit size of 2KB for a file offset of 3KB the result would be a data file offset of 1KB. This seems incorrect.=20 Regards, Suchit -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Monday, October 29, 2007 2:55 PM To: Suchit Kaura; nfsv4@ietf.org Subject: Re: [nfsv4] Question on stripe unit size in file layout --- Suchit Kaura wrote: > A couple of questions: >=20 > Do we imagine then that different layouts can have different stripe=20 > unit sizes or is this explicitly forbidden for a metadata server to=20 > return different stripe unit sizes for the same file? As currently specified, in the same filer, different layouts can have different stripe unit sizes.=20 If a server uses different stripe unit sizes for different layouts on the file, and the layouts overlap, the consequences are unspecified. =20 > In general if we are writing a client can we use file_offset - > layout->lo_offset instead of file_offset for dense layouts > calculation? I'm not understanding the question. The offset calculation for dense packing is: data_file_offset =3D floor(file_offset / stripe_width) * stripe_unit_size + file_offset % stripe_unit_size and file_offset comes from the argument to the client's programming interfsce (e.g. a vnode switch's _read or _write entry point, or what POSIX lseek() returns). _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Somsanith@fitlives.co.uk Tue Oct 30 10:27:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ims4E-0002aq-Cq for nfsv4-archive@lists.ietf.org; Tue, 30 Oct 2007 10:27:42 -0400 Received: from catv-5063fb38.catv.broadband.hu ([80.99.251.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ims4B-0005FK-Of for nfsv4-archive@lists.ietf.org; Tue, 30 Oct 2007 10:27:40 -0400 Received: from barby-ac92bb790 ([167.144.10.176] helo=barby-ac92bb790) by catv-5063fb38.catv.broadband.hu ( sendmail 8.13.3/8.13.1) with esmtpa id 1ktBcO-000JHJ-SS for nfsv4-archive@lists.ietf.org; Tue, 30 Oct 2007 15:28:26 +0100 Message-ID: <000901c81b01$15956a50$38fb6350@barbyac92bb790> From: "settimo Somsanith" To: Subject: seniraf Date: Tue, 30 Oct 2007 15:28:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C81B09.7759D250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.6 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C81B09.7759D250 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello Society nfsv4-archive your a long way from really satisfyng her, your pee pee to tiny http://bchydeo.com/ settimo Somsanith ------=_NextPart_000_0006_01C81B09.7759D250 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Hello Society nfsv4-archive
your a long way from really satisfyng her, = your pee pee=20 to tiny
http://bchydeo.com/
settimo Somsanith
------=_NextPart_000_0006_01C81B09.7759D250-- From hundtpeggy70@btillc.org Tue Oct 30 16:00:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxFr-0003B3-OO for nfsv4-archive@lists.ietf.org; Tue, 30 Oct 2007 16:00:03 -0400 Received: from cpc1-leic4-0-0-cust305.lei3.cable.ntl.com ([86.5.201.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImxFo-0000J5-OQ for nfsv4-archive@lists.ietf.org; Tue, 30 Oct 2007 16:00:01 -0400 Received: from [86.5.201.50] by ctekuha.btillc.org; Tue, 30 Oct 2007 19:59:45 +0000 Message-ID: <000501c81b2f$0179ec16$8235249b@gvpdsyt> From: "jedd amril" To: "Lydia Warner" Subject: Cocktail party wearing a beautiful watch Date: Tue, 30 Oct 2007 18:12:23 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C81B2F.0177F715" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C81B2F.0177F715 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life Should be Full of Luxuries, yet, only a handful of people can = afford the finest products, the luxuries of the elite. We are committed to bringing you the finest products, at prices = incomparably lower. Perfectly crafted luxury timepieces, all at = affordable prices. Thousands of different models to choose from! http://my07fg.net/ ------=_NextPart_000_0002_01C81B2F.0177F715 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life Should be Full of Luxuries, yet, only a handful of people can = afford the finest products,=20 the luxuries of the elite.
We are committed to bringing you the = finest products, at prices=20 incomparably lower. Perfectly crafted luxury timepieces, all at = affordable prices. Thousands=20 of different models to choose from!

http://my07fg.net/ ------=_NextPart_000_0002_01C81B2F.0177F715-- From StaceycrewmanRojas@oyez.org Tue Oct 30 17:28:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImydH-00059d-Lg; Tue, 30 Oct 2007 17:28:19 -0400 Received: from 204.red-81-44-32.dynamicip.rima-tde.net ([81.44.32.204] helo=family.local.lan) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ImydA-0003UE-TG; Tue, 30 Oct 2007 17:28:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host54274781.oyez.org (8.13.1/8.13.1) with SMTP id nPCPSTqg97.551993.XUW.bQj.0286624803133 for ; Tue, 30 Oct 2007 22:27:47 -0100 Message-ID: <14fff01c81b3b$c6f95ab0$3201a8c0@family> From: "Stacey English" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_14FFB_01C81B3B.C6F95AB0-- From PrincemusculatureTyson@askmen.com Tue Oct 30 19:53:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0th-0007kt-3w; Tue, 30 Oct 2007 19:53:25 -0400 Received: from pool-72-79-177-212.sctnpa.east.verizon.net ([72.79.177.212] helo=elizabet6jtwk8.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1In0tg-00006h-Op; Tue, 30 Oct 2007 19:53:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host47526184.askmen.com (8.13.1/8.13.1) with SMTP id 1EmwDo4w45.050009.8CC.W7b.1086700188778 for ; Tue, 30 Oct 2007 19:53:25 +0800 Message-ID: <53fea01c81b69$43f86f10$2f01a8c0@elizabet6jtwk8> From: "Porfirio Pate" To: Subject: Your order Date: Tue, 30 Oct 2007 19:53:25 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_53FE6_01C81B69.43F86F10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_53FE6_01C81B69.43F86F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_53FE6_01C81B69.43F86F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_53FE6_01C81B69.43F86F10-- From nfsv4-bounces@ietf.org Tue Oct 30 20:26:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1OK-0007l3-KW; Tue, 30 Oct 2007 20:25:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1OJ-0007kl-2h for nfsv4@ietf.org; Tue, 30 Oct 2007 20:25:03 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1OG-0001B7-Le for nfsv4@ietf.org; Tue, 30 Oct 2007 20:25:02 -0400 X-IronPort-AV: E=Sophos;i="4.21,349,1188802800"; d="scan'208";a="118197173" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Oct 2007 17:24:43 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9V0OgsU015533; Tue, 30 Oct 2007 17:24:42 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 17:24:42 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 17:24:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Device stateids Date: Tue, 30 Oct 2007 20:24:39 -0400 Message-ID: In-Reply-To: <47260003.8050400@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Device stateids Thread-Index: AcgaRGaqw2ZVagnCR0OblKBOuxFYvABBbsVA From: "Noveck, Dave" To: "Benny Halevy" , "Robert Gordon" , "Marc Eshel" X-OriginalArrivalTime: 31 Oct 2007 00:24:41.0683 (UTC) FILETIME=[6E012230:01C81B54] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > Plus, I simplified the proposal by not requiring any new sequence > flags as the server should use the proposed callback operation to > recall device mappings and use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED=20 > and SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the=20 > same it may use them for other recallable state objects (locks and=20 > layouts). As far as I can see you don't you them the same and that is an issue.=20 > The state of the mapping is represented by a recallable device=20 > stateid (devstateid). There is at most one devstateid per { client ID, > layout type, devsetid } nexus. > A recommended filesystem attribute - devsetid is introduced. Notice that this arrangement means that fsid A and fsid B share a=20 devsetid or layout type X iff they share it for layout type Y. It seems that layout type is the one that should have the flexibility to figure out how it arranges its devices. I think a better model is to divide device id into major and minor fields and then all devices sharing a major device value become a device set. I think this would give you a lot more flexibility. > DEVICERETURN returns a device ID mapping. When called, this client=20 > MUST guarantee not to make further use of that device ID mapping. Do you really mean that? Isn't this like a CLOSE if which if you used=20 the stateid for the open file, you would get an error. Do you really mean that he server can depend on you not using this? > If the deviceid argument is set to zero, all device ID mappings in the > referred devset are returned. The server updates the devstateid and=20 > returns the updated value. If the deviceid were zero, the returned value of devstateid would be zero. Correct? > GETDEVICEINFO > SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, notify_ask -> > devstateid, notify_ack, device_addr > GETDEVICELIST > SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, cookieverf, notify_ask ->> > devstateid, notify_ack, cookie, cookieverf, device info list<> > GETDEVICEINFO and GETDEVICELIST each take the a devstateid, a devsetid,=20 > and the layout type, and return a non-zero devstateid. This looks inconsistent to me. If I do a GETDEVICEINFO(a), I get a non-zero stateid. If I then do a DEVICERETURN(a), I get a zero stateid. OK, now I start with a zero stateid again and do a GETDEVICELIST and get a non-zero stateid. If I do a GETDEVICELIST, I get another non-zero stateid. If I then do a DEVICERETURN(a), I get ... a non-zero stateid because the GETDEVICELIST has some effect. Is that true. It seems the DEVICERETURN is the inverse GETDEVICEINFO but that=20 GETDEVICELIST has no inverse. At the very least we need more clarity about this stuff. > GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally=20 > asking for device notifications and return a corresponding flag=20 > confirming the notification. Isn't this new function? Is it really needed? >Device stateids follow the sequencing and use rules of all other stateid=20 >types.=20 I assume that that means I use the normal "other" value with a seqid of zero as a wildcard. =20 > The devstateid is invalidated when all devices associated with=20 >it are returned via DEVICERETURN. The client can then "forget" about that=20 > devstateid and use a value of zero for the devstateid for any subsequent=20 > operation that takes a devstateid argument and allows the uninitialized=20 > value. I suppose but the server can return that devstateid as zero. Then the=20 client can either remember that zero and use it in which case he is using=20 the correct thing or he can specially note it is zero and this allows him to forget it (but then he has to specially note that he has forgotten it and should use zero in its stead). Seems like the code would be simpler if it just remembered the last thing it got back (if the client did parallel once it would have to compare state seqids and treat zero specially as later than all normal ones. > 5. Recalling device IDs > CB_DEVICERECALL > SYNOPSIS: devstateid, devsetid, deviceid, deleted -> >=20 > CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify > the client it needs to return the specified deviceid (when non-zero) or=20 > all device IDs in the devsetid when the deviceid is set to zero, by=20 > using a respective DEVICERETURN. CB_DEVICERECALL does not change the=20 > device stateid. A couple things are unclear. It says it needs to return the specified device id, but is that true when 'deleted' is false? Also, what happens when the device id is zero and 'deleted' is false. What is supposed to happen? > All layouts using the affected device IDs remain in force, but the=20 > server SHOULD fence the client from accessing the affected devices=20 > until the client has returned the recalled device IDs. And after it has returned it? Should the server not fence the client form a device it has returned. > When the "deleted" boolean flag is set to false the client MAY use=20 > GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if=20 > it has valid layouts the refer to the changed deviceid. =20 After or instead of doing the return? > If the "deleted" flag is set to true the specified deviceid will not be > reused by the server and all outstanding layouts referring to it are=20 > expected to be recalled via CB_LAYOUTRECALL; hence the client SHOULD=20 > NOT attempt to call GETDEVICEINFO or GETDEVICELIST for the specified=20 > deviceid. However, if it does do so the server MUST return a NFS4ERR_INVAL=20 > error. > 6. Device notification > CB_DEVICENOTIFY > SYNOPSIS: devstateid, devsetid, deviceid -> > If the server supports CB_DEVICENOTIFY for devices and the client has=20 > requested device id notifications via GETDEVICEINFO or GETDEVICELIST=20 > the server can inform the client of additional deviceids that were=20 > not previously returned by GETDEVICELIST. Again, what is the need here? The client will see the device id's when he gets a layout. > 7. SEQUENCE flags > In addition to informing the client of mapping changes via=20 > CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use the=20 > SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag to indicate=20 > that one or more device IDs have been revoked without expiration=20 > of the lease period, due to the client's failure to return them=20 > when recalled.=20 First of all, in the case of CB_DEVICENOTIFY, nothing has been=20 recalled or is supposed to be returned, as far as I can see. Then it speaks of devices being "revoked". Devices do not have stateids and are not, in that sense, locking objects. If the=20 current protocol, when a stateid has multiple locks (.e.g. byte-range locks), it is carefully stateid that when one is revoked, all are as a unit and that is tied to the associated stateid being made invalid. When SEQ4_STATUS_RECALLABLE_STATE_REVOKED is set in the current=20 protocol, the client is supposed to use TEST_STATEID to determine what state has been lost and acknowledge that loss using FREE_STATEID. I think it would be much better if revocation continued to follow that model. If a devstateid is revoked, then, at least for that, you start from scratch.=20 > This status bit remains set on all SEQUENCE replies until the=20 > loss of all such device ID mappings has been acknowledged by use=20 > of DEVICERETURN. I think it should stay until all revoked stateids are freed via FREE_STATEID, just as it is today. -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Monday, October 29, 2007 11:45 AM To: Robert Gordon; Marc Eshel Cc: NFSv4 Subject: Re: [nfsv4] Device stateids During the most recent bakeathon concern has been raised about the global device ID namespace and Marc Eshel from IBM requested that we retain the ability to recall devices per-fsid. To satisfy this requirement as well as the requirement for a simple global device ID namespace the updated proposal below introduces a device-set identifier (devsetid) that qualifies the device ID. This provides for a more flexible deviceid namespace topology that can cover either a global deviceid namespace, per-fsid namespace, or anything in between (e.g. when several filesystems reside on (and are confined to) a set of devices, like in EMC or Panasas' cases). The proposal also introduces new operations to manage device mapping state rather than unnecessarily overloading existing operations. Plus, I simplified the proposal by not requiring any new sequence flags as the server should use the proposed callback operation to recall device mappings and use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED and SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the same it may use them for other recallable state objects (locks and layouts). One last change is providing for a "wildcard" value (0) for device ID that specifies all the device IDs in a devset. This means that the server MUST NOT return a zero device ID in GETDEVICELIST or in any layout and it must reject it as invalid in GETDEVICEINFO.GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally asking for device notifications and return a corresponding flag confirming the notification. I guess that this won't be an issue for anyone; otherwise, please holler. Benny -- 1. Introduction The NFS client maintains a mapping of device IDs contained in a layout to the corresponding storage device address. Device IDs and filesystem IDs are associated with device set IDs such that each fsid is associated with a single devsetid as indicated by a new, recommended filesystem attribute, and each deviceid is associated with a single devsetid. The state of the mapping is represented by a recallable device stateid (devstateid). There is at most one devstateid per { client ID, layout type, devsetid } nexus. A recommended filesystem attribute - devsetid is introduced. All deviceids associated with any file in the filesystem are associated with this devsetid.=20 If the server does not support device sets, it can omit this attribute, making the deviceid namespace global and implicitly associating all deviceids with the default devset (having the implicit devsetid ID of 0) 2. Getting device information GETDEVICEINFO SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, notify_ask -> devstateid, notify_ack, device_addr GETDEVICELIST SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, cookieverf, notify_ask -> devstateid, notify_ack, cookie, cookieverf, device info list<> GETDEVICEINFO and GETDEVICELIST each take the a devstateid, a devsetid, and the layout type, and return a non-zero devstateid. In case the client holds a valid devstateid it MUST use it for subsequent GETDEVICEINFO and GETDEVICELIST that update the device ID mappings. The devstateid argument must be set to zero whenever the client has no valid devstateid (e.g. after reboot or after the devstateid was previously returned via DEVICERETURN). GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally asking for device notifications and return a corresponding flag confirming the notification. 3. Returning device IDs DEVICERETURN SYNOPSIS: devstateid, devsetid, deviceid -> devstateid DEVICERETURN returns a device ID mapping. When called, this client MUST guarantee not to make further use of that device ID mapping. If the deviceid argument is set to zero, all device ID mappings in the referred devset are returned. The server updates the devstateid and returns the updated value. 4. Sequencing rules Device stateids follow the sequencing and use rules of all other stateid types. The devstateid is invalidated when all devices associated with it are returned via DEVICERETURN. The client can then "forget" about that devstateid and use a value of zero for the devstateid for any subsequent operation that takes a devstateid argument and allows the uninitialized value. 5. Recalling device IDs CB_DEVICERECALL SYNOPSIS: devstateid, devsetid, deviceid, deleted -> CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify the client it needs to return the specified deviceid (when non-zero) or all device IDs in the devsetid when the deviceid is set to zero, by using a respective DEVICERETURN. CB_DEVICERECALL does not change the device stateid. All layouts using the affected device IDs remain in force, but the server SHOULD fence the client from accessing the affected devices until the client has returned the recalled device IDs. When the "deleted" boolean flag is set to false the client MAY use GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if it has valid layouts the refer to the changed deviceid. If the "deleted" flag is set to true the specified deviceid will not be reused by the server and all outstanding layouts referring to it are expected to be recalled via CB_LAYOUTRECALL; hence the client SHOULD NOT attempt to call GETDEVICEINFO or GETDEVICELIST for the specified deviceid. However, if it does do so the server MUST return a NFS4ERR_INVAL error. 6. Device notification CB_DEVICENOTIFY SYNOPSIS: devstateid, devsetid, deviceid -> If the server supports CB_DEVICENOTIFY for devices and the client has requested device id notifications via GETDEVICEINFO or GETDEVICELIST the server can inform the client of additional deviceids that were not previously returned by GETDEVICELIST. The purpose of this operation is to reduce the latency for getting new device mappings. Rather than waiting until the client accesses a file that uses the new device ID, issue a LAYOUTGET, and then a GETDEVICEINFO on the new device, the server can notify the client of any new device ID in advance and have the client get the device address mapping by calling GETDEVICEINFO at its convenience. CB_DEVICENOTIFY takes a device stateid, a device set ID and a device ID in the device set for a device ID that was not returned in a previous series GETDEVICELIST calls (where the series ended in gdlr_eof =3D=3D = TRUE). The client calls GETDEVICEINFO or GETDEVICELIST to determine the mappings for the new device ID. CB_DEVICENOTIFY does not change the device stateid. If the client has already issued a GETDEVICEINFO for the specified deviceid then it SHOULD just ignore the device id notification. Updating an existing device ID mapping should be done using a sequence of CB_DEVICERECALL, DEVICERETURN, and GETDEVICEINFO (or GETDEVICELIST). 7. SEQUENCE flags In addition to informing the client of mapping changes via CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag to indicate that one or more device IDs have been revoked without expiration of the lease period, due to the client's failure to return them when recalled. This status bit remains set on all SEQUENCE replies until the loss of all such device ID mappings has been acknowledged by use of DEVICERETURN. On Aug. 09, 2007, 10:22 +0300, Benny Halevy wrote: > Robert Gordon wrote: >> In general i think this is good. >> >> I've started to think that the SEQUENCE status flags could just be=20 >> two bits. >> >> SEQ4_STATUS_DEVID_DELETED_ALL >> This flag stays on until the client issues a DELEGRETURN >> using the devstateid. >> >> SEQ_STATUS_DEVID_CHANGED >> This flag stay on until a GETDEVICELIST or GETDEVICEINFO >> (if using CB_NOTIFY) gets the affected mappings. >=20 > The DEVID_DELETED cases should be covered by CHANGED as the client=20 > will have to revalidate all the device mappings anyway to see what=20 > actually changed and should either not see the deleted deviceid=20 > returned by GETDEVICELIST or get an error from GETDEVICEINFO for that deviceid. >=20 > The DEVID_ADDED case is covered if the client is doing GETDEVICELIST=20 > and the server supports it. If the server does not support=20 > GETDEVICELIST is must not set SEQ_STATUS_DEVID_CHANGED for added=20 > devices as the client has no way to get the new device ID. These will > be discovered only when the client will get new layouts referring to=20 > the new devices (which is perfectly fine) >=20 >> Robert. >> >> On Aug 8, 2007, at 10:58 AM, Benny Halevy wrote: >> >>> The NFS client maintains a mapping of device ids contained in a=20 >>> layout, to the corresponding storage device address. >>> The state of the mapping is represented by a single recallable=20 >>> device stateid (devstateid). There is at most one devstateid per {=20 >>> client ID, layout type } pair. >>> >>> GETDEVICEINFO and GETDEVICELIST each take the layout type and an=20 >>> optional devstateid and return the devstateid. In case the client=20 >>> holds a valid devstateid it MUST use it for subsequent GETDEVICEINFO >>> and GETDEVICELIST that update the device ID mappings. The=20 >>> devstateid argument is invalid whenever the client has no valid=20 >>> devstateid (e.g. after reboot or after the devstateid was previously >>> returned via DELEGRETURN). >>> GETDEVICEINFO or GETDEVICELIST that operate on a device stateid that >>> was already recalled via CB_RECALL MUST be rejected by the server=20 >>> with NFS4ERR_BADSTATEID. >>> >>> GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally=20 >>> asking for device notifications and return a corresponding flag=20 >>> confirming the notification. >>> >>> Device stateids follow the sequencing and use rules of all other=20 >>> stateid types. The mappings are invalidated when the devstateid is=20 >>> returned via CB_DELEGRETURN or explicitly deleted via CB_NOTIFY. >>> >>> All layouts using the device IDs remain in force, but the server=20 >>> MUST fence the client from accessing the affected devices until the=20 >>> client has obtained the re-mapped device IDs via GETDEVICEINFO or=20 >>> GETDEVICELIST. >>> >>> CB_RECALL takes a devstateid to notify the client it needs to return >>> all device IDs identified by the devstateid. The filehandle=20 >>> argument has no use in this case. It does not change the device=20 >>> stateid. >>> >>> DELEGRETURN takes a devstateid to return all device IDs associated=20 >>> with the devstateid. The current filehandle has no use in this case. >>> >>> If the server supports CB_NOTIFY for devices and the Client has=20 >>> requested device id notifications via GETDEVICEINFO or=20 >>> GETDEVICELIST; The server can inform the client of a delete, add, or >>> change mapping. >>> >>> CB_NOTIFY takes a device stateid qualifying a device ID for the=20 >>> following device notifications: >>> >>> NOTIFY4_DELETE_DEVICE_ID >>> Deletes all mappings using the specified device ID. >>> The server MUST stop using the device ID. Any >>> layouts remain in force, but aren't useful until >>> new mappings are available. The server fences the >>> client from the affected data server until all >>> layouts with the device ID are returned, or the >>> client obtains new mappings. The server provides >>> a hint as to whether new mappings will arrive and >>> if so how long. >>> >>> NOTIFY4_ADD_DEVICE_ID >>> Adds a device ID to address mapping. This is >>> for a device ID the that was not returned in a >>> previous series GETDEVICELIST calls (where the >>> series ended in gdlr_eof =3D=3D TRUE). The client >>> calls GETDEVICEINFO or GETDEVICELIST to determine >>> the mappings for the new device ID. >>> >>> NOTIFY4_CHANGE_DEVICE_ID >>> The client call GETDEVICEINFO or GETDEVICELIST >>> to get updated device addresses for the device >>> ID. Layouts remain in force. The client is fenced >>> from any devices that were in the old address list, >>> but not the new address list. >>> >>> CB_NOTIFY does not change the device stateid. >>> >>> In addition to informing the client of mapping changes via CB_NOTIFY >>> and CB_RECALL, SEQUENCE carries status flags to indicate that device >>> mappings have changed. >>> >>> The flags are :- >>> >>> SEQ4_STATUS_DEVID_DELETED >>> Mapping has been partially deleted. If the client is >>> using CB_NOTIFY it may issue a GETDEVICEINFO for each >>> notified deletion or GETDEVICELIST to refresh the entire >>> map. This flag stays on until the client responds to >>> any and all _DELETE notifications, or it has issued a >>> GETDEVICELIST. >>> >>> SEQ4_STATUS_DEVID_DELETED_ALL >>> This flag stays on until the client issues a DELEGRETURN >>> using the devstateid. >>> >>> SEQ4_STATUS_DEVID_CHANGED >>> SEQ4_STATUS_DEVID_ADDED >>> These flags stay on until a GETDEVICELIST or GETDEVICEINFO >>> (if using CB_NOTIFY) gets the affected mappings. >>> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 31 05:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9lr-0000a1-8u; Wed, 31 Oct 2007 05:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9lp-0000YK-E8 for nfsv4@ietf.org; Wed, 31 Oct 2007 05:21:53 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In9lo-00023j-Ah for nfsv4@ietf.org; Wed, 31 Oct 2007 05:21:53 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 4CF0732925; Wed, 31 Oct 2007 09:21:22 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1In9lK-0003Mb-7F; Wed, 31 Oct 2007 05:21:22 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: spencer.shepler@sun.com From: IETF I-D Submission Tool Message-Id: Date: Wed, 31 Oct 2007 05:21:22 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dnoveck@netapp.com, email2mre-@yahoo.com, nfsv4@ietf.org Subject: [nfsv4] New Version Notification for draft-ietf-nfsv4-minorversion1-15 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org A new version of I-D, draft-ietf-nfsv4-minorversion1-15.txt has been successfuly submitted by Spencer Shepler and posted to the IETF repository. Filename: draft-ietf-nfsv4-minorversion1 Revision: 15 Title: NFSv4 Minor Version 1 Creation_date: 2007-10-31 WG ID: nfsv4 Number_of_pages: 514 Abstract: This Internet-Draft describes NFSv4 minor version one, including features retained from the base protocol and protocol extensions made subsequently. The current draft includes description of the major extensions, Sessions, Directory Delegations, and parallel NFS (pNFS). This Internet-Draft is an active work item of the NFSv4 working group. Active and resolved issues may be found in the issue tracker at: http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4. New issues related to this document should be raised with the NFSv4 Working Group nfsv4@ietf.org. The IETF Secretariat. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 31 05:30:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9uH-000245-O0; Wed, 31 Oct 2007 05:30:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9uD-0001lR-EJ; Wed, 31 Oct 2007 05:30:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In9uD-00030v-1Q; Wed, 31 Oct 2007 05:30:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B153F2ACEA; Wed, 31 Oct 2007 09:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1In9ti-0000eS-6l; Wed, 31 Oct 2007 05:30:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 31 Oct 2007 05:30:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nfsv4@ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-minorversion1-15.txt X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : NFSv4 Minor Version 1 Author(s) : S. Shepler, et al. Filename : draft-ietf-nfsv4-minorversion1-15.txt Pages : 514 Date : 2007-10-31 This Internet-Draft describes NFSv4 minor version one, including features retained from the base protocol and protocol extensions made subsequently. The current draft includes description of the major extensions, Sessions, Directory Delegations, and parallel NFS (pNFS). This Internet-Draft is an active work item of the NFSv4 working group. Active and resolved issues may be found in the issue tracker at: http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4. New issues related to this document should be raised with the NFSv4 Working Group nfsv4@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-minorversion1-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-31052117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-minorversion1-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-31052117.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --NextPart-- From nfsv4-bounces@ietf.org Wed Oct 31 05:32:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9vi-0006Ks-BW; Wed, 31 Oct 2007 05:32:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9vh-0006Kd-CC for nfsv4@ietf.org; Wed, 31 Oct 2007 05:32:05 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In9vh-00037z-1a for nfsv4@ietf.org; Wed, 31 Oct 2007 05:32:05 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9V9W4Uu012645 for ; Wed, 31 Oct 2007 09:32:04 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQR00801RLHXB00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 31 Oct 2007 03:32:04 -0600 (MDT) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQR0021XRTF0Z40@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 31 Oct 2007 03:32:04 -0600 (MDT) Date: Wed, 31 Oct 2007 04:32:18 -0500 From: Spencer Shepler To: NFSv4 Message-id: <67D27853-884C-4F18-99B2-56C48E929211@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [nfsv4] Boo: NFSv4.1 draft 15 is available X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Normal formating and diffs are found here: http://nfsv4-editor.org/drafts/drafts.html Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 31 08:24:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InCbP-0002qm-Bf; Wed, 31 Oct 2007 08:23:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InCbO-0002lO-07 for nfsv4@ietf.org; Wed, 31 Oct 2007 08:23:18 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InCbN-0001lW-MS for nfsv4@ietf.org; Wed, 31 Oct 2007 08:23:17 -0400 X-IronPort-AV: E=Sophos;i="4.21,351,1188802800"; d="scan'208";a="118314100" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 31 Oct 2007 05:23:02 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l9VCN1m0026774; Wed, 31 Oct 2007 05:23:01 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 05:23:01 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 05:23:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Boo: NFSv4.1 draft 15 is available Date: Wed, 31 Oct 2007 08:22:59 -0400 Message-ID: In-Reply-To: <67D27853-884C-4F18-99B2-56C48E929211@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Boo: NFSv4.1 draft 15 is available Thread-Index: AcgboSq5FwQsf8JRT8idsKdzPeF2DwAF4HlA From: "Noveck, Dave" To: "Spencer Shepler" , "NFSv4" X-OriginalArrivalTime: 31 Oct 2007 12:23:01.0549 (UTC) FILETIME=[C786C5D0:01C81BB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org If you want to be frightening, you have to include the page count :-)=20 -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Wednesday, October 31, 2007 5:32 AM To: NFSv4 Subject: [nfsv4] Boo: NFSv4.1 draft 15 is available Normal formating and diffs are found here: http://nfsv4-editor.org/drafts/drafts.html Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 31 14:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHrn-00011N-JT; Wed, 31 Oct 2007 14:00:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InHrm-0000q2-6i for nfsv4@ietf.org; Wed, 31 Oct 2007 14:00:34 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InHrd-0002Pg-Sn for nfsv4@ietf.org; Wed, 31 Oct 2007 14:00:32 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l9VI1Pc1010288; Wed, 31 Oct 2007 14:01:25 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Oct 2007 14:01:25 -0400 Received: from bh-buildlin1.bhalevy.com ([172.17.28.148]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 13:59:05 -0400 Message-ID: <4728C290.40705@panasas.com> Date: Wed, 31 Oct 2007 19:59:44 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Noveck, Dave" Subject: Re: [nfsv4] Device stateids References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 17:59:05.0351 (UTC) FILETIME=[BA16C970:01C81BE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Cc: Marc Eshel , NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Dave, thanks for the comments! My answers inline below. Benny On Oct. 31, 2007, 2:24 +0200, "Noveck, Dave" wrote: >> Plus, I simplified the proposal by not requiring any new sequence >> flags as the server should use the proposed callback operation to >> recall device mappings and use the > SEQ4_STATUS_RECALLABLE_STATE_REVOKED >> and SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the >> same it may use them for other recallable state objects (locks and >> layouts). > > As far as I can see you don't you them the same and that is an issue. OK. we can define SEQ4_STATUS_DEVID_DELETED* in the spirit of the last proposal [that I see is now part of draft-15 which seems to introduce inconsistencies with the side effects of LAYOUTRETURN for RETURN_{FSID,ALL} that return the respective device mappings but do not change the device stateid] > >> The state of the mapping is represented by a recallable device >> stateid (devstateid). There is at most one devstateid per { client ID, > >> layout type, devsetid } nexus. > >> A recommended filesystem attribute - devsetid is introduced. > > Notice that this arrangement means that fsid A and fsid B share a > devsetid or layout type X iff they share it for layout type Y. > It seems that layout type is the one that should have the flexibility > to figure out how it arranges its devices. > > I think a better model is to divide device id into major and minor > fields and then all devices sharing a major device value become a device > set. I think this would give you a lot more flexibility. Yeah, I see your point. Good idea. > >> DEVICERETURN returns a device ID mapping. When called, this client >> MUST guarantee not to make further use of that device ID mapping. > > Do you really mean that? Isn't this like a CLOSE if which if you used > the stateid for the open file, you would get an error. Do you really > mean that he server can depend on you not using this? same as LAYOUTRETURN. the server is not required to fence off the client after LAYOUTRETURN. > >> If the deviceid argument is set to zero, all device ID mappings in the > >> referred devset are returned. The server updates the devstateid and >> returns the updated value. > > If the deviceid were zero, the returned value of devstateid would be > zero. > Correct? I'm not sure. What does the server return on CLOSE? > >> GETDEVICEINFO >> SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, > notify_ask -> >> devstateid, notify_ack, device_addr > >> GETDEVICELIST >> SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, > cookieverf, notify_ask ->> >> devstateid, notify_ack, cookie, cookieverf, device info list<> > >> GETDEVICEINFO and GETDEVICELIST each take the a devstateid, a > devsetid, >> and the layout type, and return a non-zero devstateid. > > This looks inconsistent to me. > > If I do a GETDEVICEINFO(a), I get a non-zero stateid. > > If I then do a DEVICERETURN(a), I get a zero stateid. > > OK, now I start with a zero stateid again and do a GETDEVICELIST and > get a non-zero stateid. > > If I do a GETDEVICELIST, I get another non-zero stateid. > > If I then do a DEVICERETURN(a), I get ... a non-zero stateid because > the GETDEVICELIST has some effect. Is that true. if you didn't return all device IDs using deviceid==0 then you shouldn't get a zero devstateid. > > It seems the DEVICERETURN is the inverse GETDEVICEINFO but that > GETDEVICELIST has no inverse. At the very least we need more clarity > about this stuff. The way I see it DEVICERETURN w/ deviceid==0 is sort of the inverse of GETDEVICELIST as it "resets" (or reinitializes the device state. > > >> GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally >> asking for device notifications and return a corresponding flag >> confirming the notification. > > Isn't this new function? Is it really needed? It was in the previous proposal. It is not strictly needed as the new device ID can always be introduced at LAYOUTGET time and be resolved using GETDEVICEINFO. The motivation is to optimize this case and reduce the latency by allowing the client to get the device info in advance (it could do so opportunistically, only if it's idle). > >> Device stateids follow the sequencing and use rules of all other > stateid >> types. > > I assume that that means I use the normal "other" value with a seqid of > zero as a wildcard. > >> The devstateid is invalidated when all devices associated with >> it are returned via DEVICERETURN. The client can then "forget" about > that >> devstateid and use a value of zero for the devstateid for any > subsequent >> operation that takes a devstateid argument and allows the > uninitialized >> value. > > I suppose but the server can return that devstateid as zero. Then the > client can either remember that zero and use it in which case he is > using > the correct thing or he can specially note it is zero and this allows > him > to forget it (but then he has to specially note that he has forgotten it > and should use zero in its stead). Seems like the code would be simpler > if it just remembered the last thing it got back (if the client did > parallel once it would have to compare state seqids and treat zero > specially > as later than all normal ones. Agreed. That makes a lot of sense. > >> 5. Recalling device IDs > >> CB_DEVICERECALL >> SYNOPSIS: devstateid, devsetid, deviceid, deleted -> >> >> CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify > >> the client it needs to return the specified deviceid (when non-zero) > or >> all device IDs in the devsetid when the deviceid is set to zero, by >> using a respective DEVICERETURN. CB_DEVICERECALL does not change the >> device stateid. > > A couple things are unclear. It says it needs to return the specified > device id, but is that true when 'deleted' is false? Also, what happens > when the device id is zero and 'deleted' is false. What is supposed to > happen? I meant that the client should send a DEVICERETURN in both cases, although it doesn't seem harmful if it issues a GETDEVICEINFO to refresh the data when "deleted" is set to false. But the server will need to detect that case. > >> All layouts using the affected device IDs remain in force, but the >> server SHOULD fence the client from accessing the affected devices >> until the client has returned the recalled device IDs. > > And after it has returned it? Should the server not fence the client > form a device it has returned. I don't think so. We have access control mechanism to limit what the client can do on the device but fencing the client off may hurt performance needlessly. > >> When the "deleted" boolean flag is set to false the client MAY use >> GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if >> it has valid layouts the refer to the changed deviceid. > > After or instead of doing the return? See answer above. This needs to be clarified and I think I'll go with the permissive approach of allowing to get the info without and explicit DEVICERETURN. > >> If the "deleted" flag is set to true the specified deviceid will not > be >> reused by the server and all outstanding layouts referring to it are >> expected to be recalled via CB_LAYOUTRECALL; hence the client SHOULD >> NOT attempt to call GETDEVICEINFO or GETDEVICELIST for the specified >> deviceid. However, if it does do so the server MUST return a > NFS4ERR_INVAL >> error. > >> 6. Device notification > >> CB_DEVICENOTIFY >> SYNOPSIS: devstateid, devsetid, deviceid -> > >> If the server supports CB_DEVICENOTIFY for devices and the client has >> requested device id notifications via GETDEVICEINFO or GETDEVICELIST >> the server can inform the client of additional deviceids that were >> not previously returned by GETDEVICELIST. > > Again, what is the need here? The client will see the device id's > when he gets a layout. Agreed. This is an optimization we can live without of. see above... > >> 7. SEQUENCE flags > >> In addition to informing the client of mapping changes via >> CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use the >> SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag to indicate >> that one or more device IDs have been revoked without expiration >> of the lease period, due to the client's failure to return them >> when recalled. > > First of all, in the case of CB_DEVICENOTIFY, nothing has been > recalled or is supposed to be returned, as far as I can see. right. > > Then it speaks of devices being "revoked". Devices do not have > stateids and are not, in that sense, locking objects. If the > current protocol, when a stateid has multiple locks (.e.g. byte-range > locks), it is carefully stateid that when one is revoked, all are as > a unit and that is tied to the associated stateid being made invalid. > > When SEQ4_STATUS_RECALLABLE_STATE_REVOKED is set in the current > protocol, the client is supposed to use TEST_STATEID to determine > what state has been lost and acknowledge that loss using FREE_STATEID. > > I think it would be much better if revocation continued to follow > that model. If a devstateid is revoked, then, at least for that, > you start from scratch. OK > >> This status bit remains set on all SEQUENCE replies until the >> loss of all such device ID mappings has been acknowledged by use >> of DEVICERETURN. > > I think it should stay until all revoked stateids are freed via > FREE_STATEID, just as it is today. OK > > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Monday, October 29, 2007 11:45 AM > To: Robert Gordon; Marc Eshel > Cc: NFSv4 > Subject: Re: [nfsv4] Device stateids > > During the most recent bakeathon concern has been raised about the > global device ID namespace and Marc Eshel from IBM requested that we > retain the ability to recall devices per-fsid. To satisfy this > requirement as well as the requirement for a simple global device ID > namespace the updated proposal below introduces a device-set identifier > (devsetid) that qualifies the device ID. > > This provides for a more flexible deviceid namespace topology that can > cover either a global deviceid namespace, per-fsid namespace, or > anything in between (e.g. when several filesystems reside on (and are > confined to) a set of devices, like in EMC or Panasas' cases). > > The proposal also introduces new operations to manage device mapping > state rather than unnecessarily overloading existing operations. > > Plus, I simplified the proposal by not requiring any new sequence flags > as the server should use the proposed callback operation to recall > device mappings and use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED and > SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the same it may > use them for other recallable state objects (locks and layouts). > > One last change is providing for a "wildcard" value (0) for device ID > that specifies all the device IDs in a devset. This means that the > server MUST NOT return a zero device ID in GETDEVICELIST or in any > layout and it must reject it as invalid in GETDEVICEINFO.GETDEVICEINFO > and GETDEVICELIST also take a boolean flag optionally asking for device > notifications and return a corresponding flag confirming the > notification. > I guess that this won't be an issue for anyone; otherwise, please > holler. > > Benny > > -- > 1. Introduction > > The NFS client maintains a mapping of device IDs contained in a layout > to the corresponding storage device address. > Device IDs and filesystem IDs are associated with device set IDs such > that each fsid is associated with a single devsetid as indicated by a > new, recommended filesystem attribute, and each deviceid is associated > with a single devsetid. > > The state of the mapping is represented by a recallable device stateid > (devstateid). There is at most one devstateid per { client ID, layout > type, devsetid } nexus. > > A recommended filesystem attribute - devsetid is introduced. > All deviceids associated with any file in the filesystem are associated > with this devsetid. > If the server does not support device sets, it can omit this attribute, > making the deviceid namespace global and implicitly associating all > deviceids with the default devset (having the implicit devsetid ID of 0) > > 2. Getting device information > > GETDEVICEINFO > SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, > notify_ask -> > devstateid, notify_ack, device_addr > > GETDEVICELIST > SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, > cookieverf, notify_ask -> > devstateid, notify_ack, cookie, cookieverf, device info list<> > > GETDEVICEINFO and GETDEVICELIST each take the a devstateid, a devsetid, > and the layout type, and return a non-zero devstateid. > In case the client holds a valid devstateid it MUST use it for > subsequent GETDEVICEINFO and GETDEVICELIST that update the device ID > mappings. The devstateid argument must be set to zero whenever the > client has no valid devstateid (e.g. after reboot or after the > devstateid was previously returned via DEVICERETURN). > > GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally > asking for device notifications and return a corresponding flag > confirming the notification. > > 3. Returning device IDs > > DEVICERETURN > SYNOPSIS: devstateid, devsetid, deviceid -> devstateid > > DEVICERETURN returns a device ID mapping. When called, this client MUST > guarantee not to make further use of that device ID mapping. > If the deviceid argument is set to zero, all device ID mappings in the > referred devset are returned. The server updates the devstateid and > returns the updated value. > > 4. Sequencing rules > > Device stateids follow the sequencing and use rules of all other stateid > types. The devstateid is invalidated when all devices associated with > it are returned via DEVICERETURN. The client can then "forget" about > that devstateid and use a value of zero for the devstateid for any > subsequent operation that takes a devstateid argument and allows the > uninitialized value. > > 5. Recalling device IDs > > CB_DEVICERECALL > SYNOPSIS: devstateid, devsetid, deviceid, deleted -> > > CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify > the client it needs to return the specified deviceid (when non-zero) or > all device IDs in the devsetid when the deviceid is set to zero, by > using a respective DEVICERETURN. CB_DEVICERECALL does not change the > device stateid. > > All layouts using the affected device IDs remain in force, but the > server SHOULD fence the client from accessing the affected devices until > the client has returned the recalled device IDs. > > When the "deleted" boolean flag is set to false the client MAY use > GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if it > has valid layouts the refer to the changed deviceid. If the "deleted" > flag is set to true the specified deviceid will not be reused by the > server and all outstanding layouts referring to it are expected to be > recalled via CB_LAYOUTRECALL; hence the client SHOULD NOT attempt to > call GETDEVICEINFO or GETDEVICELIST for the specified deviceid. However, > if it does do so the server MUST return a NFS4ERR_INVAL error. > > 6. Device notification > > CB_DEVICENOTIFY > SYNOPSIS: devstateid, devsetid, deviceid -> > > If the server supports CB_DEVICENOTIFY for devices and the client has > requested device id notifications via GETDEVICEINFO or GETDEVICELIST the > server can inform the client of additional deviceids that were not > previously returned by GETDEVICELIST. > > The purpose of this operation is to reduce the latency for getting new > device mappings. Rather than waiting until the client accesses a file > that uses the new device ID, issue a LAYOUTGET, and then a GETDEVICEINFO > on the new device, the server can notify the client of any new device ID > in advance and have the client get the device address mapping by calling > GETDEVICEINFO at its convenience. > > CB_DEVICENOTIFY takes a device stateid, a device set ID and a device ID > in the device set for a device ID that was not returned in a previous > series GETDEVICELIST calls (where the series ended in gdlr_eof == TRUE). > The client calls GETDEVICEINFO or GETDEVICELIST to determine the > mappings for the new device ID. > CB_DEVICENOTIFY does not change the device stateid. > > If the client has already issued a GETDEVICEINFO for the specified > deviceid then it SHOULD just ignore the device id notification. > Updating an existing device ID mapping should be done using a sequence > of CB_DEVICERECALL, DEVICERETURN, and GETDEVICEINFO (or GETDEVICELIST). > > 7. SEQUENCE flags > > In addition to informing the client of mapping changes via > CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use the > SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag to indicate that one > or more device IDs have been revoked without expiration of the lease > period, due to the client's failure to return them when recalled. This > status bit remains set on all SEQUENCE replies until the loss of all > such device ID mappings has been acknowledged by use of DEVICERETURN. > > On Aug. 09, 2007, 10:22 +0300, Benny Halevy wrote: >> Robert Gordon wrote: >>> In general i think this is good. >>> >>> I've started to think that the SEQUENCE status flags could just be >>> two bits. >>> >>> SEQ4_STATUS_DEVID_DELETED_ALL >>> This flag stays on until the client issues a DELEGRETURN >>> using the devstateid. >>> >>> SEQ_STATUS_DEVID_CHANGED >>> This flag stay on until a GETDEVICELIST or GETDEVICEINFO >>> (if using CB_NOTIFY) gets the affected mappings. >> The DEVID_DELETED cases should be covered by CHANGED as the client >> will have to revalidate all the device mappings anyway to see what >> actually changed and should either not see the deleted deviceid >> returned by GETDEVICELIST or get an error from GETDEVICEINFO for that > deviceid. >> The DEVID_ADDED case is covered if the client is doing GETDEVICELIST >> and the server supports it. If the server does not support >> GETDEVICELIST is must not set SEQ_STATUS_DEVID_CHANGED for added >> devices as the client has no way to get the new device ID. These will > >> be discovered only when the client will get new layouts referring to >> the new devices (which is perfectly fine) >> >>> Robert. >>> >>> On Aug 8, 2007, at 10:58 AM, Benny Halevy wrote: >>> >>>> The NFS client maintains a mapping of device ids contained in a >>>> layout, to the corresponding storage device address. >>>> The state of the mapping is represented by a single recallable >>>> device stateid (devstateid). There is at most one devstateid per { >>>> client ID, layout type } pair. >>>> >>>> GETDEVICEINFO and GETDEVICELIST each take the layout type and an >>>> optional devstateid and return the devstateid. In case the client >>>> holds a valid devstateid it MUST use it for subsequent GETDEVICEINFO > >>>> and GETDEVICELIST that update the device ID mappings. The >>>> devstateid argument is invalid whenever the client has no valid >>>> devstateid (e.g. after reboot or after the devstateid was previously > >>>> returned via DELEGRETURN). >>>> GETDEVICEINFO or GETDEVICELIST that operate on a device stateid that > >>>> was already recalled via CB_RECALL MUST be rejected by the server >>>> with NFS4ERR_BADSTATEID. >>>> >>>> GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally >>>> asking for device notifications and return a corresponding flag >>>> confirming the notification. >>>> >>>> Device stateids follow the sequencing and use rules of all other >>>> stateid types. The mappings are invalidated when the devstateid is >>>> returned via CB_DELEGRETURN or explicitly deleted via CB_NOTIFY. >>>> >>>> All layouts using the device IDs remain in force, but the server >>>> MUST fence the client from accessing the affected devices until the >>>> client has obtained the re-mapped device IDs via GETDEVICEINFO or >>>> GETDEVICELIST. >>>> >>>> CB_RECALL takes a devstateid to notify the client it needs to return > >>>> all device IDs identified by the devstateid. The filehandle >>>> argument has no use in this case. It does not change the device >>>> stateid. >>>> >>>> DELEGRETURN takes a devstateid to return all device IDs associated >>>> with the devstateid. The current filehandle has no use in this case. >>>> >>>> If the server supports CB_NOTIFY for devices and the Client has >>>> requested device id notifications via GETDEVICEINFO or >>>> GETDEVICELIST; The server can inform the client of a delete, add, or > >>>> change mapping. >>>> >>>> CB_NOTIFY takes a device stateid qualifying a device ID for the >>>> following device notifications: >>>> >>>> NOTIFY4_DELETE_DEVICE_ID >>>> Deletes all mappings using the specified device ID. >>>> The server MUST stop using the device ID. Any >>>> layouts remain in force, but aren't useful until >>>> new mappings are available. The server fences the >>>> client from the affected data server until all >>>> layouts with the device ID are returned, or the >>>> client obtains new mappings. The server provides >>>> a hint as to whether new mappings will arrive and >>>> if so how long. >>>> >>>> NOTIFY4_ADD_DEVICE_ID >>>> Adds a device ID to address mapping. This is >>>> for a device ID the that was not returned in a >>>> previous series GETDEVICELIST calls (where the >>>> series ended in gdlr_eof == TRUE). The client >>>> calls GETDEVICEINFO or GETDEVICELIST to determine >>>> the mappings for the new device ID. >>>> >>>> NOTIFY4_CHANGE_DEVICE_ID >>>> The client call GETDEVICEINFO or GETDEVICELIST >>>> to get updated device addresses for the device >>>> ID. Layouts remain in force. The client is fenced >>>> from any devices that were in the old address list, >>>> but not the new address list. >>>> >>>> CB_NOTIFY does not change the device stateid. >>>> >>>> In addition to informing the client of mapping changes via CB_NOTIFY > >>>> and CB_RECALL, SEQUENCE carries status flags to indicate that device > >>>> mappings have changed. >>>> >>>> The flags are :- >>>> >>>> SEQ4_STATUS_DEVID_DELETED >>>> Mapping has been partially deleted. If the client is >>>> using CB_NOTIFY it may issue a GETDEVICEINFO for each >>>> notified deletion or GETDEVICELIST to refresh the entire >>>> map. This flag stays on until the client responds to >>>> any and all _DELETE notifications, or it has issued a >>>> GETDEVICELIST. >>>> >>>> SEQ4_STATUS_DEVID_DELETED_ALL >>>> This flag stays on until the client issues a DELEGRETURN >>>> using the devstateid. >>>> >>>> SEQ4_STATUS_DEVID_CHANGED >>>> SEQ4_STATUS_DEVID_ADDED >>>> These flags stay on until a GETDEVICELIST or GETDEVICEINFO >>>> (if using CB_NOTIFY) gets the affected mappings. >>>> >>> _______________________________________________ >>> nfsv4 mailing list >>> nfsv4@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nfsv4 >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 31 14:17:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InI7o-00045d-6o; Wed, 31 Oct 2007 14:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InI7n-00045W-1a for nfsv4@ietf.org; Wed, 31 Oct 2007 14:17:07 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InI7l-0003NU-R6 for nfsv4@ietf.org; Wed, 31 Oct 2007 14:17:07 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l9VIIipX011069; Wed, 31 Oct 2007 14:18:44 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Oct 2007 14:18:44 -0400 Received: from bh-buildlin1.bhalevy.com ([172.17.28.148]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 14:16:24 -0400 Message-ID: <4728C6A0.2050607@panasas.com> Date: Wed, 31 Oct 2007 20:17:04 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Noveck, Dave" , Spencer Shepler Subject: Re: [nfsv4] Boo: NFSv4.1 draft 15 is available References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 18:16:24.0831 (UTC) FILETIME=[25AAD8F0:01C81BEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct. 31, 2007, 14:22 +0200, "Noveck, Dave" wrote: > If you want to be frightening, you have to include the page count :-) Yeah :) Besides that, we have some problems with the changes for the device and layout stateid's. Off the top of my head after quickly browsing though the diff: 1. It looks like you merged the last proposal for devstateid and left the existing semantics for recalling/returning device ID's via CB_LAYOUTRECALL and LAYOUTRETURN for FSID and ALL. The problem is that LAYOUTRETURN does not update the device stateid and this seems conflicting. Also, I didn't see how the device state ID is recalled, CB_NOTIFY wasn't updated, and it is not clear how the device stateid is returns (LAYOUTRETURN for RETURN_FSID or ALL? or DELEGRETURN as the last proposal said which I really don't like). I think the proposal I sent can become a coherent and simple model that will server everyone. 2. layout state ID: there's no layout stateid argument to LAYOUTGET nor there is one in its result. Or did I just miss it? IIRC this was the whole point of doing it? Benny > > -----Original Message----- > From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] > Sent: Wednesday, October 31, 2007 5:32 AM > To: NFSv4 > Subject: [nfsv4] Boo: NFSv4.1 draft 15 is available > > > Normal formating and diffs are found here: > http://nfsv4-editor.org/drafts/drafts.html > > Spencer > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 31 14:45:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIYU-00075S-GV; Wed, 31 Oct 2007 14:44:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIYS-0006vS-VZ for nfsv4@ietf.org; Wed, 31 Oct 2007 14:44:41 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InIYQ-0001i4-AK for nfsv4@ietf.org; Wed, 31 Oct 2007 14:44:38 -0400 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9VIibre007966 for ; Wed, 31 Oct 2007 18:44:37 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQS00G01H3KXH00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Wed, 31 Oct 2007 12:44:37 -0600 (MDT) Received: from [10.1.194.250] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQS00K34HEA9VF0@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 31 Oct 2007 12:44:35 -0600 (MDT) Date: Wed, 31 Oct 2007 13:44:31 -0500 From: Robert Gordon Subject: Re: [nfsv4] Boo: NFSv4.1 draft 15 is available In-reply-to: <4728C6A0.2050607@panasas.com> To: NFSv4 Message-id: <5DBBA960-5C38-4C10-8A19-9D7014B11902@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <4728C6A0.2050607@panasas.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 31, 2007, at 1:17 PM, Benny Halevy wrote: > 2. layout state ID: there's no layout stateid argument to LAYOUTGET > nor there is one in its result. Or did I just miss it? > IIRC this was the whole point of doing it? > dot-x always wins :-) (it's in the dot x) Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 31 15:13:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIzW-0004M4-2D; Wed, 31 Oct 2007 15:12:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIzU-0004Lx-QL for nfsv4@ietf.org; Wed, 31 Oct 2007 15:12:36 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InIzU-0002nI-DM for nfsv4@ietf.org; Wed, 31 Oct 2007 15:12:36 -0400 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1InIzS-0005Jv-W8; Wed, 31 Oct 2007 15:12:35 -0400 Date: Wed, 31 Oct 2007 15:12:34 -0400 To: Spencer Shepler Subject: Re: [nfsv4] Boo: NFSv4.1 draft 15 is available Message-ID: <20071031191234.GF4569@fieldses.org> References: <67D27853-884C-4F18-99B2-56C48E929211@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67D27853-884C-4F18-99B2-56C48E929211@Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Wed, Oct 31, 2007 at 04:32:18AM -0500, Spencer Shepler wrote: > > Normal formating and diffs are found here: > http://nfsv4-editor.org/drafts/drafts.html I was just reviewing the acl changes and noticed that while you fixed at least one of my typos along the way (oops! thanks), you missed another (also my fault, sorry): an "ACE4_APPEND_DATA" is missing an underscore. (Looks fine otherwise, thanks!) --b. diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml index 139c43b..b3a7f08 100755 --- a/nfsv41_middle_fileattributes_acls.xml +++ b/nfsv41_middle_fileattributes_acls.xml @@ -742,7 +742,7 @@ const ACE4_SYNCHRONIZE = 0x00100000; paragraph. If a client submits an ALLOW ACE where ACE4_APPEND_DATA is set but ACE4_WRITE_DATA is not (or vice versa), the server should either turn off - ACE4_APPEND DATA or reject the request with + ACE4_APPEND_DATA or reject the request with NFS4ERR_ATTRNOTSUPP.
_______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 31 15:31:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJGr-0000X3-Bf; Wed, 31 Oct 2007 15:30:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJGm-0000PD-KH for nfsv4@ietf.org; Wed, 31 Oct 2007 15:30:28 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InJGl-00043I-FL for nfsv4@ietf.org; Wed, 31 Oct 2007 15:30:28 -0400 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1InJGF-0005Yy-Bs; Wed, 31 Oct 2007 15:29:55 -0400 Date: Wed, 31 Oct 2007 15:29:50 -0400 To: Spencer Shepler Subject: Re: [nfsv4] Boo: NFSv4.1 draft 15 is available Message-ID: <20071031192950.GG4569@fieldses.org> References: <67D27853-884C-4F18-99B2-56C48E929211@Sun.COM> <20071031191234.GF4569@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071031191234.GF4569@fieldses.org> User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org It looks like there was some sort of minor merge problem in the introduction; part of a sentence is duplicated here. --b. diff --git a/nfsv41_middle_introduction.xml b/nfsv41_middle_introduction.xml index 2b0781e..cd3b447 100755 --- a/nfsv41_middle_introduction.xml +++ b/nfsv41_middle_introduction.xml @@ -351,8 +351,7 @@ resources. The client may be an application which contains the logic to access the NFS server directly. The client may also be the traditional operating system client that - provides remote file system services for a set of applications. - file system services for a set of applications. + provides remote file system services for a set of applications. A client is uniquely identified by a Client Owner. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Oct 31 15:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJeW-0003MP-GL; Wed, 31 Oct 2007 15:55:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJeU-0003Kp-UN for nfsv4@ietf.org; Wed, 31 Oct 2007 15:54:58 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InJeU-0005Fl-JM for nfsv4@ietf.org; Wed, 31 Oct 2007 15:54:58 -0400 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1InJeT-0005xJ-Jp; Wed, 31 Oct 2007 15:54:57 -0400 Date: Wed, 31 Oct 2007 15:54:57 -0400 To: Spencer Shepler Subject: Re: [nfsv4] Boo: NFSv4.1 draft 15 is available Message-ID: <20071031195457.GH4569@fieldses.org> References: <67D27853-884C-4F18-99B2-56C48E929211@Sun.COM> <20071031191234.GF4569@fieldses.org> <20071031192950.GG4569@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071031192950.GG4569@fieldses.org> User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org And one remaining nit: only series with 3 or more elements get commas. (If someone is really dead set on a comma there, then you could change the "and associated session" to a nonrestrictive parenthetical thing, and adjust the number of the verb to match, like: "A client ID, with associated session, is required..." Seems more cumbersome to me, though.) --b. diff --git a/nfsv41_middle_core_infrastructure.xml b/nfsv41_middle_core_infrastructure.xml index d41f6fb..34ec875 100755 --- a/nfsv41_middle_core_infrastructure.xml +++ b/nfsv41_middle_core_infrastructure.xml @@ -1467,7 +1467,7 @@ struct server_owner4 {
Each client ID () can have - zero or more active sessions. A client ID, and associated + zero or more active sessions. A client ID and associated session are required to perform file access in NFSv4.1. Each time a session is used (whether by a client sending a request to the server, or the client replying to a callback _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From AlexisfinchCornett@metacritic.com Wed Oct 31 16:55:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InKah-0003rj-Cx; Wed, 31 Oct 2007 16:55:07 -0400 Received: from cl-col-200-30-80-26.orbitel.net.co ([200.30.80.26] helo=maria.mshome.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1InKaW-0008KK-PW; Wed, 31 Oct 2007 16:54:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host27802632.metacritic.com (8.13.1/8.13.1) with SMTP id G6YK8I5A46.146201.daI.J9Z.6505676297596 for ; Wed, 31 Oct 2007 15:54:03 +0500 Message-ID: <149d01c81c00$44d2e9f0$0100a8c0@maria> From: "Kelley Messer" To: Subject: Your family Date: Wed, 31 Oct 2007 15:54:03 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1499_01C81C00.44D2E9F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1499_01C81C00.44D2E9F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_1499_01C81C00.44D2E9F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1499_01C81C00.44D2E9F0-- From nfsv4-bounces@ietf.org Wed Oct 31 17:46:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLNE-0003nJ-PV; Wed, 31 Oct 2007 17:45:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLND-0003ko-Eq for nfsv4@ietf.org; Wed, 31 Oct 2007 17:45:15 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InLN7-0006F3-SZ for nfsv4@ietf.org; Wed, 31 Oct 2007 17:45:15 -0400 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9VLix1o028607 for ; Wed, 31 Oct 2007 21:44:59 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQS00D01OCW7E00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Wed, 31 Oct 2007 15:44:59 -0600 (MDT) Received: from [10.1.194.250] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQS0041APQFYD30@mail-amer.sun.com>; Wed, 31 Oct 2007 15:44:39 -0600 (MDT) Date: Wed, 31 Oct 2007 16:44:36 -0500 From: Robert Gordon Subject: Re: [nfsv4] Device stateids In-reply-to: <4728C290.40705@panasas.com> To: NFSv4 Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <4728C290.40705@panasas.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Benny Halevy , Dave Noveck X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Oct 31, 2007, at 12:59 PM, Benny Halevy wrote: >>> The state of the mapping is represented by a recallable device >>> stateid (devstateid). There is at most one devstateid per >>> { client ID, >> >>> layout type, devsetid } nexus. >> >>> A recommended filesystem attribute - devsetid is introduced. >> >> Notice that this arrangement means that fsid A and fsid B share a >> devsetid or layout type X iff they share it for layout type Y. >> It seems that layout type is the one that should have the flexibility >> to figure out how it arranges its devices. >> >> I think a better model is to divide device id into major and minor >> fields and then all devices sharing a major device value become a >> device >> set. I think this would give you a lot more flexibility. > > Yeah, I see your point. Good idea. > An alternative way of looking at this is to say a device stateid represents a collection of device id's. The Server can then have the flexibility to arrange the grouping how it likes. One server implementation may wish to group things by MDS FSID while another implementation may wish to group things by some other criteria or just have one stateid that represents all device ids. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From GlennhobbsHamilton@yahoo.com Wed Oct 31 18:28:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InM39-0007Mu-8l; Wed, 31 Oct 2007 18:28:35 -0400 Received: from pool-71-164-114-10.albyny.east.verizon.net ([71.164.114.10] helo=fatrat2.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1InM38-0003g1-Ka; Wed, 31 Oct 2007 18:28:35 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host87847871.yahoo.com (8.13.1/8.13.1) with SMTP id rMVpquUs68.731212.wH5.kde.2773575676228 for ; Wed, 31 Oct 2007 18:28:20 +0500 Message-ID: <4a93201c81c0d$60872000$2f01a8c0@FATRAT2> From: "Jeffery Harrison" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now

10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_4A92E_01C81C0D.60872000-- From derek8brandon@cbbn.net Wed Oct 31 22:01:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPMj-0000rW-Tg for nfsv4-archive@lists.ietf.org; Wed, 31 Oct 2007 22:01:01 -0400 Received: from [217.116.48.246] (helo=regionsvyazservice.t72.ru) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InPMj-0002eF-BO for nfsv4-archive@lists.ietf.org; Wed, 31 Oct 2007 22:01:01 -0400 Received: from [217.116.48.246] by gejfsfyu.cbbn.net; Thu, 01 Nov 2007 02:01:16 +0000 Message-ID: <000901c81c2b$069b9825$c1eff698@cljjaux> From: "galven anita" To: "Brett Buckner" Subject: We specialize in the sales of brand-name quality Date: Thu, 01 Nov 2007 00:13:53 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C81C2B.06993905" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C81C2B.06993905 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from! http://my07fg.net/ ------=_NextPart_000_0006_01C81C2B.06993905 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perfectly crafted luxury timepieces, all at affordable prices. Thousands = of different models to choose from!

http://my07fg.net/ ------=_NextPart_000_0006_01C81C2B.06993905--