From owner-freebsd-fs@FreeBSD.ORG Sun Jun 2 10:07:51 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EC5B9675 for ; Sun, 2 Jun 2013 10:07:51 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 7CEA71D64 for ; Sun, 2 Jun 2013 10:07:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id r52A7eVA012411; Sun, 2 Jun 2013 14:07:40 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 2 Jun 2013 14:07:40 +0400 (MSK) From: Dmitry Morozovsky To: Rick Macklem Subject: Re: NFS+ZFS+nullfs on Server random Permission Denied errors on client (nfsv4) In-Reply-To: <316743389.56838.1369876739579.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <316743389.56838.1369876739579.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sun, 02 Jun 2013 14:07:41 +0400 (MSK) Cc: freebsd-fs@freebsd.org, Bryan Drewery X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 10:07:52 -0000 On Wed, 29 May 2013, Rick Macklem wrote: > Bryan Drewery wrote: > > Server: [snip] > > Problem: > > > > For months I constantly get random Permission Denied errors on the > > client side. Just trying the read again can fix the problem. The > > client > > will usually show this in dmesg as the same time: > > > nfsv4 client/server protocol prob err=10020 > > > This error means "no file handle" and I believe it will happen when > the client tries to access the root of the exported tree. (The root > specified by the "V4: ..." line in /etc/exports.) Isn't it the problem with mountd cleaning all exports and re-exporting new list on every mount(2) call? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Sun Jun 2 12:30:52 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3AE68A38 for ; Sun, 2 Jun 2013 12:30:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0349610FE for ; Sun, 2 Jun 2013 12:30:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAK85q1GDaFvO/2dsb2JhbABahnW7RIESdIIjAQEFI1AGGw4KAgINGQJZBhOIDah9kQaBJo1NNAeCRIEUA5c+kUCDKyCBaw X-IronPort-AV: E=Sophos;i="4.87,788,1363147200"; d="scan'208";a="32364924" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 02 Jun 2013 08:29:43 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 50ECEB4045; Sun, 2 Jun 2013 08:29:43 -0400 (EDT) Date: Sun, 2 Jun 2013 08:29:43 -0400 (EDT) From: Rick Macklem To: Dmitry Morozovsky Message-ID: <1781152855.121926.1370176183284.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: NFS+ZFS+nullfs on Server random Permission Denied errors on client (nfsv4) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, Bryan Drewery X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 12:30:52 -0000 Dmitry Morozovsky wrote: > On Wed, 29 May 2013, Rick Macklem wrote: > > > Bryan Drewery wrote: > > > Server: > > [snip] > > > > Problem: > > > > > > For months I constantly get random Permission Denied errors on the > > > client side. Just trying the read again can fix the problem. The > > > client > > > will usually show this in dmesg as the same time: > > > > nfsv4 client/server protocol prob err=10020 > > > > > This error means "no file handle" and I believe it will happen when > > the client tries to access the root of the exported tree. (The root > > specified by the "V4: ..." line in /etc/exports.) > > Isn't it the problem with mountd cleaning all exports and re-exporting > new list > on every mount(2) call? > Yes, good point. Doing mounts or sending HUP to mountd could certainly cause this. (Back when I used a FreeBSD system as a production NFS server, I never did mounts on it or changed the /etc/exports, I just configured it and let it run for mounts/years, so I tend to forget this issue.;-) If this is the cause and you have a recent enough system to support it, you can try the "-S" option on mountd. Alternately, this issue can be avoided by switching from mountd to nfse (found on sourceforge). rick > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru > *** > ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Sun Jun 2 20:36:16 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 923BDC9B for ; Sun, 2 Jun 2013 20:36:16 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9EA1830 for ; Sun, 2 Jun 2013 20:36:14 +0000 (UTC) Received: from [10.0.1.10] (c-ce57e155.1525-1-64736c12.cust.bredbandsbolaget.se [85.225.87.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by melon.pingpong.net (Postfix) with ESMTPSA id BAED72D653; Sun, 2 Jun 2013 22:35:23 +0200 (CEST) Date: Sun, 02 Jun 2013 22:35:23 +0200 From: Palle Girgensohn To: Kirk McKusick Subject: Re: leaking lots of unreferenced inodes (pg_xlog files?) Message-ID: <69D8CE6E8C429368C08781FD@Spelvik.local> In-Reply-To: <201305311825.r4VIPeFV077457@chez.mckusick.com> References: <201305311825.r4VIPeFV077457@chez.mckusick.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Errors-To: girgen+uustuds@pingpong.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========BC84A2A88248F67D07CB==========" Cc: freebsd-fs@FreeBSD.org, Dan Thomas , Jeff Roberson , Julian Akehurst X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 20:36:16 -0000 --==========BC84A2A88248F67D07CB========== Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On 31 maj 2013 11.25.40 -0700 Kirk McKusick = wrote: >> Date: Thu, 30 May 2013 12:56:54 +0200 >> From: Palle Girgensohn >> To: Kirk McKusick >> CC: freebsd-fs@FreeBSD.org, Jeff Roberson , >> Dan Thomas , Julian Akehurst >> Subject: Re: leaking lots of unreferenced >> inodes (pg_xlog files?) >> >> Hello again! >> >> I have now remounted the postgresql filesystem on a test server that >> experiences the same problem. The production server is not remounted >> yet, we're planning that in a weeks time approximately, but I though I >> could gain som time by running the suggested procedure on the test box. >> >> The base problem was this: >> >> # df -h /pgsql ; du -hxs /pgsql >> Filesystem Size Used Avail Capacity Mounted on >> /dev/da2s1d 128G 101G 17G 86% /pgsql >> 82G /pgsql >> >> df says 101 GB used, but du only finds 82 GB, and fstat cannot find any >> open files that are unreferenced in the file system. Stopping postgresql >> does not help. It seems the OS is leaking inode references. >> >> FreeBSD 9.1, postgresql 9.2.3 from port. >> >> I ran the suggested commans (in attached diskspacecheck) before stopping >> postgresql (before.log), after stopping postgresql but before unmount >> /pgsql (before2.log), and then i unmounted /pgsql (had to run umount -f >> /pgsql, and it took about 20 seconds). I did not enter single-user mode, >> since I really did not have to this time (On the production server, the >> disk is /usr, so that will require more shutting down...) >> >> I've attach the logs here. Hope it helps! >> >> The commands run in diskspaccheck are >> # ! /bin/sh >> df -ih /pgsql >> vmstat -z >> vmstat -m >> sysctl debug >> fstat -f /pgsql >> >> as suggested by Kirk. > > Your results are very enlightening. Especially the fact that you have > to do a forcible unmount of the filesystem. What that tells me is that > somehow we are getting vnodes that have phantom references. That is > there is some system call where we get a reference on a vnode (vref, > vget, or similar) that does not ultimately have a corresponding drop > of the reference (vrele, vput, or similar). The net effect is that > the file is held open despite the fact that there are no longer any > connections to it. When you do the forcible unmount, the kernel walks > the list of vnodes associated with the filesystem and does a vgone on > each of them. That causes each to be inactivated which then triggers > the release of their associated disk space. The reason that the unmount > takes 20 seconds is to process all the releasing of the space. My guess > is that there is an error path in some system call that is missing the > vrele or vput. > > Assuming that you are able to run some more tests on your test machine, > the next step in narrowing down the set of code to look at is to try > running your system with soft updates disabled. The idea is to find out > whether the miss-matched references are in the soft updates code or are > in one of the filesystem system calls themselves. To disable soft updates > run the command `tunefs -n disable /pgsql' on the unmounted /pgsql > filesystem. If the system then runs without the problem, I will know > to search the soft updates code. If the problem persists, then I'll > know to look in the system calls themselves. You may want to do some > preliminary tests to see how quickly the problem manifests itself. > You can do this by running it for a short time (10 minutes say) and > then checking to see if you need to do a forcible unmount of the > filesystem. Once you establish how long you have to run before you > reliably have to do a forcible unmount, you will know how long to > run the test with soft updates turned off. If you find that running > with soft updates turned off makes your application run too slowly > you can mount your filesystem asynchronously. Note however, that you > should not run asynchronously if the data on the filesystem is critical > as you may end up with an unrecoverable filesystem after a power failure > or system crash. So only run asynchronously if you can afford to lose > your filesystem. > > Finally, it would be helpful if you could add two more commands to > your diskspacecheck.sh script: > > sysctl -a | egrep vnode > mount -v > > The first shows the vnode usage and the second shows the operational > state of your filesystems. > > Kirk McKusick OK, I have now turned off soft updates. This is on the test server. It is=20 not as busy as the production machine, but I'll keep an eye on it and will=20 mail new results as soon as I see any evidence of either that soft updates=20 is the culprit or that it is not. FWIW, I attach the script from this remount process as well, which includes = sysctl -a |=A0grep vnode ; mount -v. Note that it is all in one script file = this time. Cheers, Palle --==========BC84A2A88248F67D07CB========== Content-Type: application/octet-stream; name=second_test Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=second_test; size=119120 U2NyaXB0IHN0YXJ0ZWQgb24gU3VuIEp1biAgMiAyMjoyMzozMCAyMDEzCg0KIyAuL2RpcwgbW0sI G1tLCBtbSwgbW0sIG1tLB3NoIC14IGRzCBtbS3MIG1tLaXNrc3BhY2VjaGVjay5zaCANCisgZGYg LWloIC9wZ3NxbA0KRmlsZXN5c3RlbSAgICAgU2l6ZSAgICBVc2VkICAgQXZhaWwgQ2FwYWNpdHkg aXVzZWQgaWZyZWUgJWl1c2VkICBNb3VudGVkIG9uDQovZGV2L2RhMnMxZCAgICAxMjhHICAgICA4 MkcgICAgIDM2RyAgICA3MCUgICAgIDIzayAgIDE3TSAgICAwJSAgIC9wZ3NxbA0KKyB2bXN0YXQg LXoNCklURU0gICAgICAgICAgICAgICAgICAgU0laRSAgTElNSVQgICAgIFVTRUQgICAgIEZSRUUg ICAgICBSRVEgRkFJTCBTTEVFUA0KDQpVTUEgS2VnczogICAgICAgICAgICAgICAyMDgsICAgICAg MCwgICAgICA4NiwgICAgICAxNiwgICAgICA4NiwgICAwLCAgIDANClVNQSBab25lczogICAgICAg ICAgICAgMTQwOCwgICAgICAwLCAgICAgIDg2LCAgICAgICAwLCAgICAgIDg2LCAgIDAsICAgMA0K VU1BIFNsYWJzOiAgICAgICAgICAgICAgNTY4LCAgICAgIDAsICAgIDY4MTQsICAgICA1MDEsICA2 MjgzOTMsICAgMCwgICAwDQpVTUEgUkNudFNsYWJzOiAgICAgICAgICA1NjgsICAgICAgMCwgICAg NDU5MSwgICAgIDU3NSwgIDM5Mjg2OSwgICAwLCAgIDANClVNQSBIYXNoOiAgICAgICAgICAgICAg IDI1NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAzLCAgIDAsICAgMA0KMTYgQnVj a2V0OiAgICAgICAgICAgICAgMTUyLCAgICAgIDAsICAgICAgMjcsICAgICAgNzMsICAgICAyMTEs ICAgMCwgICAwDQozMiBCdWNrZXQ6ICAgICAgICAgICAgICAyODAsICAgICAgMCwgICAgICA0Nywg ICAgIDE0OSwgICAgIDMzOSwgICA2LCAgIDANCjY0IEJ1Y2tldDogICAgICAgICAgICAgIDUzNiwg ICAgICAwLCAgICAgIDc4LCAgICAgIDc2LCAgICAgNzUyLCAgOTAsICAgMA0KMTI4IEJ1Y2tldDog ICAgICAgICAgICAxMDQ4LCAgICAgIDAsICAgIDEwMjksICAgICAgIDAsIDE1NTY0NDksMTUzNDcx MDEsICAgMA0KVk0gT0JKRUNUOiAgICAgICAgICAgICAgMjMyLCAgICAgIDAsICAxNzU4MDEsICAg MTAyMzEsMTQxOTQyMjQxLCAgIDAsICAgMA0KTUFQOiAgICAgICAgICAgICAgICAgICAgMjMyLCAg ICAgIDAsICAgICAgIDcsICAgICAgMjUsICAgICAgIDcsICAgMCwgICAwDQpLTUFQIEVOVFJZOiAg ICAgICAgICAgICAxMjAsIDExMjg3MTAsICAgMTMwNzgsICAgMzgxMzQsMTc5Mzc2OTE5MywgICAw LCAgIDANCk1BUCBFTlRSWTogICAgICAgICAgICAgIDEyMCwgICAgICAwLCAgICAyODE2LCAgICAy OTUwLDMwMTk0OTAyMCwgICAwLCAgIDANCmZha2VwZzogICAgICAgICAgICAgICAgIDEyMCwgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KbXRfem9uZTogICAgICAg ICAgICAgICA0MTEyLCAgICAgIDAsICAgICAzMjYsICAgICAgIDEsICAgICAzMjYsICAgMCwgICAw DQoxNjogICAgICAgICAgICAgICAgICAgICAgMTYsICAgICAgMCwgICAgMjMzNSwgICAgMjAzMywx NTE4MDkxMiwgICAwLCAgIDANCjMyOiAgICAgICAgICAgICAgICAgICAgICAzMiwgICAgICAwLCAg ICAyNzc3LCAgICAxNjY3LDUwMTk5MjMwLCAgIDAsICAgMA0KNjQ6ICAgICAgICAgICAgICAgICAg ICAgIDY0LCAgICAgIDAsICAgIDUzNTgsICAgIDQyNzQsODMwODE5NDQsICAgMCwgICAwDQoxMjg6 ICAgICAgICAgICAgICAgICAgICAxMjgsICAgICAgMCwgICAgOTkyOCwgICAgNDY1OSw2ODk1MTM5 MjUsICAgMCwgICAwDQoyNTY6ICAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgMTM3 NSwgICAzMjY3NSwyOTIwMjQ3OTk1LCAgIDAsICAgMA0KNTEyOiAgICAgICAgICAgICAgICAgICAg NTEyLCAgICAgIDAsICAgIDI3OTYsICAgIDIzMzUsMTgxMjk5NDAsICAgMCwgICAwDQoxMDI0OiAg ICAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgICA3OCwgICAgMTMxNCwgMjIwMDE2NCwg ICAwLCAgIDANCjIwNDg6ICAgICAgICAgICAgICAgICAgMjA0OCwgICAgICAwLCAgICA1Njc0LCAg ICAxMjI4LCA0MTM1MTY2LCAgIDAsICAgMA0KNDA5NjogICAgICAgICAgICAgICAgICA0MDk2LCAg ICAgIDAsICAgICA0NjUsICAgIDExMzUsIDUzMjcxMTUsICAgMCwgICAwDQpGaWxlczogICAgICAg ICAgICAgICAgICAgODAsICAgICAgMCwgICAgMTQ0MCwgICAgOTc2NSwxOTkyMTE2OTgsICAgMCwg ICAwDQpUVVJOU1RJTEU6ICAgICAgICAgICAgICAxMzYsICAgICAgMCwgICAgMTkzOSwgICAgIDEy MSwgICAgMTk0OCwgICAwLCAgIDANCnVtdHggcGk6ICAgICAgICAgICAgICAgICA5NiwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KTUFDIGxhYmVsczogICAgICAg ICAgICAgIDQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpQ Uk9DOiAgICAgICAgICAgICAgICAgIDExODQsICAgICAgMCwgICAgICA4MiwgICAgMTQwMywgNDU0 NjQxNywgICAwLCAgIDANClRIUkVBRDogICAgICAgICAgICAgICAgMTEyOCwgICAgICAwLCAgICAx NTQ5LCAgICAgMzg5LCAgICAxOTYzLCAgIDAsICAgMA0KU0xFRVBRVUVVRTogICAgICAgICAgICAg IDgwLCAgICAgIDAsICAgIDE5MzksICAgICAyNjUsICAgIDE5NDgsICAgMCwgICAwDQpWTVNQQUNF OiAgICAgICAgICAgICAgICAzOTIsICAgICAgMCwgICAgICA2MywgICAgMTUyNywgNDU0NjQwMCwg ICAwLCAgIDANCmNwdXNldDogICAgICAgICAgICAgICAgICA3MiwgICAgICAwLCAgICAgIDg1LCAg ICAgIDY1LCAgICAgIDg1LCAgIDAsICAgMA0KYXVkaXRfcmVjb3JkOiAgICAgICAgICAgOTYwLCAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQptYnVmX3BhY2tldDog ICAgICAgICAgICAyNTYsICAgICAgMCwgICAgNDA4MCwgICAgMTY4MCw2OTc4MDM2OTAsICAgMCwg ICAwDQptYnVmOiAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgMTAyNCwgICAgMTcy MSwxOTYyODIzMzAzLCAgIDAsICAgMA0KbWJ1Zl9jbHVzdGVyOiAgICAgICAgICAyMDQ4LCAgMjU2 MDAsICAgIDU3NjAsICAgIDEyNTQsIDE3MDg1NDQsICAgMCwgICAwDQptYnVmX2p1bWJvX3BhZ2U6 ICAgICAgIDQwOTYsICAxMjgwMCwgICAgICAgMCwgICAgMTA4NCw4MzUwNTI4NSwgICAwLCAgIDAN Cm1idWZfanVtYm9fOWs6ICAgICAgICAgOTIxNiwgICA2NDAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMA0KbWJ1Zl9qdW1ib18xNms6ICAgICAgIDE2Mzg0LCAgIDMyMDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQptYnVmX2V4dF9yZWZjbnQ6ICAgICAg ICAgIDQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCmdfYmlv OiAgICAgICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgICAgICAwLCAgICAxNTg0LDI5Nzc4NDEw MzIsICAgMCwgICAwDQp0dHlpbnE6ICAgICAgICAgICAgICAgICAxNjAsICAgICAgMCwgICAgIDE1 MCwgICAgIDQ3NCwgICAgMjYyNSwgICAwLCAgIDANCnR0eW91dHE6ICAgICAgICAgICAgICAgIDI1 NiwgICAgICAwLCAgICAgIDgwLCAgICAgMzQwLCAgICAxNDAwLCAgIDAsICAgMA0KYXRhX3JlcXVl c3Q6ICAgICAgICAgICAgMzI4LCAgICAgIDAsICAgICAgIDAsICAgICAgODQsICAgICAgMzIsICAg MCwgICAwDQphdGFfY29tcG9zaXRlOiAgICAgICAgICAzMzYsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDANClZOT0RFOiAgICAgICAgICAgICAgICAgIDQ4MCwgICAg ICAwLCAgMTg5OTU3LCAgIDc1NDQzLDE1ODk3Nzc3NiwgICAwLCAgIDANClZOT0RFUE9MTDogICAg ICAgICAgICAgIDExMiwgICAgICAwLCAgICAgICAwLCAgICAgMTMyLCAgICAgICA2LCAgIDAsICAg MA0KTkFNRUk6ICAgICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAgICAgIDAsICAgIDEyMTIs NDMyMzc0NTA4LCAgIDAsICAgMA0KUyBWRlMgQ2FjaGU6ICAgICAgICAgICAgMTA4LCAgICAgIDAs ICAxOTEyMTksICAgODY2MDgsMTYzMzA4MzU1LCAgIDAsICAgMA0KU1RTIFZGUyBDYWNoZTogICAg ICAgICAgMTQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpM IFZGUyBDYWNoZTogICAgICAgICAgICAzMjgsICAgICAgMCwgICAxMjcxMSwgICAgNDAwNSwgNzYy MjgyMiwgICAwLCAgIDANCkxUUyBWRlMgQ2FjaGU6ICAgICAgICAgIDM2OCwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KTkNMTk9ERTogICAgICAgICAgICAgICAg NTY4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpESVJIQVNI OiAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgICA5NSwgICAgIDk1MywgMzA4NTI5NSwg ICAwLCAgIDANCk1vdW50cG9pbnRzOiAgICAgICAgICAgIDc5MiwgICAgICAwLCAgICAgICA4LCAg ICAgIDMyLCAgICAgICA5LCAgIDAsICAgMA0KcGlwZTogICAgICAgICAgICAgICAgICAgNzI4LCAg ICAgIDAsICAgICAgMzYsICAgIDEyOTQsIDM5NzU2NzAsICAgMCwgICAwDQprc2lnaW5mbzogICAg ICAgICAgICAgICAxMTIsICAgICAgMCwgICAgMTQ3NCwgICAgMTQzMCwxMDExMzk3NSwgICAwLCAg IDANCml0aW1lcjogICAgICAgICAgICAgICAgIDM0NCwgICAgICAwLCAgICAgICAxLCAgICAgIDIx LCAgICAgICAxLCAgIDAsICAgMA0KS05PVEU6ICAgICAgICAgICAgICAgICAgMTI4LCAgICAgIDAs ICAgICAgIDAsICAgIDE3MTEsIDExMTQ5NDcsICAgMCwgICAwDQpzb2NrZXQ6ICAgICAgICAgICAg ICAgICA2ODAsIDEwMDAwMiwgICAgICA2NCwgICAgMTM5NCwgOTYzNDE2OSwgICAwLCAgIDANCmlw cTogICAgICAgICAgICAgICAgICAgICA1NiwgICAgODE5LCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMA0KdWRwX2lucGNiOiAgICAgICAgICAgICAgMzkyLCAxMDAwMDAsICAgICAg MTMsICAgIDE1NDcsIDc1NjE2MzQsICAgMCwgICAwDQp1ZHBjYjogICAgICAgICAgICAgICAgICAg MTYsIDEwMDEyOCwgICAgICAxMywgICAgMTgzNSwgNzU2MTYzNCwgICAwLCAgIDANCnRjcF9pbnBj YjogICAgICAgICAgICAgIDM5MiwgMTAwMDAwLCAgICAgIDM2LCAgICAxNzI0LCAgNjYzNDEwLCAg IDAsICAgMA0KdGNwY2I6ICAgICAgICAgICAgICAgICAgOTc2LCAxMDAwMDAsICAgICAgMzYsICAg IDE3MzYsICA2NjM0MTAsICAgMCwgICAwDQp0Y3B0dzogICAgICAgICAgICAgICAgICAgNzIsICAy MDAwMCwgICAgICAgMCwgICAgIDU1MCwgICAgMzI4NCwgICAwLCAgIDANCnN5bmNhY2hlOiAgICAg ICAgICAgICAgIDE1MiwgIDE1Mzc1LCAgICAgICAwLCAgICAgNjI1LCAgNTE0NjU4LCAgIDAsICAg MA0KaG9zdGNhY2hlOiAgICAgICAgICAgICAgMTM2LCAgMTUzNzIsICAgICAgIDUsICAgICA0OTks ICAgIDE4NzksICAgMCwgICAwDQp0Y3ByZWFzczogICAgICAgICAgICAgICAgNDAsICAgMTY4MCwg ICAgICAgMCwgICAgMTU5NiwgICAyMTc0OCwgICAwLCAgIDANCnNhY2tob2xlOiAgICAgICAgICAg ICAgICAzMiwgICAgICAwLCAgICAgICAwLCAgICAgOTA5LCAgICAgODg1LCAgIDAsICAgMA0Kc2N0 cF9lcDogICAgICAgICAgICAgICAxMzc2LCAxMDAwMDAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwDQpzY3RwX2Fzb2M6ICAgICAgICAgICAgIDIyODgsICA0MDAwMCwgICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfbGFkZHI6ICAgICAgICAgICAgICA0 OCwgIDgwMDY0LCAgICAgICAwLCAgICAgMjg4LCAgICAgICA2LCAgIDAsICAgMA0Kc2N0cF9yYWRk cjogICAgICAgICAgICAgNzA0LCAgODAwMDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwDQpzY3RwX2NodW5rOiAgICAgICAgICAgICAxMzYsIDQwMDAwOCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfcmVhZHE6ICAgICAgICAgICAgIDEwNCwgNDAw MDMyLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0Kc2N0cF9zdHJlYW1fbXNn X291dDogICAgMTEyLCA0MDAwMjYsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw DQpzY3RwX2FzY29uZjogICAgICAgICAgICAgNDAsIDQwMDAwOCwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDANCnNjdHBfYXNjb25mX2FjazogICAgICAgICA0OCwgNDAwMDMyLCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KcmlwY2I6ICAgICAgICAgICAgICAg ICAgMzkyLCAxMDAwMDAsICAgICAgIDAsICAgICAxMDAsICAgICAxMjYsICAgMCwgICAwDQp1bnBj YjogICAgICAgICAgICAgICAgICAyNDAsIDEwMDAwMCwgICAgICAxNCwgICAgMTMxNCwgMTQwODk5 MywgICAwLCAgIDANCnJ0ZW50cnk6ICAgICAgICAgICAgICAgIDIwMCwgICAgICAwLCAgICAgIDIz LCAgICAgIDkxLCAgICAgIDIzLCAgIDAsICAgMA0Kc2VsZmQ6ICAgICAgICAgICAgICAgICAgIDU2 LCAgICAgIDAsICAgIDIwMDYsICAgIDEzMzMsMzA5Mzc2NTcyLCAgIDAsICAgMA0KU1dBUE1FVEE6 ICAgICAgICAgICAgICAgMjg4LCAxMTY1MTksICAgICAgNTYsICAgICA1NDIsIDEwNzIxMDUsICAg MCwgICAwDQpGRlMgaW5vZGU6ICAgICAgICAgICAgICAxNjgsICAgICAgMCwgIDE4NTc1NCwgICA3 NzcxOCwxNTg5NzU0NDYsICAgMCwgICAwDQpGRlMxIGRpbm9kZTogICAgICAgICAgICAxMjgsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCkZGUzIgZGlub2RlOiAg ICAgICAgICAgIDI1NiwgICAgICAwLCAgMTg1NzU0LCAgIDc3NTQxLDE1ODk3NTQ0MCwgICAwLCAg IDANCg0KKyB2bXN0YXQgLW0NCiAgICAgICAgIFR5cGUgSW5Vc2UgTWVtVXNlIEhpZ2hVc2UgUmVx dWVzdHMgIFNpemUocykNCkNBTSBkZXYgcXVldWUgICAgIDQgICAgIDFLICAgICAgIC0gICAgICAg IDQgIDEyOA0KICBtZF9zaWlfZGF0YSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICA0MiAgNTEy DQogICAgICBDQU0gWFBUICAgNTcxICAxMDQ1SyAgICAgICAtICAgICAgOTQ4ICAxNiwzMiw2NCwx MjgsMjU2LDEwMjQsMjA0OA0KICAgICAgIGlzYWRldiAgICAgOCAgICAgMUsgICAgICAgLSAgICAg ICAgOCAgMTI4DQogICAgICAgICBVQVJUICAgICA2ICAgICA0SyAgICAgICAtICAgICAgICA2ICAx Niw1MTIsMTAyNA0KICAgICBhY3BpaW50ciAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg NjQNCiAgICAgICAgIGNkZXYgICAgIDcgICAgIDJLICAgICAgIC0gICAgICAgIDcgIDI1Ng0KICAg ICAgIGFjcGljYSAgMTQ1MSAgIDEzOUsgICAgICAgLSAgNjUyNjcyNCAgMTYsMzIsNjQsMTI4LDI1 Niw1MTIsMTAyNA0KICAgICAgICBzaWdpbyAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg NjQNCiAgICAgZmlsZWRlc2MgICAxNDkgICAxNjVLICAgICAgIC0gIDUwNTMyNzAgIDE2LDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2DQogICAgICAgICBrZW52ICAgIDc4ICAgIDExSyAg ICAgICAtICAgICAgIDg5ICAxNiwzMiw2NCwxMjgNCiAgICAgICBrcXVldWUgICAgIDAgICAgIDBL ICAgICAgIC0gIDEwNzM4MTEgIDI1Niw1MTIsMjA0OA0KICAgIHByb2MtYXJncyAgICA2MyAgICAg NEsgICAgICAgLSAgNzE4NTY1MyAgMTYsMzIsNjQsMTI4LDI1Ng0KICAgICAgICBoaG9vayAgICAg MiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4DQogICAgIGFjcGl0YXNrICAgICAxICAgICAy SyAgICAgICAtICAgICAgICAxICAyMDQ4DQogICAgICBpdGhyZWFkICAgIDk5ICAgIDE2SyAgICAg ICAtICAgICAgIDk5ICAzMiwxMjgsMjU2DQogICAgQ0FNIHF1ZXVlICAgIDE5ICAgICA3SyAgICAg ICAtICAgICAgNDA3ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwyMDQ4DQogICAgICAgS1RSQUNFICAg MTAwICAgIDEzSyAgICAgICAtICAgICAgMTAwICAxMjgNCiAgICAgICBsaW5rZXIgICAxNTggICAg MTFLICAgICAgIC0gICAgICAxNjAgIDE2LDMyLDY0LDUxMg0KICAgICAgICBsb2NrZiAgICAyMCAg ICAgM0sgICAgICAgLSAgICAyNDgzNiAgNjQsMTI4DQogICBsb2dpbmNsYXNzICAgICAyICAgICAx SyAgICAgICAtICAgIDYxMDUxICA2NA0KICAgICAgIGlwNm5kcCAgICAxMiAgICAgMUsgICAgICAg LSAgICAgICAxNCAgNjQsMTI4DQogICAgICAgICB0ZW1wICAgIDUxICAgICAySyAgICAgICAtICA4 NDAwOTYyICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAgICAgIGRldmJ1 ZiAgODY0OCA0MTg4OUsgICAgICAgLSAgICAxMDE0MyAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAy NCwyMDQ4LDQwOTYNCiAgICAgICBtb2R1bGUgICA0NzcgICAgNjBLICAgICAgIC0gICAgICA0Nzcg IDEyOA0KICAgIGNpc3NfZGF0YSAgICAxNSAgICAxNEsgICAgICAgLSAgICAgNjc0OSAgMTYsMTI4 LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgbXR4X3Bvb2wgICAgIDIgICAgMTZLICAgICAg IC0gICAgICAgIDIgIA0KICAgICAgIFVTQmRldiAgICAzNCAgICAgOEsgICAgICAgLSAgICAgICA0 NCAgNjQsMTI4LDUxMiw0MDk2DQogICAgICAgICAgVVNCICAgIDUyICAgIDMxSyAgICAgICAtICAg ICAgIDY2ICAxNiwzMiw2NCwxMjgsMjU2LDIwNDgsNDA5Ng0KICAgICBwbWNob29rcyAgICAgMSAg ICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4DQogICAgICBzdWJwcm9jICAxNTcwICAxMDc2SyAg ICAgICAtICA0NTQ3OTA2ICA1MTIsNDA5Ng0KICAgICAgICAgcHJvYyAgICAgMiAgICAxNksgICAg ICAgLSAgICAgICAgMiAgDQogICAgICBzZXNzaW9uICAgIDU2ICAgICA3SyAgICAgICAtICAzNjcw MjM5ICAxMjgNCiAgICAgICAgIHBncnAgICAgNjEgICAgIDhLICAgICAgIC0gIDM2NzQ5MjAgIDEy OA0KICAgICAgICAgY3JlZCAgICA1MiAgICAgOUsgICAgICAgLSAzMzU2MzU1MCAgNjQsMjU2DQog ICAgICB1aWRpbmZvICAgICA2ICAgICAzSyAgICAgICAtICAgMTkwNjg0ICAxMjgsMjA0OA0KICAg ICAgIHBsaW1pdCAgICAxNiAgICAgNEsgICAgICAgLSAgIDc5NjY4MiAgMjU2DQogICAgICBhdGFf cGNpICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgICAgc2NzaV9jZCAgICAg MCAgICAgMEsgICAgICAgLSAgICAgICAxMCAgMTYNCiAgICBzeXNjdGx0bXAgICAgIDAgICAgIDBL ICAgICAgIC0gICAgMTUwNzAgIDE2LDMyLDY0LDEyOCw0MDk2DQogICAgc3lzY3Rsb2lkICA0OTc4 ICAgMjUxSyAgICAgICAtICAgICA1MzYwICAxNiwzMiw2NCwxMjgNCiAgICAgICBzeXNjdGwgICAg IDAgICAgIDBLICAgICAgIC0gIDgyMjM2NzEgIDE2LDMyLDY0DQogICAgICB0aWRoYXNoICAgICAx ICAgIDE2SyAgICAgICAtICAgICAgICAxICANCiAgICAgIGNhbGxvdXQgICAgIDcgMTQzMzZLICAg ICAgIC0gICAgICAgIDcgIA0KICAgICAgICAgdW10eCAgMzg3NiAgIDQ4NUsgICAgICAgLSAgICAg Mzg5NCAgMTI4DQogICAgIHAxMDAzLjFiICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAx Ng0KICAgICAgICAgU1dBUCAgICAgMiAgIDU0OUsgICAgICAgLSAgICAgICAgMiAgNjQNCiAgICAg ICBidXMtc2MgICAxMTMgICA3ODFLICAgICAgIC0gICAgIDUyMzQgIDE2LDMyLDY0LDEyOCwyNTYs NTEyLDEwMjQsMjA0OCw0MDk2DQogICAgICAgICAgYnVzICAxMjgyICAgMTA5SyAgICAgICAtICAg ICA5Njc2ICAxNiwzMiw2NCwxMjgsMjU2LDEwMjQNCiAgICAgIGRldnN0YXQgICAgMTIgICAgMjVL ICAgICAgIC0gICAgICAgMTIgIDMyLDQwOTYNCiBldmVudGhhbmRsZXIgICAgNzcgICAgIDZLICAg ICAgIC0gICAgICAgNzcgIDY0LDEyOA0KICAgICAgYWNwaXNlbSAgICAxOSAgICAgM0sgICAgICAg LSAgICAgICAxOSAgMTI4DQogICAgICAgICBrb2JqICAgMzMwICAxMzIwSyAgICAgICAtICAgICAg NjUwICA0MDk2DQogICAgICBDQU0gU0lNICAgICA1ICAgICAySyAgICAgICAtICAgICAgICA1ICAy NTYNCiAgICAgIFBlci1jcHUgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDMyDQogICBD QU0gcGVyaXBoICAgIDEwICAgICAzSyAgICAgICAtICAgICAgIDU0ICAxNiwzMiw2NCwxMjgsMjU2 DQogICAgICAgICBybWFuICAgMjQ4ICAgIDI2SyAgICAgICAtICAgICAgNjEzICAxNiwzMiwxMjgN CiAgICAgICAgIHNidWYgICAgIDEgICAgIDFLICAgICAgIC0gICAgIDI4MjYgIDE2LDMyLDY0LDEy OCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2DQogICAgICBlbnRyb3B5ICAxMDI0ICAgIDY0SyAgICAg ICAtICAgICAxMDI0ICA2NA0KICAgICAgIGN0bG1lbSAgNTA2MiAxMDExM0sgICAgICAgLSAgICAg NTA2MiAgMTI4LDIwNDgNCiAgICAgICAgc3RhY2sgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAg IDYgIDI1Ng0KICAgIHRhc2txdWV1ZSAgICAxNSAgICAgMksgICAgICAgLSAgICAgICAxNSAgMTYs MzIsMTI4DQogICAgICAgVW5pdG5vICAgIDE0ICAgICAxSyAgICAgICAtICAgNjExMTgyICAzMiw2 NA0KICAgICAgICAgIGlvdiAgICAgMCAgICAgMEsgICAgICAgLSAgMTYxMDE3MiAgMTYsMzIsNjQs MTI4LDI1Niw1MTINCiAgICAgICBzZWxlY3QgIDE0NTYgICAxODJLICAgICAgIC0gICAgIDE0NTYg IDEyOA0KICAgICBpb2N0bG9wcyAgICAgMCAgICAgMEsgICAgICAgLSAgODc3NTg4NiAgMTYsMzIs NjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgICAgICBtc2cgICAgIDQgICAgMzBL ICAgICAgIC0gICAgICAgIDQgIDIwNDgsNDA5Ng0KICAgICAgICAgIHNlbSAgICAgNCAgIDE5Nksg ICAgICAgLSAgICAgICAgNCAgDQogICAgICAgICAgc2htICAgIDM0ICAgIDg2SyAgICAgICAtICAz NDY0ODM3ICAyMDQ4DQogICAgICAgICAgdHR5ICAgIDIzICAgIDIzSyAgICAgICAtICAgICAgMTYx ICAxMDI0LDIwNDgNCiAgICAgICAgICBwdHMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAxMzQg IDI1Ng0KICAgICBtYnVmX3RhZyAgICAgMCAgICAgMEsgICAgICAgLSA0NDUyODkyOCAgMzIsMTI4 DQogICAgICAgIHNobWZkICAgICAxICAgICA4SyAgICAgICAtICAgICAgICAxICANCiAgICAgICAg ICBwY2IgICAgMjMgICAxNTdLICAgICAgIC0gICA2Mzg4MTQgIDE2LDMyLDEyOCwxMDI0LDIwNDgs NDA5Ng0KICAgICAgIHNvbmFtZSAgICAgNSAgICAgMUsgICAgICAgLSA1MzU3OTA3OSAgMTYsMzIs MTI4DQogICAgICAgICAgYWNsICAgICAwICAgICAwSyAgICAgICAtICAgMTQ2NjA5ICA0MDk2DQog ICAgICAgYmlvYnVmICAgICAxICAgICAySyAgICAgICAtICAgIDE0NjkyICAyMDQ4DQogICAgIHZm c2NhY2hlICAgICAxICA4MTkySyAgICAgICAtICAgICAgICAxICANCiAgIGNsX3NhdmVidWYgICAg IDAgICAgIDBLICAgICAgIC0gMTA1MDAyMDM5ICA2NCwxMjgNCiAgICAgdmZzX2hhc2ggICAgIDEg IDQwOTZLICAgICAgIC0gICAgICAgIDEgIA0KICAgICAgIERFVkZTMSAgIDExNSAgICA1OEsgICAg ICAgLSAgICAgIDI3MSAgNTEyDQogICAgICAgdm5vZGVzICAgICAyICAgICAxSyAgICAgICAtICAg ICAgICA0ICA2NCwyNTYNCiAgICAgICBERVZGUzMgICAxMzEgICAgMzNLICAgICAgIC0gICAgICAz MTggIDI1Ng0KICAgICAgICBtb3VudCAgIDEwNiAgICAgNUsgICAgICAgLSAgICAgIDE5MSAgMTYs MzIsNjQsMTI4LDI1Ng0KICB2bm9kZW1hcmtlciAgICAgMCAgICAgMEsgICAgICAgLSAgNTIxMjU2 NCAgNTEyDQogICAgICAgICAgQlBGICAgICA5ICAgICAySyAgICAgICAtICAgICAgICA5ICAxMjgN CiAgZXRoZXJfbXVsdGkgICAgNTYgICAgIDNLICAgICAgIC0gICAgICAgNjYgIDE2LDMyLDY0DQog ICAgICAgaWZhZGRyICAgIDg3ICAgIDIySyAgICAgICAtICAgICAgIDg3ICAzMiw2NCwxMjgsMjU2 LDUxMiw0MDk2DQogICAgICAgIGlmbmV0ICAgIDEwICAgIDE5SyAgICAgICAtICAgICAgIDEwICAx MjgsMjA0OA0KICAgICAgICBjbG9uZSAgICAgNiAgICAyNEsgICAgICAgLSAgICAgICAgNiAgNDA5 Ng0KICAgICAgIGFycGNvbSAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTYNCiAgICAg IGxsdGFibGUgICAgMzIgICAgMTNLICAgICAgIC0gICAgNTkzMTcgIDI1Niw1MTINCiAgICAgICAg REVWRlMgICAgMTcgICAgIDFLICAgICAgIC0gICAgICAgMjAgIDE2LDEyOA0KICAgICAgIERFVkZT UCAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQNCiAgICAgcm91dGV0YmwgICAgNDQg ICAgIDZLICAgICAgIC0gIDE1MTQzNTggIDMyLDY0LDEyOCwyNTYsNTEyDQogICAgICAgICBpZ21w ICAgICA5ICAgICAzSyAgICAgICAtICAgICAgICA5ICAyNTYNCiAgICAgaW5fbXVsdGkgICAgIDMg ICAgIDFLICAgICAgIC0gICAgICAgIDMgIDI1Ng0KICAgIHNjdHBfaXRlciAgICAgMCAgICAgMEsg ICAgICAgLSAgICAgICAgNCAgMjU2DQogICAgIHNjdHBfaWZuICAgICAzICAgICAxSyAgICAgICAt ICAgICAgICAzICAxMjgNCiAgICAgc2N0cF9pZmEgICAgIDcgICAgIDFLICAgICAgIC0gICAgICAg IDcgIDEyOA0KICAgICBzY3RwX3ZyZiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNjQN CiAgICBzY3RwX2FfaXQgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDQgIDE2DQogICAgaG9z dGNhY2hlICAgICAxICAgIDI4SyAgICAgICAtICAgICAgICAxICANCiAgICAgc3luY2FjaGUgICAg IDEgICAgOTZLICAgICAgIC0gICAgICAgIDEgIA0KICAgIGluNl9tdWx0aSAgICAyOCAgICAgNEsg ICAgICAgLSAgICAgICAyOCAgMzIsMjU2DQogICAgICAgICAgbWxkICAgICA5ICAgICAySyAgICAg ICAtICAgICAgICA5ICAxMjgNCiAgICAgICAgICBycGMgICAgIDIgICAgIDFLICAgICAgIC0gICAg ICAgIDIgIDI1Ng0KYXVkaXRfZXZjbGFzcyAgIDE3OSAgICAgNksgICAgICAgLSAgICAgIDIxOCAg MzINCiAgICAgc2F2ZWRpbm8gICAgIDAgICAgIDBLICAgICAgIC0gIDMxMTQ1ODIgIDI1Ng0KICAg ICBmcmVld29yayAgICAxNCAgICAgMksgICAgICAgLSA4MzUxMjExMCAgMTYsMTI4DQogICAgbmV3 ZGlyYmxrICAgICAwICAgICAwSyAgICAgICAtICAgIDE4NDAzICA2NA0KICAgICAgIGRpcnJlbSAg ICAgMSAgICAgMUsgICAgICAgLSAxMzU0MTUyOCAgMTI4DQogICAgICAgIG1rZGlyICAgICAwICAg ICAwSyAgICAgICAtICAgIDI5NDU2ICAxMjgNCiAgICAgICBkaXJhZGQgICAgIDEgICAgIDFLICAg ICAgIC0gMTM1NDkwODAgIDEyOA0KICAgICBmcmVlZmlsZSAgICAgMyAgICAgMUsgICAgICAgLSAg Njk0ODQ1MiAgNjQNCiAgICAgZnJlZWJsa3MgICAgIDEgICAgIDFLICAgICAgIC0gIDY4NDQ5Mjcg IDEyOA0KICAgICBmcmVlZnJhZyAgICAgMCAgICAgMEsgICAgICAgLSA0NDE0NjUwMjcgIDEyOA0K ICAgICBpbmRpcmRlcCAgICAgMiAgICAgMUsgICAgICAgLSAgNjQ3NjI1OSAgMTI4DQogICAgICAg bmV3YmxrICAgODEwICAgNzE1SyAgICAgICAtIDI4ODY0NzEwNjUgIDI1Ng0KICAgIGJtc2FmZW1h cCAgICAgNiAgICAxMEsgICAgICAgLSAgOTIwODkxMSAgMjU2DQogICAgIGlub2RlZGVwICAgICA4 ICA0MTAwSyAgICAgICAtICA4MDk3NzA5ICA1MTINCiAgICAgIHBhZ2VkZXAgICAgIDIgICA1MTNL ICAgICAgIC0gICAxNDIxMDQgIDI1Ng0KICB1ZnNfZGlyaGFzaCAgIDcwNyAgIDM0NksgICAgICAg LSAgIDQxMzc4MSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNA0KICAgIHVmc19tb3VudCAgICAx OCAgICA2OUsgICAgICAgLSAgICAgICAyMSAgNTEyLDIwNDgsNDA5Ng0KICAgIHZtX3BnZGF0YSAg ICAgMiAgIDEyOUsgICAgICAgLSAgICAgICAgMiAgMTI4DQogICAgICBVTUFIYXNoICAgICAzICAg IDIySyAgICAgICAtICAgICAgIDEzICA1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgIG1lbWRlc2Mg ICAgIDEgICAgIDRLICAgICAgIC0gICAgICAgIDEgIDQwOTYNCiAgICAgYXRrYmRkZXYgICAgIDIg ICAgIDFLICAgICAgIC0gICAgICAgIDIgIDY0DQogICAgcGZzX25vZGVzICAgIDIxICAgICA2SyAg ICAgICAtICAgICAgIDIxICAyNTYNCiAgcGZzX3ZuY2FjaGUgICAgIDAgICAgIDBLICAgICAgIC0g ICAgICAyNjggIDY0DQogICAgICAgY3RsYmxrICAgMjAwICAxNjAwSyAgICAgICAtICAgICAgMjAw ICANCiAgICAgICAgIEdFT00gICAxMjcgICAgNDBLICAgICAgIC0gICAgIDE0NDEgIDE2LDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQsMjA0OA0KICAgICAgcmFtZGlzayAgICAgMSAgNDA5NksgICAgICAg LSAgICAgICAgMSAgDQogICAgICBhY3BpZGV2ICAgIDMwICAgICAySyAgICAgICAtICAgICAgIDMw ICA2NA0KICAgICAgY3RscG9vbCAgIDUzMiAgIDE0MksgICAgICAgLSAgICAgIDUzMiAgMzIsNTEy DQogICAgICAga2JkbXV4ICAgICA3ICAgIDE4SyAgICAgICAtICAgICAgICA4ICAxNiw1MTIsMTAy NCwyMDQ4DQogICAgICAgYXBtZGV2ICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAxMjgN CiAgIG1hZHRfdGFibGUgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDEgIDQwOTYNCiAgICAg ICBmZWVkZXIgICAgIDcgICAgIDFLICAgICAgIC0gICAgICAgIDcgIDMyDQogICAgICBzY3NpX2Rh ICAgICAwICAgICAwSyAgICAgICAtICAgICAgMjk3ICAxNg0KICAgICBwY2lfbGluayAgICAxNiAg ICAgMksgICAgICAgLSAgICAgICAxNiAgMTYsMTI4DQogICAgcmFpZF9kYXRhICAgICAwICAgICAw SyAgICAgICAtICAgICAgMjU4ICAzMiwxMjgsMjU2DQogICAgICBpb19hcGljICAgICAxICAgICAy SyAgICAgICAtICAgICAgICAxICAyMDQ4DQogICAgICAgICAgTUNBICAgICA4ICAgICAxSyAgICAg ICAtICAgICAgICA4ICAxMjgNCiAgICAgICAgICBtc2kgICAgIDMgICAgIDFLICAgICAgIC0gICAg ICAgIDMgIDEyOA0KICAgICBuZXh1c2RldiAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAg MTYNCm1kX252aWRpYV9kYXRhICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDQyICA1MTINCisg c3lzY3RsIGRlYnVnDQpkZWJ1Zy5hY3BpLnN1c3BlbmRfYm91bmNlOiAwDQpkZWJ1Zy5hY3BpLnJl c2V0X2Nsb2NrOiAxDQpkZWJ1Zy5hY3BpLmludGVycHJldGVyX3NsYWNrOiAxDQpkZWJ1Zy5hY3Bp LmVuYWJsZV9kZWJ1Z19vYmplY3RzOiAwDQpkZWJ1Zy5hY3BpLmFjcGlfY2FfdmVyc2lvbjogMjAx MTA1MjcNCmRlYnVnLmFjcGkuY3B1X3Vub3JkZXJlZDogMA0KZGVidWcuYWNwaS5lYy50aW1lb3V0 OiA3NTANCmRlYnVnLmFjcGkuZWMucG9sbGVkOiAwDQpkZWJ1Zy5hY3BpLmVjLmJ1cnN0OiAwDQpk ZWJ1Zy5hY3BpLmJhdHQuYmF0dF9zbGVlcF9tczogMA0KZGVidWcuYWNwaS5yZXN1bWVfYmVlcDog MA0KZGVidWcuZmlyZXdpcmVfZGVidWc6IDANCmRlYnVnLmZ3bWVtX2RlYnVnOiAwDQpkZWJ1Zy5p Zl9md2VfZGVidWc6IDANCmRlYnVnLmlmX2Z3aXBfZGVidWc6IDANCmRlYnVnLmlwdzogMA0KZGVi dWcuaXdpOiAwDQpkZWJ1Zy5tZGRlYnVnOiAwDQpkZWJ1Zy53cGk6IDANCmRlYnVnLmVsZjY0X2xl Z2FjeV9jb3JlZHVtcDogMA0KZGVidWcuYm9vdHZlcmJvc2U6IDANCmRlYnVnLmJvb3Rob3d0bzog MA0KZGVidWcuY3B1ZnJlcS52ZXJib3NlOiAwDQpkZWJ1Zy5jcHVmcmVxLmxvd2VzdDogMA0KZGVi dWcuZmFpbF9wb2ludC5zeXNjdGxfcnVubmluZzogb2ZmDQpkZWJ1Zy5mYWlsX3BvaW50LmJ1Zl9w cmVzc3VyZTogb2ZmDQpkZWJ1Zy5mYWlsX3BvaW50Lm5sbV9kZW55X2dyYW50OiBvZmYNCmRlYnVn LmFkYXB0aXZlX21hY2hpbmVfYXJjaDogMQ0KZGVidWcuc2l6ZW9mLmNkZXZfcHJpdjogMzc2DQpk ZWJ1Zy5zaXplb2YuY2RldjogMjg4DQpkZWJ1Zy5zaXplb2YuZ19iaW9xOiA1Ng0KZGVidWcuc2l6 ZW9mLmdfY29uc3VtZXI6IDk2DQpkZWJ1Zy5zaXplb2YuZ19wcm92aWRlcjogMTM2DQpkZWJ1Zy5z aXplb2YuZ19nZW9tOiAxNjANCmRlYnVnLnNpemVvZi5nX2NsYXNzOiAxNjANCmRlYnVnLnNpemVv Zi5raW5mb19wcm9jOiAxMDg4DQpkZWJ1Zy5zaXplb2YuYnVmOiA2MDgNCmRlYnVnLnNpemVvZi5i aW86IDIzMg0KZGVidWcuc2l6ZW9mLnByb2M6IDExODQNCmRlYnVnLnNpemVvZi52bm9kZTogNDgw DQpkZWJ1Zy5zaXplb2YuZGV2c3RhdDogMjg4DQpkZWJ1Zy5zaXplb2YubmFtZWNhY2hlOiA3Mg0K ZGVidWcub3NkOiAwDQpkZWJ1Zy50cmFjZV9vbl9wYW5pYzogMQ0KZGVidWcuZGVidWdnZXJfb25f cGFuaWM6IDENCmRlYnVnLm5jb3JlczogNQ0KZGVidWcudG9fYXZnX21wY2FsbHM6IDc0Mw0KZGVi dWcudG9fYXZnX2xvY2tjYWxsczogMjYxDQpkZWJ1Zy50b19hdmdfZ2NhbGxzOiA0OTMNCmRlYnVn LnRvX2F2Z19kZXB0aDogMTc1OA0KZGVidWcudW10eC51bXR4X3BpX2FsbG9jYXRlZDogMA0KZGVi dWcuY2xvY2t0aW1lOiAwDQpkZWJ1Zy5rZGIuYWx0X2JyZWFrX3RvX2RlYnVnZ2VyOiAwDQpkZWJ1 Zy5rZGIuYnJlYWtfdG9fZGVidWdnZXI6IDANCmRlYnVnLmtkYi50cmFwX2NvZGU6IDANCmRlYnVn LmtkYi50cmFwOiAwDQpkZWJ1Zy5rZGIucGFuaWM6IDANCmRlYnVnLmtkYi5lbnRlcjogMA0KZGVi dWcua2RiLmN1cnJlbnQ6IA0KZGVidWcucm1hbl9kZWJ1ZzogMA0KZGVidWcuaW9zaXplX21heF9j bGFtcDogMQ0KZGVidWcuZGlzYWJsZWZ1bGxwYXRoOiAwDQpkZWJ1Zy5kaXNhYmxlY3dkOiAwDQpk ZWJ1Zy52ZnNjYWNoZTogMQ0KZGVidWcubnVtY2FjaGVodjogMjg3MTENCmRlYnVnLm51bWNhY2hl OiAyMDM5MzANCmRlYnVnLm51bW5lZzogMTI3NDUNCmRlYnVnLm5jaGFzaDogMTA0ODU3NQ0KZGVi dWcudm5scnVfbm93aGVyZTogMA0KZGVidWcucnVzaF9yZXF1ZXN0czogMzcwMjgxDQpkZWJ1Zy5p Zl90dW5fZGVidWc6IDANCmRlYnVnLm5sbV9kZWJ1ZzogMA0KZGVidWcuZnNja2NtZHM6IDANCmRl YnVnLmNvbGxlY3RzbmFwc3RhdHM6IDANCmRlYnVnLnNuYXBkZWJ1ZzogMA0KZGVidWcuZG9wZXJz aXN0ZW5jZTogMA0KZGVidWcuc29mdGRlcC5jbGVhbnVwX2ZhaWx1cmVzOiAzNjk2MzQNCmRlYnVn LnNvZnRkZXAuY2xlYW51cF9yZXRyaWVzOiA4MjYNCmRlYnVnLnNvZnRkZXAuY2xlYW51cF9oaWdo X2RlbGF5OiAxNA0KZGVidWcuc29mdGRlcC5jbGVhbnVwX2lub3JlcXVlc3RzOiAwDQpkZWJ1Zy5z b2Z0ZGVwLmNsZWFudXBfYmxrcmVxdWVzdHM6IDM2OTY5MA0KZGVidWcuc29mdGRlcC5qd2FpdF9u ZXdibGs6IDANCmRlYnVnLnNvZnRkZXAuandhaXRfaW5vZGU6IDANCmRlYnVnLnNvZnRkZXAuandh aXRfZnJlZWJsa3M6IDANCmRlYnVnLnNvZnRkZXAuandhaXRfZmlsZXBhZ2U6IDANCmRlYnVnLnNv ZnRkZXAuam91cm5hbF93YWl0OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmpvdXJuYWxfbWluOiAwDQpkZWJ1 Zy5zb2Z0ZGVwLmpvdXJuYWxfbG93OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmpuZXdibGtfcm9sbGJhY2s6 IDANCmRlYnVnLnNvZnRkZXAuamFkZHJlZl9yb2xsYmFjazogMA0KZGVidWcuc29mdGRlcC5kaXJf ZW50cnk6IDIwMjAzMg0KZGVidWcuc29mdGRlcC5kaXJlY3RfYmxrX3B0cnM6IDM0MjY1MQ0KZGVi dWcuc29mdGRlcC5pbm9kZV9iaXRtYXA6IDI1MjgyNzQNCmRlYnVnLnNvZnRkZXAuaW5kaXJfYmxr X3B0cnM6IDI2OTM3DQpkZWJ1Zy5zb2Z0ZGVwLnN5bmNfbGltaXRfaGl0OiA1OTENCmRlYnVnLnNv ZnRkZXAuaW5vX2xpbWl0X2hpdDogMA0KZGVidWcuc29mdGRlcC5ibGtfbGltaXRfaGl0OiAzNjky MjANCmRlYnVnLnNvZnRkZXAuaW5vX2xpbWl0X3B1c2g6IDANCmRlYnVnLnNvZnRkZXAuYmxrX2xp bWl0X3B1c2g6IDM2OTY5MA0KZGVidWcuc29mdGRlcC53b3JrbGlzdF9wdXNoOiAyMTU2DQpkZWJ1 Zy5zb2Z0ZGVwLm1heGluZGlyZGVwczogNTANCmRlYnVnLnNvZnRkZXAudGlja2RlbGF5OiAyDQpk ZWJ1Zy5zb2Z0ZGVwLm1heF9zb2Z0ZGVwczogMjM1MjMwOA0KZGVidWcuc29mdGRlcC53cml0ZS5q ZnN5bmM6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuanRydW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndy aXRlLnNiZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpzZWdkZXA6IDANCmRlYnVnLnNvZnRk ZXAud3JpdGUuanNlZzogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qZnJlZWZyYWc6IDANCmRlYnVn LnNvZnRkZXAud3JpdGUuamZyZWVibGs6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuam5ld2Jsazog MA0KZGVidWcuc29mdGRlcC53cml0ZS5qbXZyZWY6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuanJl bXJlZjogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qYWRkcmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndy aXRlLmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZXdvcms6IDANCmRlYnVnLnNv ZnRkZXAud3JpdGUubmV3ZGlyYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmRpcnJlbTogMA0K ZGVidWcuc29mdGRlcC53cml0ZS5ta2RpcjogMA0KZGVidWcuc29mdGRlcC53cml0ZS5kaXJhZGQ6 IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZWZpbGU6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUu ZnJlZWJsa3M6IDY5MDk0MA0KZGVidWcuc29mdGRlcC53cml0ZS5mcmVlZnJhZzogMA0KZGVidWcu c29mdGRlcC53cml0ZS5hbGxvY2luZGlyOiAyMzM0NTM2NjU2DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRl LmluZGlyZGVwOiAxMTczNDkNCmRlYnVnLnNvZnRkZXAud3JpdGUuYWxsb2NkaXJlY3Q6IDc2OTQw MDgxDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLm5ld2JsazogMA0KZGVidWcuc29mdGRlcC53cml0ZS5i bXNhZmVtYXA6IDI0Mzc4NDUNCmRlYnVnLnNvZnRkZXAud3JpdGUuaW5vZGVkZXA6IDY5MTcxMzMN CmRlYnVnLnNvZnRkZXAud3JpdGUucGFnZWRlcDogMzI5NjU5DQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJl bnQuamZzeW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuanRydW5jOiAwDQpkZWJ1Zy5zb2Z0 ZGVwLmN1cnJlbnQuc2JkZXA6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qc2VnZGVwOiAwDQpk ZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuanNlZzogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpmcmVl ZnJhZzogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpmcmVlYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVw LmN1cnJlbnQuam5ld2JsazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmptdnJlZjogMA0KZGVi dWcuc29mdGRlcC5jdXJyZW50LmpyZW1yZWY6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qYWRk cmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZnJlZWRlcDogMA0KZGVidWcuc29mdGRlcC5j dXJyZW50LmZyZWV3b3JrOiAxMw0KZGVidWcuc29mdGRlcC5jdXJyZW50Lm5ld2RpcmJsazogMA0K ZGVidWcuc29mdGRlcC5jdXJyZW50LmRpcnJlbTogMQ0KZGVidWcuc29mdGRlcC5jdXJyZW50Lm1r ZGlyOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZGlyYWRkOiAxDQpkZWJ1Zy5zb2Z0ZGVwLmN1 cnJlbnQuZnJlZWZpbGU6IDMNCmRlYnVnLnNvZnRkZXAuY3VycmVudC5mcmVlYmxrczogMQ0KZGVi dWcuc29mdGRlcC5jdXJyZW50LmZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuYWxs b2NpbmRpcjogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmluZGlyZGVwOiAyDQpkZWJ1Zy5zb2Z0 ZGVwLmN1cnJlbnQuYWxsb2NkaXJlY3Q6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5uZXdibGs6 IDgwOQ0KZGVidWcuc29mdGRlcC5jdXJyZW50LmJtc2FmZW1hcDogNQ0KZGVidWcuc29mdGRlcC5j dXJyZW50Lmlub2RlZGVwOiA3DQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQucGFnZWRlcDogMQ0KZGVi dWcuc29mdGRlcC50b3RhbC5qZnN5bmM6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuanRydW5jOiAw DQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLnNiZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmpzZWdk ZXA6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuanNlZzogMA0KZGVidWcuc29mdGRlcC50b3RhbC5q ZnJlZWZyYWc6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuamZyZWVibGs6IDANCmRlYnVnLnNvZnRk ZXAudG90YWwuam5ld2JsazogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qbXZyZWY6IDANCmRlYnVn LnNvZnRkZXAudG90YWwuanJlbXJlZjogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qYWRkcmVmOiAw DQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuZnJl ZXdvcms6IDgzNTEyMTA5DQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLm5ld2RpcmJsazogMTg0MDMNCmRl YnVnLnNvZnRkZXAudG90YWwuZGlycmVtOiAxMzU0MTUyOA0KZGVidWcuc29mdGRlcC50b3RhbC5t a2RpcjogMjk0NTYNCmRlYnVnLnNvZnRkZXAudG90YWwuZGlyYWRkOiAxMzU0OTA4MA0KZGVidWcu c29mdGRlcC50b3RhbC5mcmVlZmlsZTogNjk0ODQ1Mg0KZGVidWcuc29mdGRlcC50b3RhbC5mcmVl YmxrczogNjg0NDkyNw0KZGVidWcuc29mdGRlcC50b3RhbC5mcmVlZnJhZzogNDQxNDY1MDI3DQpk ZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmFsbG9jaW5kaXI6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuaW5k aXJkZXA6IDY0NDkzMjINCmRlYnVnLnNvZnRkZXAudG90YWwuYWxsb2NkaXJlY3Q6IDANCmRlYnVn LnNvZnRkZXAudG90YWwubmV3YmxrOiAyODg2NDcxMDY0DQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmJt c2FmZW1hcDogOTIwODkxMA0KZGVidWcuc29mdGRlcC50b3RhbC5pbm9kZWRlcDogODA5NzcwOA0K ZGVidWcuc29mdGRlcC50b3RhbC5wYWdlZGVwOiAxNDIxMDMNCmRlYnVnLmRvYmtncmR3cml0ZTog MQ0KZGVidWcuYmlnY2dzOiAwDQpkZWJ1Zy5kaXJjaGVjazogMA0KZGVidWcucHNtLnBrdGVycnRo cmVzaDogMg0KZGVidWcucHNtLnVzZWNzOiA1MDAwMDANCmRlYnVnLnBzbS5zZWNzOiAwDQpkZWJ1 Zy5wc20uZXJydXNlY3M6IDANCmRlYnVnLnBzbS5lcnJzZWNzOiAyDQpkZWJ1Zy5wc20uaHo6IDIw DQpkZWJ1Zy5wc20ubG9nbGV2ZWw6IDANCmRlYnVnLnZlc2Euc2hhZG93X3JvbTogMA0KZGVidWcu ZmRjLnNldHRsZTogMA0KZGVidWcuZmRjLnNwZWMyOiAxNg0KZGVidWcuZmRjLnNwZWMxOiAxNzUN CmRlYnVnLmZkYy5yZXRyaWVzOiAxMA0KZGVidWcuZmRjLmRlYnVnZmxhZ3M6IDANCmRlYnVnLmZk Yy5maWZvOiA4DQpkZWJ1Zy5lbGYzMl9sZWdhY3lfY29yZWR1bXA6IDANCmRlYnVnLng4NmJpb3Mu aW50OiAwDQpkZWJ1Zy54ODZiaW9zLmNhbGw6IDANCmRlYnVnLmh3cHN0YXRlX3ZlcmJvc2U6IDAN CmRlYnVnLm1pbmlkdW1wOiAxDQorIGZzdGF0IC1mIC9wZ3NxbA0KVVNFUiAgICAgQ01EICAgICAg ICAgIFBJRCAgIEZEIE1PVU5UICAgICAgSU5VTSBNT0RFICAgICAgICAgU1p8RFYgUi9XDQpwZ3Nx bCAgICBwb3N0Z3JlcyAgIDUyMzcyICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAg ICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMzcyICAgIDYgL3Bnc3FsICAgMTEwNDYw MTQgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMzQ4ICAgd2Qg L3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3Jl cyAgIDUyMzQ4ICAgIDYgL3Bnc3FsICAgMTI2NzEwMjQgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDUyMzQ0ICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0t LSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMzQ0ICAgIDYgL3Bnc3FsICAgMTEw NDg5NjkgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMzQ0ICAg NDQgL3Bnc3FsICAgMTEwNTMyOTUgLXJ3LS0tLS0tLSAgMTY3NzcyMTYgcncNCnBnc3FsICAgIHBv c3RncmVzICAgNTIzNDMgICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIg IHINCnBnc3FsICAgIHBvc3RncmVzICAgNTIzNDMgICAgNiAvcGdzcWwgICAxMTA0ODk2OSAtcnct LS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTIzNDMgICAyMCAvcGdzcWwg ICAxMTA1MzI5NSAtcnctLS0tLS0tICAxNjc3NzIxNiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1 MjM0MiAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwg ICAgcG9zdGdyZXMgICA1MjM0MiAgICA2IC9wZ3NxbCAgIDExMDQ4OTY5IC1ydy0tLS0tLS0gICAg ODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjM0MSAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4 IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjM0MSAgICA2IC9w Z3NxbCAgIDExMDQ4OTY5IC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMg ICA1MjM0MCAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KcGdz cWwgICAgcG9zdGdyZXMgICA1MjM0MCAgICA2IC9wZ3NxbCAgIDExMDQ4OTY5IC1ydy0tLS0tLS0g ICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjMxMCAgIHdkIC9wZ3NxbCAgIDExMDQ1 ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjMxMCAgICA2 IC9wZ3NxbCAgIDExMDQ2MDE0IC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICA1MjMxMCAgIDQ5IC9wZ3NxbCAgIDExMDUzMjk1IC1ydy0tLS0tLS0gIDE2Nzc3MjE2IHJ3 DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMjgzICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0t LS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMjgzICAgIDYgL3Bnc3FsICAg MTU3ODAzMzEgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMjUy ICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBw b3N0Z3JlcyAgIDUyMjUyICAgIDYgL3Bnc3FsICAgMTEwNDYwMTQgLXJ3LS0tLS0tLSAgICA4MTky IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMjUyICAgNDkgL3Bnc3FsICAgMTEwNTMyOTUgLXJ3 LS0tLS0tLSAgMTY3NzcyMTYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTIyMjggICB3ZCAvcGdz cWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAg NTIyMjggICAgNiAvcGdzcWwgICAxMjY3MTAyNCAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3Fs ICAgIHBvc3RncmVzICAgNTIyMjQgICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAg ICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAgNTIyMjQgICAgNiAvcGdzcWwgICAxMTA0ODk2 OSAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTIyMjQgICA0NCAv cGdzcWwgICAxMTA1MzI5NSAtcnctLS0tLS0tICAxNjc3NzIxNiBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICA1MjIyMyAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0K cGdzcWwgICAgcG9zdGdyZXMgICA1MjIyMyAgICA2IC9wZ3NxbCAgIDExMDQ4OTY5IC1ydy0tLS0t LS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjIyMyAgIDY0IC9wZ3NxbCAgIDEx MDUzMjk1IC1ydy0tLS0tLS0gIDE2Nzc3MjE2IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMjIy ICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBw b3N0Z3JlcyAgIDUyMjIyICAgIDYgL3Bnc3FsICAgMTEwNDg5NjkgLXJ3LS0tLS0tLSAgICA4MTky IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMjIyICAgMjEgL3Bnc3FsICAgMTEwNTMyOTUgLXJ3 LS0tLS0tLSAgMTY3NzcyMTYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTIyMjEgICB3ZCAvcGdz cWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAg NTIyMjEgICAgNiAvcGdzcWwgICAxMTA0ODk2OSAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3Fs ICAgIHBvc3RncmVzICAgNTIyMjAgICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAg ICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAgNTIyMjAgICAgNiAvcGdzcWwgICAxMTA0ODk2 OSAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTIyMTkgICB3ZCAv cGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVz ICAgNTIyMTkgICAgNiAvcGdzcWwgICAxMTA0ODk2OSAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBn c3FsICAgIHBvc3RncmVzICAgNTIxMjIgICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0t ICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAgNTIxMjIgICAgNiAvcGdzcWwgICAxMTA0 NjAxNCAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTIxMjIgICA0 OSAvcGdzcWwgICAxMTA1MzI5NSAtcnctLS0tLS0tICAxNjc3NzIxNiBydw0KcGdzcWwgICAgcG9z dGdyZXMgICA1MjA5OCAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAg cg0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjA5OCAgICA2IC9wZ3NxbCAgIDEyNjcxMDI0IC1ydy0t LS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjA5MyAgIHdkIC9wZ3NxbCAg IDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjA5 MyAgICA2IC9wZ3NxbCAgIDExMDQ4OTY5IC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAg cG9zdGdyZXMgICA1MjA5MyAgIDQ0IC9wZ3NxbCAgIDExMDUzMjk1IC1ydy0tLS0tLS0gIDE2Nzc3 MjE2IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMDkxICAgd2QgL3Bnc3FsICAgMTEwNDU4ODgg ZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyMDkxICAgIDYgL3Bn c3FsICAgMTEwNDg5NjkgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAg IDUyMDkxICAgMjEgL3Bnc3FsICAgMTEwNTMyOTUgLXJ3LS0tLS0tLSAgMTY3NzcyMTYgcncNCnBn c3FsICAgIHBvc3RncmVzICAgNTIwMzAgICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0t ICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAgNTIwMzAgICAgNiAvcGdzcWwgICAxNTc4 MDMzMSAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTE5MjMgICB3 ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3Rn cmVzICAgNTE5MjMgICAgNiAvcGdzcWwgICAxMTA0NjAxNCAtcnctLS0tLS0tICAgIDgxOTIgcncN CnBnc3FsICAgIHBvc3RncmVzICAgNTE5MjMgICA0OSAvcGdzcWwgICAxMTA1MzI5NSAtcnctLS0t LS0tICAxNjc3NzIxNiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MTc2NiAgIHdkIC9wZ3NxbCAg IDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwgICAgcG9zdGdyZXMgICA1MTc2 NiAgICA2IC9wZ3NxbCAgIDE1NzgwMzMxIC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAg cG9zdGdyZXMgICA2OTg4MSAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUx MiAgcg0KcGdzcWwgICAgcG9zdGdyZXMgICA2OTg4MSAgICA2IC9wZ3NxbCAgIDExMDQ4OTY5IC1y dy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA2OTg4MSAgIDEyIC9wZ3Nx bCAgIDExMDUzMTgyIC1ydy0tLS0tLS0gIDE2Nzc3MjE2IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAg IDY5ODgxICAgMTMgL3Bnc3FsICAgMTEwNDg5NjYgLXJ3LS0tLS0tLSAgNzYxODU2IHJ3DQpwZ3Nx bCAgICBwb3N0Z3JlcyAgIDY5ODgxICAgMTQgL3Bnc3FsICAgMTEwNDg5OTQgLXJ3LS0tLS0tLSAg MTE0Njg4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDY5ODgxICAgMTUgL3Bnc3FsICAgMTEwNDkw MjAgLXJ3LS0tLS0tLSAgMjk0OTEyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDY5ODgxICAgMTYg L3Bnc3FsICAgMTEwNDg5NzYgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3Jl cyAgIDY5ODgxICAgMTcgL3Bnc3FsICAgMTEwNDkwNDkgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDY5ODgxICAgMTggL3Bnc3FsICAgMTEwNDkwNTAgLXJ3LS0tLS0t LSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDY5ODgxICAgMTkgL3Bnc3FsICAgMTEw NDYxMTAgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDY5ODgxICAg MjAgL3Bnc3FsICAgMTEwNDYxNTYgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDY5ODgxICAgMjEgL3Bnc3FsICAgMTEwNDYyNDggLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3 DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0t LS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMTIgL3Bnc3FsICAg MTU3ODAzMzEgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4 ICAgMTMgL3Bnc3FsICAgMTU3ODAzMjkgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBw b3N0Z3JlcyAgIDEzMDE4ICAgMTQgL3Bnc3FsICAgMTU3ODAzNDkgLXJ3LS0tLS0tLSAgIDI0NTc2 IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMTUgL3Bnc3FsICAgMTU3ODAzOTcgLXJ3 LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMTYgL3Bnc3Fs ICAgMTU3ODAyOTMgLXJ3LS0tLS0tLSAgIDMyNzY4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEz MDE4ICAgMTcgL3Bnc3FsICAgMTU3ODAzNTYgLXJ3LS0tLS0tLSAgMTU1NjQ4IHJ3DQpwZ3NxbCAg ICBwb3N0Z3JlcyAgIDEzMDE4ICAgMTggL3Bnc3FsICAgMTU3ODAzNzggLXJ3LS0tLS0tLSAgOTAx MTIwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMTkgL3Bnc3FsICAgMTU3ODAzOTUg LXJ3LS0tLS0tLSAgIDgxOTIwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMjMgL3Bn c3FsICAgMTU3ODAyOTUgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAg IDEzMDE4ICAgMjQgL3Bnc3FsICAgMTU3ODAzNDggLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3Nx bCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMjUgL3Bnc3FsICAgMTU3ODA0MDEgLXJ3LS0tLS0tLSAg IDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMjYgL3Bnc3FsICAgMTU3ODAz NzIgLXJ3LS0tLS0tLSAgMjg2NzIwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMjgg L3Bnc3FsICAgMTU3ODAzNTMgLXJ3LS0tLS0tLSAgMTMxMDcyIHJ3DQpwZ3NxbCAgICBwb3N0Z3Jl cyAgIDEzMDE4ICAgMjkgL3Bnc3FsICAgMTU3ODAzODEgLXJ3LS0tLS0tLSAgMjcwMzM2IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMzEgL3Bnc3FsICAgMTU3ODAzODAgLXJ3LS0tLS0t LSAgIDgxOTIwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAgMzIgL3Bnc3FsICAgMTU3 ODAzOTQgLXJ3LS0tLS0tLSAgIDkwMTEyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE4ICAg MzQgL3Bnc3FsICAgMTU3ODAzNjUgLXJ3LS0tLS0tLSAgMTcxMjEyOCBydw0KcGdzcWwgICAgcG9z dGdyZXMgICAxMzAxOCAgIDM3IC9wZ3NxbCAgIDE1NzgwNDE1IC1ydy0tLS0tLS0gIDE0MjU0MDgg cncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTggICAzOSAtICAgICAgICAxMTA1MzMwNCAtcnct LS0tLS0tICAxNjc3NzIxNiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDQwIC9wZ3Nx bCAgIDE1NzgwMzgyIC1ydy0tLS0tLS0gIDM2ODY0MCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAx MzAxOCAgIDQxIC9wZ3NxbCAgIDE1NzgwNDA1IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwg ICAgcG9zdGdyZXMgICAxMzAxOCAgIDQyIC9wZ3NxbCAgIDE1NzgwMzUxIC1ydy0tLS0tLS0gIDEz MTA3MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDQzIC9wZ3NxbCAgIDE1NzgwNDAz IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDQ0IC9w Z3NxbCAgIDE1NzgwMjk2IC1ydy0tLS0tLS0gIDQ1ODc1MiBydw0KcGdzcWwgICAgcG9zdGdyZXMg ICAxMzAxOCAgIDQ1IC9wZ3NxbCAgIDE1NzgwMzk2IC1ydy0tLS0tLS0gICA0MDk2MCBydw0KcGdz cWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDQ2IC9wZ3NxbCAgIDE1NzgwMzM3IC1ydy0tLS0tLS0g IDExNDY4OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDQ3IC9wZ3NxbCAgIDE1Nzgw MzA3IC1ydy0tLS0tLS0gICAzMjc2OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDQ4 IC9wZ3NxbCAgIDExMDQ2MTEwIC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICAxMzAxOCAgIDQ5IC9wZ3NxbCAgIDExMDQ2MTU2IC1ydy0tLS0tLS0gICAxNjM4NCBydw0K cGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDUwIC9wZ3NxbCAgIDExMDQ2MjQ4IC1ydy0tLS0t LS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDUxIC9wZ3NxbCAgIDE1 NzgwMzk5IC1ydy0tLS0tLS0gICAzMjc2OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAg IDUyIC9wZ3NxbCAgIDE1NzgwMzUwIC1ydy0tLS0tLS0gICAzMjc2OCBydw0KcGdzcWwgICAgcG9z dGdyZXMgICAxMzAxOCAgIDUzIC9wZ3NxbCAgIDE1NzgwMzc2IC1ydy0tLS0tLS0gIDIyOTM3NiBy dw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDU1IC9wZ3NxbCAgIDE1NzgwMjkyIC1ydy0t LS0tLS0gICAzMjc2OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxOCAgIDU2IC9wZ3NxbCAg IDE1NzgwMzcxIC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAx OCAgIDU3IC9wZ3NxbCAgIDE1NzgwMzM5IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAg cG9zdGdyZXMgICAxMzAxNiAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUx MiAgcg0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxNiAgICA2IC9wZ3NxbCAgIDExMDQ2MTE2IC1y dy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxNiAgIDEwIC9wZ3Nx bCAgIDExMDQ2MTk4IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAx MzAxNiAgIDExIC9wZ3NxbCAgIDExMDQ2NjE1IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwg ICAgcG9zdGdyZXMgICAxMzAxNiAgIDEyIC9wZ3NxbCAgIDExMDQ2MDExIC1ydy0tLS0tLS0gIDc5 NDYyNCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxNiAgIDEzIC9wZ3NxbCAgIDExMDQ1OTk5 IC1ydy0tLS0tLS0gIDQxODYxMTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAxNCAv cGdzcWwgICAxMTA0NjAxOSAtcnctLS0tLS0tICAzOTMyMTYgcncNCnBnc3FsICAgIHBvc3RncmVz ICAgMTMwMTYgICAxNSAvcGdzcWwgICAxMTA0NjAxNCAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBn c3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAxNiAvcGdzcWwgICAxMTA0NjAxMiAtcnctLS0tLS0t ICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAxNyAvcGdzcWwgICAxMTA0 NjAzMiAtcnctLS0tLS0tICAgMjQ1NzYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAx OCAvcGdzcWwgICAxMTA0NjA3OCAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3Rn cmVzICAgMTMwMTYgICAxOSAvcGdzcWwgICAxMTA0NTk0NCAtcnctLS0tLS0tICAgMzI3NjggcncN CnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAyMCAvcGdzcWwgICAxMTA0NjAzOSAtcnctLS0t LS0tICAxMzEwNzIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAyMSAvcGdzcWwgICAx MTA0NjA1OSAtcnctLS0tLS0tICA3MjA4OTYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYg ICAyMiAvcGdzcWwgICAxMTA0NjA3NiAtcnctLS0tLS0tICAgNjU1MzYgcncNCnBnc3FsICAgIHBv c3RncmVzICAgMTMwMTYgICAyMyAvcGdzcWwgICAxMTA0NjA5MiAtcnctLS0tLS0tICAgMTYzODQg cncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAyNCAvcGdzcWwgICAxMTA0NjAyMSAtcnct LS0tLS0tICAgMjQ1NzYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAyNSAvcGdzcWwg ICAxMTA0NjA5MyAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMw MTYgICAyNiAvcGdzcWwgICAxMTA0NTk2OCAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAg IHBvc3RncmVzICAgMTMwMTYgICAyNyAvcGdzcWwgICAxMTA0NjAzMSAtcnctLS0tLS0tICAgIDgx OTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAyOCAvcGdzcWwgICAxMTA0NjA4MiAt cnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAyOSAvcGdz cWwgICAxMTA0NjA1MyAtcnctLS0tLS0tICAyNzAzMzYgcncNCnBnc3FsICAgIHBvc3RncmVzICAg MTMwMTYgICAzMCAvcGdzcWwgICAxMTA0NjAwOSAtcnctLS0tLS0tICA2NDcxNjggcncNCnBnc3Fs ICAgIHBvc3RncmVzICAgMTMwMTYgICAzMSAvcGdzcWwgICAxMTA0NjAzNiAtcnctLS0tLS0tICAx MDY0OTYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAzMiAvcGdzcWwgICAxMTA0NjA2 MiAtcnctLS0tLS0tICAyNzAzMzYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAzNCAv cGdzcWwgICAxMTA0NjA2MSAtcnctLS0tLS0tICAgODE5MjAgcncNCnBnc3FsICAgIHBvc3RncmVz ICAgMTMwMTYgICAzNSAvcGdzcWwgICAxMTA0NjA3NSAtcnctLS0tLS0tICAgODE5MjAgcncNCnBn c3FsICAgIHBvc3RncmVzICAgMTMwMTYgICAzNyAvcGdzcWwgICAxMTA0NjA0OCAtcnctLS0tLS0t ICAxNDMzNjAwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNDAgL3Bnc3FsICAgMTEw NDYwOTYgLXJ3LS0tLS0tLSAgMTE3OTY0OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAxNiAg IDQyIC0gICAgICAgIDExMDUzMzA0IC1ydy0tLS0tLS0gIDE2Nzc3MjE2IHJ3DQpwZ3NxbCAgICBw b3N0Z3JlcyAgIDEzMDE2ICAgNDMgL3Bnc3FsICAgMTEwNDYwNjMgLXJ3LS0tLS0tLSAgMzM1ODcy IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNDQgL3Bnc3FsICAgMTEwNDYwODYgLXJ3 LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNDUgL3Bnc3Fs ICAgMTEwNDYwMzQgLXJ3LS0tLS0tLSAgMTMxMDcyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEz MDE2ICAgNDYgL3Bnc3FsICAgMTEwNDYwODQgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAg ICBwb3N0Z3JlcyAgIDEzMDE2ICAgNDcgL3Bnc3FsICAgMTEwNDU5NzQgLXJ3LS0tLS0tLSAgNDU4 NzUyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNDggL3Bnc3FsICAgMTEwNDYwNzcg LXJ3LS0tLS0tLSAgIDQwOTYwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNDkgL3Bn c3FsICAgMTEwNDYwMjAgLXJ3LS0tLS0tLSAgMTE0Njg4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAg IDEzMDE2ICAgNTAgL3Bnc3FsICAgMTEwNDU5OTAgLXJ3LS0tLS0tLSAgIDMyNzY4IHJ3DQpwZ3Nx bCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNTEgL3Bnc3FsICAgMTEwNDYxMTAgLXJ3LS0tLS0tLSAg ICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNTIgL3Bnc3FsICAgMTEwNDYx NTYgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNTMg L3Bnc3FsICAgMTEwNDYyNDggLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3Jl cyAgIDEzMDE2ICAgNTQgL3Bnc3FsICAgMTEwNDYwODAgLXJ3LS0tLS0tLSAgIDMyNzY4IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNTUgL3Bnc3FsICAgMTEwNDYwMzMgLXJ3LS0tLS0t LSAgIDMyNzY4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNTYgL3Bnc3FsICAgMTEw NDYwNTcgLXJ3LS0tLS0tLSAgMjIxMTg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAg NTggL3Bnc3FsICAgMTEwNDU5MzkgLXJ3LS0tLS0tLSAgIDMyNzY4IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDEzMDE2ICAgNTkgL3Bnc3FsICAgMTEwNDYwNTIgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3 DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE2ICAgNjAgL3Bnc3FsICAgMTEwNDYwMjIgLXJ3LS0t LS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDE0ICAgd2QgL3Bnc3FsICAg MTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDEz ICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBw b3N0Z3JlcyAgIDEzMDEzICAgIDggL3Bnc3FsICAgMTEwNDY2MTQgLXJ3LS0tLS0tLSAgICA4MTky IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDEyICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3 eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEzMDEyICAgIDYgL3Bnc3Fs ICAgMTEwNTMyOTUgLXJ3LS0tLS0tLSAgMTY3NzcyMTYgcncNCnBnc3FsICAgIHBvc3RncmVzICAg MTMwMTEgICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3Fs ICAgIHBvc3RncmVzICAgMTMwMTAgICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAg ICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAgMTMwMTAgICAgOSAvcGdzcWwgICAxMTA1MzI5 NSAtcnctLS0tLS0tICAxNjc3NzIxNiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMzAwNiAgIHdk IC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KKyBzeXNjdGwgLWENCisg ZWdyZXAgdm5vZGUNCmtlcm4ubWF4dm5vZGVzOiA1ODgwNzcNCmtlcm4ubWludm5vZGVzOiAxNDcw MTkNCnZtLnN0YXRzLnZtLnZfdm5vZGVwZ3NvdXQ6IDANCnZtLnN0YXRzLnZtLnZfdm5vZGVwZ3Np bjogNTIxODANCnZtLnN0YXRzLnZtLnZfdm5vZGVvdXQ6IDANCnZtLnN0YXRzLnZtLnZfdm5vZGVp bjogMjE5MTMNCnZmcy5mcmVldm5vZGVzOiAxNDY4MjINCnZmcy53YW50ZnJlZXZub2RlczogMTQ3 MDE5DQp2ZnMubnVtdm5vZGVzOiAxODk5NTcNCmRlYnVnLnNpemVvZi52bm9kZTogNDgwDQorIG1v dW50IC12DQovZGV2L2RhMHMxYSBvbiAvICh1ZnMsIGxvY2FsLCB3cml0ZXM6IHN5bmMgMzg4IGFz eW5jIDE2MSwgcmVhZHM6IHN5bmMgMjk2NTggYXN5bmMgMjA5NiwgZnNpZCA2Y2ExNzE0YjY3YTBl MmU2KQ0KZGV2ZnMgb24gL2RldiAoZGV2ZnMsIGxvY2FsLCBtdWx0aWxhYmVsLCBmc2lkIDAwZmYw MDcxNzEwMDAwMDApDQovZGV2L2RhMXMxIG9uIC9vcHQgKHVmcywgbG9jYWwsIHNvZnQtdXBkYXRl cywgd3JpdGVzOiBzeW5jIDQyMDQxOCBhc3luYyAxNTExNDg5NSwgcmVhZHM6IHN5bmMgMTc2ODc0 ODI2IGFzeW5jIDE0NDIwMDQ3NCwgZnNpZCAzMDMxODU1MGY1Njc5ZTg2KQ0KL2Rldi9kYTBzMWUg b24gL3RtcCAodWZzLCBsb2NhbCwgc29mdC11cGRhdGVzLCB3cml0ZXM6IHN5bmMgNDIgYXN5bmMg MTU0NTAsIHJlYWRzOiBzeW5jIDUyODAgYXN5bmMgMCwgZnNpZCA2Y2ExNzE0YjAxMWNmZTFjKQ0K L2Rldi9kYTBzMWYgb24gL3VzciAodWZzLCBsb2NhbCwgc29mdC11cGRhdGVzLCB3cml0ZXM6IHN5 bmMgMTU0NCBhc3luYyAyMTQ0NDY5LCByZWFkczogc3luYyAxMzUyOTYxMCBhc3luYyA3NDExLCBm c2lkIDZjYTE3MTRiN2E1Y2I2MTUpDQovZGV2L2RhMHMxZCBvbiAvdmFyICh1ZnMsIGxvY2FsLCBz b2Z0LXVwZGF0ZXMsIHdyaXRlczogc3luYyAxMDYyOSBhc3luYyAxMzMxNzg4LCByZWFkczogc3lu YyAyNzE0MTYgYXN5bmMgMjQ4ODEsIGZzaWQgNmRhMTcxNGJlOTEzM2JmYSkNCnByb2NmcyBvbiAv cHJvYyAocHJvY2ZzLCBsb2NhbCwgZnNpZCAwMWZmMDAwMjAyMDAwMDAwKQ0KL2Rldi9kYTJzMWQg b24gL3Bnc3FsICh1ZnMsIGxvY2FsLCBzb2Z0LXVwZGF0ZXMsIHdyaXRlczogc3luYyA5NDQyNCBh c3luYyAxMTcwNDgyNiwgcmVhZHM6IHN5bmMgMjExOTUwMSBhc3luYyAxNzY3NzI5LCBmc2lkIDZj YTE3MTRiYmUwYjhjNGQpDQojIHNlcnZpY2UgcG9zdGdyZXNxbCBzdG9wDQojIHVtb3VudCAvcGdz cWwNCnVtb3VudDogdW5tb3VudCBvZiAvcGdzcWwgZmFpbGVkOiBEZXZpY2UgYnVzeQ0KIyBmc3Rh dCB8IGdyZSAIcCBwZ3NxbA0KIyB1bW91bnQgLWEgL3Bnc3FsCAgICAgICAgbW1AgCBtbNGhmG1s0 bCAIDQojIHR1bmVmcyAtbiBkaXNhYmxlIC9wZ3NxbA0KdHVuZWZzOiBzb2Z0IHVwZGF0ZXMgY2xl YXJlZA0KIyBtb3VudCAvcGdzcQgbW0sIG1tLCBtbSwgbW0sIG1tLCAgbW0sIG1tLCBtbSwgbW0sI G1tLBwcHB3R1bmVmcyAtbiBkaXNhYmxlIC9wZ3NxbBtbMjREG1s4UHVtb3VudCAtZhtbN0MbWzE2 RBtbNGhmcxtbNGx0YXQgfCBncmVwIBtbNUMbWzE4RBtbMlB1bW91bnQgLWYgLxtbNUMbWzE2RBtb NGh0dW5lZnMgLRtbNGxuIGRpc2FibGUbWzdDG1syNEQbW0sHBwcHB3NoIC14IGRpc2tzcGFjZWNo ZWNrLnNoIA0KKyBkZiAtaWggL3Bnc3FsDQpGaWxlc3lzdGVtICAgICBTaXplICAgIFVzZWQgICBB dmFpbCBDYXBhY2l0eSBpdXNlZCBpZnJlZSAlaXVzZWQgIE1vdW50ZWQgb24NCi9kZXYvZGEwczFh ICAgIDQ5NU0gICAgMzU0TSAgICAxMDFNICAgIDc4JSAgICAyLjBrICAgNjNrICAgIDMlICAgLw0K KyB2bXN0YXQgLXoNCklURU0gICAgICAgICAgICAgICAgICAgU0laRSAgTElNSVQgICAgIFVTRUQg ICAgIEZSRUUgICAgICBSRVEgRkFJTCBTTEVFUA0KDQpVTUEgS2VnczogICAgICAgICAgICAgICAy MDgsICAgICAgMCwgICAgICA4NiwgICAgICAxNiwgICAgICA4NiwgICAwLCAgIDANClVNQSBab25l czogICAgICAgICAgICAgMTQwOCwgICAgICAwLCAgICAgIDg2LCAgICAgICAwLCAgICAgIDg2LCAg IDAsICAgMA0KVU1BIFNsYWJzOiAgICAgICAgICAgICAgNTY4LCAgICAgIDAsICAgIDY4MDksICAg ICA1MDYsICA2Mjg0NDUsICAgMCwgICAwDQpVTUEgUkNudFNsYWJzOiAgICAgICAgICA1NjgsICAg ICAgMCwgICAgNDU5MSwgICAgIDU3NSwgIDM5Mjg2OSwgICAwLCAgIDANClVNQSBIYXNoOiAgICAg ICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAzLCAgIDAsICAg MA0KMTYgQnVja2V0OiAgICAgICAgICAgICAgMTUyLCAgICAgIDAsICAgICAgMjcsICAgICAgNzMs ICAgICAyMTEsICAgMCwgICAwDQozMiBCdWNrZXQ6ICAgICAgICAgICAgICAyODAsICAgICAgMCwg ICAgICA0NywgICAgIDE0OSwgICAgIDMzOSwgICA2LCAgIDANCjY0IEJ1Y2tldDogICAgICAgICAg ICAgIDUzNiwgICAgICAwLCAgICAgIDc4LCAgICAgIDc2LCAgICAgNzUyLCAgOTAsICAgMA0KMTI4 IEJ1Y2tldDogICAgICAgICAgICAxMDQ4LCAgICAgIDAsICAgIDE4MDQsICAgICAgIDIsIDE1NTcy MjQsMTUzNDk5NjksICAgMA0KVk0gT0JKRUNUOiAgICAgICAgICAgICAgMjMyLCAgICAgIDAsICAx NTQ5MjMsICAgMzExMDksMTQxOTQzMzEwLCAgIDAsICAgMA0KTUFQOiAgICAgICAgICAgICAgICAg ICAgMjMyLCAgICAgIDAsICAgICAgIDcsICAgICAgMjUsICAgICAgIDcsICAgMCwgICAwDQpLTUFQ IEVOVFJZOiAgICAgICAgICAgICAxMjAsIDExMjg3MTAsICAgMTMwNjIsICAgMzgxNTAsMTc5Mzc2 OTMzMiwgICAwLCAgIDANCk1BUCBFTlRSWTogICAgICAgICAgICAgIDEyMCwgICAgICAwLCAgICAg ODQ2LCAgICA0OTIwLDMwMTk1MDk4MSwgICAwLCAgIDANCmZha2VwZzogICAgICAgICAgICAgICAg IDEyMCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KbXRfem9u ZTogICAgICAgICAgICAgICA0MTEyLCAgICAgIDAsICAgICAzMjYsICAgICAgIDEsICAgICAzMjYs ICAgMCwgICAwDQoxNjogICAgICAgICAgICAgICAgICAgICAgMTYsICAgICAgMCwgICAgMjMxOCwg ICAgMjA1MCwxNTE4MjYxOCwgICAwLCAgIDANCjMyOiAgICAgICAgICAgICAgICAgICAgICAzMiwg ICAgICAwLCAgICAyNzc0LCAgICAxNjcwLDUwMTk5Nzk1LCAgIDAsICAgMA0KNjQ6ICAgICAgICAg ICAgICAgICAgICAgIDY0LCAgICAgIDAsICAgIDUzMTUsICAgIDQzMTcsODMwODM0NzksICAgMCwg ICAwDQoxMjg6ICAgICAgICAgICAgICAgICAgICAxMjgsICAgICAgMCwgICAgOTg0MSwgICAgNDc0 Niw2ODk1MTQ5NjYsICAgMCwgICAwDQoyNTY6ICAgICAgICAgICAgICAgICAgICAyNTYsICAgICAg MCwgICAgIDU2MiwgICAzMzQ4OCwyOTIwMjUwODU5LCAgIDAsICAgMA0KNTEyOiAgICAgICAgICAg ICAgICAgICAgNTEyLCAgICAgIDAsICAgIDI3MzcsICAgIDIzOTQsMTgxMzAxNjEsICAgMCwgICAw DQoxMDI0OiAgICAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgICA1NCwgICAgMTMzOCwg MjIwNDU0OCwgICAwLCAgIDANCjIwNDg6ICAgICAgICAgICAgICAgICAgMjA0OCwgICAgICAwLCAg ICA1NjI4LCAgICAxMjc0LCA0MTM1NDgzLCAgIDAsICAgMA0KNDA5NjogICAgICAgICAgICAgICAg ICA0MDk2LCAgICAgIDAsICAgICA0MjgsICAgIDExNzIsIDUzMjcyMDMsICAgMCwgICAwDQpGaWxl czogICAgICAgICAgICAgICAgICAgODAsICAgICAgMCwgICAgICA5NCwgICAxMTExMSwxOTkyMTIz MzUsICAgMCwgICAwDQpUVVJOU1RJTEU6ICAgICAgICAgICAgICAxMzYsICAgICAgMCwgICAgMTkz OSwgICAgIDEyMSwgICAgMTk0OCwgICAwLCAgIDANCnVtdHggcGk6ICAgICAgICAgICAgICAgICA5 NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KTUFDIGxhYmVs czogICAgICAgICAgICAgIDQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwDQpQUk9DOiAgICAgICAgICAgICAgICAgIDExODQsICAgICAgMCwgICAgICA0OSwgICAg MTQzNiwgNDU0NjQ0OSwgICAwLCAgIDANClRIUkVBRDogICAgICAgICAgICAgICAgMTEyOCwgICAg ICAwLCAgICAxNTQ5LCAgICAgMzg5LCAgICAxOTYzLCAgIDAsICAgMA0KU0xFRVBRVUVVRTogICAg ICAgICAgICAgIDgwLCAgICAgIDAsICAgIDE5MzksICAgICAyNjUsICAgIDE5NDgsICAgMCwgICAw DQpWTVNQQUNFOiAgICAgICAgICAgICAgICAzOTIsICAgICAgMCwgICAgICAzMCwgICAgMTU2MCwg NDU0NjQzMiwgICAwLCAgIDANCmNwdXNldDogICAgICAgICAgICAgICAgICA3MiwgICAgICAwLCAg ICAgIDg1LCAgICAgIDY1LCAgICAgIDg1LCAgIDAsICAgMA0KYXVkaXRfcmVjb3JkOiAgICAgICAg ICAgOTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQptYnVm X3BhY2tldDogICAgICAgICAgICAyNTYsICAgICAgMCwgICAgNDA4MSwgICAgMTY3OSw2OTc4MDM4 MjQsICAgMCwgICAwDQptYnVmOiAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgMTAy MiwgICAgMTcyMywxOTYyODI0OTc4LCAgIDAsICAgMA0KbWJ1Zl9jbHVzdGVyOiAgICAgICAgICAy MDQ4LCAgMjU2MDAsICAgIDU3NjAsICAgIDEyNTQsIDE3MDg1NDQsICAgMCwgICAwDQptYnVmX2p1 bWJvX3BhZ2U6ICAgICAgIDQwOTYsICAxMjgwMCwgICAgICAgMCwgICAgMTA4NCw4MzUwNTI4OSwg ICAwLCAgIDANCm1idWZfanVtYm9fOWs6ICAgICAgICAgOTIxNiwgICA2NDAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KbWJ1Zl9qdW1ib18xNms6ICAgICAgIDE2Mzg0LCAg IDMyMDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQptYnVmX2V4dF9yZWZj bnQ6ICAgICAgICAgIDQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDANCmdfYmlvOiAgICAgICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgICAgICAwLCAgICAxNTg0 LDI5Nzc4NDM0NDcsICAgMCwgICAwDQp0dHlpbnE6ICAgICAgICAgICAgICAgICAxNjAsICAgICAg MCwgICAgIDE1MCwgICAgIDQ3NCwgICAgMjYyNSwgICAwLCAgIDANCnR0eW91dHE6ICAgICAgICAg ICAgICAgIDI1NiwgICAgICAwLCAgICAgIDgwLCAgICAgMzQwLCAgICAxNDAwLCAgIDAsICAgMA0K YXRhX3JlcXVlc3Q6ICAgICAgICAgICAgMzI4LCAgICAgIDAsICAgICAgIDAsICAgICAgODQsICAg ICAgMzIsICAgMCwgICAwDQphdGFfY29tcG9zaXRlOiAgICAgICAgICAzMzYsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANClZOT0RFOiAgICAgICAgICAgICAgICAg IDQ4MCwgICAgICAwLCAgMTY5NTIwLCAgIDk1ODgwLDE1ODk3Nzc4NSwgICAwLCAgIDANClZOT0RF UE9MTDogICAgICAgICAgICAgIDExMiwgICAgICAwLCAgICAgICAwLCAgICAgMTMyLCAgICAgICA2 LCAgIDAsICAgMA0KTkFNRUk6ICAgICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAgICAgIDAs ICAgIDEyMTIsNDMyMzc3NDcyLCAgIDAsICAgMA0KUyBWRlMgQ2FjaGU6ICAgICAgICAgICAgMTA4 LCAgICAgIDAsICAxNzA0MzIsICAxMDczOTUsMTYzMzA4MzY2LCAgIDAsICAgMA0KU1RTIFZGUyBD YWNoZTogICAgICAgICAgMTQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwDQpMIFZGUyBDYWNoZTogICAgICAgICAgICAzMjgsICAgICAgMCwgICAxMjUwNiwgICAg NDIxMCwgNzYyMjgyMiwgICAwLCAgIDANCkxUUyBWRlMgQ2FjaGU6ICAgICAgICAgIDM2OCwgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KTkNMTk9ERTogICAgICAg ICAgICAgICAgNTY4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw DQpESVJIQVNIOiAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgICA5MCwgICAgIDk1OCwg MzA4NTI5NSwgICAwLCAgIDANCk1vdW50cG9pbnRzOiAgICAgICAgICAgIDc5MiwgICAgICAwLCAg ICAgICA3LCAgICAgIDMzLCAgICAgICA5LCAgIDAsICAgMA0KcGlwZTogICAgICAgICAgICAgICAg ICAgNzI4LCAgICAgIDAsICAgICAgIDMsICAgIDEzMjcsIDM5NzU2ODcsICAgMCwgICAwDQprc2ln aW5mbzogICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAgMTQ3NCwgICAgMTQzMCwxMDExNDA0 OCwgICAwLCAgIDANCml0aW1lcjogICAgICAgICAgICAgICAgIDM0NCwgICAgICAwLCAgICAgICAx LCAgICAgIDIxLCAgICAgICAxLCAgIDAsICAgMA0KS05PVEU6ICAgICAgICAgICAgICAgICAgMTI4 LCAgICAgIDAsICAgICAgIDAsICAgIDE3MTEsIDExMTQ5NDcsICAgMCwgICAwDQpzb2NrZXQ6ICAg ICAgICAgICAgICAgICA2ODAsIDEwMDAwMiwgICAgICAzMSwgICAgMTQyNywgOTYzNDI0MywgICAw LCAgIDANCmlwcTogICAgICAgICAgICAgICAgICAgICA1NiwgICAgODE5LCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMA0KdWRwX2lucGNiOiAgICAgICAgICAgICAgMzkyLCAxMDAw MDAsICAgICAgMTIsICAgIDE1NDgsIDc1NjE3MDIsICAgMCwgICAwDQp1ZHBjYjogICAgICAgICAg ICAgICAgICAgMTYsIDEwMDEyOCwgICAgICAxMiwgICAgMTgzNiwgNzU2MTcwMiwgICAwLCAgIDAN CnRjcF9pbnBjYjogICAgICAgICAgICAgIDM5MiwgMTAwMDAwLCAgICAgICA4LCAgICAxNzUyLCAg NjYzNDE1LCAgIDAsICAgMA0KdGNwY2I6ICAgICAgICAgICAgICAgICAgOTc2LCAxMDAwMDAsICAg ICAgIDgsICAgIDE3NjQsICA2NjM0MTUsICAgMCwgICAwDQp0Y3B0dzogICAgICAgICAgICAgICAg ICAgNzIsICAyMDAwMCwgICAgICAgMCwgICAgIDU1MCwgICAgMzI4NywgICAwLCAgIDANCnN5bmNh Y2hlOiAgICAgICAgICAgICAgIDE1MiwgIDE1Mzc1LCAgICAgICAwLCAgICAgNjI1LCAgNTE0NjYz LCAgIDAsICAgMA0KaG9zdGNhY2hlOiAgICAgICAgICAgICAgMTM2LCAgMTUzNzIsICAgICAgIDUs ICAgICA0OTksICAgIDE4NzksICAgMCwgICAwDQp0Y3ByZWFzczogICAgICAgICAgICAgICAgNDAs ICAgMTY4MCwgICAgICAgMCwgICAgMTU5NiwgICAyMTc2MiwgICAwLCAgIDANCnNhY2tob2xlOiAg ICAgICAgICAgICAgICAzMiwgICAgICAwLCAgICAgICAwLCAgICAgOTA5LCAgICAgODg1LCAgIDAs ICAgMA0Kc2N0cF9lcDogICAgICAgICAgICAgICAxMzc2LCAxMDAwMDAsICAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgMCwgICAwDQpzY3RwX2Fzb2M6ICAgICAgICAgICAgIDIyODgsICA0MDAw MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfbGFkZHI6ICAgICAg ICAgICAgICA0OCwgIDgwMDY0LCAgICAgICAwLCAgICAgMjg4LCAgICAgICA2LCAgIDAsICAgMA0K c2N0cF9yYWRkcjogICAgICAgICAgICAgNzA0LCAgODAwMDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwDQpzY3RwX2NodW5rOiAgICAgICAgICAgICAxMzYsIDQwMDAwOCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfcmVhZHE6ICAgICAgICAgICAg IDEwNCwgNDAwMDMyLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0Kc2N0cF9z dHJlYW1fbXNnX291dDogICAgMTEyLCA0MDAwMjYsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwDQpzY3RwX2FzY29uZjogICAgICAgICAgICAgNDAsIDQwMDAwOCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfYXNjb25mX2FjazogICAgICAgICA0OCwg NDAwMDMyLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KcmlwY2I6ICAgICAg ICAgICAgICAgICAgMzkyLCAxMDAwMDAsICAgICAgIDAsICAgICAxMDAsICAgICAxMjYsICAgMCwg ICAwDQp1bnBjYjogICAgICAgICAgICAgICAgICAyNDAsIDEwMDAwMCwgICAgICAxMCwgICAgMTMx OCwgMTQwODk5NCwgICAwLCAgIDANCnJ0ZW50cnk6ICAgICAgICAgICAgICAgIDIwMCwgICAgICAw LCAgICAgIDIzLCAgICAgIDkxLCAgICAgIDIzLCAgIDAsICAgMA0Kc2VsZmQ6ICAgICAgICAgICAg ICAgICAgIDU2LCAgICAgIDAsICAgIDE5OTMsICAgIDEzNDYsMzA5Mzg1NDA4LCAgIDAsICAgMA0K U1dBUE1FVEE6ICAgICAgICAgICAgICAgMjg4LCAxMTY1MTksICAgICAgNDAsICAgICA1NTgsIDEw NzIxMjAsICAgMCwgICAwDQpGRlMgaW5vZGU6ICAgICAgICAgICAgICAxNjgsICAgICAgMCwgIDE2 NTMxNSwgICA5ODE1NywxNTg5NzU0NTQsICAgMCwgICAwDQpGRlMxIGRpbm9kZTogICAgICAgICAg ICAxMjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCkZGUzIg ZGlub2RlOiAgICAgICAgICAgIDI1NiwgICAgICAwLCAgMTY1MzE1LCAgIDk3OTgwLDE1ODk3NTQ0 NywgICAwLCAgIDANCg0KKyB2bXN0YXQgLW0NCiAgICAgICAgIFR5cGUgSW5Vc2UgTWVtVXNlIEhp Z2hVc2UgUmVxdWVzdHMgIFNpemUocykNCkNBTSBkZXYgcXVldWUgICAgIDQgICAgIDFLICAgICAg IC0gICAgICAgIDQgIDEyOA0KICBtZF9zaWlfZGF0YSAgICAgMCAgICAgMEsgICAgICAgLSAgICAg ICA1MCAgNTEyDQogICAgICBDQU0gWFBUICAgNTcxICAxMDQ1SyAgICAgICAtICAgICAgOTU4ICAx NiwzMiw2NCwxMjgsMjU2LDEwMjQsMjA0OA0KICAgICAgIGlzYWRldiAgICAgOCAgICAgMUsgICAg ICAgLSAgICAgICAgOCAgMTI4DQogICAgICAgICBVQVJUICAgICA2ICAgICA0SyAgICAgICAtICAg ICAgICA2ICAxNiw1MTIsMTAyNA0KICAgICBhY3BpaW50ciAgICAgMSAgICAgMUsgICAgICAgLSAg ICAgICAgMSAgNjQNCiAgICAgICAgIGNkZXYgICAgIDcgICAgIDJLICAgICAgIC0gICAgICAgIDcg IDI1Ng0KICAgICAgIGFjcGljYSAgMTQ1MSAgIDEzOUsgICAgICAgLSAgNjUyODQzOCAgMTYsMzIs NjQsMTI4LDI1Niw1MTIsMTAyNA0KICAgICAgICBzaWdpbyAgICAgMSAgICAgMUsgICAgICAgLSAg ICAgICAgMSAgNjQNCiAgICAgZmlsZWRlc2MgICAgNjAgICAgNDRLICAgICAgIC0gIDUwNTMzMDMg IDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2DQogICAgICAgICBrZW52ICAgIDc4 ICAgIDExSyAgICAgICAtICAgICAgIDg5ICAxNiwzMiw2NCwxMjgNCiAgICAgICBrcXVldWUgICAg IDAgICAgIDBLICAgICAgIC0gIDEwNzM4MTEgIDI1Niw1MTIsMjA0OA0KICAgIHByb2MtYXJncyAg ICAzMCAgICAgMksgICAgICAgLSAgNzE4NTcwNiAgMTYsMzIsNjQsMTI4LDI1Ng0KICAgICAgICBo aG9vayAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4DQogICAgIGFjcGl0YXNrICAg ICAxICAgICAySyAgICAgICAtICAgICAgICAxICAyMDQ4DQogICAgICBpdGhyZWFkICAgIDk5ICAg IDE2SyAgICAgICAtICAgICAgIDk5ICAzMiwxMjgsMjU2DQogICAgQ0FNIHF1ZXVlICAgIDE5ICAg ICA3SyAgICAgICAtICAgICAgNDA3ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwyMDQ4DQogICAgICAg S1RSQUNFICAgMTAwICAgIDEzSyAgICAgICAtICAgICAgMTAwICAxMjgNCiAgICAgICBsaW5rZXIg ICAxNTggICAgMTFLICAgICAgIC0gICAgICAxNjAgIDE2LDMyLDY0LDUxMg0KICAgICAgICBsb2Nr ZiAgICAyMCAgICAgM0sgICAgICAgLSAgICAyNDgzNiAgNjQsMTI4DQogICBsb2dpbmNsYXNzICAg ICAyICAgICAxSyAgICAgICAtICAgIDYxMDUzICA2NA0KICAgICAgIGlwNm5kcCAgICAxMiAgICAg MUsgICAgICAgLSAgICAgICAxNCAgNjQsMTI4DQogICAgICAgICB0ZW1wICAgIDUxICAgICAySyAg ICAgICAtICA4NDA1MTk1ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAg ICAgIGRldmJ1ZiAgODY0OCA0MTg4OUsgICAgICAgLSAgICAxMDE0MyAgMTYsMzIsNjQsMTI4LDI1 Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgICBtb2R1bGUgICA0NzcgICAgNjBLICAgICAgIC0g ICAgICA0NzcgIDEyOA0KICAgIGNpc3NfZGF0YSAgICAxNSAgICAxNEsgICAgICAgLSAgICAgNjc0 OSAgMTYsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgbXR4X3Bvb2wgICAgIDIgICAg MTZLICAgICAgIC0gICAgICAgIDIgIA0KICAgICAgIFVTQmRldiAgICAzNCAgICAgOEsgICAgICAg LSAgICAgICA0NCAgNjQsMTI4LDUxMiw0MDk2DQogICAgICAgICAgVVNCICAgIDUyICAgIDMxSyAg ICAgICAtICAgICAgIDY2ICAxNiwzMiw2NCwxMjgsMjU2LDIwNDgsNDA5Ng0KICAgICBwbWNob29r cyAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4DQogICAgICBzdWJwcm9jICAxNTM3 ICAgOTQ0SyAgICAgICAtICA0NTQ3OTM4ICA1MTIsNDA5Ng0KICAgICAgICAgcHJvYyAgICAgMiAg ICAxNksgICAgICAgLSAgICAgICAgMiAgDQogICAgICBzZXNzaW9uICAgIDIzICAgICAzSyAgICAg ICAtICAzNjcwMjQ3ICAxMjgNCiAgICAgICAgIHBncnAgICAgMjggICAgIDRLICAgICAgIC0gIDM2 NzQ5NDMgIDEyOA0KICAgICAgICAgY3JlZCAgICA0OCAgICAgOEsgICAgICAgLSAzMzU2NDE0OCAg NjQsMjU2DQogICAgICB1aWRpbmZvICAgICA1ICAgICAzSyAgICAgICAtICAgMTkwNjg1ICAxMjgs MjA0OA0KICAgICAgIHBsaW1pdCAgICAxNSAgICAgNEsgICAgICAgLSAgIDc5NjcwOCAgMjU2DQog ICAgICBhdGFfcGNpICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgICAgc2Nz aV9jZCAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxMCAgMTYNCiAgICBzeXNjdGx0bXAgICAg IDAgICAgIDBLICAgICAgIC0gICAgMTUyNTIgIDE2LDMyLDY0LDEyOCw0MDk2DQogICAgc3lzY3Rs b2lkICA0OTc4ICAgMjUxSyAgICAgICAtICAgICA1MzYwICAxNiwzMiw2NCwxMjgNCiAgICAgICBz eXNjdGwgICAgIDAgICAgIDBLICAgICAgIC0gIDgyMjM5OTYgIDE2LDMyLDY0DQogICAgICB0aWRo YXNoICAgICAxICAgIDE2SyAgICAgICAtICAgICAgICAxICANCiAgICAgIGNhbGxvdXQgICAgIDcg MTQzMzZLICAgICAgIC0gICAgICAgIDcgIA0KICAgICAgICAgdW10eCAgMzg3NiAgIDQ4NUsgICAg ICAgLSAgICAgMzg5NCAgMTI4DQogICAgIHAxMDAzLjFiICAgICAxICAgICAxSyAgICAgICAtICAg ICAgICAxICAxNg0KICAgICAgICAgU1dBUCAgICAgMiAgIDU0OUsgICAgICAgLSAgICAgICAgMiAg NjQNCiAgICAgICBidXMtc2MgICAxMTMgICA3ODFLICAgICAgIC0gICAgIDUyMzQgIDE2LDMyLDY0 LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2DQogICAgICAgICAgYnVzICAxMjgyICAgMTA5SyAg ICAgICAtICAgIDEwMTg2ICAxNiwzMiw2NCwxMjgsMjU2LDEwMjQNCiAgICAgIGRldnN0YXQgICAg MTIgICAgMjVLICAgICAgIC0gICAgICAgMTIgIDMyLDQwOTYNCiBldmVudGhhbmRsZXIgICAgNzcg ICAgIDZLICAgICAgIC0gICAgICAgNzcgIDY0LDEyOA0KICAgICAgYWNwaXNlbSAgICAxOSAgICAg M0sgICAgICAgLSAgICAgICAxOSAgMTI4DQogICAgICAgICBrb2JqICAgMzMwICAxMzIwSyAgICAg ICAtICAgICAgNjk4ICA0MDk2DQogICAgICBDQU0gU0lNICAgICA1ICAgICAySyAgICAgICAtICAg ICAgICA1ICAyNTYNCiAgICAgIFBlci1jcHUgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEg IDMyDQogICBDQU0gcGVyaXBoICAgIDEwICAgICAzSyAgICAgICAtICAgICAgIDU0ICAxNiwzMiw2 NCwxMjgsMjU2DQogICAgICAgICBybWFuICAgMjQ4ICAgIDI2SyAgICAgICAtICAgICAgNjEzICAx NiwzMiwxMjgNCiAgICAgICAgIHNidWYgICAgIDEgICAgIDFLICAgICAgIC0gICAgIDMyMzYgIDE2 LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2DQogICAgICBlbnRyb3B5ICAxMDI0ICAg IDY0SyAgICAgICAtICAgICAxMDI0ICA2NA0KICAgICAgIGN0bG1lbSAgNTA2MiAxMDExM0sgICAg ICAgLSAgICAgNTA2MiAgMTI4LDIwNDgNCiAgICAgICAgc3RhY2sgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAgIDggIDI1Ng0KICAgIHRhc2txdWV1ZSAgICAxNSAgICAgMksgICAgICAgLSAgICAg ICAxNSAgMTYsMzIsMTI4DQogICAgICAgVW5pdG5vICAgIDE0ICAgICAxSyAgICAgICAtICAgNjEx MjAyICAzMiw2NA0KICAgICAgICAgIGlvdiAgICAgMCAgICAgMEsgICAgICAgLSAgMTYxMDI2MSAg MTYsMzIsNjQsMTI4LDI1Niw1MTINCiAgICAgICBzZWxlY3QgIDE0NTYgICAxODJLICAgICAgIC0g ICAgIDE0NTYgIDEyOA0KICAgICBpb2N0bG9wcyAgICAgMCAgICAgMEsgICAgICAgLSAgODc3NjE2 MSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgICAgICBtc2cgICAg IDQgICAgMzBLICAgICAgIC0gICAgICAgIDQgIDIwNDgsNDA5Ng0KICAgICAgICAgIHNlbSAgICAg NCAgIDE5NksgICAgICAgLSAgICAgICAgNCAgDQogICAgICAgICAgc2htICAgICAxICAgIDIwSyAg ICAgICAtICAzNDY0ODQ0ICAyMDQ4DQogICAgICAgICAgdHR5ICAgIDIzICAgIDIzSyAgICAgICAt ICAgICAgMTYzICAxMDI0LDIwNDgNCiAgICAgICAgICBwdHMgICAgIDIgICAgIDFLICAgICAgIC0g ICAgICAxMzQgIDI1Ng0KICAgICBtYnVmX3RhZyAgICAgMCAgICAgMEsgICAgICAgLSA0NDUyODk4 NyAgMzIsMTI4DQogICAgICAgIHNobWZkICAgICAxICAgICA4SyAgICAgICAtICAgICAgICAxICAN CiAgICAgICAgICBwY2IgICAgMjEgICAxNTdLICAgICAgIC0gICA2Mzg4MTUgIDE2LDMyLDEyOCwx MDI0LDIwNDgsNDA5Ng0KICAgICAgIHNvbmFtZSAgICAgNCAgICAgMUsgICAgICAgLSA1MzU3OTgw MyAgMTYsMzIsMTI4DQogICAgICAgICAgYWNsICAgICAwICAgICAwSyAgICAgICAtICAgMTQ2NjA5 ICA0MDk2DQogICAgICAgYmlvYnVmICAgICAxICAgICAySyAgICAgICAtICAgIDE0NjkyICAyMDQ4 DQogICAgIHZmc2NhY2hlICAgICAxICA4MTkySyAgICAgICAtICAgICAgICAxICANCiAgIGNsX3Nh dmVidWYgICAgIDAgICAgIDBLICAgICAgIC0gMTA1MDAyMTE0ICA2NCwxMjgNCiAgICAgdmZzX2hh c2ggICAgIDEgIDQwOTZLICAgICAgIC0gICAgICAgIDEgIA0KICAgICAgIERFVkZTMSAgIDExNiAg ICA1OEsgICAgICAgLSAgICAgIDI3MyAgNTEyDQogICAgICAgdm5vZGVzICAgICAyICAgICAxSyAg ICAgICAtICAgICAgICA0ICA2NCwyNTYNCiAgICAgICBERVZGUzMgICAxMzUgICAgMzRLICAgICAg IC0gICAgICAzMjYgIDI1Ng0KICAgICAgICBtb3VudCAgICA5MSAgICAgNUsgICAgICAgLSAgICAg IDE5MSAgMTYsMzIsNjQsMTI4LDI1Ng0KICB2bm9kZW1hcmtlciAgICAgMCAgICAgMEsgICAgICAg LSAgNTIxMjYyMSAgNTEyDQogICAgICAgICAgQlBGICAgICA5ICAgICAySyAgICAgICAtICAgICAg ICA5ICAxMjgNCiAgZXRoZXJfbXVsdGkgICAgNTYgICAgIDNLICAgICAgIC0gICAgICAgNjYgIDE2 LDMyLDY0DQogICAgICAgaWZhZGRyICAgIDg3ICAgIDIySyAgICAgICAtICAgICAgIDg3ICAzMiw2 NCwxMjgsMjU2LDUxMiw0MDk2DQogICAgICAgIGlmbmV0ICAgIDEwICAgIDE5SyAgICAgICAtICAg ICAgIDEwICAxMjgsMjA0OA0KICAgICAgICBjbG9uZSAgICAgNiAgICAyNEsgICAgICAgLSAgICAg ICAgNiAgNDA5Ng0KICAgICAgIGFycGNvbSAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAg MTYNCiAgICAgIGxsdGFibGUgICAgMzIgICAgMTNLICAgICAgIC0gICAgNTkzMTcgIDI1Niw1MTIN CiAgICAgICAgREVWRlMgICAgMTcgICAgIDFLICAgICAgIC0gICAgICAgMjAgIDE2LDEyOA0KICAg ICAgIERFVkZTUCAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQNCiAgICAgcm91dGV0 YmwgICAgNDQgICAgIDZLICAgICAgIC0gIDE1MTQzNzQgIDMyLDY0LDEyOCwyNTYsNTEyDQogICAg ICAgICBpZ21wICAgICA5ICAgICAzSyAgICAgICAtICAgICAgICA5ICAyNTYNCiAgICAgaW5fbXVs dGkgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDI1Ng0KICAgIHNjdHBfaXRlciAgICAg MCAgICAgMEsgICAgICAgLSAgICAgICAgNCAgMjU2DQogICAgIHNjdHBfaWZuICAgICAzICAgICAx SyAgICAgICAtICAgICAgICAzICAxMjgNCiAgICAgc2N0cF9pZmEgICAgIDcgICAgIDFLICAgICAg IC0gICAgICAgIDcgIDEyOA0KICAgICBzY3RwX3ZyZiAgICAgMSAgICAgMUsgICAgICAgLSAgICAg ICAgMSAgNjQNCiAgICBzY3RwX2FfaXQgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDQgIDE2 DQogICAgaG9zdGNhY2hlICAgICAxICAgIDI4SyAgICAgICAtICAgICAgICAxICANCiAgICAgc3lu Y2FjaGUgICAgIDEgICAgOTZLICAgICAgIC0gICAgICAgIDEgIA0KICAgIGluNl9tdWx0aSAgICAy OCAgICAgNEsgICAgICAgLSAgICAgICAyOCAgMzIsMjU2DQogICAgICAgICAgbWxkICAgICA5ICAg ICAySyAgICAgICAtICAgICAgICA5ICAxMjgNCiAgICAgICAgICBycGMgICAgIDIgICAgIDFLICAg ICAgIC0gICAgICAgIDIgIDI1Ng0KYXVkaXRfZXZjbGFzcyAgIDE3OSAgICAgNksgICAgICAgLSAg ICAgIDIxOCAgMzINCiAgICAgc2F2ZWRpbm8gICAgIDAgICAgIDBLICAgICAgIC0gIDMxMTQ1ODMg IDI1Ng0KICAgICBmcmVld29yayAgICAgMSAgICAgMUsgICAgICAgLSA4MzUxMjIyOSAgMTYsMTI4 DQogICAgbmV3ZGlyYmxrICAgICAwICAgICAwSyAgICAgICAtICAgIDE4NDAzICA2NA0KICAgICAg IGRpcnJlbSAgICAgMCAgICAgMEsgICAgICAgLSAxMzU0MTU0MSAgMTI4DQogICAgICAgIG1rZGly ICAgICAwICAgICAwSyAgICAgICAtICAgIDI5NDU2ICAxMjgNCiAgICAgICBkaXJhZGQgICAgIDAg ICAgIDBLICAgICAgIC0gMTM1NDkwOTAgIDEyOA0KICAgICBmcmVlZmlsZSAgICAgMCAgICAgMEsg ICAgICAgLSAgNjk0ODQ2NSAgNjQNCiAgICAgZnJlZWJsa3MgICAgIDAgICAgIDBLICAgICAgIC0g IDY4NDQ5MzggIDEyOA0KICAgICBmcmVlZnJhZyAgICAgMCAgICAgMEsgICAgICAgLSA0NDE0NjUz NTIgIDEyOA0KICAgICBpbmRpcmRlcCAgICAgMCAgICAgMEsgICAgICAgLSAgNjQ3NjI2NCAgMTI4 DQogICAgICAgbmV3YmxrICAgICAxICAgNTEySyAgICAgICAtIDI4ODY0NzM0MTIgIDI1Ng0KICAg IGJtc2FmZW1hcCAgICAgMSAgICAgOEsgICAgICAgLSAgOTIwODkyMiAgMjU2DQogICAgIGlub2Rl ZGVwICAgICAxICA0MDk2SyAgICAgICAtICA4MDk3NzI4ICA1MTINCiAgICAgIHBhZ2VkZXAgICAg IDEgICA1MTJLICAgICAgIC0gICAxNDIxMDcgIDI1Ng0KICB1ZnNfZGlyaGFzaCAgIDY4NiAgIDMz NksgICAgICAgLSAgIDQxMzc4MSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNA0KICAgIHVmc19t b3VudCAgICAxNSAgICA1MUsgICAgICAgLSAgICAgICAyMSAgNTEyLDIwNDgsNDA5Ng0KICAgIHZt X3BnZGF0YSAgICAgMiAgIDEyOUsgICAgICAgLSAgICAgICAgMiAgMTI4DQogICAgICBVTUFIYXNo ICAgICAzICAgIDIySyAgICAgICAtICAgICAgIDEzICA1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAg IG1lbWRlc2MgICAgIDEgICAgIDRLICAgICAgIC0gICAgICAgIDEgIDQwOTYNCiAgICAgYXRrYmRk ZXYgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDY0DQogICAgcGZzX25vZGVzICAgIDIx ICAgICA2SyAgICAgICAtICAgICAgIDIxICAyNTYNCiAgcGZzX3ZuY2FjaGUgICAgIDAgICAgIDBL ICAgICAgIC0gICAgICAyNjggIDY0DQogICAgICAgY3RsYmxrICAgMjAwICAxNjAwSyAgICAgICAt ICAgICAgMjAwICANCiAgICAgICAgIEdFT00gICAxMzMgICAgNDFLICAgICAgIC0gICAgIDE2NjYg IDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OA0KICAgICAgcmFtZGlzayAgICAgMSAgNDA5 NksgICAgICAgLSAgICAgICAgMSAgDQogICAgICBhY3BpZGV2ICAgIDMwICAgICAySyAgICAgICAt ICAgICAgIDMwICA2NA0KICAgICAgY3RscG9vbCAgIDUzMiAgIDE0MksgICAgICAgLSAgICAgIDUz MiAgMzIsNTEyDQogICAgICAga2JkbXV4ICAgICA3ICAgIDE4SyAgICAgICAtICAgICAgICA4ICAx Niw1MTIsMTAyNCwyMDQ4DQogICAgICAgYXBtZGV2ICAgICAxICAgICAxSyAgICAgICAtICAgICAg ICAxICAxMjgNCiAgIG1hZHRfdGFibGUgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDEgIDQw OTYNCiAgICAgICBmZWVkZXIgICAgIDcgICAgIDFLICAgICAgIC0gICAgICAgIDcgIDMyDQogICAg ICBzY3NpX2RhICAgICAwICAgICAwSyAgICAgICAtICAgICAgMzU5ICAxNg0KICAgICBwY2lfbGlu ayAgICAxNiAgICAgMksgICAgICAgLSAgICAgICAxNiAgMTYsMTI4DQogICAgcmFpZF9kYXRhICAg ICAwICAgICAwSyAgICAgICAtICAgICAgMzA2ICAzMiwxMjgsMjU2DQogICAgICBpb19hcGljICAg ICAxICAgICAySyAgICAgICAtICAgICAgICAxICAyMDQ4DQogICAgICAgICAgTUNBICAgICA4ICAg ICAxSyAgICAgICAtICAgICAgICA4ICAxMjgNCiAgICAgICAgICBtc2kgICAgIDMgICAgIDFLICAg ICAgIC0gICAgICAgIDMgIDEyOA0KICAgICBuZXh1c2RldiAgICAgMyAgICAgMUsgICAgICAgLSAg ICAgICAgMyAgMTYNCm1kX252aWRpYV9kYXRhICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDUw ICA1MTINCisgc3lzY3RsIGRlYnVnDQpkZWJ1Zy5hY3BpLnN1c3BlbmRfYm91bmNlOiAwDQpkZWJ1 Zy5hY3BpLnJlc2V0X2Nsb2NrOiAxDQpkZWJ1Zy5hY3BpLmludGVycHJldGVyX3NsYWNrOiAxDQpk ZWJ1Zy5hY3BpLmVuYWJsZV9kZWJ1Z19vYmplY3RzOiAwDQpkZWJ1Zy5hY3BpLmFjcGlfY2FfdmVy c2lvbjogMjAxMTA1MjcNCmRlYnVnLmFjcGkuY3B1X3Vub3JkZXJlZDogMA0KZGVidWcuYWNwaS5l Yy50aW1lb3V0OiA3NTANCmRlYnVnLmFjcGkuZWMucG9sbGVkOiAwDQpkZWJ1Zy5hY3BpLmVjLmJ1 cnN0OiAwDQpkZWJ1Zy5hY3BpLmJhdHQuYmF0dF9zbGVlcF9tczogMA0KZGVidWcuYWNwaS5yZXN1 bWVfYmVlcDogMA0KZGVidWcuZmlyZXdpcmVfZGVidWc6IDANCmRlYnVnLmZ3bWVtX2RlYnVnOiAw DQpkZWJ1Zy5pZl9md2VfZGVidWc6IDANCmRlYnVnLmlmX2Z3aXBfZGVidWc6IDANCmRlYnVnLmlw dzogMA0KZGVidWcuaXdpOiAwDQpkZWJ1Zy5tZGRlYnVnOiAwDQpkZWJ1Zy53cGk6IDANCmRlYnVn LmVsZjY0X2xlZ2FjeV9jb3JlZHVtcDogMA0KZGVidWcuYm9vdHZlcmJvc2U6IDANCmRlYnVnLmJv b3Rob3d0bzogMA0KZGVidWcuY3B1ZnJlcS52ZXJib3NlOiAwDQpkZWJ1Zy5jcHVmcmVxLmxvd2Vz dDogMA0KZGVidWcuZmFpbF9wb2ludC5zeXNjdGxfcnVubmluZzogb2ZmDQpkZWJ1Zy5mYWlsX3Bv aW50LmJ1Zl9wcmVzc3VyZTogb2ZmDQpkZWJ1Zy5mYWlsX3BvaW50Lm5sbV9kZW55X2dyYW50OiBv ZmYNCmRlYnVnLmFkYXB0aXZlX21hY2hpbmVfYXJjaDogMQ0KZGVidWcuc2l6ZW9mLmNkZXZfcHJp djogMzc2DQpkZWJ1Zy5zaXplb2YuY2RldjogMjg4DQpkZWJ1Zy5zaXplb2YuZ19iaW9xOiA1Ng0K ZGVidWcuc2l6ZW9mLmdfY29uc3VtZXI6IDk2DQpkZWJ1Zy5zaXplb2YuZ19wcm92aWRlcjogMTM2 DQpkZWJ1Zy5zaXplb2YuZ19nZW9tOiAxNjANCmRlYnVnLnNpemVvZi5nX2NsYXNzOiAxNjANCmRl YnVnLnNpemVvZi5raW5mb19wcm9jOiAxMDg4DQpkZWJ1Zy5zaXplb2YuYnVmOiA2MDgNCmRlYnVn LnNpemVvZi5iaW86IDIzMg0KZGVidWcuc2l6ZW9mLnByb2M6IDExODQNCmRlYnVnLnNpemVvZi52 bm9kZTogNDgwDQpkZWJ1Zy5zaXplb2YuZGV2c3RhdDogMjg4DQpkZWJ1Zy5zaXplb2YubmFtZWNh Y2hlOiA3Mg0KZGVidWcub3NkOiAwDQpkZWJ1Zy50cmFjZV9vbl9wYW5pYzogMQ0KZGVidWcuZGVi dWdnZXJfb25fcGFuaWM6IDENCmRlYnVnLm5jb3JlczogNQ0KZGVidWcudG9fYXZnX21wY2FsbHM6 IDc0NQ0KZGVidWcudG9fYXZnX2xvY2tjYWxsczogMjQ1DQpkZWJ1Zy50b19hdmdfZ2NhbGxzOiA0 ODgNCmRlYnVnLnRvX2F2Z19kZXB0aDogMTczOA0KZGVidWcudW10eC51bXR4X3BpX2FsbG9jYXRl ZDogMA0KZGVidWcuY2xvY2t0aW1lOiAwDQpkZWJ1Zy5rZGIuYWx0X2JyZWFrX3RvX2RlYnVnZ2Vy OiAwDQpkZWJ1Zy5rZGIuYnJlYWtfdG9fZGVidWdnZXI6IDANCmRlYnVnLmtkYi50cmFwX2NvZGU6 IDANCmRlYnVnLmtkYi50cmFwOiAwDQpkZWJ1Zy5rZGIucGFuaWM6IDANCmRlYnVnLmtkYi5lbnRl cjogMA0KZGVidWcua2RiLmN1cnJlbnQ6IA0KZGVidWcucm1hbl9kZWJ1ZzogMA0KZGVidWcuaW9z aXplX21heF9jbGFtcDogMQ0KZGVidWcuZGlzYWJsZWZ1bGxwYXRoOiAwDQpkZWJ1Zy5kaXNhYmxl Y3dkOiAwDQpkZWJ1Zy52ZnNjYWNoZTogMQ0KZGVidWcubnVtY2FjaGVodjogMjg2ODINCmRlYnVn Lm51bWNhY2hlOiAxODI5MzgNCmRlYnVnLm51bW5lZzogMTIxODINCmRlYnVnLm5jaGFzaDogMTA0 ODU3NQ0KZGVidWcudm5scnVfbm93aGVyZTogMA0KZGVidWcucnVzaF9yZXF1ZXN0czogMzcwMjgx DQpkZWJ1Zy5pZl90dW5fZGVidWc6IDANCmRlYnVnLm5sbV9kZWJ1ZzogMA0KZGVidWcuZnNja2Nt ZHM6IDANCmRlYnVnLmNvbGxlY3RzbmFwc3RhdHM6IDANCmRlYnVnLnNuYXBkZWJ1ZzogMA0KZGVi dWcuZG9wZXJzaXN0ZW5jZTogMA0KZGVidWcuc29mdGRlcC5jbGVhbnVwX2ZhaWx1cmVzOiAzNjk2 MzQNCmRlYnVnLnNvZnRkZXAuY2xlYW51cF9yZXRyaWVzOiA4MjYNCmRlYnVnLnNvZnRkZXAuY2xl YW51cF9oaWdoX2RlbGF5OiAxNA0KZGVidWcuc29mdGRlcC5jbGVhbnVwX2lub3JlcXVlc3RzOiAw DQpkZWJ1Zy5zb2Z0ZGVwLmNsZWFudXBfYmxrcmVxdWVzdHM6IDM2OTY5MA0KZGVidWcuc29mdGRl cC5qd2FpdF9uZXdibGs6IDANCmRlYnVnLnNvZnRkZXAuandhaXRfaW5vZGU6IDANCmRlYnVnLnNv ZnRkZXAuandhaXRfZnJlZWJsa3M6IDANCmRlYnVnLnNvZnRkZXAuandhaXRfZmlsZXBhZ2U6IDAN CmRlYnVnLnNvZnRkZXAuam91cm5hbF93YWl0OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmpvdXJuYWxfbWlu OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmpvdXJuYWxfbG93OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmpuZXdibGtf cm9sbGJhY2s6IDANCmRlYnVnLnNvZnRkZXAuamFkZHJlZl9yb2xsYmFjazogMA0KZGVidWcuc29m dGRlcC5kaXJfZW50cnk6IDIwMjAzMw0KZGVidWcuc29mdGRlcC5kaXJlY3RfYmxrX3B0cnM6IDM0 MjY1NQ0KZGVidWcuc29mdGRlcC5pbm9kZV9iaXRtYXA6IDI1MjgyNzUNCmRlYnVnLnNvZnRkZXAu aW5kaXJfYmxrX3B0cnM6IDI2OTM3DQpkZWJ1Zy5zb2Z0ZGVwLnN5bmNfbGltaXRfaGl0OiA1OTEN CmRlYnVnLnNvZnRkZXAuaW5vX2xpbWl0X2hpdDogMA0KZGVidWcuc29mdGRlcC5ibGtfbGltaXRf aGl0OiAzNjkyMjANCmRlYnVnLnNvZnRkZXAuaW5vX2xpbWl0X3B1c2g6IDANCmRlYnVnLnNvZnRk ZXAuYmxrX2xpbWl0X3B1c2g6IDM2OTY5MA0KZGVidWcuc29mdGRlcC53b3JrbGlzdF9wdXNoOiAy MTU2DQpkZWJ1Zy5zb2Z0ZGVwLm1heGluZGlyZGVwczogNTANCmRlYnVnLnNvZnRkZXAudGlja2Rl bGF5OiAyDQpkZWJ1Zy5zb2Z0ZGVwLm1heF9zb2Z0ZGVwczogMjM1MjMwOA0KZGVidWcuc29mdGRl cC53cml0ZS5qZnN5bmM6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuanRydW5jOiAwDQpkZWJ1Zy5z b2Z0ZGVwLndyaXRlLnNiZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpzZWdkZXA6IDANCmRl YnVnLnNvZnRkZXAud3JpdGUuanNlZzogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qZnJlZWZyYWc6 IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuamZyZWVibGs6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUu am5ld2JsazogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qbXZyZWY6IDANCmRlYnVnLnNvZnRkZXAu d3JpdGUuanJlbXJlZjogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qYWRkcmVmOiAwDQpkZWJ1Zy5z b2Z0ZGVwLndyaXRlLmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZXdvcms6IDAN CmRlYnVnLnNvZnRkZXAud3JpdGUubmV3ZGlyYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmRp cnJlbTogMA0KZGVidWcuc29mdGRlcC53cml0ZS5ta2RpcjogMA0KZGVidWcuc29mdGRlcC53cml0 ZS5kaXJhZGQ6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZWZpbGU6IDANCmRlYnVnLnNvZnRk ZXAud3JpdGUuZnJlZWJsa3M6IDY5MDk0Nw0KZGVidWcuc29mdGRlcC53cml0ZS5mcmVlZnJhZzog MA0KZGVidWcuc29mdGRlcC53cml0ZS5hbGxvY2luZGlyOiAyMzM0NTM4NTgxDQpkZWJ1Zy5zb2Z0 ZGVwLndyaXRlLmluZGlyZGVwOiAxMTczNTANCmRlYnVnLnNvZnRkZXAud3JpdGUuYWxsb2NkaXJl Y3Q6IDc2OTQwMTQzDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLm5ld2JsazogMA0KZGVidWcuc29mdGRl cC53cml0ZS5ibXNhZmVtYXA6IDI0Mzc4NTYNCmRlYnVnLnNvZnRkZXAud3JpdGUuaW5vZGVkZXA6 IDY5MTcxNTcNCmRlYnVnLnNvZnRkZXAud3JpdGUucGFnZWRlcDogMzI5NjY0DQpkZWJ1Zy5zb2Z0 ZGVwLmN1cnJlbnQuamZzeW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuanRydW5jOiAwDQpk ZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuc2JkZXA6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qc2Vn ZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuanNlZzogMA0KZGVidWcuc29mdGRlcC5jdXJy ZW50LmpmcmVlZnJhZzogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpmcmVlYmxrOiAwDQpkZWJ1 Zy5zb2Z0ZGVwLmN1cnJlbnQuam5ld2JsazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmptdnJl ZjogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpyZW1yZWY6IDANCmRlYnVnLnNvZnRkZXAuY3Vy cmVudC5qYWRkcmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZnJlZWRlcDogMA0KZGVidWcu c29mdGRlcC5jdXJyZW50LmZyZWV3b3JrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQubmV3ZGly YmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZGlycmVtOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1 cnJlbnQubWtkaXI6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5kaXJhZGQ6IDANCmRlYnVnLnNv ZnRkZXAuY3VycmVudC5mcmVlZmlsZTogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmZyZWVibGtz OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZnJlZWZyYWc6IDANCmRlYnVnLnNvZnRkZXAuY3Vy cmVudC5hbGxvY2luZGlyOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuaW5kaXJkZXA6IDANCmRl YnVnLnNvZnRkZXAuY3VycmVudC5hbGxvY2RpcmVjdDogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50 Lm5ld2JsazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmJtc2FmZW1hcDogMA0KZGVidWcuc29m dGRlcC5jdXJyZW50Lmlub2RlZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQucGFnZWRlcDog MA0KZGVidWcuc29mdGRlcC50b3RhbC5qZnN5bmM6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuanRy dW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLnNiZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFs LmpzZWdkZXA6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuanNlZzogMA0KZGVidWcuc29mdGRlcC50 b3RhbC5qZnJlZWZyYWc6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuamZyZWVibGs6IDANCmRlYnVn LnNvZnRkZXAudG90YWwuam5ld2JsazogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qbXZyZWY6IDAN CmRlYnVnLnNvZnRkZXAudG90YWwuanJlbXJlZjogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qYWRk cmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAudG90 YWwuZnJlZXdvcms6IDgzNTEyMjI4DQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLm5ld2RpcmJsazogMTg0 MDMNCmRlYnVnLnNvZnRkZXAudG90YWwuZGlycmVtOiAxMzU0MTU0MQ0KZGVidWcuc29mdGRlcC50 b3RhbC5ta2RpcjogMjk0NTYNCmRlYnVnLnNvZnRkZXAudG90YWwuZGlyYWRkOiAxMzU0OTA5MA0K ZGVidWcuc29mdGRlcC50b3RhbC5mcmVlZmlsZTogNjk0ODQ2NQ0KZGVidWcuc29mdGRlcC50b3Rh bC5mcmVlYmxrczogNjg0NDkzOA0KZGVidWcuc29mdGRlcC50b3RhbC5mcmVlZnJhZzogNDQxNDY1 MzUyDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmFsbG9jaW5kaXI6IDANCmRlYnVnLnNvZnRkZXAudG90 YWwuaW5kaXJkZXA6IDY0NDkzMjcNCmRlYnVnLnNvZnRkZXAudG90YWwuYWxsb2NkaXJlY3Q6IDAN CmRlYnVnLnNvZnRkZXAudG90YWwubmV3YmxrOiAyODg2NDczNDExDQpkZWJ1Zy5zb2Z0ZGVwLnRv dGFsLmJtc2FmZW1hcDogOTIwODkyMQ0KZGVidWcuc29mdGRlcC50b3RhbC5pbm9kZWRlcDogODA5 NzcyNw0KZGVidWcuc29mdGRlcC50b3RhbC5wYWdlZGVwOiAxNDIxMDYNCmRlYnVnLmRvYmtncmR3 cml0ZTogMQ0KZGVidWcuYmlnY2dzOiAwDQpkZWJ1Zy5kaXJjaGVjazogMA0KZGVidWcucHNtLnBr dGVycnRocmVzaDogMg0KZGVidWcucHNtLnVzZWNzOiA1MDAwMDANCmRlYnVnLnBzbS5zZWNzOiAw DQpkZWJ1Zy5wc20uZXJydXNlY3M6IDANCmRlYnVnLnBzbS5lcnJzZWNzOiAyDQpkZWJ1Zy5wc20u aHo6IDIwDQpkZWJ1Zy5wc20ubG9nbGV2ZWw6IDANCmRlYnVnLnZlc2Euc2hhZG93X3JvbTogMA0K ZGVidWcuZmRjLnNldHRsZTogMA0KZGVidWcuZmRjLnNwZWMyOiAxNg0KZGVidWcuZmRjLnNwZWMx OiAxNzUNCmRlYnVnLmZkYy5yZXRyaWVzOiAxMA0KZGVidWcuZmRjLmRlYnVnZmxhZ3M6IDANCmRl YnVnLmZkYy5maWZvOiA4DQpkZWJ1Zy5lbGYzMl9sZWdhY3lfY29yZWR1bXA6IDANCmRlYnVnLng4 NmJpb3MuaW50OiAwDQpkZWJ1Zy54ODZiaW9zLmNhbGw6IDANCmRlYnVnLmh3cHN0YXRlX3ZlcmJv c2U6IDANCmRlYnVnLm1pbmlkdW1wOiAxDQorIGZzdGF0IC1mIC9wZ3NxbA0KVVNFUiAgICAgQ01E ICAgICAgICAgIFBJRCAgIEZEIE1PVU5UICAgICAgSU5VTSBNT0RFICAgICAgICAgU1p8RFYgUi9X DQpyb290ICAgICBmc3RhdCAgICAgIDUyNTM2ICAgd2QgLyAgICAgICAgIDMyOTAyIGRyd3hyLXhy LXggICAgMTAyNCAgcg0Kcm9vdCAgICAgZnN0YXQgICAgICA1MjUzNiByb290IC8gICAgICAgICAg ICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGZzdGF0ICAgICAgNTI1MzYgICAg MyAvICAgICAgICAgNDk3ODQgLXJ3LS0tLS0tLSAgIDQwOTYwICByDQpyb290ICAgICBzaCAgICAg ICAgIDUyNTMxIHRleHQgLyAgICAgICAgIDMyOTU2IC1yLXhyLXhyLXggIDE0Mjk4NCAgcg0Kcm9v dCAgICAgc2ggICAgICAgICA1MjUzMSAgIHdkIC8gICAgICAgICAzMjkwMiBkcnd4ci14ci14ICAg IDEwMjQgIHINCnJvb3QgICAgIHNoICAgICAgICAgNTI1MzEgcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBzaCAgICAgICAgIDUyNTMxICAgMTAgLyAg ICAgICAgIDMyOTgxIC1yd3hyLXhyLXggICAgIDEwNyAgcg0Kcm9vdCAgICAgc2ggICAgICAgICA1 MjQ5NSB0ZXh0IC8gICAgICAgICAzMjk1NiAtci14ci14ci14ICAxNDI5ODQgIHINCnJvb3QgICAg IHNoICAgICAgICAgNTI0OTUgICB3ZCAvICAgICAgICAgMzI5MDIgZHJ3eHIteHIteCAgICAxMDI0 ICByDQpyb290ICAgICBzaCAgICAgICAgIDUyNDk1IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hy LXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgc2NyaXB0ICAgICA1MjQ5NCAgIHdkIC8gICAgICAg ICAzMjkwMiBkcnd4ci14ci14ICAgIDEwMjQgIHINCnJvb3QgICAgIHNjcmlwdCAgICAgNTI0OTQg cm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBzY3Jp cHQgICAgIDUyNDk0ICAgIDMgLSAgICAgICAgIDMyOTc4IC1ydy1yLS1yLS0gICA1MDk0MSAgdw0K cm9vdCAgICAgYmFzaCAgICAgICA1MjQxMiAgIHdkIC8gICAgICAgICAzMjkwMiBkcnd4ci14ci14 ICAgIDEwMjQgIHINCnJvb3QgICAgIGJhc2ggICAgICAgNTI0MTIgcm9vdCAvICAgICAgICAgICAg IDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBzaCAgICAgICAgIDUyNDExIHRleHQg LyAgICAgICAgIDMyOTU2IC1yLXhyLXhyLXggIDE0Mjk4NCAgcg0Kcm9vdCAgICAgc2ggICAgICAg ICA1MjQxMSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3Qg ICAgIHN1ICAgICAgICAgNTI0MDkgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAg NTEyICByDQpnaXJnZW4gICBiYXNoICAgICAgIDUyNDA2IHJvb3QgLyAgICAgICAgICAgICAyIGRy d3hyLXhyLXggICAgIDUxMiAgcg0KZ2lyZ2VuICAgc3NoZCAgICAgICA1MjQwNSAgIHdkIC8gICAg ICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCmdpcmdlbiAgIHNzaGQgICAgICAgNTI0 MDUgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBz c2hkICAgICAgIDUyNDAyICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAg cg0Kcm9vdCAgICAgc3NoZCAgICAgICA1MjQwMiByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14 ci14ICAgICA1MTIgIHINCm5hZ2lvcyAgIG5ycGUyICAgICAgNzM3MDQgICB3ZCAvICAgICAgICAg ICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpuYWdpb3MgICBucnBlMiAgICAgIDczNzA0IHJv b3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgZ2V0dHkg ICAgICAxMzAyMCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJv b3QgICAgIGdldHR5ICAgICAgMTMwMjAgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAgNTEyICByDQpyb290ICAgICBtb3VzZWQgICAgIDY4OTc0ICAgd2QgLyAgICAgICAgICAgICAy IGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgbW91c2VkICAgICA2ODk3NCByb290IC8g ICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGdldHR5ICAgICAg IDEzMjAgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAg ICBnZXR0eSAgICAgICAxMzIwIHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUx MiAgcg0Kcm9vdCAgICAgZ2V0dHkgICAgICAgMTMxOSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4 ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGdldHR5ICAgICAgIDEzMTkgcm9vdCAvICAgICAg ICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBnZXR0eSAgICAgICAxMzE4 ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgZ2V0 dHkgICAgICAgMTMxOCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIN CnJvb3QgICAgIGdldHR5ICAgICAgIDEzMTcgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIt eCAgICAgNTEyICByDQpyb290ICAgICBnZXR0eSAgICAgICAxMzE3IHJvb3QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgZ2V0dHkgICAgICAgMTMxNiAgIHdk IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGdldHR5ICAg ICAgIDEzMTYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290 ICAgICBnZXR0eSAgICAgICAxMzE1ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAg IDUxMiAgcg0Kcm9vdCAgICAgZ2V0dHkgICAgICAgMTMxNSByb290IC8gICAgICAgICAgICAgMiBk cnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGdldHR5ICAgICAgIDEzMTQgICB3ZCAvICAg ICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBnZXR0eSAgICAgICAx MzE0IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAg Y3JvbiAgICAgICAgMTI3NSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIg IHINCnNtbXNwICAgIHNlbmRtYWlsICAgIDEyNzEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIt eHIteCAgICAgNTEyICByDQpyb290ICAgICBzZW5kbWFpbCAgICAxMjY4IHJvb3QgLyAgICAgICAg ICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgc3NoZCAgICAgICAgMTI0OSAg IHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIHNzaGQg ICAgICAgIDEyNDkgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpy b290ICAgICBudHBkICAgICAgICAxMjEyICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXgg ICAgIDUxMiAgcg0Kcm9vdCAgICAgbnRwZCAgICAgICAgMTIxMiByb290IC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIHNubXBkICAgICAgIDExODAgICB3ZCAv ICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBzbm1wZCAgICAg ICAxMTgwIHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAg ICAgc3lzbG9nZCAgICAgMTEyNiAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1 MTIgIHINCnJvb3QgICAgIHN5c2xvZ2QgICAgIDExMjYgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3 eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBkZXZkICAgICAgICAxMDEyIHRleHQgLyAgICAg ICAgICAgMTA1IC1yLXhyLXhyLXggIDQ1NDUyOCAgcg0Kcm9vdCAgICAgZGV2ZCAgICAgICAgMTAx MiAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGRl dmQgICAgICAgIDEwMTIgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICBy DQpyb290ICAgICBhZGprZXJudHogICAgMTIyIHRleHQgLyAgICAgICAgICAgMTAwIC1yLXhyLXhy LXggICAgOTI2NCAgcg0Kcm9vdCAgICAgYWRqa2VybnR6ICAgIDEyMiAgIHdkIC8gICAgICAgICAg ICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGFkamtlcm50eiAgICAxMjIgcm9v dCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBpbml0ICAg ICAgICAgICAxIHRleHQgLyAgICAgICAgICAgMTEyIC1yLXhyLXhyLXggIDc5MjEyOCAgcg0Kcm9v dCAgICAgaW5pdCAgICAgICAgICAgMSAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAg ICA1MTIgIHINCnJvb3QgICAgIGluaXQgICAgICAgICAgIDEgcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBrZXJuZWwgICAgICAgICAwICAgd2QgLyAg ICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAga2VybmVsICAgICAg ICAgMCByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCisgc3lzY3Rs IC1hDQorIGVncmVwIHZub2RlDQprZXJuLm1heHZub2RlczogNTg4MDc3DQprZXJuLm1pbnZub2Rl czogMTQ3MDE5DQp2bS5zdGF0cy52bS52X3Zub2RlcGdzb3V0OiAwDQp2bS5zdGF0cy52bS52X3Zu b2RlcGdzaW46IDUyMTg5DQp2bS5zdGF0cy52bS52X3Zub2Rlb3V0OiAwDQp2bS5zdGF0cy52bS52 X3Zub2RlaW46IDIxOTE3DQp2ZnMuZnJlZXZub2RlczogMTI4ODQ5DQp2ZnMud2FudGZyZWV2bm9k ZXM6IDE0NzAxOQ0KdmZzLm51bXZub2RlczogMTY5NTIwDQpkZWJ1Zy5zaXplb2Yudm5vZGU6IDQ4 MA0KKyBtb3VudCAtdg0KL2Rldi9kYTBzMWEgb24gLyAodWZzLCBsb2NhbCwgd3JpdGVzOiBzeW5j IDM4OCBhc3luYyAxNjUsIHJlYWRzOiBzeW5jIDI5NjYzIGFzeW5jIDIwOTYsIGZzaWQgNmNhMTcx NGI2N2EwZTJlNikNCmRldmZzIG9uIC9kZXYgKGRldmZzLCBsb2NhbCwgbXVsdGlsYWJlbCwgZnNp ZCAwMGZmMDA3MTcxMDAwMDAwKQ0KL2Rldi9kYTFzMSBvbiAvb3B0ICh1ZnMsIGxvY2FsLCBzb2Z0 LXVwZGF0ZXMsIHdyaXRlczogc3luYyA0MjA0MjAgYXN5bmMgMTUxMTQ5NDIsIHJlYWRzOiBzeW5j IDE3Njg3NDg0MCBhc3luYyAxNDQyMDA0NzQsIGZzaWQgMzAzMTg1NTBmNTY3OWU4NikNCi9kZXYv ZGEwczFlIG9uIC90bXAgKHVmcywgbG9jYWwsIHNvZnQtdXBkYXRlcywgd3JpdGVzOiBzeW5jIDQy IGFzeW5jIDE1NDU5LCByZWFkczogc3luYyA1MjgwIGFzeW5jIDAsIGZzaWQgNmNhMTcxNGIwMTFj ZmUxYykNCi9kZXYvZGEwczFmIG9uIC91c3IgKHVmcywgbG9jYWwsIHNvZnQtdXBkYXRlcywgd3Jp dGVzOiBzeW5jIDE1NDQgYXN5bmMgMjE0NDUxNCwgcmVhZHM6IHN5bmMgMTM1Mjk2MjIgYXN5bmMg NzQxMSwgZnNpZCA2Y2ExNzE0YjdhNWNiNjE1KQ0KL2Rldi9kYTBzMWQgb24gL3ZhciAodWZzLCBs b2NhbCwgc29mdC11cGRhdGVzLCB3cml0ZXM6IHN5bmMgMTA2MjkgYXN5bmMgMTMzMTgwMiwgcmVh ZHM6IHN5bmMgMjcxNDE3IGFzeW5jIDI0ODgxLCBmc2lkIDZkYTE3MTRiZTkxMzNiZmEpDQpwcm9j ZnMgb24gL3Byb2MgKHByb2NmcywgbG9jYWwsIGZzaWQgMDFmZjAwMDIwMjAwMDAwMCkNCiMgbW91 bnQgL3Bnc3FsDQojIG1vdW50IC9wZ3NxbBtbMTJEG1tLbW91bnQgL3Bnc3FsG1sxMkRzaCAteCBk aXNrc3BhY2VjaGVjay5zaA0KKyBkZiAtaWggL3Bnc3FsDQpGaWxlc3lzdGVtICAgICBTaXplICAg IFVzZWQgICBBdmFpbCBDYXBhY2l0eSBpdXNlZCBpZnJlZSAlaXVzZWQgIE1vdW50ZWQgb24NCi9k ZXYvZGEyczFkICAgIDEyOEcgICAgIDgyRyAgICAgMzZHICAgIDcwJSAgICAgMjNrICAgMTdNICAg IDAlICAgL3Bnc3FsDQorIHZtc3RhdCAteg0KSVRFTSAgICAgICAgICAgICAgICAgICBTSVpFICBM SU1JVCAgICAgVVNFRCAgICAgRlJFRSAgICAgIFJFUSBGQUlMIFNMRUVQDQoNClVNQSBLZWdzOiAg ICAgICAgICAgICAgIDIwOCwgICAgICAwLCAgICAgIDg2LCAgICAgIDE2LCAgICAgIDg2LCAgIDAs ICAgMA0KVU1BIFpvbmVzOiAgICAgICAgICAgICAxNDA4LCAgICAgIDAsICAgICAgODYsICAgICAg IDAsICAgICAgODYsICAgMCwgICAwDQpVTUEgU2xhYnM6ICAgICAgICAgICAgICA1NjgsICAgICAg MCwgICAgNjgxMCwgICAgIDUwNSwgIDYyODQ1OCwgICAwLCAgIDANClVNQSBSQ250U2xhYnM6ICAg ICAgICAgIDU2OCwgICAgICAwLCAgICA0NTkxLCAgICAgNTc1LCAgMzkyODY5LCAgIDAsICAgMA0K VU1BIEhhc2g6ICAgICAgICAgICAgICAgMjU2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDMsICAgMCwgICAwDQoxNiBCdWNrZXQ6ICAgICAgICAgICAgICAxNTIsICAgICAgMCwgICAg ICAyNywgICAgICA3MywgICAgIDIxMSwgICAwLCAgIDANCjMyIEJ1Y2tldDogICAgICAgICAgICAg IDI4MCwgICAgICAwLCAgICAgIDQ3LCAgICAgMTQ5LCAgICAgMzM5LCAgIDYsICAgMA0KNjQgQnVj a2V0OiAgICAgICAgICAgICAgNTM2LCAgICAgIDAsICAgICAgNzgsICAgICAgNzYsICAgICA3NTIs ICA5MCwgICAwDQoxMjggQnVja2V0OiAgICAgICAgICAgIDEwNDgsICAgICAgMCwgICAgMTgwNywg ICAgICAgMiwgMTU1NzIyNywxNTM0OTk2OSwgICAwDQpWTSBPQkpFQ1Q6ICAgICAgICAgICAgICAy MzIsICAgICAgMCwgIDE1NDkyMywgICAzMTEwOSwxNDE5NDM1MTcsICAgMCwgICAwDQpNQVA6ICAg ICAgICAgICAgICAgICAgICAyMzIsICAgICAgMCwgICAgICAgNywgICAgICAyNSwgICAgICAgNywg ICAwLCAgIDANCktNQVAgRU5UUlk6ICAgICAgICAgICAgIDEyMCwgMTEyODcxMCwgICAxMzA2MSwg ICAzODE1MSwxNzkzNzY5MzU5LCAgIDAsICAgMA0KTUFQIEVOVFJZOiAgICAgICAgICAgICAgMTIw LCAgICAgIDAsICAgICA4NDYsICAgIDQ5MjAsMzAxOTUxNTUzLCAgIDAsICAgMA0KZmFrZXBnOiAg ICAgICAgICAgICAgICAgMTIwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwDQptdF96b25lOiAgICAgICAgICAgICAgIDQxMTIsICAgICAgMCwgICAgIDMyNiwgICAg ICAgMSwgICAgIDMyNiwgICAwLCAgIDANCjE2OiAgICAgICAgICAgICAgICAgICAgICAxNiwgICAg ICAwLCAgICAyMzI3LCAgICAyMDQxLDE1MTgzNzkwLCAgIDAsICAgMA0KMzI6ICAgICAgICAgICAg ICAgICAgICAgIDMyLCAgICAgIDAsICAgIDI3NzIsICAgIDE2NzIsNTAyMDAwNTUsICAgMCwgICAw DQo2NDogICAgICAgICAgICAgICAgICAgICAgNjQsICAgICAgMCwgICAgNTMyMCwgICAgNDMxMiw4 MzA4NDQ1MiwgICAwLCAgIDANCjEyODogICAgICAgICAgICAgICAgICAgIDEyOCwgICAgICAwLCAg ICA5ODQwLCAgICA0NzQ3LDY4OTUxNTE0MiwgICAwLCAgIDANCjI1NjogICAgICAgICAgICAgICAg ICAgIDI1NiwgICAgICAwLCAgICAgNTU5LCAgIDMzNDkxLDI5MjAyNTA5NjEsICAgMCwgICAwDQo1 MTI6ICAgICAgICAgICAgICAgICAgICA1MTIsICAgICAgMCwgICAgMjczNywgICAgMjM5NCwxODEz MDE4NiwgICAwLCAgIDANCjEwMjQ6ICAgICAgICAgICAgICAgICAgMTAyNCwgICAgICAwLCAgICAg IDU0LCAgICAxMzM4LCAyMjA1NTY3LCAgIDAsICAgMA0KMjA0ODogICAgICAgICAgICAgICAgICAy MDQ4LCAgICAgIDAsICAgIDU2MjksICAgIDEyNzMsIDQxMzU2MjAsICAgMCwgICAwDQo0MDk2OiAg ICAgICAgICAgICAgICAgIDQwOTYsICAgICAgMCwgICAgIDQyOCwgICAgMTE3MiwgNTMyNzIyMSwg ICAwLCAgIDANCkZpbGVzOiAgICAgICAgICAgICAgICAgICA4MCwgICAgICAwLCAgICAgIDk0LCAg IDExMTExLDE5OTIxMjQxOCwgICAwLCAgIDANClRVUk5TVElMRTogICAgICAgICAgICAgIDEzNiwg ICAgICAwLCAgICAxOTM5LCAgICAgMTIxLCAgICAxOTQ4LCAgIDAsICAgMA0KdW10eCBwaTogICAg ICAgICAgICAgICAgIDk2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwDQpNQUMgbGFiZWxzOiAgICAgICAgICAgICAgNDAsICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDANClBST0M6ICAgICAgICAgICAgICAgICAgMTE4NCwgICAgICAw LCAgICAgIDQ5LCAgICAxNDM2LCA0NTQ2NDU5LCAgIDAsICAgMA0KVEhSRUFEOiAgICAgICAgICAg ICAgICAxMTI4LCAgICAgIDAsICAgIDE1NDksICAgICAzODksICAgIDE5NjMsICAgMCwgICAwDQpT TEVFUFFVRVVFOiAgICAgICAgICAgICAgODAsICAgICAgMCwgICAgMTkzOSwgICAgIDI2NSwgICAg MTk0OCwgICAwLCAgIDANClZNU1BBQ0U6ICAgICAgICAgICAgICAgIDM5MiwgICAgICAwLCAgICAg IDMwLCAgICAxNTYwLCA0NTQ2NDQyLCAgIDAsICAgMA0KY3B1c2V0OiAgICAgICAgICAgICAgICAg IDcyLCAgICAgIDAsICAgICAgODUsICAgICAgNjUsICAgICAgODUsICAgMCwgICAwDQphdWRpdF9y ZWNvcmQ6ICAgICAgICAgICA5NjAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDANCm1idWZfcGFja2V0OiAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICA0MDgxLCAg ICAxNjc5LDY5NzgwMzg4NSwgICAwLCAgIDANCm1idWY6ICAgICAgICAgICAgICAgICAgIDI1Niwg ICAgICAwLCAgICAxMDIyLCAgICAxNzIzLDE5NjI4MjU0NTksICAgMCwgICAwDQptYnVmX2NsdXN0 ZXI6ICAgICAgICAgIDIwNDgsICAyNTYwMCwgICAgNTc2MCwgICAgMTI1NCwgMTcwODU0NCwgICAw LCAgIDANCm1idWZfanVtYm9fcGFnZTogICAgICAgNDA5NiwgIDEyODAwLCAgICAgICAwLCAgICAx MDg0LDgzNTA1MjkzLCAgIDAsICAgMA0KbWJ1Zl9qdW1ib185azogICAgICAgICA5MjE2LCAgIDY0 MDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQptYnVmX2p1bWJvXzE2azog ICAgICAgMTYzODQsICAgMzIwMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAN Cm1idWZfZXh0X3JlZmNudDogICAgICAgICAgNCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMA0KZ19iaW86ICAgICAgICAgICAgICAgICAgMjMyLCAgICAgIDAsICAg ICAgIDAsICAgIDE1ODQsMjk3Nzg0MzQ5MSwgICAwLCAgIDANCnR0eWlucTogICAgICAgICAgICAg ICAgIDE2MCwgICAgICAwLCAgICAgMTUwLCAgICAgNDc0LCAgICAyNjI1LCAgIDAsICAgMA0KdHR5 b3V0cTogICAgICAgICAgICAgICAgMjU2LCAgICAgIDAsICAgICAgODAsICAgICAzNDAsICAgIDE0 MDAsICAgMCwgICAwDQphdGFfcmVxdWVzdDogICAgICAgICAgICAzMjgsICAgICAgMCwgICAgICAg MCwgICAgICA4NCwgICAgICAzMiwgICAwLCAgIDANCmF0YV9jb21wb3NpdGU6ICAgICAgICAgIDMz NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KVk5PREU6ICAg ICAgICAgICAgICAgICAgNDgwLCAgICAgIDAsICAxNjk1MjIsICAgOTU4NzgsMTU4OTc3Nzg4LCAg IDAsICAgMA0KVk5PREVQT0xMOiAgICAgICAgICAgICAgMTEyLCAgICAgIDAsICAgICAgIDAsICAg ICAxMzIsICAgICAgIDYsICAgMCwgICAwDQpOQU1FSTogICAgICAgICAgICAgICAgIDEwMjQsICAg ICAgMCwgICAgICAgMCwgICAgMTIxMiw0MzIzNzc5NzQsICAgMCwgICAwDQpTIFZGUyBDYWNoZTog ICAgICAgICAgICAxMDgsICAgICAgMCwgIDE3MDQzMCwgIDEwNzM5NywxNjMzMDgzNjgsICAgMCwg ICAwDQpTVFMgVkZTIENhY2hlOiAgICAgICAgICAxNDgsICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDANCkwgVkZTIENhY2hlOiAgICAgICAgICAgIDMyOCwgICAgICAw LCAgIDEyNTA2LCAgICA0MjEwLCA3NjIyODIyLCAgIDAsICAgMA0KTFRTIFZGUyBDYWNoZTogICAg ICAgICAgMzY4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpO Q0xOT0RFOiAgICAgICAgICAgICAgICA1NjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDANCkRJUkhBU0g6ICAgICAgICAgICAgICAgMTAyNCwgICAgICAwLCAgICAg IDkwLCAgICAgOTU4LCAzMDg1Mjk1LCAgIDAsICAgMA0KTW91bnRwb2ludHM6ICAgICAgICAgICAg NzkyLCAgICAgIDAsICAgICAgIDgsICAgICAgMzIsICAgICAgMTAsICAgMCwgICAwDQpwaXBlOiAg ICAgICAgICAgICAgICAgICA3MjgsICAgICAgMCwgICAgICAgMywgICAgMTMyNywgMzk3NTY4OCwg ICAwLCAgIDANCmtzaWdpbmZvOiAgICAgICAgICAgICAgIDExMiwgICAgICAwLCAgICAxNDc0LCAg ICAxNDMwLDEwMTE0MDQ4LCAgIDAsICAgMA0KaXRpbWVyOiAgICAgICAgICAgICAgICAgMzQ0LCAg ICAgIDAsICAgICAgIDEsICAgICAgMjEsICAgICAgIDEsICAgMCwgICAwDQpLTk9URTogICAgICAg ICAgICAgICAgICAxMjgsICAgICAgMCwgICAgICAgMCwgICAgMTcxMSwgMTExNDk0NywgICAwLCAg IDANCnNvY2tldDogICAgICAgICAgICAgICAgIDY4MCwgMTAwMDAyLCAgICAgIDMxLCAgICAxNDI3 LCA5NjM0MjQzLCAgIDAsICAgMA0KaXBxOiAgICAgICAgICAgICAgICAgICAgIDU2LCAgICA4MTks ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQp1ZHBfaW5wY2I6ICAgICAgICAg ICAgICAzOTIsIDEwMDAwMCwgICAgICAxMiwgICAgMTU0OCwgNzU2MTcwMiwgICAwLCAgIDANCnVk cGNiOiAgICAgICAgICAgICAgICAgICAxNiwgMTAwMTI4LCAgICAgIDEyLCAgICAxODM2LCA3NTYx NzAyLCAgIDAsICAgMA0KdGNwX2lucGNiOiAgICAgICAgICAgICAgMzkyLCAxMDAwMDAsICAgICAg IDgsICAgIDE3NTIsICA2NjM0MTUsICAgMCwgICAwDQp0Y3BjYjogICAgICAgICAgICAgICAgICA5 NzYsIDEwMDAwMCwgICAgICAgOCwgICAgMTc2NCwgIDY2MzQxNSwgICAwLCAgIDANCnRjcHR3OiAg ICAgICAgICAgICAgICAgICA3MiwgIDIwMDAwLCAgICAgICAwLCAgICAgNTUwLCAgICAzMjg3LCAg IDAsICAgMA0Kc3luY2FjaGU6ICAgICAgICAgICAgICAgMTUyLCAgMTUzNzUsICAgICAgIDAsICAg ICA2MjUsICA1MTQ2NjMsICAgMCwgICAwDQpob3N0Y2FjaGU6ICAgICAgICAgICAgICAxMzYsICAx NTM3MiwgICAgICAgNSwgICAgIDQ5OSwgICAgMTg3OSwgICAwLCAgIDANCnRjcHJlYXNzOiAgICAg ICAgICAgICAgICA0MCwgICAxNjgwLCAgICAgICAwLCAgICAxNTk2LCAgIDIxNzYyLCAgIDAsICAg MA0Kc2Fja2hvbGU6ICAgICAgICAgICAgICAgIDMyLCAgICAgIDAsICAgICAgIDAsICAgICA5MDks ICAgICA4OTAsICAgMCwgICAwDQpzY3RwX2VwOiAgICAgICAgICAgICAgIDEzNzYsIDEwMDAwMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfYXNvYzogICAgICAgICAg ICAgMjI4OCwgIDQwMDAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0Kc2N0 cF9sYWRkcjogICAgICAgICAgICAgIDQ4LCAgODAwNjQsICAgICAgIDAsICAgICAyODgsICAgICAg IDYsICAgMCwgICAwDQpzY3RwX3JhZGRyOiAgICAgICAgICAgICA3MDQsICA4MDAwMCwgICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfY2h1bms6ICAgICAgICAgICAgIDEz NiwgNDAwMDA4LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0Kc2N0cF9yZWFk cTogICAgICAgICAgICAgMTA0LCA0MDAwMzIsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwDQpzY3RwX3N0cmVhbV9tc2dfb3V0OiAgICAxMTIsIDQwMDAyNiwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfYXNjb25mOiAgICAgICAgICAgICA0MCwgNDAw MDA4LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0Kc2N0cF9hc2NvbmZfYWNr OiAgICAgICAgIDQ4LCA0MDAwMzIsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw DQpyaXBjYjogICAgICAgICAgICAgICAgICAzOTIsIDEwMDAwMCwgICAgICAgMCwgICAgIDEwMCwg ICAgIDEyNiwgICAwLCAgIDANCnVucGNiOiAgICAgICAgICAgICAgICAgIDI0MCwgMTAwMDAwLCAg ICAgIDEwLCAgICAxMzE4LCAxNDA4OTk0LCAgIDAsICAgMA0KcnRlbnRyeTogICAgICAgICAgICAg ICAgMjAwLCAgICAgIDAsICAgICAgMjMsICAgICAgOTEsICAgICAgMjMsICAgMCwgICAwDQpzZWxm ZDogICAgICAgICAgICAgICAgICAgNTYsICAgICAgMCwgICAgMTk5MywgICAgMTM0NiwzMDkzODkx MzQsICAgMCwgICAwDQpTV0FQTUVUQTogICAgICAgICAgICAgICAyODgsIDExNjUxOSwgICAgICA0 MCwgICAgIDU1OCwgMTA3MjEyMCwgICAwLCAgIDANCkZGUyBpbm9kZTogICAgICAgICAgICAgIDE2 OCwgICAgICAwLCAgMTY1MzE2LCAgIDk4MTU2LDE1ODk3NTQ1NiwgICAwLCAgIDANCkZGUzEgZGlu b2RlOiAgICAgICAgICAgIDEyOCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMA0KRkZTMiBkaW5vZGU6ICAgICAgICAgICAgMjU2LCAgICAgIDAsICAxNjUzMTYsICAg OTc5NzksMTU4OTc1NDQ5LCAgIDAsICAgMA0KDQorIHZtc3RhdCAtbQ0KICAgICAgICAgVHlwZSBJ blVzZSBNZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQ0KQ0FNIGRldiBxdWV1ZSAgICAg NCAgICAgMUsgICAgICAgLSAgICAgICAgNCAgMTI4DQogIG1kX3NpaV9kYXRhICAgICAwICAgICAw SyAgICAgICAtICAgICAgIDUwICA1MTINCiAgICAgIENBTSBYUFQgICA1NzEgIDEwNDVLICAgICAg IC0gICAgICA5NTggIDE2LDMyLDY0LDEyOCwyNTYsMTAyNCwyMDQ4DQogICAgICAgaXNhZGV2ICAg ICA4ICAgICAxSyAgICAgICAtICAgICAgICA4ICAxMjgNCiAgICAgICAgIFVBUlQgICAgIDYgICAg IDRLICAgICAgIC0gICAgICAgIDYgIDE2LDUxMiwxMDI0DQogICAgIGFjcGlpbnRyICAgICAxICAg ICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgICAgICAgY2RldiAgICAgNyAgICAgMksgICAg ICAgLSAgICAgICAgNyAgMjU2DQogICAgICAgYWNwaWNhICAxNDUxICAgMTM5SyAgICAgICAtICA2 NTMwMTA0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0DQogICAgICAgIHNpZ2lvICAgICAxICAg ICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgICBmaWxlZGVzYyAgICA2MCAgICA0NEsgICAg ICAgLSAgNTA1MzMxMyAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAg ICAgIGtlbnYgICAgNzggICAgMTFLICAgICAgIC0gICAgICAgODkgIDE2LDMyLDY0LDEyOA0KICAg ICAgIGtxdWV1ZSAgICAgMCAgICAgMEsgICAgICAgLSAgMTA3MzgxMSAgMjU2LDUxMiwyMDQ4DQog ICAgcHJvYy1hcmdzICAgIDMwICAgICAySyAgICAgICAtICA3MTg1NzE4ICAxNiwzMiw2NCwxMjgs MjU2DQogICAgICAgIGhob29rICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAxMjgNCiAg ICAgYWNwaXRhc2sgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIwNDgNCiAgICAgIGl0 aHJlYWQgICAgOTkgICAgMTZLICAgICAgIC0gICAgICAgOTkgIDMyLDEyOCwyNTYNCiAgICBDQU0g cXVldWUgICAgMTkgICAgIDdLICAgICAgIC0gICAgICA0MDcgIDE2LDMyLDY0LDEyOCwyNTYsNTEy LDIwNDgNCiAgICAgICBLVFJBQ0UgICAxMDAgICAgMTNLICAgICAgIC0gICAgICAxMDAgIDEyOA0K ICAgICAgIGxpbmtlciAgIDE1OCAgICAxMUsgICAgICAgLSAgICAgIDE2MCAgMTYsMzIsNjQsNTEy DQogICAgICAgIGxvY2tmICAgIDIwICAgICAzSyAgICAgICAtICAgIDI0ODQwICA2NCwxMjgNCiAg IGxvZ2luY2xhc3MgICAgIDIgICAgIDFLICAgICAgIC0gICAgNjEwNTMgIDY0DQogICAgICAgaXA2 bmRwICAgIDEyICAgICAxSyAgICAgICAtICAgICAgIDE0ICA2NCwxMjgNCiAgICAgICAgIHRlbXAg ICAgNTEgICAgIDJLICAgICAgIC0gIDg0MDU4NDQgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQs MjA0OCw0MDk2DQogICAgICAgZGV2YnVmICA4NjQ4IDQxODg5SyAgICAgICAtICAgIDEwMTQzICAx NiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAgICAgIG1vZHVsZSAgIDQ3NyAg ICA2MEsgICAgICAgLSAgICAgIDQ3NyAgMTI4DQogICAgY2lzc19kYXRhICAgIDE1ICAgIDE0SyAg ICAgICAtICAgICA2NzQ5ICAxNiwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAgICBtdHhf cG9vbCAgICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgDQogICAgICAgVVNCZGV2ICAgIDM0 ICAgICA4SyAgICAgICAtICAgICAgIDQ0ICA2NCwxMjgsNTEyLDQwOTYNCiAgICAgICAgICBVU0Ig ICAgNTIgICAgMzFLICAgICAgIC0gICAgICAgNjYgIDE2LDMyLDY0LDEyOCwyNTYsMjA0OCw0MDk2 DQogICAgIHBtY2hvb2tzICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAxMjgNCiAgICAg IHN1YnByb2MgIDE1MzcgICA5NDRLICAgICAgIC0gIDQ1NDc5NDggIDUxMiw0MDk2DQogICAgICAg ICBwcm9jICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICANCiAgICAgIHNlc3Npb24gICAg MjMgICAgIDNLICAgICAgIC0gIDM2NzAyNDcgIDEyOA0KICAgICAgICAgcGdycCAgICAyOCAgICAg NEsgICAgICAgLSAgMzY3NDk0NyAgMTI4DQogICAgICAgICBjcmVkICAgIDUwICAgICA4SyAgICAg ICAtIDMzNTY0Mjk2ICA2NCwyNTYNCiAgICAgIHVpZGluZm8gICAgIDUgICAgIDNLICAgICAgIC0g ICAxOTA2ODUgIDEyOCwyMDQ4DQogICAgICAgcGxpbWl0ICAgIDE1ICAgICA0SyAgICAgICAtICAg Nzk2NzA4ICAyNTYNCiAgICAgIGF0YV9wY2kgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEg IDY0DQogICAgICBzY3NpX2NkICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDEwICAxNg0KICAg IHN5c2N0bHRtcCAgICAgMCAgICAgMEsgICAgICAgLSAgICAxNTQzMCAgMTYsMzIsNjQsMTI4LDQw OTYNCiAgICBzeXNjdGxvaWQgIDQ5NzggICAyNTFLICAgICAgIC0gICAgIDUzNjAgIDE2LDMyLDY0 LDEyOA0KICAgICAgIHN5c2N0bCAgICAgMCAgICAgMEsgICAgICAgLSAgODIyNDEyMSAgMTYsMzIs NjQNCiAgICAgIHRpZGhhc2ggICAgIDEgICAgMTZLICAgICAgIC0gICAgICAgIDEgIA0KICAgICAg Y2FsbG91dCAgICAgNyAxNDMzNksgICAgICAgLSAgICAgICAgNyAgDQogICAgICAgICB1bXR4ICAz ODc2ICAgNDg1SyAgICAgICAtICAgICAzODk0ICAxMjgNCiAgICAgcDEwMDMuMWIgICAgIDEgICAg IDFLICAgICAgIC0gICAgICAgIDEgIDE2DQogICAgICAgICBTV0FQICAgICAyICAgNTQ5SyAgICAg ICAtICAgICAgICAyICA2NA0KICAgICAgIGJ1cy1zYyAgIDExMyAgIDc4MUsgICAgICAgLSAgICAg NTIzNCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgICAgICBidXMg IDEyODIgICAxMDlLICAgICAgIC0gICAgMTA2OTIgIDE2LDMyLDY0LDEyOCwyNTYsMTAyNA0KICAg ICAgZGV2c3RhdCAgICAxMiAgICAyNUsgICAgICAgLSAgICAgICAxMiAgMzIsNDA5Ng0KIGV2ZW50 aGFuZGxlciAgICA3NyAgICAgNksgICAgICAgLSAgICAgICA3NyAgNjQsMTI4DQogICAgICBhY3Bp c2VtICAgIDE5ICAgICAzSyAgICAgICAtICAgICAgIDE5ICAxMjgNCiAgICAgICAgIGtvYmogICAz MzAgIDEzMjBLICAgICAgIC0gICAgICA2OTggIDQwOTYNCiAgICAgIENBTSBTSU0gICAgIDUgICAg IDJLICAgICAgIC0gICAgICAgIDUgIDI1Ng0KICAgICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAg ICAgLSAgICAgICAgMSAgMzINCiAgIENBTSBwZXJpcGggICAgMTAgICAgIDNLICAgICAgIC0gICAg ICAgNTQgIDE2LDMyLDY0LDEyOCwyNTYNCiAgICAgICAgIHJtYW4gICAyNDggICAgMjZLICAgICAg IC0gICAgICA2MTMgIDE2LDMyLDEyOA0KICAgICAgICAgc2J1ZiAgICAgMSAgICAgMUsgICAgICAg LSAgICAgMzYwMiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgIGVu dHJvcHkgIDEwMjQgICAgNjRLICAgICAgIC0gICAgIDEwMjQgIDY0DQogICAgICAgY3RsbWVtICA1 MDYyIDEwMTEzSyAgICAgICAtICAgICA1MDYyICAxMjgsMjA0OA0KICAgICAgICBzdGFjayAgICAg MCAgICAgMEsgICAgICAgLSAgICAgICAxMCAgMjU2DQogICAgdGFza3F1ZXVlICAgIDE1ICAgICAy SyAgICAgICAtICAgICAgIDE1ICAxNiwzMiwxMjgNCiAgICAgICBVbml0bm8gICAgMTQgICAgIDFL ICAgICAgIC0gICA2MTEyMDggIDMyLDY0DQogICAgICAgICAgaW92ICAgICAwICAgICAwSyAgICAg ICAtICAxNjEwMjYyICAxNiwzMiw2NCwxMjgsMjU2LDUxMg0KICAgICAgIHNlbGVjdCAgMTQ1NiAg IDE4MksgICAgICAgLSAgICAgMTQ1NiAgMTI4DQogICAgIGlvY3Rsb3BzICAgICAwICAgICAwSyAg ICAgICAtICA4Nzc2MTk5ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAg ICAgICAgIG1zZyAgICAgNCAgICAzMEsgICAgICAgLSAgICAgICAgNCAgMjA0OCw0MDk2DQogICAg ICAgICAgc2VtICAgICA0ICAgMTk2SyAgICAgICAtICAgICAgICA0ICANCiAgICAgICAgICBzaG0g ICAgIDEgICAgMjBLICAgICAgIC0gIDM0NjQ4NDQgIDIwNDgNCiAgICAgICAgICB0dHkgICAgMjMg ICAgMjNLICAgICAgIC0gICAgICAxNjUgIDEwMjQsMjA0OA0KICAgICAgICAgIHB0cyAgICAgMiAg ICAgMUsgICAgICAgLSAgICAgIDEzNCAgMjU2DQogICAgIG1idWZfdGFnICAgICAwICAgICAwSyAg ICAgICAtIDQ0NTI4OTg3ICAzMiwxMjgNCiAgICAgICAgc2htZmQgICAgIDEgICAgIDhLICAgICAg IC0gICAgICAgIDEgIA0KICAgICAgICAgIHBjYiAgICAyMSAgIDE1N0sgICAgICAgLSAgIDYzODgx NSAgMTYsMzIsMTI4LDEwMjQsMjA0OCw0MDk2DQogICAgICAgc29uYW1lICAgICA0ICAgICAxSyAg ICAgICAtIDUzNTc5OTI3ICAxNiwzMiwxMjgNCiAgICAgICAgICBhY2wgICAgIDAgICAgIDBLICAg ICAgIC0gICAxNDY2MDkgIDQwOTYNCiAgICAgICBiaW9idWYgICAgIDEgICAgIDJLICAgICAgIC0g ICAgMTQ2OTIgIDIwNDgNCiAgICAgdmZzY2FjaGUgICAgIDEgIDgxOTJLICAgICAgIC0gICAgICAg IDEgIA0KICAgY2xfc2F2ZWJ1ZiAgICAgMCAgICAgMEsgICAgICAgLSAxMDUwMDIxMTUgIDY0LDEy OA0KICAgICB2ZnNfaGFzaCAgICAgMSAgNDA5NksgICAgICAgLSAgICAgICAgMSAgDQogICAgICAg REVWRlMxICAgMTE1ICAgIDU4SyAgICAgICAtICAgICAgMjczICA1MTINCiAgICAgICB2bm9kZXMg ICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDQgIDY0LDI1Ng0KICAgICAgIERFVkZTMyAgIDEz MSAgICAzM0sgICAgICAgLSAgICAgIDMyNiAgMjU2DQogICAgICAgIG1vdW50ICAgMTA2ICAgICA1 SyAgICAgICAtICAgICAgMjA2ICAxNiwzMiw2NCwxMjgsMjU2DQogIHZub2RlbWFya2VyICAgICAw ICAgICAwSyAgICAgICAtICA1MjEyNjI1ICA1MTINCiAgICAgICAgICBCUEYgICAgIDkgICAgIDJL ICAgICAgIC0gICAgICAgIDkgIDEyOA0KICBldGhlcl9tdWx0aSAgICA1NiAgICAgM0sgICAgICAg LSAgICAgICA2NiAgMTYsMzIsNjQNCiAgICAgICBpZmFkZHIgICAgODcgICAgMjJLICAgICAgIC0g ICAgICAgODcgIDMyLDY0LDEyOCwyNTYsNTEyLDQwOTYNCiAgICAgICAgaWZuZXQgICAgMTAgICAg MTlLICAgICAgIC0gICAgICAgMTAgIDEyOCwyMDQ4DQogICAgICAgIGNsb25lICAgICA2ICAgIDI0 SyAgICAgICAtICAgICAgICA2ICA0MDk2DQogICAgICAgYXJwY29tICAgICAyICAgICAxSyAgICAg ICAtICAgICAgICAyICAxNg0KICAgICAgbGx0YWJsZSAgICAzMiAgICAxM0sgICAgICAgLSAgICA1 OTMxNyAgMjU2LDUxMg0KICAgICAgICBERVZGUyAgICAxNyAgICAgMUsgICAgICAgLSAgICAgICAy MCAgMTYsMTI4DQogICAgICAgREVWRlNQICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAyICA2 NA0KICAgICByb3V0ZXRibCAgICA0NCAgICAgNksgICAgICAgLSAgMTUxNDM3NCAgMzIsNjQsMTI4 LDI1Niw1MTINCiAgICAgICAgIGlnbXAgICAgIDkgICAgIDNLICAgICAgIC0gICAgICAgIDkgIDI1 Ng0KICAgICBpbl9tdWx0aSAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMjU2DQogICAg c2N0cF9pdGVyICAgICAwICAgICAwSyAgICAgICAtICAgICAgICA0ICAyNTYNCiAgICAgc2N0cF9p Zm4gICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDEyOA0KICAgICBzY3RwX2lmYSAgICAg NyAgICAgMUsgICAgICAgLSAgICAgICAgNyAgMTI4DQogICAgIHNjdHBfdnJmICAgICAxICAgICAx SyAgICAgICAtICAgICAgICAxICA2NA0KICAgIHNjdHBfYV9pdCAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAgNCAgMTYNCiAgICBob3N0Y2FjaGUgICAgIDEgICAgMjhLICAgICAgIC0gICAgICAg IDEgIA0KICAgICBzeW5jYWNoZSAgICAgMSAgICA5NksgICAgICAgLSAgICAgICAgMSAgDQogICAg aW42X211bHRpICAgIDI4ICAgICA0SyAgICAgICAtICAgICAgIDI4ICAzMiwyNTYNCiAgICAgICAg ICBtbGQgICAgIDkgICAgIDJLICAgICAgIC0gICAgICAgIDkgIDEyOA0KICAgICAgICAgIHJwYyAg ICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMjU2DQphdWRpdF9ldmNsYXNzICAgMTc5ICAg ICA2SyAgICAgICAtICAgICAgMjE4ICAzMg0KICAgICBzYXZlZGlubyAgICAgMCAgICAgMEsgICAg ICAgLSAgMzExNDU4MyAgMjU2DQogICAgIGZyZWV3b3JrICAgICAxICAgICAxSyAgICAgICAtIDgz NTEyMjI5ICAxNiwxMjgNCiAgICBuZXdkaXJibGsgICAgIDAgICAgIDBLICAgICAgIC0gICAgMTg0 MDMgIDY0DQogICAgICAgZGlycmVtICAgICAwICAgICAwSyAgICAgICAtIDEzNTQxNTQyICAxMjgN CiAgICAgICAgbWtkaXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgMjk0NTYgIDEyOA0KICAgICAg IGRpcmFkZCAgICAgMCAgICAgMEsgICAgICAgLSAxMzU0OTA5MSAgMTI4DQogICAgIGZyZWVmaWxl ICAgICAwICAgICAwSyAgICAgICAtICA2OTQ4NDY2ICA2NA0KICAgICBmcmVlYmxrcyAgICAgMCAg ICAgMEsgICAgICAgLSAgNjg0NDkzOCAgMTI4DQogICAgIGZyZWVmcmFnICAgICAwICAgICAwSyAg ICAgICAtIDQ0MTQ2NTM1MiAgMTI4DQogICAgIGluZGlyZGVwICAgICAwICAgICAwSyAgICAgICAt ICA2NDc2MjY0ICAxMjgNCiAgICAgICBuZXdibGsgICAgIDEgICA1MTJLICAgICAgIC0gMjg4NjQ3 MzQxMiAgMjU2DQogICAgYm1zYWZlbWFwICAgICAxICAgICA4SyAgICAgICAtICA5MjA4OTIzICAy NTYNCiAgICAgaW5vZGVkZXAgICAgIDEgIDQwOTZLICAgICAgIC0gIDgwOTc3MzAgIDUxMg0KICAg ICAgcGFnZWRlcCAgICAgMiAgIDUxM0sgICAgICAgLSAgIDE0MjEwOCAgMjU2DQogIHVmc19kaXJo YXNoICAgNjg2ICAgMzM2SyAgICAgICAtICAgNDEzNzgxICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwx MDI0DQogICAgdWZzX21vdW50ICAgIDE4ICAgIDY5SyAgICAgICAtICAgICAgIDI0ICA1MTIsMjA0 OCw0MDk2DQogICAgdm1fcGdkYXRhICAgICAyICAgMTI5SyAgICAgICAtICAgICAgICAyICAxMjgN CiAgICAgIFVNQUhhc2ggICAgIDMgICAgMjJLICAgICAgIC0gICAgICAgMTMgIDUxMiwxMDI0LDIw NDgsNDA5Ng0KICAgICAgbWVtZGVzYyAgICAgMSAgICAgNEsgICAgICAgLSAgICAgICAgMSAgNDA5 Ng0KICAgICBhdGtiZGRldiAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQNCiAgICBw ZnNfbm9kZXMgICAgMjEgICAgIDZLICAgICAgIC0gICAgICAgMjEgIDI1Ng0KICBwZnNfdm5jYWNo ZSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgIDI2OCAgNjQNCiAgICAgICBjdGxibGsgICAyMDAg IDE2MDBLICAgICAgIC0gICAgICAyMDAgIA0KICAgICAgICAgR0VPTSAgIDEyNyAgICA0MEsgICAg ICAgLSAgICAgMTY4MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4DQogICAgICByYW1k aXNrICAgICAxICA0MDk2SyAgICAgICAtICAgICAgICAxICANCiAgICAgIGFjcGlkZXYgICAgMzAg ICAgIDJLICAgICAgIC0gICAgICAgMzAgIDY0DQogICAgICBjdGxwb29sICAgNTMyICAgMTQySyAg ICAgICAtICAgICAgNTMyICAzMiw1MTINCiAgICAgICBrYmRtdXggICAgIDcgICAgMThLICAgICAg IC0gICAgICAgIDggIDE2LDUxMiwxMDI0LDIwNDgNCiAgICAgICBhcG1kZXYgICAgIDEgICAgIDFL ICAgICAgIC0gICAgICAgIDEgIDEyOA0KICAgbWFkdF90YWJsZSAgICAgMCAgICAgMEsgICAgICAg LSAgICAgICAgMSAgNDA5Ng0KICAgICAgIGZlZWRlciAgICAgNyAgICAgMUsgICAgICAgLSAgICAg ICAgNyAgMzINCiAgICAgIHNjc2lfZGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAzNjAgIDE2 DQogICAgIHBjaV9saW5rICAgIDE2ICAgICAySyAgICAgICAtICAgICAgIDE2ICAxNiwxMjgNCiAg ICByYWlkX2RhdGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAzMDYgIDMyLDEyOCwyNTYNCiAg ICAgIGlvX2FwaWMgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIwNDgNCiAgICAgICAg ICBNQ0EgICAgIDggICAgIDFLICAgICAgIC0gICAgICAgIDggIDEyOA0KICAgICAgICAgIG1zaSAg ICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMTI4DQogICAgIG5leHVzZGV2ICAgICAzICAg ICAxSyAgICAgICAtICAgICAgICAzICAxNg0KbWRfbnZpZGlhX2RhdGEgICAgIDAgICAgIDBLICAg ICAgIC0gICAgICAgNTAgIDUxMg0KKyBzeXNjdGwgZGVidWcNCmRlYnVnLmFjcGkuc3VzcGVuZF9i b3VuY2U6IDANCmRlYnVnLmFjcGkucmVzZXRfY2xvY2s6IDENCmRlYnVnLmFjcGkuaW50ZXJwcmV0 ZXJfc2xhY2s6IDENCmRlYnVnLmFjcGkuZW5hYmxlX2RlYnVnX29iamVjdHM6IDANCmRlYnVnLmFj cGkuYWNwaV9jYV92ZXJzaW9uOiAyMDExMDUyNw0KZGVidWcuYWNwaS5jcHVfdW5vcmRlcmVkOiAw DQpkZWJ1Zy5hY3BpLmVjLnRpbWVvdXQ6IDc1MA0KZGVidWcuYWNwaS5lYy5wb2xsZWQ6IDANCmRl YnVnLmFjcGkuZWMuYnVyc3Q6IDANCmRlYnVnLmFjcGkuYmF0dC5iYXR0X3NsZWVwX21zOiAwDQpk ZWJ1Zy5hY3BpLnJlc3VtZV9iZWVwOiAwDQpkZWJ1Zy5maXJld2lyZV9kZWJ1ZzogMA0KZGVidWcu ZndtZW1fZGVidWc6IDANCmRlYnVnLmlmX2Z3ZV9kZWJ1ZzogMA0KZGVidWcuaWZfZndpcF9kZWJ1 ZzogMA0KZGVidWcuaXB3OiAwDQpkZWJ1Zy5pd2k6IDANCmRlYnVnLm1kZGVidWc6IDANCmRlYnVn LndwaTogMA0KZGVidWcuZWxmNjRfbGVnYWN5X2NvcmVkdW1wOiAwDQpkZWJ1Zy5ib290dmVyYm9z ZTogMA0KZGVidWcuYm9vdGhvd3RvOiAwDQpkZWJ1Zy5jcHVmcmVxLnZlcmJvc2U6IDANCmRlYnVn LmNwdWZyZXEubG93ZXN0OiAwDQpkZWJ1Zy5mYWlsX3BvaW50LnN5c2N0bF9ydW5uaW5nOiBvZmYN CmRlYnVnLmZhaWxfcG9pbnQuYnVmX3ByZXNzdXJlOiBvZmYNCmRlYnVnLmZhaWxfcG9pbnQubmxt X2RlbnlfZ3JhbnQ6IG9mZg0KZGVidWcuYWRhcHRpdmVfbWFjaGluZV9hcmNoOiAxDQpkZWJ1Zy5z aXplb2YuY2Rldl9wcml2OiAzNzYNCmRlYnVnLnNpemVvZi5jZGV2OiAyODgNCmRlYnVnLnNpemVv Zi5nX2Jpb3E6IDU2DQpkZWJ1Zy5zaXplb2YuZ19jb25zdW1lcjogOTYNCmRlYnVnLnNpemVvZi5n X3Byb3ZpZGVyOiAxMzYNCmRlYnVnLnNpemVvZi5nX2dlb206IDE2MA0KZGVidWcuc2l6ZW9mLmdf Y2xhc3M6IDE2MA0KZGVidWcuc2l6ZW9mLmtpbmZvX3Byb2M6IDEwODgNCmRlYnVnLnNpemVvZi5i dWY6IDYwOA0KZGVidWcuc2l6ZW9mLmJpbzogMjMyDQpkZWJ1Zy5zaXplb2YucHJvYzogMTE4NA0K ZGVidWcuc2l6ZW9mLnZub2RlOiA0ODANCmRlYnVnLnNpemVvZi5kZXZzdGF0OiAyODgNCmRlYnVn LnNpemVvZi5uYW1lY2FjaGU6IDcyDQpkZWJ1Zy5vc2Q6IDANCmRlYnVnLnRyYWNlX29uX3Bhbmlj OiAxDQpkZWJ1Zy5kZWJ1Z2dlcl9vbl9wYW5pYzogMQ0KZGVidWcubmNvcmVzOiA1DQpkZWJ1Zy50 b19hdmdfbXBjYWxsczogNzQ5DQpkZWJ1Zy50b19hdmdfbG9ja2NhbGxzOiAyODINCmRlYnVnLnRv X2F2Z19nY2FsbHM6IDQ5NA0KZGVidWcudG9fYXZnX2RlcHRoOiAxNzkwDQpkZWJ1Zy51bXR4LnVt dHhfcGlfYWxsb2NhdGVkOiAwDQpkZWJ1Zy5jbG9ja3RpbWU6IDANCmRlYnVnLmtkYi5hbHRfYnJl YWtfdG9fZGVidWdnZXI6IDANCmRlYnVnLmtkYi5icmVha190b19kZWJ1Z2dlcjogMA0KZGVidWcu a2RiLnRyYXBfY29kZTogMA0KZGVidWcua2RiLnRyYXA6IDANCmRlYnVnLmtkYi5wYW5pYzogMA0K ZGVidWcua2RiLmVudGVyOiAwDQpkZWJ1Zy5rZGIuY3VycmVudDogDQpkZWJ1Zy5ybWFuX2RlYnVn OiAwDQpkZWJ1Zy5pb3NpemVfbWF4X2NsYW1wOiAxDQpkZWJ1Zy5kaXNhYmxlZnVsbHBhdGg6IDAN CmRlYnVnLmRpc2FibGVjd2Q6IDANCmRlYnVnLnZmc2NhY2hlOiAxDQpkZWJ1Zy5udW1jYWNoZWh2 OiAyODY4Mg0KZGVidWcubnVtY2FjaGU6IDE4MjkzNg0KZGVidWcubnVtbmVnOiAxMjE4MA0KZGVi dWcubmNoYXNoOiAxMDQ4NTc1DQpkZWJ1Zy52bmxydV9ub3doZXJlOiAwDQpkZWJ1Zy5ydXNoX3Jl cXVlc3RzOiAzNzAyODENCmRlYnVnLmlmX3R1bl9kZWJ1ZzogMA0KZGVidWcubmxtX2RlYnVnOiAw DQpkZWJ1Zy5mc2NrY21kczogMA0KZGVidWcuY29sbGVjdHNuYXBzdGF0czogMA0KZGVidWcuc25h cGRlYnVnOiAwDQpkZWJ1Zy5kb3BlcnNpc3RlbmNlOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmNsZWFudXBf ZmFpbHVyZXM6IDM2OTYzNA0KZGVidWcuc29mdGRlcC5jbGVhbnVwX3JldHJpZXM6IDgyNg0KZGVi dWcuc29mdGRlcC5jbGVhbnVwX2hpZ2hfZGVsYXk6IDE0DQpkZWJ1Zy5zb2Z0ZGVwLmNsZWFudXBf aW5vcmVxdWVzdHM6IDANCmRlYnVnLnNvZnRkZXAuY2xlYW51cF9ibGtyZXF1ZXN0czogMzY5Njkw DQpkZWJ1Zy5zb2Z0ZGVwLmp3YWl0X25ld2JsazogMA0KZGVidWcuc29mdGRlcC5qd2FpdF9pbm9k ZTogMA0KZGVidWcuc29mdGRlcC5qd2FpdF9mcmVlYmxrczogMA0KZGVidWcuc29mdGRlcC5qd2Fp dF9maWxlcGFnZTogMA0KZGVidWcuc29mdGRlcC5qb3VybmFsX3dhaXQ6IDANCmRlYnVnLnNvZnRk ZXAuam91cm5hbF9taW46IDANCmRlYnVnLnNvZnRkZXAuam91cm5hbF9sb3c6IDANCmRlYnVnLnNv ZnRkZXAuam5ld2Jsa19yb2xsYmFjazogMA0KZGVidWcuc29mdGRlcC5qYWRkcmVmX3JvbGxiYWNr OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmRpcl9lbnRyeTogMjAyMDMzDQpkZWJ1Zy5zb2Z0ZGVwLmRpcmVj dF9ibGtfcHRyczogMzQyNjU1DQpkZWJ1Zy5zb2Z0ZGVwLmlub2RlX2JpdG1hcDogMjUyODI3NQ0K ZGVidWcuc29mdGRlcC5pbmRpcl9ibGtfcHRyczogMjY5MzcNCmRlYnVnLnNvZnRkZXAuc3luY19s aW1pdF9oaXQ6IDU5MQ0KZGVidWcuc29mdGRlcC5pbm9fbGltaXRfaGl0OiAwDQpkZWJ1Zy5zb2Z0 ZGVwLmJsa19saW1pdF9oaXQ6IDM2OTIyMA0KZGVidWcuc29mdGRlcC5pbm9fbGltaXRfcHVzaDog MA0KZGVidWcuc29mdGRlcC5ibGtfbGltaXRfcHVzaDogMzY5NjkwDQpkZWJ1Zy5zb2Z0ZGVwLndv cmtsaXN0X3B1c2g6IDIxNTYNCmRlYnVnLnNvZnRkZXAubWF4aW5kaXJkZXBzOiA1MA0KZGVidWcu c29mdGRlcC50aWNrZGVsYXk6IDINCmRlYnVnLnNvZnRkZXAubWF4X3NvZnRkZXBzOiAyMzUyMzA4 DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpmc3luYzogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qdHJ1 bmM6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuc2JkZXA6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUu anNlZ2RlcDogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qc2VnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndy aXRlLmpmcmVlZnJhZzogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qZnJlZWJsazogMA0KZGVidWcu c29mdGRlcC53cml0ZS5qbmV3YmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmptdnJlZjogMA0K ZGVidWcuc29mdGRlcC53cml0ZS5qcmVtcmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmphZGRy ZWY6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZWRlcDogMA0KZGVidWcuc29mdGRlcC53cml0 ZS5mcmVld29yazogMA0KZGVidWcuc29mdGRlcC53cml0ZS5uZXdkaXJibGs6IDANCmRlYnVnLnNv ZnRkZXAud3JpdGUuZGlycmVtOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLm1rZGlyOiAwDQpkZWJ1 Zy5zb2Z0ZGVwLndyaXRlLmRpcmFkZDogMA0KZGVidWcuc29mdGRlcC53cml0ZS5mcmVlZmlsZTog MA0KZGVidWcuc29mdGRlcC53cml0ZS5mcmVlYmxrczogNjkwOTQ3DQpkZWJ1Zy5zb2Z0ZGVwLndy aXRlLmZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmFsbG9jaW5kaXI6IDIzMzQ1Mzg1 ODENCmRlYnVnLnNvZnRkZXAud3JpdGUuaW5kaXJkZXA6IDExNzM1MA0KZGVidWcuc29mdGRlcC53 cml0ZS5hbGxvY2RpcmVjdDogNzY5NDAxNDMNCmRlYnVnLnNvZnRkZXAud3JpdGUubmV3YmxrOiAw DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmJtc2FmZW1hcDogMjQzNzg1Nw0KZGVidWcuc29mdGRlcC53 cml0ZS5pbm9kZWRlcDogNjkxNzE1OA0KZGVidWcuc29mdGRlcC53cml0ZS5wYWdlZGVwOiAzMjk2 NjQNCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qZnN5bmM6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVu dC5qdHJ1bmM6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5zYmRlcDogMA0KZGVidWcuc29mdGRl cC5jdXJyZW50LmpzZWdkZXA6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qc2VnOiAwDQpkZWJ1 Zy5zb2Z0ZGVwLmN1cnJlbnQuamZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuamZy ZWVibGs6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qbmV3YmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVw LmN1cnJlbnQuam12cmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuanJlbXJlZjogMA0KZGVi dWcuc29mdGRlcC5jdXJyZW50LmphZGRyZWY6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5mcmVl ZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZnJlZXdvcms6IDANCmRlYnVnLnNvZnRkZXAu Y3VycmVudC5uZXdkaXJibGs6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5kaXJyZW06IDANCmRl YnVnLnNvZnRkZXAuY3VycmVudC5ta2RpcjogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmRpcmFk ZDogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmZyZWVmaWxlOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1 cnJlbnQuZnJlZWJsa3M6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5mcmVlZnJhZzogMA0KZGVi dWcuc29mdGRlcC5jdXJyZW50LmFsbG9jaW5kaXI6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5p bmRpcmRlcDogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmFsbG9jZGlyZWN0OiAwDQpkZWJ1Zy5z b2Z0ZGVwLmN1cnJlbnQubmV3YmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuYm1zYWZlbWFw OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuaW5vZGVkZXA6IDANCmRlYnVnLnNvZnRkZXAuY3Vy cmVudC5wYWdlZGVwOiAxDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmpmc3luYzogMA0KZGVidWcuc29m dGRlcC50b3RhbC5qdHJ1bmM6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuc2JkZXA6IDANCmRlYnVn LnNvZnRkZXAudG90YWwuanNlZ2RlcDogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qc2VnOiAwDQpk ZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmpmcmVlZnJhZzogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qZnJl ZWJsazogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qbmV3YmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRv dGFsLmptdnJlZjogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qcmVtcmVmOiAwDQpkZWJ1Zy5zb2Z0 ZGVwLnRvdGFsLmphZGRyZWY6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuZnJlZWRlcDogMA0KZGVi dWcuc29mdGRlcC50b3RhbC5mcmVld29yazogODM1MTIyMjgNCmRlYnVnLnNvZnRkZXAudG90YWwu bmV3ZGlyYmxrOiAxODQwMw0KZGVidWcuc29mdGRlcC50b3RhbC5kaXJyZW06IDEzNTQxNTQyDQpk ZWJ1Zy5zb2Z0ZGVwLnRvdGFsLm1rZGlyOiAyOTQ1Ng0KZGVidWcuc29mdGRlcC50b3RhbC5kaXJh ZGQ6IDEzNTQ5MDkxDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmZyZWVmaWxlOiA2OTQ4NDY2DQpkZWJ1 Zy5zb2Z0ZGVwLnRvdGFsLmZyZWVibGtzOiA2ODQ0OTM4DQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmZy ZWVmcmFnOiA0NDE0NjUzNTINCmRlYnVnLnNvZnRkZXAudG90YWwuYWxsb2NpbmRpcjogMA0KZGVi dWcuc29mdGRlcC50b3RhbC5pbmRpcmRlcDogNjQ0OTMyNw0KZGVidWcuc29mdGRlcC50b3RhbC5h bGxvY2RpcmVjdDogMA0KZGVidWcuc29mdGRlcC50b3RhbC5uZXdibGs6IDI4ODY0NzM0MTENCmRl YnVnLnNvZnRkZXAudG90YWwuYm1zYWZlbWFwOiA5MjA4OTIyDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFs Lmlub2RlZGVwOiA4MDk3NzI5DQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLnBhZ2VkZXA6IDE0MjEwNw0K ZGVidWcuZG9ia2dyZHdyaXRlOiAxDQpkZWJ1Zy5iaWdjZ3M6IDANCmRlYnVnLmRpcmNoZWNrOiAw DQpkZWJ1Zy5wc20ucGt0ZXJydGhyZXNoOiAyDQpkZWJ1Zy5wc20udXNlY3M6IDUwMDAwMA0KZGVi dWcucHNtLnNlY3M6IDANCmRlYnVnLnBzbS5lcnJ1c2VjczogMA0KZGVidWcucHNtLmVycnNlY3M6 IDINCmRlYnVnLnBzbS5oejogMjANCmRlYnVnLnBzbS5sb2dsZXZlbDogMA0KZGVidWcudmVzYS5z aGFkb3dfcm9tOiAwDQpkZWJ1Zy5mZGMuc2V0dGxlOiAwDQpkZWJ1Zy5mZGMuc3BlYzI6IDE2DQpk ZWJ1Zy5mZGMuc3BlYzE6IDE3NQ0KZGVidWcuZmRjLnJldHJpZXM6IDEwDQpkZWJ1Zy5mZGMuZGVi dWdmbGFnczogMA0KZGVidWcuZmRjLmZpZm86IDgNCmRlYnVnLmVsZjMyX2xlZ2FjeV9jb3JlZHVt cDogMA0KZGVidWcueDg2Ymlvcy5pbnQ6IDANCmRlYnVnLng4NmJpb3MuY2FsbDogMA0KZGVidWcu aHdwc3RhdGVfdmVyYm9zZTogMA0KZGVidWcubWluaWR1bXA6IDENCisgZnN0YXQgLWYgL3Bnc3Fs DQpVU0VSICAgICBDTUQgICAgICAgICAgUElEICAgRkQgTU9VTlQgICAgICBJTlVNIE1PREUgICAg ICAgICBTWnxEViBSL1cNCisgc3lzY3RsIC1hDQorIGVncmVwIHZub2RlDQprZXJuLm1heHZub2Rl czogNTg4MDc3DQprZXJuLm1pbnZub2RlczogMTQ3MDE5DQp2bS5zdGF0cy52bS52X3Zub2RlcGdz b3V0OiAwDQp2bS5zdGF0cy52bS52X3Zub2RlcGdzaW46IDUyMTg5DQp2bS5zdGF0cy52bS52X3Zu b2Rlb3V0OiAwDQp2bS5zdGF0cy52bS52X3Zub2RlaW46IDIxOTE3DQp2ZnMuZnJlZXZub2Rlczog MTI4ODQ4DQp2ZnMud2FudGZyZWV2bm9kZXM6IDE0NzAxOQ0KdmZzLm51bXZub2RlczogMTY5NTIy DQpkZWJ1Zy5zaXplb2Yudm5vZGU6IDQ4MA0KKyBtb3VudCAtdg0KL2Rldi9kYTBzMWEgb24gLyAo dWZzLCBsb2NhbCwgd3JpdGVzOiBzeW5jIDM4OCBhc3luYyAxNjUsIHJlYWRzOiBzeW5jIDI5NjYz IGFzeW5jIDIwOTYsIGZzaWQgNmNhMTcxNGI2N2EwZTJlNikNCmRldmZzIG9uIC9kZXYgKGRldmZz LCBsb2NhbCwgbXVsdGlsYWJlbCwgZnNpZCAwMGZmMDA3MTcxMDAwMDAwKQ0KL2Rldi9kYTFzMSBv biAvb3B0ICh1ZnMsIGxvY2FsLCBzb2Z0LXVwZGF0ZXMsIHdyaXRlczogc3luYyA0MjA0MjAgYXN5 bmMgMTUxMTQ5NDIsIHJlYWRzOiBzeW5jIDE3Njg3NDg0MCBhc3luYyAxNDQyMDA0NzQsIGZzaWQg MzAzMTg1NTBmNTY3OWU4NikNCi9kZXYvZGEwczFlIG9uIC90bXAgKHVmcywgbG9jYWwsIHNvZnQt dXBkYXRlcywgd3JpdGVzOiBzeW5jIDQyIGFzeW5jIDE1NDU5LCByZWFkczogc3luYyA1MjgwIGFz eW5jIDAsIGZzaWQgNmNhMTcxNGIwMTFjZmUxYykNCi9kZXYvZGEwczFmIG9uIC91c3IgKHVmcywg bG9jYWwsIHNvZnQtdXBkYXRlcywgd3JpdGVzOiBzeW5jIDE1NDQgYXN5bmMgMjE0NDUxNCwgcmVh ZHM6IHN5bmMgMTM1Mjk2MjIgYXN5bmMgNzQxMSwgZnNpZCA2Y2ExNzE0YjdhNWNiNjE1KQ0KL2Rl di9kYTBzMWQgb24gL3ZhciAodWZzLCBsb2NhbCwgc29mdC11cGRhdGVzLCB3cml0ZXM6IHN5bmMg MTA2MjkgYXN5bmMgMTMzMTgwNSwgcmVhZHM6IHN5bmMgMjcxNDE4IGFzeW5jIDI0ODgxLCBmc2lk IDZkYTE3MTRiZTkxMzNiZmEpDQpwcm9jZnMgb24gL3Byb2MgKHByb2NmcywgbG9jYWwsIGZzaWQg MDFmZjAwMDIwMjAwMDAwMCkNCi9kZXYvZGEyczFkIG9uIC9wZ3NxbCAodWZzLCBsb2NhbCwgd3Jp dGVzOiBzeW5jIDIgYXN5bmMgMCwgcmVhZHM6IHN5bmMgMSBhc3luYyAwLCBmc2lkIDZjYTE3MTRi YmUwYjhjNGQpDQojIHNlcnZpY2UgcG9zdGdyZXNxbCBzdGFydA0KIyBeRApTY3JpcHQgZG9uZSBv biBTdW4gSnVuICAyIDIyOjI1OjMzIDIwMTMKU2NyaXB0IHN0YXJ0ZWQgb24gU3VuIEp1biAgMiAy MjoyNTozOCAyMDEzCg0KIyBzY3QIG1tLcmlwCBtbSwgbW0sIG1tLCBtbSwgbW0sHBwcHc3MIG1tL aCAteCBkaXNrc3BhY2VjaGVjay5zaCANCi5iYXNoX2hpc3RvcnkgICAgIC5jc2hyYyAgICAgICAg ICAgIC5oaXN0b3J5ICAgICAgICAgIC5rNWxvZ2luICAgICAgICAgIC5sZXNzaHN0ICAgICAgICAg IC5sb2dpbiAgICAgICAgICAgDQoubHNvZl9waW5lYXBwbGUgICAucHJvZmlsZSAgICAgICAgICAu cHNxbF9oaXN0b3J5ICAgICAucm5kICAgICAgICAgICAgICAuc3NoICAgICAgICAgICAgICAudmlt ICAgICAgICAgICAgIA0KLnZpbWluZm8gICAgICAgICAgMmJlZm9yZSAgICAgICAgICAgMmJlZm9y ZTIgICAgICAgICAgYWZ0ZXIubG9nICAgICAgICAgYmFja3VwICAgICAgICAgICAgYmFja3VwLnRh ciAgICAgICANCmJlZm9yZS5sb2cgICAgICAgIGJlZm9yZTIubG9nICAgICAgIGNlcnQgICAgICAg ICAgICAgIGRpc2tzcGFjZWNoZWNrLnNoIGluc3RhbGwuc2ggICAgICAgIGluc3RhbGxfZ3BhcnQu c2ggDQppbnN0YWxsYnNkLnNoICAgICBwb3J0cy5jdnN1cCAgICAgICBzcmMuY3ZzdXAgICAgICAg IA0KDRtbSyMgc2ggLXggZGlza3NwYWNlY2hlY2suc2ggDQorIGRmIC1paCAvcGdzcWwNCkZpbGVz eXN0ZW0gICAgIFNpemUgICAgVXNlZCAgIEF2YWlsIENhcGFjaXR5IGl1c2VkIGlmcmVlICVpdXNl ZCAgTW91bnRlZCBvbg0KL2Rldi9kYTJzMWQgICAgMTI4RyAgICAgODJHICAgICAzNkcgICAgNzAl ICAgICAyM2sgICAxN00gICAgMCUgICAvcGdzcWwNCisgdm1zdGF0IC16DQpJVEVNICAgICAgICAg ICAgICAgICAgIFNJWkUgIExJTUlUICAgICBVU0VEICAgICBGUkVFICAgICAgUkVRIEZBSUwgU0xF RVANCg0KVU1BIEtlZ3M6ICAgICAgICAgICAgICAgMjA4LCAgICAgIDAsICAgICAgODYsICAgICAg MTYsICAgICAgODYsICAgMCwgICAwDQpVTUEgWm9uZXM6ICAgICAgICAgICAgIDE0MDgsICAgICAg MCwgICAgICA4NiwgICAgICAgMCwgICAgICA4NiwgICAwLCAgIDANClVNQSBTbGFiczogICAgICAg ICAgICAgIDU2OCwgICAgICAwLCAgICA3MDA0LCAgICAgMzExLCAgNjI4NjYyLCAgIDAsICAgMA0K VU1BIFJDbnRTbGFiczogICAgICAgICAgNTY4LCAgICAgIDAsICAgIDQ1OTEsICAgICA1NzUsICAz OTI4NjksICAgMCwgICAwDQpVTUEgSGFzaDogICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMywgICAwLCAgIDANCjE2IEJ1Y2tldDogICAgICAgICAgICAg IDE1MiwgICAgICAwLCAgICAgIDI3LCAgICAgIDczLCAgICAgMjExLCAgIDAsICAgMA0KMzIgQnVj a2V0OiAgICAgICAgICAgICAgMjgwLCAgICAgIDAsICAgICAgNDcsICAgICAxNDksICAgICAzMzks ICAgNiwgICAwDQo2NCBCdWNrZXQ6ICAgICAgICAgICAgICA1MzYsICAgICAgMCwgICAgICA3OCwg ICAgICA3NiwgICAgIDc1MiwgIDkwLCAgIDANCjEyOCBCdWNrZXQ6ICAgICAgICAgICAgMTA0OCwg ICAgICAwLCAgICAxODA4LCAgICAgICAxLCAxNTU3MjI4LDE1MzQ5OTY5LCAgIDANClZNIE9CSkVD VDogICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgMTU1Mzk5LCAgIDMwNjMzLDE0MTk0NDgwNywg ICAwLCAgIDANCk1BUDogICAgICAgICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgICAgICA3LCAg ICAgIDI1LCAgICAgICA3LCAgIDAsICAgMA0KS01BUCBFTlRSWTogICAgICAgICAgICAgMTIwLCAx MTI4NzEwLCAgIDEzMDkxLCAgIDM4MTIxLDE3OTM3NzIwNTksICAgMCwgICAwDQpNQVAgRU5UUlk6 ICAgICAgICAgICAgICAxMjAsICAgICAgMCwgICAgMTM4OCwgICAgNDM3OCwzMDE5NTQyMTYsICAg MCwgICAwDQpmYWtlcGc6ICAgICAgICAgICAgICAgICAxMjAsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDANCm10X3pvbmU6ICAgICAgICAgICAgICAgNDExMiwgICAg ICAwLCAgICAgMzI2LCAgICAgICAxLCAgICAgMzI2LCAgIDAsICAgMA0KMTY6ICAgICAgICAgICAg ICAgICAgICAgIDE2LCAgICAgIDAsICAgIDIzMzAsICAgIDIwMzgsMTUxODUwMzQsICAgMCwgICAw DQozMjogICAgICAgICAgICAgICAgICAgICAgMzIsICAgICAgMCwgICAgMjc4OSwgICAgMTY1NSw1 MDIwMDQzNCwgICAwLCAgIDANCjY0OiAgICAgICAgICAgICAgICAgICAgICA2NCwgICAgICAwLCAg ICA1MzQ1LCAgICA0Mjg3LDgzMDg2MDM5LCAgIDAsICAgMA0KMTI4OiAgICAgICAgICAgICAgICAg ICAgMTI4LCAgICAgIDAsICAgIDk4NjIsICAgIDQ3MjUsNjg5NTE1NjU2LCAgIDAsICAgMA0KMjU2 OiAgICAgICAgICAgICAgICAgICAgMjU2LCAgICAgIDAsICAgICA1NzgsICAgMzM0NzIsMjkyMDI1 MTQyNiwgICAwLCAgIDANCjUxMjogICAgICAgICAgICAgICAgICAgIDUxMiwgICAgICAwLCAgICAy Nzg0LCAgICAyMzQ3LDE4MTMwMjgwLCAgIDAsICAgMA0KMTAyNDogICAgICAgICAgICAgICAgICAx MDI0LCAgICAgIDAsICAgICAgNTksICAgIDEzMzMsIDIyMDY2MjMsICAgMCwgICAwDQoyMDQ4OiAg ICAgICAgICAgICAgICAgIDIwNDgsICAgICAgMCwgICAgNTY0MCwgICAgMTI2MiwgNDEzNTc3Niwg ICAwLCAgIDANCjQwOTY6ICAgICAgICAgICAgICAgICAgNDA5NiwgICAgICAwLCAgICAgNDM4LCAg ICAxMTYyLCA1MzI3MjcxLCAgIDAsICAgMA0KRmlsZXM6ICAgICAgICAgICAgICAgICAgIDgwLCAg ICAgIDAsICAgICAyODYsICAgMTA5MTksMTk5MjEzMjY1LCAgIDAsICAgMA0KVFVSTlNUSUxFOiAg ICAgICAgICAgICAgMTM2LCAgICAgIDAsICAgIDE5MzksICAgICAxMjEsICAgIDE5NDgsICAgMCwg ICAwDQp1bXR4IHBpOiAgICAgICAgICAgICAgICAgOTYsICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDANCk1BQyBsYWJlbHM6ICAgICAgICAgICAgICA0MCwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KUFJPQzogICAgICAgICAgICAg ICAgICAxMTg0LCAgICAgIDAsICAgICAgNTgsICAgIDE0MjcsIDQ1NDY0OTksICAgMCwgICAwDQpU SFJFQUQ6ICAgICAgICAgICAgICAgIDExMjgsICAgICAgMCwgICAgMTU0OSwgICAgIDM4OSwgICAg MTk2MywgICAwLCAgIDANClNMRUVQUVVFVUU6ICAgICAgICAgICAgICA4MCwgICAgICAwLCAgICAx OTM5LCAgICAgMjY1LCAgICAxOTQ4LCAgIDAsICAgMA0KVk1TUEFDRTogICAgICAgICAgICAgICAg MzkyLCAgICAgIDAsICAgICAgMzksICAgIDE1NTEsIDQ1NDY0ODIsICAgMCwgICAwDQpjcHVzZXQ6 ICAgICAgICAgICAgICAgICAgNzIsICAgICAgMCwgICAgICA4NSwgICAgICA2NSwgICAgICA4NSwg ICAwLCAgIDANCmF1ZGl0X3JlY29yZDogICAgICAgICAgIDk2MCwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KbWJ1Zl9wYWNrZXQ6ICAgICAgICAgICAgMjU2LCAg ICAgIDAsICAgIDQwODAsICAgIDE2ODAsNjk3ODA0MDA1LCAgIDAsICAgMA0KbWJ1ZjogICAgICAg ICAgICAgICAgICAgMjU2LCAgICAgIDAsICAgIDEwMjQsICAgIDE3MjEsMTk2MjgyNjQ4MCwgICAw LCAgIDANCm1idWZfY2x1c3RlcjogICAgICAgICAgMjA0OCwgIDI1NjAwLCAgICA1NzYwLCAgICAx MjU0LCAxNzA4NTQ0LCAgIDAsICAgMA0KbWJ1Zl9qdW1ib19wYWdlOiAgICAgICA0MDk2LCAgMTI4 MDAsICAgICAgIDAsICAgIDEwODQsODM1MDUzMDQsICAgMCwgICAwDQptYnVmX2p1bWJvXzlrOiAg ICAgICAgIDkyMTYsICAgNjQwMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAN Cm1idWZfanVtYm9fMTZrOiAgICAgICAxNjM4NCwgICAzMjAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMA0KbWJ1Zl9leHRfcmVmY250OiAgICAgICAgICA0LCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpnX2JpbzogICAgICAgICAgICAgICAg ICAyMzIsICAgICAgMCwgICAgICAgMCwgICAgMTU4NCwyOTc3ODUwMTk5LCAgIDAsICAgMA0KdHR5 aW5xOiAgICAgICAgICAgICAgICAgMTYwLCAgICAgIDAsICAgICAxNTAsICAgICA0NzQsICAgIDI2 NDAsICAgMCwgICAwDQp0dHlvdXRxOiAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgICA4 MCwgICAgIDM0MCwgICAgMTQwOCwgICAwLCAgIDANCmF0YV9yZXF1ZXN0OiAgICAgICAgICAgIDMy OCwgICAgICAwLCAgICAgICAwLCAgICAgIDg0LCAgICAgIDMyLCAgIDAsICAgMA0KYXRhX2NvbXBv c2l0ZTogICAgICAgICAgMzM2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwDQpWTk9ERTogICAgICAgICAgICAgICAgICA0ODAsICAgICAgMCwgIDE2OTgyNSwgICA5 NTU3NSwxNTg5NzgxMzEsICAgMCwgICAwDQpWTk9ERVBPTEw6ICAgICAgICAgICAgICAxMTIsICAg ICAgMCwgICAgICAgMCwgICAgIDEzMiwgICAgICAgNiwgICAwLCAgIDANCk5BTUVJOiAgICAgICAg ICAgICAgICAgMTAyNCwgICAgICAwLCAgICAgICAwLCAgICAxMjEyLDQzMjM3OTgwNiwgICAwLCAg IDANClMgVkZTIENhY2hlOiAgICAgICAgICAgIDEwOCwgICAgICAwLCAgMTcwMzk5LCAgMTA3NDI4 LDE2MzMwODcwNywgICAwLCAgIDANClNUUyBWRlMgQ2FjaGU6ICAgICAgICAgIDE0OCwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KTCBWRlMgQ2FjaGU6ICAgICAg ICAgICAgMzI4LCAgICAgIDAsICAgMTI1MDYsICAgIDQyMTAsIDc2MjI4MjIsICAgMCwgICAwDQpM VFMgVkZTIENhY2hlOiAgICAgICAgICAzNjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDANCk5DTE5PREU6ICAgICAgICAgICAgICAgIDU2OCwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KRElSSEFTSDogICAgICAgICAgICAgICAx MDI0LCAgICAgIDAsICAgICA3NzgsICAgIDEwMzgsIDMwODU5ODMsICAgMCwgICAwDQpNb3VudHBv aW50czogICAgICAgICAgICA3OTIsICAgICAgMCwgICAgICAgOCwgICAgICAzMiwgICAgICAxMCwg ICAwLCAgIDANCnBpcGU6ICAgICAgICAgICAgICAgICAgIDcyOCwgICAgICAwLCAgICAgIDEyLCAg ICAxMzE4LCAzOTc1NzEyLCAgIDAsICAgMA0Ka3NpZ2luZm86ICAgICAgICAgICAgICAgMTEyLCAg ICAgIDAsICAgIDE0NzQsICAgIDE0MzAsMTAxMTQwNjUsICAgMCwgICAwDQppdGltZXI6ICAgICAg ICAgICAgICAgICAzNDQsICAgICAgMCwgICAgICAgMSwgICAgICAyMSwgICAgICAgMSwgICAwLCAg IDANCktOT1RFOiAgICAgICAgICAgICAgICAgIDEyOCwgICAgICAwLCAgICAgICAwLCAgICAxNzEx LCAxMTE0OTQ3LCAgIDAsICAgMA0Kc29ja2V0OiAgICAgICAgICAgICAgICAgNjgwLCAxMDAwMDIs ICAgICAgMzksICAgIDE0MTksIDk2MzQyNzYsICAgMCwgICAwDQppcHE6ICAgICAgICAgICAgICAg ICAgICAgNTYsICAgIDgxOSwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnVk cF9pbnBjYjogICAgICAgICAgICAgIDM5MiwgMTAwMDAwLCAgICAgIDEzLCAgICAxNTQ3LCA3NTYx NzIxLCAgIDAsICAgMA0KdWRwY2I6ICAgICAgICAgICAgICAgICAgIDE2LCAxMDAxMjgsICAgICAg MTMsICAgIDE4MzUsIDc1NjE3MjEsICAgMCwgICAwDQp0Y3BfaW5wY2I6ICAgICAgICAgICAgICAz OTIsIDEwMDAwMCwgICAgICAxNCwgICAgMTc0NiwgIDY2MzQyMSwgICAwLCAgIDANCnRjcGNiOiAg ICAgICAgICAgICAgICAgIDk3NiwgMTAwMDAwLCAgICAgIDEyLCAgICAxNzYwLCAgNjYzNDIxLCAg IDAsICAgMA0KdGNwdHc6ICAgICAgICAgICAgICAgICAgIDcyLCAgMjAwMDAsICAgICAgIDIsICAg ICA1NDgsICAgIDMyODksICAgMCwgICAwDQpzeW5jYWNoZTogICAgICAgICAgICAgICAxNTIsICAx NTM3NSwgICAgICAgMCwgICAgIDYyNSwgIDUxNDY2OCwgICAwLCAgIDANCmhvc3RjYWNoZTogICAg ICAgICAgICAgIDEzNiwgIDE1MzcyLCAgICAgICA1LCAgICAgNDk5LCAgICAxODc5LCAgIDAsICAg MA0KdGNwcmVhc3M6ICAgICAgICAgICAgICAgIDQwLCAgIDE2ODAsICAgICAgIDAsICAgIDE1OTYs ICAgMjE3NjcsICAgMCwgICAwDQpzYWNraG9sZTogICAgICAgICAgICAgICAgMzIsICAgICAgMCwg ICAgICAgMCwgICAgIDkwOSwgICAgIDg5NywgICAwLCAgIDANCnNjdHBfZXA6ICAgICAgICAgICAg ICAgMTM3NiwgMTAwMDAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0Kc2N0 cF9hc29jOiAgICAgICAgICAgICAyMjg4LCAgNDAwMDAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwDQpzY3RwX2xhZGRyOiAgICAgICAgICAgICAgNDgsICA4MDA2NCwgICAgICAg MCwgICAgIDI4OCwgICAgICAgNiwgICAwLCAgIDANCnNjdHBfcmFkZHI6ICAgICAgICAgICAgIDcw NCwgIDgwMDAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0Kc2N0cF9jaHVu azogICAgICAgICAgICAgMTM2LCA0MDAwMDgsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwDQpzY3RwX3JlYWRxOiAgICAgICAgICAgICAxMDQsIDQwMDAzMiwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfc3RyZWFtX21zZ19vdXQ6ICAgIDExMiwgNDAw MDI2LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0Kc2N0cF9hc2NvbmY6ICAg ICAgICAgICAgIDQwLCA0MDAwMDgsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw DQpzY3RwX2FzY29uZl9hY2s6ICAgICAgICAgNDgsIDQwMDAzMiwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDANCnJpcGNiOiAgICAgICAgICAgICAgICAgIDM5MiwgMTAwMDAwLCAg ICAgICAwLCAgICAgMTAwLCAgICAgMTI2LCAgIDAsICAgMA0KdW5wY2I6ICAgICAgICAgICAgICAg ICAgMjQwLCAxMDAwMDAsICAgICAgMTMsICAgIDEzMTUsIDE0MDkwMDIsICAgMCwgICAwDQpydGVu dHJ5OiAgICAgICAgICAgICAgICAyMDAsICAgICAgMCwgICAgICAyMywgICAgICA5MSwgICAgICAy MywgICAwLCAgIDANCnNlbGZkOiAgICAgICAgICAgICAgICAgICA1NiwgICAgICAwLCAgICAyMDAy LCAgICAxMzM3LDMwOTM5NDg2OSwgICAwLCAgIDANClNXQVBNRVRBOiAgICAgICAgICAgICAgIDI4 OCwgMTE2NTE5LCAgICAgIDQwLCAgICAgNTU4LCAxMDcyMTIwLCAgIDAsICAgMA0KRkZTIGlub2Rl OiAgICAgICAgICAgICAgMTY4LCAgICAgIDAsICAxNjU2MTgsICAgOTc4NTQsMTU4OTc1Nzk4LCAg IDAsICAgMA0KRkZTMSBkaW5vZGU6ICAgICAgICAgICAgMTI4LCAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpGRlMyIGRpbm9kZTogICAgICAgICAgICAyNTYsICAg ICAgMCwgIDE2NTYxOCwgICA5NzY3NywxNTg5NzU3OTEsICAgMCwgICAwDQoNCisgdm1zdGF0IC1t DQogICAgICAgICBUeXBlIEluVXNlIE1lbVVzZSBIaWdoVXNlIFJlcXVlc3RzICBTaXplKHMpDQpD QU0gZGV2IHF1ZXVlICAgICA0ICAgICAxSyAgICAgICAtICAgICAgICA0ICAxMjgNCiAgbWRfc2lp X2RhdGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgNTAgIDUxMg0KICAgICAgQ0FNIFhQVCAg IDU3MSAgMTA0NUsgICAgICAgLSAgICAgIDk1OCAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgN CiAgICAgICBpc2FkZXYgICAgIDggICAgIDFLICAgICAgIC0gICAgICAgIDggIDEyOA0KICAgICAg ICAgVUFSVCAgICAgNiAgICAgNEsgICAgICAgLSAgICAgICAgNiAgMTYsNTEyLDEwMjQNCiAgICAg YWNwaWludHIgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0DQogICAgICAgICBjZGV2 ICAgICA3ICAgICAySyAgICAgICAtICAgICAgICA3ICAyNTYNCiAgICAgICBhY3BpY2EgIDE0NTEg ICAxMzlLICAgICAgIC0gIDY1MzE3ODIgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQNCiAgICAg ICAgc2lnaW8gICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0DQogICAgIGZpbGVkZXNj ICAgIDgwICAgIDgwSyAgICAgICAtICA1MDUzMzcwICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0 LDIwNDgsNDA5Ng0KICAgICAgICAga2VudiAgICA3OCAgICAxMUsgICAgICAgLSAgICAgICA4OSAg MTYsMzIsNjQsMTI4DQogICAgICAga3F1ZXVlICAgICAwICAgICAwSyAgICAgICAtICAxMDczODEx ICAyNTYsNTEyLDIwNDgNCiAgICBwcm9jLWFyZ3MgICAgMzkgICAgIDNLICAgICAgIC0gIDcxODU3 NjMgIDE2LDMyLDY0LDEyOCwyNTYNCiAgICAgICAgaGhvb2sgICAgIDIgICAgIDFLICAgICAgIC0g ICAgICAgIDIgIDEyOA0KICAgICBhY3BpdGFzayAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAg MSAgMjA0OA0KICAgICAgaXRocmVhZCAgICA5OSAgICAxNksgICAgICAgLSAgICAgICA5OSAgMzIs MTI4LDI1Ng0KICAgIENBTSBxdWV1ZSAgICAxOSAgICAgN0sgICAgICAgLSAgICAgIDQwNyAgMTYs MzIsNjQsMTI4LDI1Niw1MTIsMjA0OA0KICAgICAgIEtUUkFDRSAgIDEwMCAgICAxM0sgICAgICAg LSAgICAgIDEwMCAgMTI4DQogICAgICAgbGlua2VyICAgMTU4ICAgIDExSyAgICAgICAtICAgICAg MTYwICAxNiwzMiw2NCw1MTINCiAgICAgICAgbG9ja2YgICAgMjAgICAgIDNLICAgICAgIC0gICAg MjQ4NDAgIDY0LDEyOA0KICAgbG9naW5jbGFzcyAgICAgMiAgICAgMUsgICAgICAgLSAgICA2MTA1 NCAgNjQNCiAgICAgICBpcDZuZHAgICAgMTIgICAgIDFLICAgICAgIC0gICAgICAgMTQgIDY0LDEy OA0KICAgICAgICAgdGVtcCAgICA1MSAgICAgMksgICAgICAgLSAgODQwNjU0NiAgMTYsMzIsNjQs MTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgICBkZXZidWYgIDg2NDggNDE4ODlLICAg ICAgIC0gICAgMTAxNDMgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2DQogICAg ICAgbW9kdWxlICAgNDc3ICAgIDYwSyAgICAgICAtICAgICAgNDc3ICAxMjgNCiAgICBjaXNzX2Rh dGEgICAgMTUgICAgMTRLICAgICAgIC0gICAgIDY3NDkgIDE2LDEyOCwyNTYsNTEyLDEwMjQsMjA0 OCw0MDk2DQogICAgIG10eF9wb29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICANCiAg ICAgICBVU0JkZXYgICAgMzQgICAgIDhLICAgICAgIC0gICAgICAgNDQgIDY0LDEyOCw1MTIsNDA5 Ng0KICAgICAgICAgIFVTQiAgICA1MiAgICAzMUsgICAgICAgLSAgICAgICA2NiAgMTYsMzIsNjQs MTI4LDI1NiwyMDQ4LDQwOTYNCiAgICAgcG1jaG9va3MgICAgIDEgICAgIDFLICAgICAgIC0gICAg ICAgIDEgIDEyOA0KICAgICAgc3VicHJvYyAgMTU0NiAgIDk4MEsgICAgICAgLSAgNDU0Nzk4OCAg NTEyLDQwOTYNCiAgICAgICAgIHByb2MgICAgIDIgICAgMTZLICAgICAgIC0gICAgICAgIDIgIA0K ICAgICAgc2Vzc2lvbiAgICAzMiAgICAgNEsgICAgICAgLSAgMzY3MDI2NSAgMTI4DQogICAgICAg ICBwZ3JwICAgIDM3ICAgICA1SyAgICAgICAtICAzNjc0OTc0ICAxMjgNCiAgICAgICAgIGNyZWQg ICAgNTIgICAgIDlLICAgICAgIC0gMzM1NjUwODYgIDY0LDI1Ng0KICAgICAgdWlkaW5mbyAgICAg NiAgICAgM0sgICAgICAgLSAgIDE5MDY4NiAgMTI4LDIwNDgNCiAgICAgICBwbGltaXQgICAgMTYg ICAgIDRLICAgICAgIC0gICA3OTY3MjEgIDI1Ng0KICAgICAgYXRhX3BjaSAgICAgMSAgICAgMUsg ICAgICAgLSAgICAgICAgMSAgNjQNCiAgICAgIHNjc2lfY2QgICAgIDAgICAgIDBLICAgICAgIC0g ICAgICAgMTAgIDE2DQogICAgc3lzY3RsdG1wICAgICAwICAgICAwSyAgICAgICAtICAgIDE1NjEy ICAxNiwzMiw2NCwxMjgsNDA5Ng0KICAgIHN5c2N0bG9pZCAgNDk3OCAgIDI1MUsgICAgICAgLSAg ICAgNTM2MCAgMTYsMzIsNjQsMTI4DQogICAgICAgc3lzY3RsICAgICAwICAgICAwSyAgICAgICAt ICA4MjI0Mjc4ICAxNiwzMiw2NA0KICAgICAgdGlkaGFzaCAgICAgMSAgICAxNksgICAgICAgLSAg ICAgICAgMSAgDQogICAgICBjYWxsb3V0ICAgICA3IDE0MzM2SyAgICAgICAtICAgICAgICA3ICAN CiAgICAgICAgIHVtdHggIDM4NzYgICA0ODVLICAgICAgIC0gICAgIDM4OTQgIDEyOA0KICAgICBw MTAwMy4xYiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYNCiAgICAgICAgIFNXQVAg ICAgIDIgICA1NDlLICAgICAgIC0gICAgICAgIDIgIDY0DQogICAgICAgYnVzLXNjICAgMTEzICAg NzgxSyAgICAgICAtICAgICA1MjM0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5 Ng0KICAgICAgICAgIGJ1cyAgMTI4MiAgIDEwOUsgICAgICAgLSAgICAxMTE5OCAgMTYsMzIsNjQs MTI4LDI1NiwxMDI0DQogICAgICBkZXZzdGF0ICAgIDEyICAgIDI1SyAgICAgICAtICAgICAgIDEy ICAzMiw0MDk2DQogZXZlbnRoYW5kbGVyICAgIDc3ICAgICA2SyAgICAgICAtICAgICAgIDc3ICA2 NCwxMjgNCiAgICAgIGFjcGlzZW0gICAgMTkgICAgIDNLICAgICAgIC0gICAgICAgMTkgIDEyOA0K ICAgICAgICAga29iaiAgIDMzMCAgMTMyMEsgICAgICAgLSAgICAgIDY5OCAgNDA5Ng0KICAgICAg Q0FNIFNJTSAgICAgNSAgICAgMksgICAgICAgLSAgICAgICAgNSAgMjU2DQogICAgICBQZXItY3B1 ICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAzMg0KICAgQ0FNIHBlcmlwaCAgICAxMCAg ICAgM0sgICAgICAgLSAgICAgICA1NCAgMTYsMzIsNjQsMTI4LDI1Ng0KICAgICAgICAgcm1hbiAg IDI0OCAgICAyNksgICAgICAgLSAgICAgIDYxMyAgMTYsMzIsMTI4DQogICAgICAgICBzYnVmICAg ICAxICAgICAxSyAgICAgICAtICAgICAzOTUyICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIw NDgsNDA5Ng0KICAgICAgZW50cm9weSAgMTAyNCAgICA2NEsgICAgICAgLSAgICAgMTAyNCAgNjQN CiAgICAgICBjdGxtZW0gIDUwNjIgMTAxMTNLICAgICAgIC0gICAgIDUwNjIgIDEyOCwyMDQ4DQog ICAgICAgIHN0YWNrICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDEyICAyNTYNCiAgICB0YXNr cXVldWUgICAgMTUgICAgIDJLICAgICAgIC0gICAgICAgMTUgIDE2LDMyLDEyOA0KICAgICAgIFVu aXRubyAgICAxNCAgICAgMUsgICAgICAgLSAgIDYxMTIyMiAgMzIsNjQNCiAgICAgICAgICBpb3Yg ICAgIDAgICAgIDBLICAgICAgIC0gIDE2MTAyNzUgIDE2LDMyLDY0LDEyOCwyNTYsNTEyDQogICAg ICAgc2VsZWN0ICAxNDU2ICAgMTgySyAgICAgICAtICAgICAxNDU2ICAxMjgNCiAgICAgaW9jdGxv cHMgICAgIDAgICAgIDBLICAgICAgIC0gIDg3NzYzNjUgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEw MjQsMjA0OCw0MDk2DQogICAgICAgICAgbXNnICAgICA0ICAgIDMwSyAgICAgICAtICAgICAgICA0 ICAyMDQ4LDQwOTYNCiAgICAgICAgICBzZW0gICAgIDQgICAxOTZLICAgICAgIC0gICAgICAgIDQg IA0KICAgICAgICAgIHNobSAgICAxMCAgICAzOEsgICAgICAgLSAgMzQ2NDg2MiAgMjA0OA0KICAg ICAgICAgIHR0eSAgICAyNCAgICAyNEsgICAgICAgLSAgICAgIDE2OCAgMTAyNCwyMDQ4DQogICAg ICAgICAgcHRzICAgICAzICAgICAxSyAgICAgICAtICAgICAgMTM1ICAyNTYNCiAgICAgbWJ1Zl90 YWcgICAgIDAgICAgIDBLICAgICAgIC0gNDQ1MjkwNjkgIDMyLDEyOA0KICAgICAgICBzaG1mZCAg ICAgMSAgICAgOEsgICAgICAgLSAgICAgICAgMSAgDQogICAgICAgICAgcGNiICAgIDIzICAgMTU3 SyAgICAgICAtICAgNjM4ODE3ICAxNiwzMiwxMjgsMTAyNCwyMDQ4LDQwOTYNCiAgICAgICBzb25h bWUgICAgIDUgICAgIDFLICAgICAgIC0gNTM1ODAxODMgIDE2LDMyLDEyOA0KICAgICAgICAgIGFj bCAgICAgMCAgICAgMEsgICAgICAgLSAgIDE0NjYwOSAgNDA5Ng0KICAgICAgIGJpb2J1ZiAgICAg MSAgICAgMksgICAgICAgLSAgICAxNDY5MiAgMjA0OA0KICAgICB2ZnNjYWNoZSAgICAgMSAgODE5 MksgICAgICAgLSAgICAgICAgMSAgDQogICBjbF9zYXZlYnVmICAgICAwICAgICAwSyAgICAgICAt IDEwNTAwMjQzNiAgNjQsMTI4DQogICAgIHZmc19oYXNoICAgICAxICA0MDk2SyAgICAgICAtICAg ICAgICAxICANCiAgICAgICBERVZGUzEgICAxMTYgICAgNThLICAgICAgIC0gICAgICAyNzQgIDUx Mg0KICAgICAgIHZub2RlcyAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgNCAgNjQsMjU2DQog ICAgICAgREVWRlMzICAgMTMyICAgIDMzSyAgICAgICAtICAgICAgMzI3ICAyNTYNCiAgICAgICAg bW91bnQgICAxMDYgICAgIDVLICAgICAgIC0gICAgICAyMDYgIDE2LDMyLDY0LDEyOCwyNTYNCiAg dm5vZGVtYXJrZXIgICAgIDAgICAgIDBLICAgICAgIC0gIDUyMTI2MzIgIDUxMg0KICAgICAgICAg IEJQRiAgICAgOSAgICAgMksgICAgICAgLSAgICAgICAgOSAgMTI4DQogIGV0aGVyX211bHRpICAg IDU2ICAgICAzSyAgICAgICAtICAgICAgIDY2ICAxNiwzMiw2NA0KICAgICAgIGlmYWRkciAgICA4 NyAgICAyMksgICAgICAgLSAgICAgICA4NyAgMzIsNjQsMTI4LDI1Niw1MTIsNDA5Ng0KICAgICAg ICBpZm5ldCAgICAxMCAgICAxOUsgICAgICAgLSAgICAgICAxMCAgMTI4LDIwNDgNCiAgICAgICAg Y2xvbmUgICAgIDYgICAgMjRLICAgICAgIC0gICAgICAgIDYgIDQwOTYNCiAgICAgICBhcnBjb20g ICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDE2DQogICAgICBsbHRhYmxlICAgIDMyICAg IDEzSyAgICAgICAtICAgIDU5MzE3ICAyNTYsNTEyDQogICAgICAgIERFVkZTICAgIDE3ICAgICAx SyAgICAgICAtICAgICAgIDIwICAxNiwxMjgNCiAgICAgICBERVZGU1AgICAgIDEgICAgIDFLICAg ICAgIC0gICAgICAgIDIgIDY0DQogICAgIHJvdXRldGJsICAgIDQ0ICAgICA2SyAgICAgICAtICAx NTE0Mzc4ICAzMiw2NCwxMjgsMjU2LDUxMg0KICAgICAgICAgaWdtcCAgICAgOSAgICAgM0sgICAg ICAgLSAgICAgICAgOSAgMjU2DQogICAgIGluX211bHRpICAgICAzICAgICAxSyAgICAgICAtICAg ICAgICAzICAyNTYNCiAgICBzY3RwX2l0ZXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDQg IDI1Ng0KICAgICBzY3RwX2lmbiAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMTI4DQog ICAgIHNjdHBfaWZhICAgICA3ICAgICAxSyAgICAgICAtICAgICAgICA3ICAxMjgNCiAgICAgc2N0 cF92cmYgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0DQogICAgc2N0cF9hX2l0ICAg ICAwICAgICAwSyAgICAgICAtICAgICAgICA0ICAxNg0KICAgIGhvc3RjYWNoZSAgICAgMSAgICAy OEsgICAgICAgLSAgICAgICAgMSAgDQogICAgIHN5bmNhY2hlICAgICAxICAgIDk2SyAgICAgICAt ICAgICAgICAxICANCiAgICBpbjZfbXVsdGkgICAgMjggICAgIDRLICAgICAgIC0gICAgICAgMjgg IDMyLDI1Ng0KICAgICAgICAgIG1sZCAgICAgOSAgICAgMksgICAgICAgLSAgICAgICAgOSAgMTI4 DQogICAgICAgICAgcnBjICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAyNTYNCmF1ZGl0 X2V2Y2xhc3MgICAxNzkgICAgIDZLICAgICAgIC0gICAgICAyMTggIDMyDQogICAgIHNhdmVkaW5v ICAgICAwICAgICAwSyAgICAgICAtICAzMTE0NTgzICAyNTYNCiAgICAgZnJlZXdvcmsgICAgIDEg ICAgIDFLICAgICAgIC0gODM1MTIyMjkgIDE2LDEyOA0KICAgIG5ld2RpcmJsayAgICAgMCAgICAg MEsgICAgICAgLSAgICAxODQwMyAgNjQNCiAgICAgICBkaXJyZW0gICAgIDAgICAgIDBLICAgICAg IC0gMTM1NDE1NDIgIDEyOA0KICAgICAgICBta2RpciAgICAgMCAgICAgMEsgICAgICAgLSAgICAy OTQ1NiAgMTI4DQogICAgICAgZGlyYWRkICAgICAxICAgICAxSyAgICAgICAtIDEzNTQ5MDkzICAx MjgNCiAgICAgZnJlZWZpbGUgICAgIDAgICAgIDBLICAgICAgIC0gIDY5NDg0NjYgIDY0DQogICAg IGZyZWVibGtzICAgICAwICAgICAwSyAgICAgICAtICA2ODQ0OTM4ICAxMjgNCiAgICAgZnJlZWZy YWcgICAgIDAgICAgIDBLICAgICAgIC0gNDQxNDY1MzUyICAxMjgNCiAgICAgaW5kaXJkZXAgICAg IDAgICAgIDBLICAgICAgIC0gIDY0NzYyNjQgIDEyOA0KICAgICAgIG5ld2JsayAgICAgMSAgIDUx MksgICAgICAgLSAyODg2NDczNDEzICAyNTYNCiAgICBibXNhZmVtYXAgICAgIDIgICAgIDlLICAg ICAgIC0gIDkyMDg5MjUgIDI1Ng0KICAgICBpbm9kZWRlcCAgICAgMiAgNDA5N0sgICAgICAgLSAg ODA5NzczMiAgNTEyDQogICAgICBwYWdlZGVwICAgICAzICAgNTEzSyAgICAgICAtICAgMTQyMTEw ICAyNTYNCiAgdWZzX2Rpcmhhc2ggICA3NjcgICAzNTlLICAgICAgIC0gICA0MTM4NjIgIDE2LDMy LDY0LDEyOCwyNTYsNTEyLDEwMjQNCiAgICB1ZnNfbW91bnQgICAgMTggICAgNjlLICAgICAgIC0g ICAgICAgMjQgIDUxMiwyMDQ4LDQwOTYNCiAgICB2bV9wZ2RhdGEgICAgIDIgICAxMjlLICAgICAg IC0gICAgICAgIDIgIDEyOA0KICAgICAgVU1BSGFzaCAgICAgMyAgICAyMksgICAgICAgLSAgICAg ICAxMyAgNTEyLDEwMjQsMjA0OCw0MDk2DQogICAgICBtZW1kZXNjICAgICAxICAgICA0SyAgICAg ICAtICAgICAgICAxICA0MDk2DQogICAgIGF0a2JkZGV2ICAgICAyICAgICAxSyAgICAgICAtICAg ICAgICAyICA2NA0KICAgIHBmc19ub2RlcyAgICAyMSAgICAgNksgICAgICAgLSAgICAgICAyMSAg MjU2DQogIHBmc192bmNhY2hlICAgICAwICAgICAwSyAgICAgICAtICAgICAgMjY4ICA2NA0KICAg ICAgIGN0bGJsayAgIDIwMCAgMTYwMEsgICAgICAgLSAgICAgIDIwMCAgDQogICAgICAgICBHRU9N ICAgMTI3ICAgIDQwSyAgICAgICAtICAgICAxNjg4ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0 LDIwNDgNCiAgICAgIHJhbWRpc2sgICAgIDEgIDQwOTZLICAgICAgIC0gICAgICAgIDEgIA0KICAg ICAgYWNwaWRldiAgICAzMCAgICAgMksgICAgICAgLSAgICAgICAzMCAgNjQNCiAgICAgIGN0bHBv b2wgICA1MzIgICAxNDJLICAgICAgIC0gICAgICA1MzIgIDMyLDUxMg0KICAgICAgIGtiZG11eCAg ICAgNyAgICAxOEsgICAgICAgLSAgICAgICAgOCAgMTYsNTEyLDEwMjQsMjA0OA0KICAgICAgIGFw bWRldiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4DQogICBtYWR0X3RhYmxlICAg ICAwICAgICAwSyAgICAgICAtICAgICAgICAxICA0MDk2DQogICAgICAgZmVlZGVyICAgICA3ICAg ICAxSyAgICAgICAtICAgICAgICA3ICAzMg0KICAgICAgc2NzaV9kYSAgICAgMCAgICAgMEsgICAg ICAgLSAgICAgIDM2MCAgMTYNCiAgICAgcGNpX2xpbmsgICAgMTYgICAgIDJLICAgICAgIC0gICAg ICAgMTYgIDE2LDEyOA0KICAgIHJhaWRfZGF0YSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgIDMw NiAgMzIsMTI4LDI1Ng0KICAgICAgaW9fYXBpYyAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAg MSAgMjA0OA0KICAgICAgICAgIE1DQSAgICAgOCAgICAgMUsgICAgICAgLSAgICAgICAgOCAgMTI4 DQogICAgICAgICAgbXNpICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAxMjgNCiAgICAg bmV4dXNkZXYgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDE2DQptZF9udmlkaWFfZGF0 YSAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICA1MCAgNTEyDQorIHN5c2N0bCBkZWJ1Zw0KZGVi dWcuYWNwaS5zdXNwZW5kX2JvdW5jZTogMA0KZGVidWcuYWNwaS5yZXNldF9jbG9jazogMQ0KZGVi dWcuYWNwaS5pbnRlcnByZXRlcl9zbGFjazogMQ0KZGVidWcuYWNwaS5lbmFibGVfZGVidWdfb2Jq ZWN0czogMA0KZGVidWcuYWNwaS5hY3BpX2NhX3ZlcnNpb246IDIwMTEwNTI3DQpkZWJ1Zy5hY3Bp LmNwdV91bm9yZGVyZWQ6IDANCmRlYnVnLmFjcGkuZWMudGltZW91dDogNzUwDQpkZWJ1Zy5hY3Bp LmVjLnBvbGxlZDogMA0KZGVidWcuYWNwaS5lYy5idXJzdDogMA0KZGVidWcuYWNwaS5iYXR0LmJh dHRfc2xlZXBfbXM6IDANCmRlYnVnLmFjcGkucmVzdW1lX2JlZXA6IDANCmRlYnVnLmZpcmV3aXJl X2RlYnVnOiAwDQpkZWJ1Zy5md21lbV9kZWJ1ZzogMA0KZGVidWcuaWZfZndlX2RlYnVnOiAwDQpk ZWJ1Zy5pZl9md2lwX2RlYnVnOiAwDQpkZWJ1Zy5pcHc6IDANCmRlYnVnLml3aTogMA0KZGVidWcu bWRkZWJ1ZzogMA0KZGVidWcud3BpOiAwDQpkZWJ1Zy5lbGY2NF9sZWdhY3lfY29yZWR1bXA6IDAN CmRlYnVnLmJvb3R2ZXJib3NlOiAwDQpkZWJ1Zy5ib290aG93dG86IDANCmRlYnVnLmNwdWZyZXEu dmVyYm9zZTogMA0KZGVidWcuY3B1ZnJlcS5sb3dlc3Q6IDANCmRlYnVnLmZhaWxfcG9pbnQuc3lz Y3RsX3J1bm5pbmc6IG9mZg0KZGVidWcuZmFpbF9wb2ludC5idWZfcHJlc3N1cmU6IG9mZg0KZGVi dWcuZmFpbF9wb2ludC5ubG1fZGVueV9ncmFudDogb2ZmDQpkZWJ1Zy5hZGFwdGl2ZV9tYWNoaW5l X2FyY2g6IDENCmRlYnVnLnNpemVvZi5jZGV2X3ByaXY6IDM3Ng0KZGVidWcuc2l6ZW9mLmNkZXY6 IDI4OA0KZGVidWcuc2l6ZW9mLmdfYmlvcTogNTYNCmRlYnVnLnNpemVvZi5nX2NvbnN1bWVyOiA5 Ng0KZGVidWcuc2l6ZW9mLmdfcHJvdmlkZXI6IDEzNg0KZGVidWcuc2l6ZW9mLmdfZ2VvbTogMTYw DQpkZWJ1Zy5zaXplb2YuZ19jbGFzczogMTYwDQpkZWJ1Zy5zaXplb2Yua2luZm9fcHJvYzogMTA4 OA0KZGVidWcuc2l6ZW9mLmJ1ZjogNjA4DQpkZWJ1Zy5zaXplb2YuYmlvOiAyMzINCmRlYnVnLnNp emVvZi5wcm9jOiAxMTg0DQpkZWJ1Zy5zaXplb2Yudm5vZGU6IDQ4MA0KZGVidWcuc2l6ZW9mLmRl dnN0YXQ6IDI4OA0KZGVidWcuc2l6ZW9mLm5hbWVjYWNoZTogNzINCmRlYnVnLm9zZDogMA0KZGVi dWcudHJhY2Vfb25fcGFuaWM6IDENCmRlYnVnLmRlYnVnZ2VyX29uX3BhbmljOiAxDQpkZWJ1Zy5u Y29yZXM6IDUNCmRlYnVnLnRvX2F2Z19tcGNhbGxzOiA3NDINCmRlYnVnLnRvX2F2Z19sb2NrY2Fs bHM6IDIzMg0KZGVidWcudG9fYXZnX2djYWxsczogNDgyDQpkZWJ1Zy50b19hdmdfZGVwdGg6IDE3 MTINCmRlYnVnLnVtdHgudW10eF9waV9hbGxvY2F0ZWQ6IDANCmRlYnVnLmNsb2NrdGltZTogMA0K ZGVidWcua2RiLmFsdF9icmVha190b19kZWJ1Z2dlcjogMA0KZGVidWcua2RiLmJyZWFrX3RvX2Rl YnVnZ2VyOiAwDQpkZWJ1Zy5rZGIudHJhcF9jb2RlOiAwDQpkZWJ1Zy5rZGIudHJhcDogMA0KZGVi dWcua2RiLnBhbmljOiAwDQpkZWJ1Zy5rZGIuZW50ZXI6IDANCmRlYnVnLmtkYi5jdXJyZW50OiAN CmRlYnVnLnJtYW5fZGVidWc6IDANCmRlYnVnLmlvc2l6ZV9tYXhfY2xhbXA6IDENCmRlYnVnLmRp c2FibGVmdWxscGF0aDogMA0KZGVidWcuZGlzYWJsZWN3ZDogMA0KZGVidWcudmZzY2FjaGU6IDEN CmRlYnVnLm51bWNhY2hlaHY6IDI4NzA0DQpkZWJ1Zy5udW1jYWNoZTogMTgyOTA1DQpkZWJ1Zy5u dW1uZWc6IDExODYwDQpkZWJ1Zy5uY2hhc2g6IDEwNDg1NzUNCmRlYnVnLnZubHJ1X25vd2hlcmU6 IDANCmRlYnVnLnJ1c2hfcmVxdWVzdHM6IDM3MDI4MQ0KZGVidWcuaWZfdHVuX2RlYnVnOiAwDQpk ZWJ1Zy5ubG1fZGVidWc6IDANCmRlYnVnLmZzY2tjbWRzOiAwDQpkZWJ1Zy5jb2xsZWN0c25hcHN0 YXRzOiAwDQpkZWJ1Zy5zbmFwZGVidWc6IDANCmRlYnVnLmRvcGVyc2lzdGVuY2U6IDANCmRlYnVn LnNvZnRkZXAuY2xlYW51cF9mYWlsdXJlczogMzY5NjM0DQpkZWJ1Zy5zb2Z0ZGVwLmNsZWFudXBf cmV0cmllczogODI2DQpkZWJ1Zy5zb2Z0ZGVwLmNsZWFudXBfaGlnaF9kZWxheTogMTQNCmRlYnVn LnNvZnRkZXAuY2xlYW51cF9pbm9yZXF1ZXN0czogMA0KZGVidWcuc29mdGRlcC5jbGVhbnVwX2Js a3JlcXVlc3RzOiAzNjk2OTANCmRlYnVnLnNvZnRkZXAuandhaXRfbmV3YmxrOiAwDQpkZWJ1Zy5z b2Z0ZGVwLmp3YWl0X2lub2RlOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmp3YWl0X2ZyZWVibGtzOiAwDQpk ZWJ1Zy5zb2Z0ZGVwLmp3YWl0X2ZpbGVwYWdlOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmpvdXJuYWxfd2Fp dDogMA0KZGVidWcuc29mdGRlcC5qb3VybmFsX21pbjogMA0KZGVidWcuc29mdGRlcC5qb3VybmFs X2xvdzogMA0KZGVidWcuc29mdGRlcC5qbmV3YmxrX3JvbGxiYWNrOiAwDQpkZWJ1Zy5zb2Z0ZGVw LmphZGRyZWZfcm9sbGJhY2s6IDANCmRlYnVnLnNvZnRkZXAuZGlyX2VudHJ5OiAyMDIwMzMNCmRl YnVnLnNvZnRkZXAuZGlyZWN0X2Jsa19wdHJzOiAzNDI2NTUNCmRlYnVnLnNvZnRkZXAuaW5vZGVf Yml0bWFwOiAyNTI4Mjc1DQpkZWJ1Zy5zb2Z0ZGVwLmluZGlyX2Jsa19wdHJzOiAyNjkzNw0KZGVi dWcuc29mdGRlcC5zeW5jX2xpbWl0X2hpdDogNTkxDQpkZWJ1Zy5zb2Z0ZGVwLmlub19saW1pdF9o aXQ6IDANCmRlYnVnLnNvZnRkZXAuYmxrX2xpbWl0X2hpdDogMzY5MjIwDQpkZWJ1Zy5zb2Z0ZGVw Lmlub19saW1pdF9wdXNoOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmJsa19saW1pdF9wdXNoOiAzNjk2OTAN CmRlYnVnLnNvZnRkZXAud29ya2xpc3RfcHVzaDogMjE1Ng0KZGVidWcuc29mdGRlcC5tYXhpbmRp cmRlcHM6IDUwDQpkZWJ1Zy5zb2Z0ZGVwLnRpY2tkZWxheTogMg0KZGVidWcuc29mdGRlcC5tYXhf c29mdGRlcHM6IDIzNTIzMDgNCmRlYnVnLnNvZnRkZXAud3JpdGUuamZzeW5jOiAwDQpkZWJ1Zy5z b2Z0ZGVwLndyaXRlLmp0cnVuYzogMA0KZGVidWcuc29mdGRlcC53cml0ZS5zYmRlcDogMA0KZGVi dWcuc29mdGRlcC53cml0ZS5qc2VnZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpzZWc6IDAN CmRlYnVnLnNvZnRkZXAud3JpdGUuamZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpm cmVlYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpuZXdibGs6IDANCmRlYnVnLnNvZnRkZXAu d3JpdGUuam12cmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpyZW1yZWY6IDANCmRlYnVnLnNv ZnRkZXAud3JpdGUuamFkZHJlZjogMA0KZGVidWcuc29mdGRlcC53cml0ZS5mcmVlZGVwOiAwDQpk ZWJ1Zy5zb2Z0ZGVwLndyaXRlLmZyZWV3b3JrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLm5ld2Rp cmJsazogMA0KZGVidWcuc29mdGRlcC53cml0ZS5kaXJyZW06IDANCmRlYnVnLnNvZnRkZXAud3Jp dGUubWtkaXI6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZGlyYWRkOiAwDQpkZWJ1Zy5zb2Z0ZGVw LndyaXRlLmZyZWVmaWxlOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmZyZWVibGtzOiA2OTA5NDcN CmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZWZyYWc6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuYWxs b2NpbmRpcjogMjMzNDUzODU4MQ0KZGVidWcuc29mdGRlcC53cml0ZS5pbmRpcmRlcDogMTE3MzUw DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmFsbG9jZGlyZWN0OiA3Njk0MDE0NA0KZGVidWcuc29mdGRl cC53cml0ZS5uZXdibGs6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuYm1zYWZlbWFwOiAyNDM3ODU4 DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmlub2RlZGVwOiA2OTE3MTU5DQpkZWJ1Zy5zb2Z0ZGVwLndy aXRlLnBhZ2VkZXA6IDMyOTY2NQ0KZGVidWcuc29mdGRlcC5jdXJyZW50Lmpmc3luYzogMA0KZGVi dWcuc29mdGRlcC5jdXJyZW50Lmp0cnVuYzogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LnNiZGVw OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuanNlZ2RlcDogMA0KZGVidWcuc29mdGRlcC5jdXJy ZW50LmpzZWc6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qZnJlZWZyYWc6IDANCmRlYnVnLnNv ZnRkZXAuY3VycmVudC5qZnJlZWJsazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpuZXdibGs6 IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qbXZyZWY6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVu dC5qcmVtcmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuamFkZHJlZjogMA0KZGVidWcuc29m dGRlcC5jdXJyZW50LmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5mcmVld29yazog MA0KZGVidWcuc29mdGRlcC5jdXJyZW50Lm5ld2RpcmJsazogMA0KZGVidWcuc29mdGRlcC5jdXJy ZW50LmRpcnJlbTogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50Lm1rZGlyOiAwDQpkZWJ1Zy5zb2Z0 ZGVwLmN1cnJlbnQuZGlyYWRkOiAxDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZnJlZWZpbGU6IDAN CmRlYnVnLnNvZnRkZXAuY3VycmVudC5mcmVlYmxrczogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50 LmZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuYWxsb2NpbmRpcjogMA0KZGVidWcu c29mdGRlcC5jdXJyZW50LmluZGlyZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuYWxsb2Nk aXJlY3Q6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5uZXdibGs6IDANCmRlYnVnLnNvZnRkZXAu Y3VycmVudC5ibXNhZmVtYXA6IDENCmRlYnVnLnNvZnRkZXAuY3VycmVudC5pbm9kZWRlcDogMQ0K ZGVidWcuc29mdGRlcC5jdXJyZW50LnBhZ2VkZXA6IDINCmRlYnVnLnNvZnRkZXAudG90YWwuamZz eW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmp0cnVuYzogMA0KZGVidWcuc29mdGRlcC50b3Rh bC5zYmRlcDogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qc2VnZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVw LnRvdGFsLmpzZWc6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuamZyZWVmcmFnOiAwDQpkZWJ1Zy5z b2Z0ZGVwLnRvdGFsLmpmcmVlYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmpuZXdibGs6IDAN CmRlYnVnLnNvZnRkZXAudG90YWwuam12cmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmpyZW1y ZWY6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuamFkZHJlZjogMA0KZGVidWcuc29mdGRlcC50b3Rh bC5mcmVlZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmZyZWV3b3JrOiA4MzUxMjIyOA0KZGVi dWcuc29mdGRlcC50b3RhbC5uZXdkaXJibGs6IDE4NDAzDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmRp cnJlbTogMTM1NDE1NDINCmRlYnVnLnNvZnRkZXAudG90YWwubWtkaXI6IDI5NDU2DQpkZWJ1Zy5z b2Z0ZGVwLnRvdGFsLmRpcmFkZDogMTM1NDkwOTMNCmRlYnVnLnNvZnRkZXAudG90YWwuZnJlZWZp bGU6IDY5NDg0NjYNCmRlYnVnLnNvZnRkZXAudG90YWwuZnJlZWJsa3M6IDY4NDQ5MzgNCmRlYnVn LnNvZnRkZXAudG90YWwuZnJlZWZyYWc6IDQ0MTQ2NTM1Mg0KZGVidWcuc29mdGRlcC50b3RhbC5h bGxvY2luZGlyOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmluZGlyZGVwOiA2NDQ5MzI3DQpkZWJ1 Zy5zb2Z0ZGVwLnRvdGFsLmFsbG9jZGlyZWN0OiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLm5ld2Js azogMjg4NjQ3MzQxMg0KZGVidWcuc29mdGRlcC50b3RhbC5ibXNhZmVtYXA6IDkyMDg5MjQNCmRl YnVnLnNvZnRkZXAudG90YWwuaW5vZGVkZXA6IDgwOTc3MzENCmRlYnVnLnNvZnRkZXAudG90YWwu cGFnZWRlcDogMTQyMTA5DQpkZWJ1Zy5kb2JrZ3Jkd3JpdGU6IDENCmRlYnVnLmJpZ2NnczogMA0K ZGVidWcuZGlyY2hlY2s6IDANCmRlYnVnLnBzbS5wa3RlcnJ0aHJlc2g6IDINCmRlYnVnLnBzbS51 c2VjczogNTAwMDAwDQpkZWJ1Zy5wc20uc2VjczogMA0KZGVidWcucHNtLmVycnVzZWNzOiAwDQpk ZWJ1Zy5wc20uZXJyc2VjczogMg0KZGVidWcucHNtLmh6OiAyMA0KZGVidWcucHNtLmxvZ2xldmVs OiAwDQpkZWJ1Zy52ZXNhLnNoYWRvd19yb206IDANCmRlYnVnLmZkYy5zZXR0bGU6IDANCmRlYnVn LmZkYy5zcGVjMjogMTYNCmRlYnVnLmZkYy5zcGVjMTogMTc1DQpkZWJ1Zy5mZGMucmV0cmllczog MTANCmRlYnVnLmZkYy5kZWJ1Z2ZsYWdzOiAwDQpkZWJ1Zy5mZGMuZmlmbzogOA0KZGVidWcuZWxm MzJfbGVnYWN5X2NvcmVkdW1wOiAwDQpkZWJ1Zy54ODZiaW9zLmludDogMA0KZGVidWcueDg2Ymlv cy5jYWxsOiAwDQpkZWJ1Zy5od3BzdGF0ZV92ZXJib3NlOiAwDQpkZWJ1Zy5taW5pZHVtcDogMQ0K KyBmc3RhdCAtZiAvcGdzcWwNClVTRVIgICAgIENNRCAgICAgICAgICBQSUQgICBGRCBNT1VOVCAg ICAgIElOVU0gTU9ERSAgICAgICAgIFNafERWIFIvVw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3 NyAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwgICAg cG9zdGdyZXMgICA1MjU3NyAgICA2IC9wZ3NxbCAgIDE1NzgwMzI4IC1ydy0tLS0tLS0gIDgxMTAw OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDEwIC9wZ3NxbCAgIDE1NzgwMzE2IC1y dy0tLS0tLS0gIDQyMTA2ODggcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAxMSAvcGdz cWwgICAxNTc4MDMzNiAtcnctLS0tLS0tICAzNzY4MzIgcncNCnBnc3FsICAgIHBvc3RncmVzICAg NTI1NzcgICAxMiAvcGdzcWwgICAxNTc4MDMzMSAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3Fs ICAgIHBvc3RncmVzICAgNTI1NzcgICAxMyAvcGdzcWwgICAxNTc4MDMyOSAtcnctLS0tLS0tICAg MTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAxNCAvcGdzcWwgICAxNTc4MDM0 OSAtcnctLS0tLS0tICAgMjQ1NzYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAxNSAv cGdzcWwgICAxNTc4MDM5NyAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVz ICAgNTI1NzcgICAxNiAvcGdzcWwgICAxNTc4MDI5MyAtcnctLS0tLS0tICAgMzI3NjggcncNCnBn c3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAxNyAvcGdzcWwgICAxNTc4MDM1NiAtcnctLS0tLS0t ICAxNTU2NDggcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAxOCAvcGdzcWwgICAxNTc4 MDM3OCAtcnctLS0tLS0tICA5MDExMjAgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAx OSAvcGdzcWwgICAxNTc4MDM5NSAtcnctLS0tLS0tICAgODE5MjAgcncNCnBnc3FsICAgIHBvc3Rn cmVzICAgNTI1NzcgICAyMCAvcGdzcWwgICAxNTc4MDQxMSAtcnctLS0tLS0tICAgMTYzODQgcncN CnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAyMSAvcGdzcWwgICAxNTc4MDMzOCAtcnctLS0t LS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAyMiAvcGdzcWwgICAx NTc4MDQxMiAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1Nzcg ICAyMyAvcGdzcWwgICAxNTc4MDI5NSAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBv c3RncmVzICAgNTI1NzcgICAyNCAvcGdzcWwgICAxNTc4MDM0OCAtcnctLS0tLS0tICAgIDgxOTIg cncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAyNSAvcGdzcWwgICAxNTc4MDQwMSAtcnct LS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAyNiAvcGdzcWwg ICAxNTc4MDM3MiAtcnctLS0tLS0tICAyODY3MjAgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1 NzcgICAyNyAvcGdzcWwgICAxNTc4MDMyNiAtcnctLS0tLS0tICA2ODgxMjggcncNCnBnc3FsICAg IHBvc3RncmVzICAgNTI1NzcgICAyOCAvcGdzcWwgICAxNTc4MDM1MyAtcnctLS0tLS0tICAxMzEw NzIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAyOSAvcGdzcWwgICAxNTc4MDM4MSAt cnctLS0tLS0tICAyNzAzMzYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAzMCAvcGdz cWwgICAxNTc4MDM0NiAtcnctLS0tLS0tICA3MTI3MDQgcncNCnBnc3FsICAgIHBvc3RncmVzICAg NTI1NzcgICAzMSAvcGdzcWwgICAxNTc4MDM4MCAtcnctLS0tLS0tICAgODE5MjAgcncNCnBnc3Fs ICAgIHBvc3RncmVzICAgNTI1NzcgICAzMiAvcGdzcWwgICAxNTc4MDM5NCAtcnctLS0tLS0tICAg OTAxMTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAzMyAvcGdzcWwgICAxNTc4MDQ1 NCAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICAzNCAv cGdzcWwgICAxNTc4MDM2NSAtcnctLS0tLS0tICAxNzEyMTI4IHJ3DQpwZ3NxbCAgICBwb3N0Z3Jl cyAgIDUyNTc3ICAgMzUgL3Bnc3FsICAgMTU3ODAzNDEgLXJ3LS0tLS0tLSAgMTU4MTA1NiBydw0K cGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDM2IC9wZ3NxbCAgIDE1NzgwNDg1IC1ydy0tLS0t LS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDM3IC9wZ3NxbCAgIDE1 NzgwNDE1IC1ydy0tLS0tLS0gIDE0MjU0MDggcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1Nzcg ICAzOCAvcGdzcWwgICAxNTc4MDQ4NiAtcnctLS0tLS0tICAgMjQ1NzYgcncNCnBnc3FsICAgIHBv c3RncmVzICAgNTI1NzcgICAzOSAvcGdzcWwgICAxMTA1MzI5NSAtcnctLS0tLS0tICAxNjc3NzIx NiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDQwIC9wZ3NxbCAgIDE1NzgwMzgyIC1y dy0tLS0tLS0gIDM2ODY0MCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDQxIC9wZ3Nx bCAgIDE1NzgwNDA1IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1 MjU3NyAgIDQyIC9wZ3NxbCAgIDE1NzgwMzUxIC1ydy0tLS0tLS0gIDEzMTA3MiBydw0KcGdzcWwg ICAgcG9zdGdyZXMgICA1MjU3NyAgIDQzIC9wZ3NxbCAgIDE1NzgwNDAzIC1ydy0tLS0tLS0gICAx NjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDQ0IC9wZ3NxbCAgIDE1NzgwMjk2 IC1ydy0tLS0tLS0gIDQ1ODc1MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDQ1IC9w Z3NxbCAgIDE1NzgwMzk2IC1ydy0tLS0tLS0gICA0MDk2MCBydw0KcGdzcWwgICAgcG9zdGdyZXMg ICA1MjU3NyAgIDQ2IC9wZ3NxbCAgIDE1NzgwMzM3IC1ydy0tLS0tLS0gIDExNDY4OCBydw0KcGdz cWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDQ3IC9wZ3NxbCAgIDE1NzgwMzA3IC1ydy0tLS0tLS0g ICAzMjc2OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDQ4IC9wZ3NxbCAgIDExMDQ2 MTEwIC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDQ5 IC9wZ3NxbCAgIDExMDQ2MTU2IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICA1MjU3NyAgIDUwIC9wZ3NxbCAgIDExMDQ2MjQ4IC1ydy0tLS0tLS0gICAxNjM4NCBydw0K cGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDUxIC9wZ3NxbCAgIDE1NzgwMzk5IC1ydy0tLS0t LS0gICAzMjc2OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAgIDUyIC9wZ3NxbCAgIDE1 NzgwMzUwIC1ydy0tLS0tLS0gICAzMjc2OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3NyAg IDUzIC9wZ3NxbCAgIDE1NzgwMzc2IC1ydy0tLS0tLS0gIDIyOTM3NiBydw0KcGdzcWwgICAgcG9z dGdyZXMgICA1MjU3NyAgIDU0IC9wZ3NxbCAgIDE1NzgwMzcwIC1ydy0tLS0tLS0gIDQ4NjYwNDgg cncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICA1NSAvcGdzcWwgICAxNTc4MDI5MiAtcnct LS0tLS0tICAgMzI3NjggcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICA1NiAvcGdzcWwg ICAxNTc4MDM3MSAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1 NzcgICA1NyAvcGdzcWwgICAxNTc4MDMzOSAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAg IHBvc3RncmVzICAgNTI1NzcgICA2MCAvcGdzcWwgICAxNTc4MDM3NSAtcnctLS0tLS0tICAgODE5 MjAgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzcgICA2MSAvcGdzcWwgICAxNTc4MDM3NCAt cnctLS0tLS0tICAyMzE4MzM2IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgd2QgL3Bn c3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAg IDUyNTcyICAgIDYgL3Bnc3FsICAgMTEwNDYwMTEgLXJ3LS0tLS0tLSAgNzk0NjI0IHJ3DQpwZ3Nx bCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgMTAgL3Bnc3FsICAgMTEwNDU5OTkgLXJ3LS0tLS0tLSAg NDE4NjExMiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDExIC9wZ3NxbCAgIDExMDQ2 MDE5IC1ydy0tLS0tLS0gIDM5MzIxNiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDEy IC9wZ3NxbCAgIDExMDQ2MDE0IC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICA1MjU3MiAgIDEzIC9wZ3NxbCAgIDExMDQ2MDEyIC1ydy0tLS0tLS0gICAxNjM4NCBydw0K cGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDE0IC9wZ3NxbCAgIDExMDQ2MDMyIC1ydy0tLS0t LS0gICAyNDU3NiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDE1IC9wZ3NxbCAgIDEx MDQ2MDc4IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAg IDE2IC9wZ3NxbCAgIDExMDQ1OTQ0IC1ydy0tLS0tLS0gICAzMjc2OCBydw0KcGdzcWwgICAgcG9z dGdyZXMgICA1MjU3MiAgIDE3IC9wZ3NxbCAgIDExMDQ2MDM5IC1ydy0tLS0tLS0gIDEzMTA3MiBy dw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDE4IC9wZ3NxbCAgIDExMDQ2MDU5IC1ydy0t LS0tLS0gIDcyMDg5NiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDE5IC9wZ3NxbCAg IDExMDQ2MDc2IC1ydy0tLS0tLS0gICA2NTUzNiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3 MiAgIDIwIC9wZ3NxbCAgIDExMDQ2MDkyIC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAg cG9zdGdyZXMgICA1MjU3MiAgIDIxIC9wZ3NxbCAgIDExMDQ2MDIxIC1ydy0tLS0tLS0gICAyNDU3 NiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDIyIC9wZ3NxbCAgIDExMDQ2MDkzIC1y dy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDIzIC9wZ3Nx bCAgIDExMDQ1OTY4IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1 MjU3MiAgIDI0IC9wZ3NxbCAgIDExMDQ2MDMxIC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwg ICAgcG9zdGdyZXMgICA1MjU3MiAgIDI1IC9wZ3NxbCAgIDExMDQ2MDgyIC1ydy0tLS0tLS0gICAx NjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDI2IC9wZ3NxbCAgIDExMDQ2MDUz IC1ydy0tLS0tLS0gIDI3MDMzNiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDI3IC9w Z3NxbCAgIDExMDQ2MDA5IC1ydy0tLS0tLS0gIDY0NzE2OCBydw0KcGdzcWwgICAgcG9zdGdyZXMg ICA1MjU3MiAgIDI4IC9wZ3NxbCAgIDExMDQ2MDM2IC1ydy0tLS0tLS0gIDEwNjQ5NiBydw0KcGdz cWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDI5IC9wZ3NxbCAgIDExMDQ2MDYyIC1ydy0tLS0tLS0g IDI3MDMzNiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDMwIC9wZ3NxbCAgIDExMDQ2 MDI5IC1ydy0tLS0tLS0gIDcxMjcwNCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDMx IC9wZ3NxbCAgIDExMDQ2MDYxIC1ydy0tLS0tLS0gICA4MTkyMCBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICA1MjU3MiAgIDMyIC9wZ3NxbCAgIDExMDQ2MDc1IC1ydy0tLS0tLS0gICA4MTkyMCBydw0K cGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDMzIC9wZ3NxbCAgIDExMDQ2ODUxIC1ydy0tLS0t LS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDM0IC9wZ3NxbCAgIDEx MDQ2MDQ4IC1ydy0tLS0tLS0gIDE0MzM2MDAgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzIg ICAzNSAvcGdzcWwgICAxMTA0NjAyNCAtcnctLS0tLS0tICAxNTU2NDgwIHJ3DQpwZ3NxbCAgICBw b3N0Z3JlcyAgIDUyNTcyICAgMzYgL3Bnc3FsICAgMTEwNDY4ODIgLXJ3LS0tLS0tLSAgICA4MTky IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgMzcgL3Bnc3FsICAgMTEwNDYwOTYgLXJ3 LS0tLS0tLSAgMTE3OTY0OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDM4IC9wZ3Nx bCAgIDExMDQ2ODgzIC1ydy0tLS0tLS0gICAyNDU3NiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1 MjU3MiAgIDM5IC9wZ3NxbCAgIDExMDUzMjk1IC1ydy0tLS0tLS0gIDE2Nzc3MjE2IHJ3DQpwZ3Nx bCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgNDAgL3Bnc3FsICAgMTEwNDYwNjMgLXJ3LS0tLS0tLSAg MzM1ODcyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgNDEgL3Bnc3FsICAgMTEwNDYw ODYgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgNDIg L3Bnc3FsICAgMTEwNDYwMzQgLXJ3LS0tLS0tLSAgMTMxMDcyIHJ3DQpwZ3NxbCAgICBwb3N0Z3Jl cyAgIDUyNTcyICAgNDMgL3Bnc3FsICAgMTEwNDYwODQgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgNDQgL3Bnc3FsICAgMTEwNDU5NzQgLXJ3LS0tLS0t LSAgNDU4NzUyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgNDUgL3Bnc3FsICAgMTEw NDYwNzcgLXJ3LS0tLS0tLSAgIDQwOTYwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAg NDYgL3Bnc3FsICAgMTEwNDYwMjAgLXJ3LS0tLS0tLSAgMTE0Njg4IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDUyNTcyICAgNDcgL3Bnc3FsICAgMTEwNDU5OTAgLXJ3LS0tLS0tLSAgIDMyNzY4IHJ3 DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgNDggL3Bnc3FsICAgMTEwNDYxMTAgLXJ3LS0t LS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgNDkgL3Bnc3FsICAg MTEwNDYxNTYgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcy ICAgNTAgL3Bnc3FsICAgMTEwNDYyNDggLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBw b3N0Z3JlcyAgIDUyNTcyICAgNTEgL3Bnc3FsICAgMTEwNDYwODAgLXJ3LS0tLS0tLSAgIDMyNzY4 IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgNTIgL3Bnc3FsICAgMTEwNDYwMzMgLXJ3 LS0tLS0tLSAgIDMyNzY4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcyICAgNTMgL3Bnc3Fs ICAgMTEwNDYwNTcgLXJ3LS0tLS0tLSAgMjIxMTg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUy NTcyICAgNTQgL3Bnc3FsICAgMTEwNDYwNTEgLXJ3LS0tLS0tLSAgNDg3NDI0MCBydw0KcGdzcWwg ICAgcG9zdGdyZXMgICA1MjU3MiAgIDU1IC9wZ3NxbCAgIDExMDQ1OTM5IC1ydy0tLS0tLS0gICAz Mjc2OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDU2IC9wZ3NxbCAgIDExMDQ2MDUy IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDU3IC9w Z3NxbCAgIDExMDQ2MDIyIC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMg ICA1MjU3MiAgIDYwIC9wZ3NxbCAgIDExMDQ2MDU2IC1ydy0tLS0tLS0gICA2NTUzNiBydw0KcGdz cWwgICAgcG9zdGdyZXMgICA1MjU3MiAgIDYxIC9wZ3NxbCAgIDExMDQ2MDU1IC1ydy0tLS0tLS0g IDIzMTAxNDQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICB3ZCAvcGdzcWwgICAxMTA0 NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICAg NiAvcGdzcWwgICAxMTA0NjExNiAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3Rn cmVzICAgNTI1NzEgICAxMCAvcGdzcWwgICAxMTA0NjE5OCAtcnctLS0tLS0tICAgMTYzODQgcncN CnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICAxMSAvcGdzcWwgICAxMTA0NjYxNSAtcnctLS0t LS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICAxMiAvcGdzcWwgICAx MTA0ODk2NiAtcnctLS0tLS0tICA3NjE4NTYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEg ICAxMyAvcGdzcWwgICAxMTA0ODk1NCAtcnctLS0tLS0tICAzMzk5NjgwIHJ3DQpwZ3NxbCAgICBw b3N0Z3JlcyAgIDUyNTcxICAgMTQgL3Bnc3FsICAgMTEwNDg5NzQgLXJ3LS0tLS0tLSAgMzE5NDg4 IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMTUgL3Bnc3FsICAgMTEwNDg5NjkgLXJ3 LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMTYgL3Bnc3Fs ICAgMTEwNDg5NjcgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUy NTcxICAgMTcgL3Bnc3FsICAgMTEwNDg5ODcgLXJ3LS0tLS0tLSAgIDI0NTc2IHJ3DQpwZ3NxbCAg ICBwb3N0Z3JlcyAgIDUyNTcxICAgMTggL3Bnc3FsICAgMTEwNDkwMzUgLXJ3LS0tLS0tLSAgIDE2 Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMTkgL3Bnc3FsICAgMTEwNDc4NjYg LXJ3LS0tLS0tLSAgIDMyNzY4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMjAgL3Bn c3FsICAgMTEwNDg5OTQgLXJ3LS0tLS0tLSAgMTE0Njg4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAg IDUyNTcxICAgMjEgL3Bnc3FsICAgMTEwNDkwMTYgLXJ3LS0tLS0tLSAgNTI0Mjg4IHJ3DQpwZ3Nx bCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMjIgL3Bnc3FsICAgMTEwNDkwMzMgLXJ3LS0tLS0tLSAg IDU3MzQ0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMjMgL3Bnc3FsICAgMTEwNDkw NDkgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMjQg L3Bnc3FsICAgMTEwNDg5NzYgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3Jl cyAgIDUyNTcxICAgMjUgL3Bnc3FsICAgMTEwNDkwNTAgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMjYgL3Bnc3FsICAgMTEwNDc4NjggLXJ3LS0tLS0t LSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMjcgL3Bnc3FsICAgMTEw NDg5ODYgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAg MjggL3Bnc3FsICAgMTEwNDkwMzkgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDUyNTcxICAgMjkgL3Bnc3FsICAgMTEwNDkwMTAgLXJ3LS0tLS0tLSAgMjIxMTg0IHJ3 DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMzAgL3Bnc3FsICAgMTEwNDg5NjQgLXJ3LS0t LS0tLSAgNTY1MjQ4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMzEgL3Bnc3FsICAg MTEwNDg5OTEgLXJ3LS0tLS0tLSAgIDgxOTIwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcx ICAgMzIgL3Bnc3FsICAgMTEwNDkwMTkgLXJ3LS0tLS0tLSAgMjcwMzM2IHJ3DQpwZ3NxbCAgICBw b3N0Z3JlcyAgIDUyNTcxICAgMzMgL3Bnc3FsICAgMTEwNDg5ODQgLXJ3LS0tLS0tLSAgNzIwODk2 IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMzQgL3Bnc3FsICAgMTEwNDkwMTggLXJ3 LS0tLS0tLSAgIDgxOTIwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgMzUgL3Bnc3Fs ICAgMTEwNDkwMzIgLXJ3LS0tLS0tLSAgIDczNzI4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUy NTcxICAgMzYgL3Bnc3FsICAgMTEwNDkwOTIgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAg ICBwb3N0Z3JlcyAgIDUyNTcxICAgMzcgL3Bnc3FsICAgMTEwNDkwMDMgLXJ3LS0tLS0tLSAgMTI3 Nzk1MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU3MSAgIDM4IC9wZ3NxbCAgIDExMDQ4OTc5 IC1ydy0tLS0tLS0gIDE0ODI3NTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICAzOSAv cGdzcWwgICAxMTA0OTEyMyAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVz ICAgNTI1NzEgICA0MCAvcGdzcWwgICAxMTA0OTA1MyAtcnctLS0tLS0tICAxMDU2NzY4IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgNDEgL3Bnc3FsICAgMTEwNDkxMjQgLXJ3LS0tLS0t LSAgIDI0NTc2IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgNDIgL3Bnc3FsICAgMTEw NTMyOTUgLXJ3LS0tLS0tLSAgMTY3NzcyMTYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEg ICA0MyAvcGdzcWwgICAxMTA0OTAyMCAtcnctLS0tLS0tICAyOTQ5MTIgcncNCnBnc3FsICAgIHBv c3RncmVzICAgNTI1NzEgICA0NCAvcGdzcWwgICAxMTA0OTA0MyAtcnctLS0tLS0tICAgMTYzODQg cncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICA0NSAvcGdzcWwgICAxMTA0ODk4OSAtcnct LS0tLS0tICAxMzEwNzIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICA0NiAvcGdzcWwg ICAxMTA0OTA0MSAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1 NzEgICA0NyAvcGdzcWwgICAxMTA0Nzg2OSAtcnctLS0tLS0tICAzNDQwNjQgcncNCnBnc3FsICAg IHBvc3RncmVzICAgNTI1NzEgICA0OCAvcGdzcWwgICAxMTA0OTAzNCAtcnctLS0tLS0tICAgNDA5 NjAgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICA0OSAvcGdzcWwgICAxMTA0ODk3NSAt cnctLS0tLS0tICAxMTQ2ODggcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICA1MCAvcGdz cWwgICAxMTA0ODk0NSAtcnctLS0tLS0tICAgMzI3NjggcncNCnBnc3FsICAgIHBvc3RncmVzICAg NTI1NzEgICA1MSAvcGdzcWwgICAxMTA0NjExMCAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3Fs ICAgIHBvc3RncmVzICAgNTI1NzEgICA1MiAvcGdzcWwgICAxMTA0NjE1NiAtcnctLS0tLS0tICAg MTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICA1MyAvcGdzcWwgICAxMTA0NjI0 OCAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICA1NCAv cGdzcWwgICAxMTA0OTAzNyAtcnctLS0tLS0tICAgMzI3NjggcncNCnBnc3FsICAgIHBvc3RncmVz ICAgNTI1NzEgICA1NSAvcGdzcWwgICAxMTA0ODk4OCAtcnctLS0tLS0tICAgMzI3NjggcncNCnBn c3FsICAgIHBvc3RncmVzICAgNTI1NzEgICA1NiAvcGdzcWwgICAxMTA0OTAxNCAtcnctLS0tLS0t ICAxMzkyNjQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNTI1NzEgICA1NyAvcGdzcWwgICAxMTA0 OTAwOCAtcnctLS0tLS0tICAyMjI4MjI0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAg NTggL3Bnc3FsICAgMTEwNDc4NjUgLXJ3LS0tLS0tLSAgIDMyNzY4IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDUyNTcxICAgNTkgL3Bnc3FsICAgMTEwNDkwMDkgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3 DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgNjAgL3Bnc3FsICAgMTEwNDg5NzcgLXJ3LS0t LS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcxICAgNjMgL3Bnc3FsICAg MTEwNDkwMTMgLXJ3LS0tLS0tLSAgIDQwOTYwIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTcx ICAgNjQgL3Bnc3FsICAgMTEwNDkwMTIgLXJ3LS0tLS0tLSAgMTA0ODU3NiBydw0KcGdzcWwgICAg cG9zdGdyZXMgICA1MjU2OSAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUx MiAgcg0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU2OCAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRy d3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwgICAgcG9zdGdyZXMgICA1MjU2OCAgICA4IC9wZ3Nx bCAgIDExMDQ2NjE0IC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1 MjU2NyAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwg ICAgcG9zdGdyZXMgICA1MjU2NyAgICA2IC9wZ3NxbCAgIDExMDUzMjk1IC1ydy0tLS0tLS0gIDE2 Nzc3MjE2IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTY2ICAgd2QgL3Bnc3FsICAgMTEwNDU4 ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDUyNTY1ICAgd2Qg L3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3Jl cyAgIDUyNTYxICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQor IHN5c2N0bCAtYQ0KKyBlZ3JlcCB2bm9kZQ0Ka2Vybi5tYXh2bm9kZXM6IDU4ODA3Nw0Ka2Vybi5t aW52bm9kZXM6IDE0NzAxOQ0Kdm0uc3RhdHMudm0udl92bm9kZXBnc291dDogMA0Kdm0uc3RhdHMu dm0udl92bm9kZXBnc2luOiA1MjI2Mg0Kdm0uc3RhdHMudm0udl92bm9kZW91dDogMA0Kdm0uc3Rh dHMudm0udl92bm9kZWluOiAyMTkzNg0KdmZzLmZyZWV2bm9kZXM6IDEyODg0Ng0KdmZzLndhbnRm cmVldm5vZGVzOiAxNDcwMTkNCnZmcy5udW12bm9kZXM6IDE2OTgyNQ0KZGVidWcuc2l6ZW9mLnZu b2RlOiA0ODANCisgbW91bnQgLXYNCi9kZXYvZGEwczFhIG9uIC8gKHVmcywgbG9jYWwsIHdyaXRl czogc3luYyAzODkgYXN5bmMgMTY3LCByZWFkczogc3luYyAyOTY2NCBhc3luYyAyMDk2LCBmc2lk IDZjYTE3MTRiNjdhMGUyZTYpDQpkZXZmcyBvbiAvZGV2IChkZXZmcywgbG9jYWwsIG11bHRpbGFi ZWwsIGZzaWQgMDBmZjAwNzE3MTAwMDAwMCkNCi9kZXYvZGExczEgb24gL29wdCAodWZzLCBsb2Nh bCwgc29mdC11cGRhdGVzLCB3cml0ZXM6IHN5bmMgNDIwNDIwIGFzeW5jIDE1MTE0OTQyLCByZWFk czogc3luYyAxNzY4NzQ4ODEgYXN5bmMgMTQ0MjAwNTI1LCBmc2lkIDMwMzE4NTUwZjU2NzllODYp DQovZGV2L2RhMHMxZSBvbiAvdG1wICh1ZnMsIGxvY2FsLCBzb2Z0LXVwZGF0ZXMsIHdyaXRlczog c3luYyA0NCBhc3luYyAxNTQ2MywgcmVhZHM6IHN5bmMgNTI4MCBhc3luYyAwLCBmc2lkIDZjYTE3 MTRiMDExY2ZlMWMpDQovZGV2L2RhMHMxZiBvbiAvdXNyICh1ZnMsIGxvY2FsLCBzb2Z0LXVwZGF0 ZXMsIHdyaXRlczogc3luYyAxNTQ0IGFzeW5jIDIxNDQ1MjgsIHJlYWRzOiBzeW5jIDEzNTI5NjU2 IGFzeW5jIDc0MTEsIGZzaWQgNmNhMTcxNGI3YTVjYjYxNSkNCi9kZXYvZGEwczFkIG9uIC92YXIg KHVmcywgbG9jYWwsIHNvZnQtdXBkYXRlcywgd3JpdGVzOiBzeW5jIDEwNjI5IGFzeW5jIDEzMzE4 MDgsIHJlYWRzOiBzeW5jIDI3MTQxOCBhc3luYyAyNDg4MSwgZnNpZCA2ZGExNzE0YmU5MTMzYmZh KQ0KcHJvY2ZzIG9uIC9wcm9jIChwcm9jZnMsIGxvY2FsLCBmc2lkIDAxZmYwMDAyMDIwMDAwMDAp DQovZGV2L2RhMnMxZCBvbiAvcGdzcWwgKHVmcywgbG9jYWwsIHdyaXRlczogc3luYyAyMzQgYXN5 bmMgNTY1LCByZWFkczogc3luYyA1MTQgYXN5bmMgMjI4LCBmc2lkIDZjYTE3MTRiYmUwYjhjNGQp DQojIF5EClNjcmlwdCBkb25lIG9uIFN1biBKdW4gIDIgMjI6MjU6NDkgMjAxMwo= --==========BC84A2A88248F67D07CB==========-- From owner-freebsd-fs@FreeBSD.ORG Sun Jun 2 21:01:13 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4CD7419E; Sun, 2 Jun 2013 21:01:13 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 2464F18E7; Sun, 2 Jun 2013 21:01:13 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r52L19vg033389; Sun, 2 Jun 2013 14:01:09 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201306022101.r52L19vg033389@chez.mckusick.com> To: Palle Girgensohn Subject: Re: leaking lots of unreferenced inodes (pg_xlog files?) In-reply-to: <69D8CE6E8C429368C08781FD@Spelvik.local> Date: Sun, 02 Jun 2013 14:01:09 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org, Dan Thomas , Jeff Roberson , Julian Akehurst X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 21:01:13 -0000 > Date: Sun, 02 Jun 2013 22:35:23 +0200 > From: Palle Girgensohn > To: Kirk McKusick > Subject: Re: leaking lots of unreferenced inodes (pg_xlog files?) > Cc: freebsd-fs@freebsd.org, Dan Thomas , > Jeff Roberson , > Julian Akehurst > > --On 31 maj 2013 11.25.40 -0700 Kirk McKusick wrote: > >> Your results are very enlightening. Especially the fact that you have >> to do a forcible unmount of the filesystem. What that tells me is that >> somehow we are getting vnodes that have phantom references. That is >> there is some system call where we get a reference on a vnode (vref, >> vget, or similar) that does not ultimately have a corresponding drop >> of the reference (vrele, vput, or similar). The net effect is that >> the file is held open despite the fact that there are no longer any >> connections to it. When you do the forcible unmount, the kernel walks >> the list of vnodes associated with the filesystem and does a vgone on >> each of them. That causes each to be inactivated which then triggers >> the release of their associated disk space. The reason that the unmount >> takes 20 seconds is to process all the releasing of the space. My guess >> is that there is an error path in some system call that is missing the >> vrele or vput. >> >> Assuming that you are able to run some more tests on your test machine, >> the next step in narrowing down the set of code to look at is to try >> running your system with soft updates disabled. The idea is to find out >> whether the miss-matched references are in the soft updates code or are >> in one of the filesystem system calls themselves. To disable soft updates >> run the command `tunefs -n disable /pgsql' on the unmounted /pgsql >> filesystem. If the system then runs without the problem, I will know >> to search the soft updates code. If the problem persists, then I'll >> know to look in the system calls themselves. You may want to do some >> preliminary tests to see how quickly the problem manifests itself. >> You can do this by running it for a short time (10 minutes say) and >> then checking to see if you need to do a forcible unmount of the >> filesystem. Once you establish how long you have to run before you >> reliably have to do a forcible unmount, you will know how long to >> run the test with soft updates turned off. If you find that running >> with soft updates turned off makes your application run too slowly >> you can mount your filesystem asynchronously. Note however, that you >> should not run asynchronously if the data on the filesystem is critical >> as you may end up with an unrecoverable filesystem after a power failure >> or system crash. So only run asynchronously if you can afford to lose >> your filesystem. >> >> Finally, it would be helpful if you could add two more commands to >> your diskspacecheck.sh script: >> >> sysctl -a | egrep vnode >> mount -v >> >> The first shows the vnode usage and the second shows the operational >> state of your filesystems. >> >> Kirk McKusick > > OK, I have now turned off soft updates. This is on the test server. It is > not as busy as the production machine, but I'll keep an eye on it and will > mail new results as soon as I see any evidence of either that soft updates > is the culprit or that it is not. > > FWIW, I attach the script from this remount process as well, which includes > > sysctl -a | grep vnode ; mount -v. > > Note that it is all in one script file this time. > > Cheers, > Palle This looks good. Keep me posted. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Mon Jun 3 11:06:44 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 93DD0589 for ; Mon, 3 Jun 2013 11:06:44 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8490C13AA for ; Mon, 3 Jun 2013 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r53B6ibM015001 for ; Mon, 3 Jun 2013 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r53B6icm014999 for freebsd-fs@FreeBSD.org; Mon, 3 Jun 2013 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Jun 2013 11:06:44 GMT Message-Id: <201306031106.r53B6icm014999@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:06:44 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/178999 fs [zfs] dev entries for cloned zvol don't show up until o bin/178996 fs [zfs] [patch] error in message with zfs mount -> there o kern/178854 fs [ufs] FreeBSD kernel crash in UFS o kern/178713 fs [nfs] [patch] Correct WebNFS support in NFS server and o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/178103 fs [kernel] [nfs] [patch] Correct support of index files o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic f kern/177335 fs [nfs] [panic] Sleeping on "vmopar" with the following o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/174060 fs [ext2fs] Ext2FS system crashes (buffer overflow?) o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 320 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jun 3 18:53:25 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2D49DA7A for ; Mon, 3 Jun 2013 18:53:25 +0000 (UTC) (envelope-from kentas@hush.com) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by mx1.freebsd.org (Postfix) with ESMTP id 1985A1FE0 for ; Mon, 3 Jun 2013 18:53:24 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 70F995808E for ; Mon, 3 Jun 2013 18:53:14 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp5.hushmail.com (Postfix) with ESMTP; Mon, 3 Jun 2013 18:53:14 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 5BB956F487; Mon, 3 Jun 2013 18:52:00 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 03 Jun 2013 14:52:00 -0400 To: freebsd-stable@freebsd.org Subject: ZFS LZ4 Upgrade From: "Kenta Suzumoto" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130603185200.5BB956F487@smtp.hushmail.com> Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:53:25 -0000 Hi. I'm planning on doing a ZFS root installation on a remote server very soon. The company only offers a 9.0 and 9.1 installation and "rescue" (nfs/pxe boot with ramdisk basically) system. I'd like to use LZ4 with the ZFS root pool, so I'm going to be upgrading to -STABLE once I have the initial system installed. Here's what I'll do: - install the 9.1 system - svn source, buildworld/kernel, install, reboot - upon booting the -STABLE system, begin enabling LZ4 compression on /usr/ports /usr/src etc. Will this work, or do I need to find some way to initially create the zpool with a -STABLE system? Is it just a matter of running "zfs upgrade" and "zpool upgrade" before enabling LZ4, or am I missing something? Thanks -kenta From owner-freebsd-fs@FreeBSD.ORG Mon Jun 3 19:24:58 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1E92CF1; Mon, 3 Jun 2013 19:24:58 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (secure.freebsdsolutions.net [69.55.234.48]) by mx1.freebsd.org (Postfix) with ESMTP id 99BB91154; Mon, 3 Jun 2013 19:24:58 +0000 (UTC) Received: from [10.10.1.32] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by ns1.jnielsen.net (8.14.4/8.14.4) with ESMTP id r53J7oNX086079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 15:07:50 -0400 (EDT) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ZFS LZ4 Upgrade From: John Nielsen In-Reply-To: <20130603185200.5BB956F487@smtp.hushmail.com> Date: Mon, 3 Jun 2013 13:07:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130603185200.5BB956F487@smtp.hushmail.com> To: Kenta Suzumoto X-Mailer: Apple Mail (2.1503) X-DCC-sonic.net-Metrics: ns1.jnielsen.net 1156; Body=3 Fuz1=3 Fuz2=3 X-Virus-Scanned: clamav-milter 0.97.5 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 19:24:58 -0000 On Jun 3, 2013, at 12:52 PM, Kenta Suzumoto wrote: > Hi. I'm planning on doing a ZFS root installation on a remote server = very soon. The company only offers a 9.0 and 9.1 installation and = "rescue" (nfs/pxe boot with ramdisk basically) system. I'd like to use = LZ4 with the ZFS root pool, so I'm going to be upgrading to -STABLE once = I have the initial system installed. Here's what I'll do: >=20 > - install the 9.1 system > - svn source, buildworld/kernel, install, reboot > - upon booting the -STABLE system, begin enabling LZ4 compression on = /usr/ports /usr/src etc. >=20 > Will this work, or do I need to find some way to initially create the = zpool with a -STABLE system? Is it just a matter of running "zfs = upgrade" and "zpool upgrade" before enabling LZ4, or am I missing = something? Thanks That should work. Just keep in mind that blocks written before you = enable compression won't be compressed. So you may want to create a = _new_ ZFS for src (and ports if it already exists as well) after your = source upgrade, then copy the contents of /usr/src over to it. (Then = update the mountpoints as desired, etc.) JN From owner-freebsd-fs@FreeBSD.ORG Tue Jun 4 07:39:30 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C7DEE26B for ; Tue, 4 Jun 2013 07:39:30 +0000 (UTC) (envelope-from ajit.jain@cloudbyte.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 5C1101FAE for ; Tue, 4 Jun 2013 07:39:30 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wd20so8851769obb.5 for ; Tue, 04 Jun 2013 00:39:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=ashhKdw0dHjXYF1qopm3H4wObuhOv4zUr/Cp2e2+kig=; b=W19UvxzNFs4GUpFCbVNok/i5wDh2F+zJquDs23oAufPHZ92A2VYvd9VwUAwhYs//z0 mnJZoqwCkCCO+zhOtRR+ksyB/WB6GbwUOR+xbn1TjSRLNchukQm2GBVh1X9BvA+sZm2Z u0agkddmXczW0SyrZrIAwVKM2lbjxRZsWvc/UFV1qWwzhcm4CXQPegz+qiIffAxZDFSL n1Kjanp3+Ug7/vJLM2HQA6AacbrBOwRyUmbYWCb2MnvPSVw+6v7qqVeRynHv59zMmuF3 YpvYkVcEy2aL5shGfLMV+eDjw2uFDlUtQbcQ1lBkdcYODH1f31uSiq671ILyLkz8augv dY3w== X-Received: by 10.182.66.170 with SMTP id g10mr11958497obt.64.1370331569722; Tue, 04 Jun 2013 00:39:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.97.163 with HTTP; Tue, 4 Jun 2013 00:39:08 -0700 (PDT) In-Reply-To: References: <9681E07546D348168052D4FC5365B4CD@multiplay.co.uk> <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk> <93D0677B373A452BAF58C8EA6823783D@multiplay.co.uk> <35ABA7AAEB7F4D86A1ED54C4C47FEB49@multiplay.co.uk> <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> <6E4EBFE196274519B847A47A062950EE@multiplay.co.uk> From: Ajit Jain Date: Tue, 4 Jun 2013 13:09:08 +0530 Message-ID: Subject: Fwd: seeing data corruption with zfs trim functionality To: freebsd-fs , Steven Hartland Content-Type: multipart/mixed; boundary=001a11c1ed8a702b9904de4f2ed7 X-Gm-Message-State: ALoCoQnh2vklAkmZD2f2BDy1adyJTZHYQEYYeivE4r10QwkfeTpwXUKRKvhq8utZk+v8wJdyhgUk X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 07:39:30 -0000 --001a11c1ed8a702b9904de4f2ed7 Content-Type: text/plain; charset=ISO-8859-1 Hi Steven, I am not able to send full output file to freebsd-fs. I am just sending the error file in this mail and will send you another mail which contain to full untar output. regards, ajit ---------- Forwarded message ---------- From: Ajit Jain Date: Mon, Jun 3, 2013 at 11:51 PM Subject: Re: seeing data corruption with zfs trim functionality To: Steven Hartland Cc: freebsd-fs Hi Steven, untar of the tarball is throwing the error below: tar: Error exit delayed from previous errors. I have download the file from the link 3 times, every time I am seeing the same issue. Please find the tar output file and error (grep from the tar output file) attached with mail. checksum of tar ball (after unzip, on freebsd) is: root@everest:/pool_9stable/obj_src/new # cksum stable-9-r251096.tar 2972813925 3474278400 stable-9-r251096.tar regards, ajit On Fri, May 31, 2013 at 4:12 AM, Steven Hartland wrote: > Tar archive of /usr/src and /usr/obj with built world and GENERIC kernel > for ams64 can be found here:- > http://blog.multiplay.co.uk/**dropzone/freebsd/stable-9-**r251096.tar.gz > > This is based off r251096 with current proposed MFC of CAM BIO_DELETE & > ZFS TRIM. > > > Regards > Steve > ----- Original Message ----- From: "Ajit Jain" > > > Hi Steven, >> >> That would be really great. I'll install build provided by you and can >> quickly >> update the result. I am kind of feeling that I am asking too much of fever >> from you. >> >> thanks for the help and bearing me, >> ajit >> >> >> On Wed, May 29, 2013 at 6:39 PM, Steven Hartland > >**wrote: >> >> Unfortunately FS corruption is a serious matters so even though I'm >>> 99.99% >>> convinced there isn't a problem I'd still prefer to confirm this was >>> indeed >>> an issue with your code base and not an issue with the current code prior >>> to MFC'ing. >>> >>> Would a pre-patched stable/9 source / build help. If so I can look at >>> making >>> that available for you. >>> >>> >>> Regards >>> Steve >>> >>> ----- Original Message ----- From: "Ajit Jain" >>> >>> >>> Hi Steven, >>> >>>> >>>> Sorry for the long delay, but might delay even further. >>>> I think the reason for the corruption was, my code >>>> was not updated specially cam directory. >>>> >>>> I request please do not stop just because of the issue I reported. >>>> I'll update my src tree and rerun the experiments I was running >>>> if I see some issue then probably we fix the bug rather then stopping >>>> for MFC. >>>> >>>> thanks, >>>> ajit >>>> >>>> >>>> >>>> On Wed, May 29, 2013 at 5:19 PM, Steven Hartland < >>>> killing@multiplay.co.uk >>>> >**wrote: >>>> >>>> >>>> Sorry to pester, but any update on this Ajit? >>>> >>>>> >>>>> I ask as its currently blocking the MFC of TRIM to stable/8 & 9 and >>>>> I've >>>>> been >>>>> unable to reproduce this issue even with your testing code on working >>>>> FW >>>>> versions. >>>>> >>>>> >>>>> Regards >>>>> Steve >>>>> >>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>> ajit.jain@cloudbyte.com> >>>>> >>>>> >>>>> Sure Steven, >>>>> >>>>> I'll apply the patches and update ASAP. >>>>>> >>>>>> thanks >>>>>> ajit >>>>>> >>>>>> >>>>>> On Thu, May 23, 2013 at 3:03 PM, Steven Hartland < >>>>>> killing@multiplay.co.uk >>>>>> >**wrote: >>>>>> >>>>>> >>>>>> I've attacked the two patch sets I'm looking to MFC to stable-9, one >>>>>> >>>>>> adds BIO_DELETE CAM changes and the other is ZFS TRIM support. >>>>>>> >>>>>>> They should both apply cleanly to stable-9, if you could test with >>>>>>> those on your machine and let me know. >>>>>>> >>>>>>> Regards >>>>>>> Steve >>>>>>> >>>>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>>>> ajit.jain@cloudbyte.com> >>>>>>> >>>>>>> >>>>>>> Hi Steven, >>>>>>> >>>>>>> >>>>>>> FW version on the setup is P15. >>>>>>>> I will upgrade the FW to P16, but I think my >>>>>>>> best bet will be to update code base to 9 stable as unlike you, >>>>>>>> I was seeing corruption for all three delete methods. >>>>>>>> >>>>>>>> thanks >>>>>>>> ajit >>>>>>>> >>>>>>>> On Sat, May 18, 2013 at 4:15 AM, Steven Hartland < >>>>>>>> killing@multiplay.co.uk >>>>>>>> >**wrote: >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- From: "Steven Hartland" < >>>>>>>> >>>>>>>> killing@multiplay.co.uk> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> After initially seeing not issues, our overnight monitoring >>>>>>>>> started >>>>>>>>> >>>>>>>>> moaning >>>>>>>>> >>>>>>>>>> big time on the test box. So we checked and there was zpool >>>>>>>>>> corruption >>>>>>>>>> as >>>>>>>>>> well >>>>>>>>>> as a missing boot loader and a corrupt GPT, so I believe we have >>>>>>>>>> reproduced >>>>>>>>>> your issue. >>>>>>>>>> >>>>>>>>>> After recovering the machine I created 3 pools on 3 different >>>>>>>>>> disks >>>>>>>>>> each >>>>>>>>>> running a different delete_method. >>>>>>>>>> >>>>>>>>>> We then re-ran the tests which resulted in the pool running with >>>>>>>>>> delete_method >>>>>>>>>> WS16 being so broken it had suspended IO. A reboot resulted in it >>>>>>>>>> once >>>>>>>>>> again >>>>>>>>>> reporting no partition table via gpart. >>>>>>>>>> >>>>>>>>>> A third test run again produced a corrupt pool for WS16. >>>>>>>>>> >>>>>>>>>> I've conducted a preliminary review of the CAM WS16 code path >>>>>>>>>> along >>>>>>>>>> with >>>>>>>>>> SBC-3 >>>>>>>>>> spec which didn't identify any obvious issues. >>>>>>>>>> >>>>>>>>>> Given we're both using LSI 2008 based controllers it could be FW >>>>>>>>>> issue >>>>>>>>>> specific >>>>>>>>>> to WS16 but that's just speculation atm, so I'll continue to >>>>>>>>>> investigate. >>>>>>>>>> >>>>>>>>>> If you could re-test you end without using WS16 to see if you can >>>>>>>>>> reproduce the >>>>>>>>>> problem with either UNMAP or ATA_TRIM that would be a very useful >>>>>>>>>> data >>>>>>>>>> point. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> After much playing I narrow down a test case of one delete which >>>>>>>>>> was >>>>>>>>>> >>>>>>>>>> causing >>>>>>>>> disc corruption for us (deleted the partition table instead of data >>>>>>>>> in >>>>>>>>> the middle of the disk). >>>>>>>>> >>>>>>>>> The conclusion is LSI 2008 HBA with FW below P13 will eat the data >>>>>>>>> on >>>>>>>>> your >>>>>>>>> SATA >>>>>>>>> disks if you use WS16 due to the following bug:- >>>>>>>>> SCGCQ00230159 (DFCT) - Write same command to a SATA drive that >>>>>>>>> doesn't >>>>>>>>> support >>>>>>>>> SCT write same may write wrong region. >>>>>>>>> >>>>>>>>> After updating here to P16, which we would generally be running, >>>>>>>>> but >>>>>>>>> test >>>>>>>>> box >>>>>>>>> was new and hadnt updated yet the corruption issue is no longer >>>>>>>>> reproducable. >>>>>>>>> >>>>>>>>> So Ajit please check your FW version, I'm hoping to here your on >>>>>>>>> something >>>>>>>>> below P13, P12 possibly? >>>>>>>>> >>>>>>>>> If so then this is your issue, to fix simply update to P16 and the >>>>>>>>> problem >>>>>>>>> should be gone. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> >>>>>>>>> ==============================**********================== >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. >>>>>>>>> and >>>>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>>>> misdirection, >>>>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>>>> otherwise >>>>>>>>> disseminating it or any information contained in it. >>>>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>>>> please >>>>>>>>> telephone +44 845 868 1337 >>>>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ==============================********================== >>>>>>>>> >>>>>>>> >>>>>>>> This e.mail is private and confidential between Multiplay (UK) >>>>>>> Ltd. and >>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>> misdirection, >>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>> otherwise >>>>>>> disseminating it or any information contained in it. >>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>> please >>>>>>> telephone +44 845 868 1337 >>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ==============================******================== >>>>>> >>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>>> the person or entity to whom it is addressed. In the event of >>>>> misdirection, >>>>> the recipient is prohibited from using, copying, printing or otherwise >>>>> disseminating it or any information contained in it. >>>>> In the event of misdirection, illegible or incomplete transmission >>>>> please >>>>> telephone +44 845 868 1337 >>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>> >>>>> >>>>> >>>>> >>>> ==============================****================== >>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>> the person or entity to whom it is addressed. In the event of >>> misdirection, >>> the recipient is prohibited from using, copying, printing or otherwise >>> disseminating it or any information contained in it. >>> In the event of misdirection, illegible or incomplete transmission please >>> telephone +44 845 868 1337 >>> or return the E.mail to postmaster@multiplay.co.uk. >>> >>> >>> >> > ==============================**================== > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of misdirection, > the recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > --001a11c1ed8a702b9904de4f2ed7 Content-Type: application/octet-stream; name=error_log Content-Disposition: attachment; filename=error_log Content-Transfer-Encoding: base64 X-Attachment-Id: f_hhhzf8rb1 eCB1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRkaXIvRXVyb3BlL1Nrb3BqZTog Q2FuJ3QgY3JlYXRlICd1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRkaXIvRXVy b3BlL1Nrb3BqZScKeCB1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRkaXIvRXVy b3BlL1phZ3JlYjogQ2FuJ3QgY3JlYXRlICd1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8v YnVpbGRkaXIvRXVyb3BlL1phZ3JlYicKeCB1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8v YnVpbGRkaXIvRXVyb3BlL0lzbGVfb2ZfTWFuOiBDYW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNyL3Ny Yy9zaGFyZS96b25laW5mby9idWlsZGRpci9FdXJvcGUvSXNsZV9vZl9NYW4nCnggdXNyL29iai91 c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V1cm9wZS9HdWVybnNleTogQ2FuJ3QgY3Jl YXRlICd1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRkaXIvRXVyb3BlL0d1ZXJu c2V5Jwp4IHVzci9vYmovdXNyL3NyYy9zaGFyZS96b25laW5mby9idWlsZGRpci9FdXJvcGUvSmVy c2V5OiBDYW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNyL3NyYy9zaGFyZS96b25laW5mby9idWlsZGRp ci9FdXJvcGUvSmVyc2V5Jwp4IHVzci9vYmovdXNyL3NyYy9zaGFyZS96b25laW5mby9idWlsZGRp ci9FdXJvcGUvUG9kZ29yaWNhOiBDYW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNyL3NyYy9zaGFyZS96 b25laW5mby9idWlsZGRpci9FdXJvcGUvUG9kZ29yaWNhJwp4IHVzci9vYmovdXNyL3NyYy9zaGFy ZS96b25laW5mby9idWlsZGRpci9FdXJvcGUvVmF0aWNhbjogQ2FuJ3QgY3JlYXRlICd1c3Ivb2Jq L3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRkaXIvRXVyb3BlL1ZhdGljYW4nCnggdXNyL29i ai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V1cm9wZS9ManVibGphbmE6IENhbid0 IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V1cm9wZS9M anVibGphbmEnCnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V1cm9w ZS9adXJpY2g6IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1 aWxkZGlyL0V1cm9wZS9adXJpY2gnCnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1 aWxkZGlyL0V1cm9wZS9Sb21lOiBDYW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNyL3NyYy9zaGFyZS96 b25laW5mby9idWlsZGRpci9FdXJvcGUvUm9tZScKeCB1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9u ZWluZm8vYnVpbGRkaXIvRXVyb3BlL0JlbGdyYWRlOiBDYW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNy L3NyYy9zaGFyZS96b25laW5mby9idWlsZGRpci9FdXJvcGUvQmVsZ3JhZGUnCnggdXNyL29iai91 c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V1cm9wZS9QcmFndWU6IENhbid0IGNyZWF0 ZSAndXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V1cm9wZS9QcmFndWUn CnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V1cm9wZS9NYXJpZWhh bW46IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGly L0V1cm9wZS9NYXJpZWhhbW4nCnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxk ZGlyL0FyY3RpYy9Mb25neWVhcmJ5ZW46IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3No YXJlL3pvbmVpbmZvL2J1aWxkZGlyL0FyY3RpYy9Mb25neWVhcmJ5ZW4nCnggdXNyL29iai91c3Iv c3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0FzaWEvSXN0YW5idWw6IENhbid0IGNyZWF0ZSAn dXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0FzaWEvSXN0YW5idWwnCngg dXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0FzaWEvTmljb3NpYTogQ2Fu J3QgY3JlYXRlICd1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRkaXIvQXNpYS9O aWNvc2lhJwp4IHVzci9vYmovdXNyL3NyYy9zaGFyZS96b25laW5mby9idWlsZGRpci9BbnRhcmN0 aWNhL01jTXVyZG86IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZv L2J1aWxkZGlyL0FudGFyY3RpY2EvTWNNdXJkbycKeCB1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9u ZWluZm8vYnVpbGRkaXIvQW1lcmljYS9Mb3dlcl9QcmluY2VzOiBDYW4ndCBjcmVhdGUgJ3Vzci9v YmovdXNyL3NyYy9zaGFyZS96b25laW5mby9idWlsZGRpci9BbWVyaWNhL0xvd2VyX1ByaW5jZXMn CnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0FtZXJpY2EvTmV3X1lv cms6IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGly L0FtZXJpY2EvTmV3X1lvcmsnCnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxk ZGlyL0FtZXJpY2EvS3JhbGVuZGlqazogQ2FuJ3QgY3JlYXRlICd1c3Ivb2JqL3Vzci9zcmMvc2hh cmUvem9uZWluZm8vYnVpbGRkaXIvQW1lcmljYS9LcmFsZW5kaWprJwp4IHVzci9vYmovdXNyL3Ny Yy9zaGFyZS96b25laW5mby9idWlsZGRpci9BbWVyaWNhL01hcmlnb3Q6IENhbid0IGNyZWF0ZSAn dXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0FtZXJpY2EvTWFyaWdvdCcK eCB1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRkaXIvQW1lcmljYS9TaGlwcm9j azogQ2FuJ3QgY3JlYXRlICd1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRkaXIv QW1lcmljYS9TaGlwcm9jaycKeCB1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRk aXIvQW1lcmljYS9TdF9CYXJ0aGVsZW15OiBDYW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNyL3NyYy9z aGFyZS96b25laW5mby9idWlsZGRpci9BbWVyaWNhL1N0X0JhcnRoZWxlbXknCnggdXNyL29iai91 c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V0Yy9Vbml2ZXJzYWw6IENhbid0IGNyZWF0 ZSAndXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V0Yy9Vbml2ZXJzYWwn CnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V0Yy9HTVQwOiBDYW4n dCBjcmVhdGUgJ3Vzci9vYmovdXNyL3NyYy9zaGFyZS96b25laW5mby9idWlsZGRpci9FdGMvR01U MCcKeCB1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVpbGRkaXIvRXRjL0dNVCswOiBD YW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNyL3NyYy9zaGFyZS96b25laW5mby9idWlsZGRpci9FdGMv R01UKzAnCnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V0Yy9HTVQ6 IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V0 Yy9HTVQnCnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxkZGlyL0V0Yy9HcmVl bndpY2g6IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxk ZGlyL0V0Yy9HcmVlbndpY2gnCnggdXNyL29iai91c3Ivc3JjL3NoYXJlL3pvbmVpbmZvL2J1aWxk ZGlyL0V0Yy9adWx1OiBDYW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNyL3NyYy9zaGFyZS96b25laW5m by9idWlsZGRpci9FdGMvWnVsdScKeCB1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWluZm8vYnVp bGRkaXIvRXRjL1VUQzogQ2FuJ3QgY3JlYXRlICd1c3Ivb2JqL3Vzci9zcmMvc2hhcmUvem9uZWlu Zm8vYnVpbGRkaXIvRXRjL1VUQycKeCB1c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvbGli ZXhlYy9tYWtld2hhdGlzLmxvY2FsOiBDYW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNyL3NyYy90bXAv bGVnYWN5L3Vzci9saWJleGVjL21ha2V3aGF0aXMubG9jYWwnCnggdXNyL29iai91c3Ivc3JjL3Rt cC91c3IvYmluL2djcHA6IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3RtcC91c3IvYmlu L2djcHAnCnggdXNyL29iai91c3Ivc3JjL3RtcC91c3IvYmluL0NDOiBDYW4ndCBjcmVhdGUgJ3Vz ci9vYmovdXNyL3NyYy90bXAvdXNyL2Jpbi9DQycKeCB1c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9i aW4vY2M6IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL3RtcC91c3IvYmluL2NjJwp4IHVz ci9vYmovdXNyL3NyYy90bXAvdXNyL2Jpbi9jKys6IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Iv c3JjL3RtcC91c3IvYmluL2MrKycKeCB1c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9saWIvbGliZmwu YTogQ2FuJ3QgY3JlYXRlICd1c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9saWIvbGliZmwuYScKeCB1 c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9saWIvbGlibG4uYTogQ2FuJ3QgY3JlYXRlICd1c3Ivb2Jq L3Vzci9zcmMvdG1wL3Vzci9saWIvbGlibG4uYScKeCB1c3Ivb2JqL3Vzci9zcmMvbGliMzIvdXNy L2xpYjMyL2xpYmZsX3AuYTogQ2FuJ3QgY3JlYXRlICd1c3Ivb2JqL3Vzci9zcmMvbGliMzIvdXNy L2xpYjMyL2xpYmZsX3AuYScKeCB1c3Ivb2JqL3Vzci9zcmMvbGliMzIvdXNyL2xpYjMyL2xpYmZs LmE6IENhbid0IGNyZWF0ZSAndXNyL29iai91c3Ivc3JjL2xpYjMyL3Vzci9saWIzMi9saWJmbC5h Jwp4IHVzci9vYmovdXNyL3NyYy9saWIzMi91c3IvbGliMzIvbGlibC5hOiBDYW4ndCBjcmVhdGUg J3Vzci9vYmovdXNyL3NyYy9saWIzMi91c3IvbGliMzIvbGlibC5hJwp4IHVzci9vYmovdXNyL3Ny Yy9saWIzMi91c3IvbGliMzIvbGlibG5fcC5hOiBDYW4ndCBjcmVhdGUgJ3Vzci9vYmovdXNyL3Ny Yy9saWIzMi91c3IvbGliMzIvbGlibG5fcC5hJwo= --001a11c1ed8a702b9904de4f2ed7-- From owner-freebsd-fs@FreeBSD.ORG Tue Jun 4 08:35:24 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD8B036E for ; Tue, 4 Jun 2013 08:35:24 +0000 (UTC) (envelope-from prvs=1867102569=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 3E43311BF for ; Tue, 4 Jun 2013 08:35:23 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004149828.msg for ; Tue, 04 Jun 2013 09:35:15 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 04 Jun 2013 09:35:15 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1867102569=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Ajit Jain" , "freebsd-fs" References: <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk> <93D0677B373A452BAF58C8EA6823783D@multiplay.co.uk> <35ABA7AAEB7F4D86A1ED54C4C47FEB49@multiplay.co.uk> <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> <6E4EBFE196274519B847A47A062950EE@multiplay.co.uk> Subject: Re: seeing data corruption with zfs trim functionality Date: Tue, 4 Jun 2013 09:35:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 08:35:24 -0000 Those are all just symlinks so unless your extracting to the correct location then its likely just moaning because the absolutely pathed file doesn't exsit. If your just wanting to update that machine run:- rm -rf /usr/src /usr/obj tar -xzPf stable-9-r251096.tar.gz Regards Steve ----- Original Message ----- From: "Ajit Jain" To: "freebsd-fs" ; "Steven Hartland" Sent: Tuesday, June 04, 2013 8:39 AM Subject: Fwd: seeing data corruption with zfs trim functionality > Hi Steven, > > I am not able to send full output file to freebsd-fs. > I am just sending the error file in this mail and will > send you another mail which contain to full untar output. > > > regards, > ajit > > ---------- Forwarded message ---------- > From: Ajit Jain > Date: Mon, Jun 3, 2013 at 11:51 PM > Subject: Re: seeing data corruption with zfs trim functionality > To: Steven Hartland > Cc: freebsd-fs > > > Hi Steven, > > > untar of the tarball is throwing the error below: > tar: Error exit delayed from previous errors. > > I have download the file from the link 3 times, every time I am seeing the > same issue. > Please find the tar output file and error (grep from the tar output file) > attached with mail. > > checksum of tar ball (after unzip, on freebsd) is: > root@everest:/pool_9stable/obj_src/new # cksum stable-9-r251096.tar > 2972813925 3474278400 stable-9-r251096.tar > > > regards, > ajit > > > > > On Fri, May 31, 2013 at 4:12 AM, Steven Hartland wrote: > >> Tar archive of /usr/src and /usr/obj with built world and GENERIC kernel >> for ams64 can be found here:- >> http://blog.multiplay.co.uk/**dropzone/freebsd/stable-9-**r251096.tar.gz >> >> This is based off r251096 with current proposed MFC of CAM BIO_DELETE & >> ZFS TRIM. >> >> >> Regards >> Steve >> ----- Original Message ----- From: "Ajit Jain" >> >> >> Hi Steven, >>> >>> That would be really great. I'll install build provided by you and can >>> quickly >>> update the result. I am kind of feeling that I am asking too much of fever >>> from you. >>> >>> thanks for the help and bearing me, >>> ajit >>> >>> >>> On Wed, May 29, 2013 at 6:39 PM, Steven Hartland >> >**wrote: >>> >>> Unfortunately FS corruption is a serious matters so even though I'm >>>> 99.99% >>>> convinced there isn't a problem I'd still prefer to confirm this was >>>> indeed >>>> an issue with your code base and not an issue with the current code prior >>>> to MFC'ing. >>>> >>>> Would a pre-patched stable/9 source / build help. If so I can look at >>>> making >>>> that available for you. >>>> >>>> >>>> Regards >>>> Steve >>>> >>>> ----- Original Message ----- From: "Ajit Jain" >>>> >>>> >>>> Hi Steven, >>>> >>>>> >>>>> Sorry for the long delay, but might delay even further. >>>>> I think the reason for the corruption was, my code >>>>> was not updated specially cam directory. >>>>> >>>>> I request please do not stop just because of the issue I reported. >>>>> I'll update my src tree and rerun the experiments I was running >>>>> if I see some issue then probably we fix the bug rather then stopping >>>>> for MFC. >>>>> >>>>> thanks, >>>>> ajit >>>>> >>>>> >>>>> >>>>> On Wed, May 29, 2013 at 5:19 PM, Steven Hartland < >>>>> killing@multiplay.co.uk >>>>> >**wrote: >>>>> >>>>> >>>>> Sorry to pester, but any update on this Ajit? >>>>> >>>>>> >>>>>> I ask as its currently blocking the MFC of TRIM to stable/8 & 9 and >>>>>> I've >>>>>> been >>>>>> unable to reproduce this issue even with your testing code on working >>>>>> FW >>>>>> versions. >>>>>> >>>>>> >>>>>> Regards >>>>>> Steve >>>>>> >>>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>>> ajit.jain@cloudbyte.com> >>>>>> >>>>>> >>>>>> Sure Steven, >>>>>> >>>>>> I'll apply the patches and update ASAP. >>>>>>> >>>>>>> thanks >>>>>>> ajit >>>>>>> >>>>>>> >>>>>>> On Thu, May 23, 2013 at 3:03 PM, Steven Hartland < >>>>>>> killing@multiplay.co.uk >>>>>>> >**wrote: >>>>>>> >>>>>>> >>>>>>> I've attacked the two patch sets I'm looking to MFC to stable-9, one >>>>>>> >>>>>>> adds BIO_DELETE CAM changes and the other is ZFS TRIM support. >>>>>>>> >>>>>>>> They should both apply cleanly to stable-9, if you could test with >>>>>>>> those on your machine and let me know. >>>>>>>> >>>>>>>> Regards >>>>>>>> Steve >>>>>>>> >>>>>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>>>>> ajit.jain@cloudbyte.com> >>>>>>>> >>>>>>>> >>>>>>>> Hi Steven, >>>>>>>> >>>>>>>> >>>>>>>> FW version on the setup is P15. >>>>>>>>> I will upgrade the FW to P16, but I think my >>>>>>>>> best bet will be to update code base to 9 stable as unlike you, >>>>>>>>> I was seeing corruption for all three delete methods. >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> ajit >>>>>>>>> >>>>>>>>> On Sat, May 18, 2013 at 4:15 AM, Steven Hartland < >>>>>>>>> killing@multiplay.co.uk >>>>>>>>> >**wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- From: "Steven Hartland" < >>>>>>>>> >>>>>>>>> killing@multiplay.co.uk> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> After initially seeing not issues, our overnight monitoring >>>>>>>>>> started >>>>>>>>>> >>>>>>>>>> moaning >>>>>>>>>> >>>>>>>>>>> big time on the test box. So we checked and there was zpool >>>>>>>>>>> corruption >>>>>>>>>>> as >>>>>>>>>>> well >>>>>>>>>>> as a missing boot loader and a corrupt GPT, so I believe we have >>>>>>>>>>> reproduced >>>>>>>>>>> your issue. >>>>>>>>>>> >>>>>>>>>>> After recovering the machine I created 3 pools on 3 different >>>>>>>>>>> disks >>>>>>>>>>> each >>>>>>>>>>> running a different delete_method. >>>>>>>>>>> >>>>>>>>>>> We then re-ran the tests which resulted in the pool running with >>>>>>>>>>> delete_method >>>>>>>>>>> WS16 being so broken it had suspended IO. A reboot resulted in it >>>>>>>>>>> once >>>>>>>>>>> again >>>>>>>>>>> reporting no partition table via gpart. >>>>>>>>>>> >>>>>>>>>>> A third test run again produced a corrupt pool for WS16. >>>>>>>>>>> >>>>>>>>>>> I've conducted a preliminary review of the CAM WS16 code path >>>>>>>>>>> along >>>>>>>>>>> with >>>>>>>>>>> SBC-3 >>>>>>>>>>> spec which didn't identify any obvious issues. >>>>>>>>>>> >>>>>>>>>>> Given we're both using LSI 2008 based controllers it could be FW >>>>>>>>>>> issue >>>>>>>>>>> specific >>>>>>>>>>> to WS16 but that's just speculation atm, so I'll continue to >>>>>>>>>>> investigate. >>>>>>>>>>> >>>>>>>>>>> If you could re-test you end without using WS16 to see if you can >>>>>>>>>>> reproduce the >>>>>>>>>>> problem with either UNMAP or ATA_TRIM that would be a very useful >>>>>>>>>>> data >>>>>>>>>>> point. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> After much playing I narrow down a test case of one delete which >>>>>>>>>>> was >>>>>>>>>>> >>>>>>>>>>> causing >>>>>>>>>> disc corruption for us (deleted the partition table instead of data >>>>>>>>>> in >>>>>>>>>> the middle of the disk). >>>>>>>>>> >>>>>>>>>> The conclusion is LSI 2008 HBA with FW below P13 will eat the data >>>>>>>>>> on >>>>>>>>>> your >>>>>>>>>> SATA >>>>>>>>>> disks if you use WS16 due to the following bug:- >>>>>>>>>> SCGCQ00230159 (DFCT) - Write same command to a SATA drive that >>>>>>>>>> doesn't >>>>>>>>>> support >>>>>>>>>> SCT write same may write wrong region. >>>>>>>>>> >>>>>>>>>> After updating here to P16, which we would generally be running, >>>>>>>>>> but >>>>>>>>>> test >>>>>>>>>> box >>>>>>>>>> was new and hadnt updated yet the corruption issue is no longer >>>>>>>>>> reproducable. >>>>>>>>>> >>>>>>>>>> So Ajit please check your FW version, I'm hoping to here your on >>>>>>>>>> something >>>>>>>>>> below P13, P12 possibly? >>>>>>>>>> >>>>>>>>>> If so then this is your issue, to fix simply update to P16 and the >>>>>>>>>> problem >>>>>>>>>> should be gone. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Steve >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ==============================**********================== >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. >>>>>>>>>> and >>>>>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>>>>> misdirection, >>>>>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>>>>> otherwise >>>>>>>>>> disseminating it or any information contained in it. >>>>>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>>>>> please >>>>>>>>>> telephone +44 845 868 1337 >>>>>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ==============================********================== >>>>>>>>>> >>>>>>>>> >>>>>>>>> This e.mail is private and confidential between Multiplay (UK) >>>>>>>> Ltd. and >>>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>>> misdirection, >>>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>>> otherwise >>>>>>>> disseminating it or any information contained in it. >>>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>>> please >>>>>>>> telephone +44 845 868 1337 >>>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ==============================******================== >>>>>>> >>>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>>>> the person or entity to whom it is addressed. In the event of >>>>>> misdirection, >>>>>> the recipient is prohibited from using, copying, printing or otherwise >>>>>> disseminating it or any information contained in it. >>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>> please >>>>>> telephone +44 845 868 1337 >>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ==============================****================== >>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>> the person or entity to whom it is addressed. In the event of >>>> misdirection, >>>> the recipient is prohibited from using, copying, printing or otherwise >>>> disseminating it or any information contained in it. >>>> In the event of misdirection, illegible or incomplete transmission please >>>> telephone +44 845 868 1337 >>>> or return the E.mail to postmaster@multiplay.co.uk. >>>> >>>> >>>> >>> >> ==============================**================== >> This e.mail is private and confidential between Multiplay (UK) Ltd. and >> the person or entity to whom it is addressed. In the event of misdirection, >> the recipient is prohibited from using, copying, printing or otherwise >> disseminating it or any information contained in it. >> In the event of misdirection, illegible or incomplete transmission please >> telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >> >> > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Jun 4 15:53:46 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6EF50D1A for ; Tue, 4 Jun 2013 15:53:46 +0000 (UTC) (envelope-from ajit.jain@cloudbyte.com) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 33B961A1E for ; Tue, 4 Jun 2013 15:53:46 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id j6so281418oag.4 for ; Tue, 04 Jun 2013 08:53:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=7Kx2STNIoCt9k7SWLkY5obFLlv/RZxQ6LDwqtFDzYFM=; b=FyRLlBs6k0JFijAgfVfc7oGzn+36UVysibBZjjO3kb0/SEwkg79R4DuTmRaOeK9eyt GQf4cb4T78vmH8QhmcG48DCnNcmSG9MMyqiKiF9ZDnwprrF5CZSE3+DEjOuMWvBBfg3W lz/qhdiMftnGOINXT23ysKAjlH+JT9lw0rQD6bXt1RhvjLYKR+Z0HQw5C3wY9B5YzfuW TyOXeiDIcL9KuirQswS35W2fCH3ARmB7ZjDiDjiDFXhehrTgIEudw0oG1UjVKZGjxhW2 JYEh/khKyEcJeTeAyXhXMLxOl0qDg/1sLRTGfn4QFzbPP4yOyXinZE8bZOCU7QAQV1q8 l0Jg== X-Received: by 10.182.66.170 with SMTP id g10mr12757856obt.64.1370361225532; Tue, 04 Jun 2013 08:53:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.97.163 with HTTP; Tue, 4 Jun 2013 08:53:25 -0700 (PDT) In-Reply-To: References: <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk> <93D0677B373A452BAF58C8EA6823783D@multiplay.co.uk> <35ABA7AAEB7F4D86A1ED54C4C47FEB49@multiplay.co.uk> <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> <6E4EBFE196274519B847A47A062950EE@multiplay.co.uk> From: Ajit Jain Date: Tue, 4 Jun 2013 21:23:25 +0530 Message-ID: Subject: Re: seeing data corruption with zfs trim functionality To: Steven Hartland X-Gm-Message-State: ALoCoQnlvQwbJgUE+E4gyXRikKK75Q4AThWhpU3BS8MZLlBgVXjC7qN3u1WVuVMrsYHnASlusDOv Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:53:46 -0000 Hi Steven, I did not see the fs corruption issue after installing kernel from your tarball on my 9stable machine, and run the same test many times on the same physical setup with the same disk. So we can pretty much conclude that it was an issue with my src code previously. thanks ajit On Tue, Jun 4, 2013 at 2:05 PM, Steven Hartland wrote: > Those are all just symlinks so unless your extracting to the correct > location then its likely just moaning because the absolutely pathed file > doesn't exsit. > > If your just wanting to update that machine run:- > rm -rf /usr/src /usr/obj > tar -xzPf stable-9-r251096.tar.gz > > > Regards > Steve > ----- Original Message ----- From: "Ajit Jain" > To: "freebsd-fs" ; "Steven Hartland" < > killing@multiplay.co.uk> > Sent: Tuesday, June 04, 2013 8:39 AM > Subject: Fwd: seeing data corruption with zfs trim functionality > > > Hi Steven, >> >> I am not able to send full output file to freebsd-fs. >> I am just sending the error file in this mail and will >> send you another mail which contain to full untar output. >> >> >> regards, >> ajit >> >> ---------- Forwarded message ---------- >> From: Ajit Jain >> Date: Mon, Jun 3, 2013 at 11:51 PM >> Subject: Re: seeing data corruption with zfs trim functionality >> To: Steven Hartland >> Cc: freebsd-fs >> >> >> Hi Steven, >> >> >> untar of the tarball is throwing the error below: >> tar: Error exit delayed from previous errors. >> >> I have download the file from the link 3 times, every time I am seeing the >> same issue. >> Please find the tar output file and error (grep from the tar output file) >> attached with mail. >> >> checksum of tar ball (after unzip, on freebsd) is: >> root@everest:/pool_9stable/**obj_src/new # cksum stable-9-r251096.tar >> 2972813925 3474278400 stable-9-r251096.tar >> >> >> regards, >> ajit >> >> >> >> >> On Fri, May 31, 2013 at 4:12 AM, Steven Hartland > >**wrote: >> >> Tar archive of /usr/src and /usr/obj with built world and GENERIC kernel >>> for ams64 can be found here:- >>> http://blog.multiplay.co.uk/****dropzone/freebsd/stable-9-**** >>> r251096.tar.gz >>> >> *gz >>> > >>> >>> >>> This is based off r251096 with current proposed MFC of CAM BIO_DELETE & >>> ZFS TRIM. >>> >>> >>> Regards >>> Steve >>> ----- Original Message ----- From: "Ajit Jain" >>> >>> >>> Hi Steven, >>> >>>> >>>> That would be really great. I'll install build provided by you and can >>>> quickly >>>> update the result. I am kind of feeling that I am asking too much of >>>> fever >>>> from you. >>>> >>>> thanks for the help and bearing me, >>>> ajit >>>> >>>> >>>> On Wed, May 29, 2013 at 6:39 PM, Steven Hartland < >>>> killing@multiplay.co.uk >>>> >**wrote: >>>> >>>> >>>> Unfortunately FS corruption is a serious matters so even though I'm >>>> >>>>> 99.99% >>>>> convinced there isn't a problem I'd still prefer to confirm this was >>>>> indeed >>>>> an issue with your code base and not an issue with the current code >>>>> prior >>>>> to MFC'ing. >>>>> >>>>> Would a pre-patched stable/9 source / build help. If so I can look at >>>>> making >>>>> that available for you. >>>>> >>>>> >>>>> Regards >>>>> Steve >>>>> >>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>> ajit.jain@cloudbyte.com> >>>>> >>>>> >>>>> Hi Steven, >>>>> >>>>> >>>>>> Sorry for the long delay, but might delay even further. >>>>>> I think the reason for the corruption was, my code >>>>>> was not updated specially cam directory. >>>>>> >>>>>> I request please do not stop just because of the issue I reported. >>>>>> I'll update my src tree and rerun the experiments I was running >>>>>> if I see some issue then probably we fix the bug rather then stopping >>>>>> for MFC. >>>>>> >>>>>> thanks, >>>>>> ajit >>>>>> >>>>>> >>>>>> >>>>>> On Wed, May 29, 2013 at 5:19 PM, Steven Hartland < >>>>>> killing@multiplay.co.uk >>>>>> >**wrote: >>>>>> >>>>>> >>>>>> Sorry to pester, but any update on this Ajit? >>>>>> >>>>>> >>>>>>> I ask as its currently blocking the MFC of TRIM to stable/8 & 9 and >>>>>>> I've >>>>>>> been >>>>>>> unable to reproduce this issue even with your testing code on working >>>>>>> FW >>>>>>> versions. >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Steve >>>>>>> >>>>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>>>> ajit.jain@cloudbyte.com> >>>>>>> >>>>>>> >>>>>>> Sure Steven, >>>>>>> >>>>>>> I'll apply the patches and update ASAP. >>>>>>> >>>>>>>> >>>>>>>> thanks >>>>>>>> ajit >>>>>>>> >>>>>>>> >>>>>>>> On Thu, May 23, 2013 at 3:03 PM, Steven Hartland < >>>>>>>> killing@multiplay.co.uk >>>>>>>> >**wrote: >>>>>>>> >>>>>>>> >>>>>>>> I've attacked the two patch sets I'm looking to MFC to stable-9, >>>>>>>> one >>>>>>>> >>>>>>>> adds BIO_DELETE CAM changes and the other is ZFS TRIM support. >>>>>>>> >>>>>>>>> >>>>>>>>> They should both apply cleanly to stable-9, if you could test with >>>>>>>>> those on your machine and let me know. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>>>>>> ajit.jain@cloudbyte.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Steven, >>>>>>>>> >>>>>>>>> >>>>>>>>> FW version on the setup is P15. >>>>>>>>> >>>>>>>>>> I will upgrade the FW to P16, but I think my >>>>>>>>>> best bet will be to update code base to 9 stable as unlike you, >>>>>>>>>> I was seeing corruption for all three delete methods. >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> ajit >>>>>>>>>> >>>>>>>>>> On Sat, May 18, 2013 at 4:15 AM, Steven Hartland < >>>>>>>>>> killing@multiplay.co.uk >>>>>>>>>> >**wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- From: "Steven Hartland" < >>>>>>>>>> >>>>>>>>>> killing@multiplay.co.uk> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> After initially seeing not issues, our overnight monitoring >>>>>>>>>>> started >>>>>>>>>>> >>>>>>>>>>> moaning >>>>>>>>>>> >>>>>>>>>>> big time on the test box. So we checked and there was zpool >>>>>>>>>>>> corruption >>>>>>>>>>>> as >>>>>>>>>>>> well >>>>>>>>>>>> as a missing boot loader and a corrupt GPT, so I believe we have >>>>>>>>>>>> reproduced >>>>>>>>>>>> your issue. >>>>>>>>>>>> >>>>>>>>>>>> After recovering the machine I created 3 pools on 3 different >>>>>>>>>>>> disks >>>>>>>>>>>> each >>>>>>>>>>>> running a different delete_method. >>>>>>>>>>>> >>>>>>>>>>>> We then re-ran the tests which resulted in the pool running with >>>>>>>>>>>> delete_method >>>>>>>>>>>> WS16 being so broken it had suspended IO. A reboot resulted in >>>>>>>>>>>> it >>>>>>>>>>>> once >>>>>>>>>>>> again >>>>>>>>>>>> reporting no partition table via gpart. >>>>>>>>>>>> >>>>>>>>>>>> A third test run again produced a corrupt pool for WS16. >>>>>>>>>>>> >>>>>>>>>>>> I've conducted a preliminary review of the CAM WS16 code path >>>>>>>>>>>> along >>>>>>>>>>>> with >>>>>>>>>>>> SBC-3 >>>>>>>>>>>> spec which didn't identify any obvious issues. >>>>>>>>>>>> >>>>>>>>>>>> Given we're both using LSI 2008 based controllers it could be FW >>>>>>>>>>>> issue >>>>>>>>>>>> specific >>>>>>>>>>>> to WS16 but that's just speculation atm, so I'll continue to >>>>>>>>>>>> investigate. >>>>>>>>>>>> >>>>>>>>>>>> If you could re-test you end without using WS16 to see if you >>>>>>>>>>>> can >>>>>>>>>>>> reproduce the >>>>>>>>>>>> problem with either UNMAP or ATA_TRIM that would be a very >>>>>>>>>>>> useful >>>>>>>>>>>> data >>>>>>>>>>>> point. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> After much playing I narrow down a test case of one delete >>>>>>>>>>>> which >>>>>>>>>>>> was >>>>>>>>>>>> >>>>>>>>>>>> causing >>>>>>>>>>>> >>>>>>>>>>> disc corruption for us (deleted the partition table instead of >>>>>>>>>>> data >>>>>>>>>>> in >>>>>>>>>>> the middle of the disk). >>>>>>>>>>> >>>>>>>>>>> The conclusion is LSI 2008 HBA with FW below P13 will eat the >>>>>>>>>>> data >>>>>>>>>>> on >>>>>>>>>>> your >>>>>>>>>>> SATA >>>>>>>>>>> disks if you use WS16 due to the following bug:- >>>>>>>>>>> SCGCQ00230159 (DFCT) - Write same command to a SATA drive that >>>>>>>>>>> doesn't >>>>>>>>>>> support >>>>>>>>>>> SCT write same may write wrong region. >>>>>>>>>>> >>>>>>>>>>> After updating here to P16, which we would generally be running, >>>>>>>>>>> but >>>>>>>>>>> test >>>>>>>>>>> box >>>>>>>>>>> was new and hadnt updated yet the corruption issue is no longer >>>>>>>>>>> reproducable. >>>>>>>>>>> >>>>>>>>>>> So Ajit please check your FW version, I'm hoping to here your on >>>>>>>>>>> something >>>>>>>>>>> below P13, P12 possibly? >>>>>>>>>>> >>>>>>>>>>> If so then this is your issue, to fix simply update to P16 and >>>>>>>>>>> the >>>>>>>>>>> problem >>>>>>>>>>> should be gone. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Steve >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ==============================************================== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This e.mail is private and confidential between Multiplay (UK) >>>>>>>>>>> Ltd. >>>>>>>>>>> and >>>>>>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>>>>>> misdirection, >>>>>>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>>>>>> otherwise >>>>>>>>>>> disseminating it or any information contained in it. >>>>>>>>>>> In the event of misdirection, illegible or incomplete >>>>>>>>>>> transmission >>>>>>>>>>> please >>>>>>>>>>> telephone +44 845 868 1337 >>>>>>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ==============================**********================== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> This e.mail is private and confidential between Multiplay (UK) >>>>>>>>>> >>>>>>>>> Ltd. and >>>>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>>>> misdirection, >>>>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>>>> otherwise >>>>>>>>> disseminating it or any information contained in it. >>>>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>>>> please >>>>>>>>> telephone +44 845 868 1337 >>>>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ==============================********================== >>>>>>>>> >>>>>>>> >>>>>>>> This e.mail is private and confidential between Multiplay (UK) >>>>>>> Ltd. and >>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>> misdirection, >>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>> otherwise >>>>>>> disseminating it or any information contained in it. >>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>> please >>>>>>> telephone +44 845 868 1337 >>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ==============================******================== >>>>>> >>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>>> the person or entity to whom it is addressed. In the event of >>>>> misdirection, >>>>> the recipient is prohibited from using, copying, printing or otherwise >>>>> disseminating it or any information contained in it. >>>>> In the event of misdirection, illegible or incomplete transmission >>>>> please >>>>> telephone +44 845 868 1337 >>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>> >>>>> >>>>> >>>>> >>>> ==============================****================== >>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>> the person or entity to whom it is addressed. In the event of >>> misdirection, >>> the recipient is prohibited from using, copying, printing or otherwise >>> disseminating it or any information contained in it. >>> In the event of misdirection, illegible or incomplete transmission please >>> telephone +44 845 868 1337 >>> or return the E.mail to postmaster@multiplay.co.uk. >>> >>> >>> >> > > ==============================**================== > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of misdirection, > the recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > From owner-freebsd-fs@FreeBSD.ORG Tue Jun 4 16:04:15 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0D08F795 for ; Tue, 4 Jun 2013 16:04:15 +0000 (UTC) (envelope-from prvs=1867102569=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC7C1B21 for ; Tue, 4 Jun 2013 16:04:14 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004155581.msg for ; Tue, 04 Jun 2013 17:04:13 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 04 Jun 2013 17:04:13 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1867102569=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Ajit Jain" References: <93D0677B373A452BAF58C8EA6823783D@multiplay.co.uk> <35ABA7AAEB7F4D86A1ED54C4C47FEB49@multiplay.co.uk> <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> <6E4EBFE196274519B847A47A062950EE@multiplay.co.uk> Subject: Re: seeing data corruption with zfs trim functionality Date: Tue, 4 Jun 2013 17:04:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:04:15 -0000 Thanks for the confirmation Ajit, most appreciated :) Regards Steve ----- Original Message ----- From: "Ajit Jain" > Hi Steven, > > I did not see the fs corruption issue after installing kernel from your > tarball on > my 9stable machine, and run the same test many times on the same physical > setup with the same disk. > > So we can pretty much conclude that it was an issue with my src code > previously. > > thanks > ajit > > > On Tue, Jun 4, 2013 at 2:05 PM, Steven Hartland wrote: > >> Those are all just symlinks so unless your extracting to the correct >> location then its likely just moaning because the absolutely pathed file >> doesn't exsit. >> >> If your just wanting to update that machine run:- >> rm -rf /usr/src /usr/obj >> tar -xzPf stable-9-r251096.tar.gz >> >> >> Regards >> Steve >> ----- Original Message ----- From: "Ajit Jain" >> To: "freebsd-fs" ; "Steven Hartland" < >> killing@multiplay.co.uk> >> Sent: Tuesday, June 04, 2013 8:39 AM >> Subject: Fwd: seeing data corruption with zfs trim functionality >> >> >> Hi Steven, >>> >>> I am not able to send full output file to freebsd-fs. >>> I am just sending the error file in this mail and will >>> send you another mail which contain to full untar output. >>> >>> >>> regards, >>> ajit >>> >>> ---------- Forwarded message ---------- >>> From: Ajit Jain >>> Date: Mon, Jun 3, 2013 at 11:51 PM >>> Subject: Re: seeing data corruption with zfs trim functionality >>> To: Steven Hartland >>> Cc: freebsd-fs >>> >>> >>> Hi Steven, >>> >>> >>> untar of the tarball is throwing the error below: >>> tar: Error exit delayed from previous errors. >>> >>> I have download the file from the link 3 times, every time I am seeing the >>> same issue. >>> Please find the tar output file and error (grep from the tar output file) >>> attached with mail. >>> >>> checksum of tar ball (after unzip, on freebsd) is: >>> root@everest:/pool_9stable/**obj_src/new # cksum stable-9-r251096.tar >>> 2972813925 3474278400 stable-9-r251096.tar >>> >>> >>> regards, >>> ajit >>> >>> >>> >>> >>> On Fri, May 31, 2013 at 4:12 AM, Steven Hartland >> >**wrote: >>> >>> Tar archive of /usr/src and /usr/obj with built world and GENERIC kernel >>>> for ams64 can be found here:- >>>> http://blog.multiplay.co.uk/****dropzone/freebsd/stable-9-**** >>>> r251096.tar.gz >>>> >>> *gz >>>> > >>>> >>>> >>>> This is based off r251096 with current proposed MFC of CAM BIO_DELETE & >>>> ZFS TRIM. >>>> >>>> >>>> Regards >>>> Steve >>>> ----- Original Message ----- From: "Ajit Jain" >>>> >>>> >>>> Hi Steven, >>>> >>>>> >>>>> That would be really great. I'll install build provided by you and can >>>>> quickly >>>>> update the result. I am kind of feeling that I am asking too much of >>>>> fever >>>>> from you. >>>>> >>>>> thanks for the help and bearing me, >>>>> ajit >>>>> >>>>> >>>>> On Wed, May 29, 2013 at 6:39 PM, Steven Hartland < >>>>> killing@multiplay.co.uk >>>>> >**wrote: >>>>> >>>>> >>>>> Unfortunately FS corruption is a serious matters so even though I'm >>>>> >>>>>> 99.99% >>>>>> convinced there isn't a problem I'd still prefer to confirm this was >>>>>> indeed >>>>>> an issue with your code base and not an issue with the current code >>>>>> prior >>>>>> to MFC'ing. >>>>>> >>>>>> Would a pre-patched stable/9 source / build help. If so I can look at >>>>>> making >>>>>> that available for you. >>>>>> >>>>>> >>>>>> Regards >>>>>> Steve >>>>>> >>>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>>> ajit.jain@cloudbyte.com> >>>>>> >>>>>> >>>>>> Hi Steven, >>>>>> >>>>>> >>>>>>> Sorry for the long delay, but might delay even further. >>>>>>> I think the reason for the corruption was, my code >>>>>>> was not updated specially cam directory. >>>>>>> >>>>>>> I request please do not stop just because of the issue I reported. >>>>>>> I'll update my src tree and rerun the experiments I was running >>>>>>> if I see some issue then probably we fix the bug rather then stopping >>>>>>> for MFC. >>>>>>> >>>>>>> thanks, >>>>>>> ajit >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, May 29, 2013 at 5:19 PM, Steven Hartland < >>>>>>> killing@multiplay.co.uk >>>>>>> >**wrote: >>>>>>> >>>>>>> >>>>>>> Sorry to pester, but any update on this Ajit? >>>>>>> >>>>>>> >>>>>>>> I ask as its currently blocking the MFC of TRIM to stable/8 & 9 and >>>>>>>> I've >>>>>>>> been >>>>>>>> unable to reproduce this issue even with your testing code on working >>>>>>>> FW >>>>>>>> versions. >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Steve >>>>>>>> >>>>>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>>>>> ajit.jain@cloudbyte.com> >>>>>>>> >>>>>>>> >>>>>>>> Sure Steven, >>>>>>>> >>>>>>>> I'll apply the patches and update ASAP. >>>>>>>> >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> ajit >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, May 23, 2013 at 3:03 PM, Steven Hartland < >>>>>>>>> killing@multiplay.co.uk >>>>>>>>> >**wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I've attacked the two patch sets I'm looking to MFC to stable-9, >>>>>>>>> one >>>>>>>>> >>>>>>>>> adds BIO_DELETE CAM changes and the other is ZFS TRIM support. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> They should both apply cleanly to stable-9, if you could test with >>>>>>>>>> those on your machine and let me know. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Steve >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>>>>>>> ajit.jain@cloudbyte.com> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Steven, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> FW version on the setup is P15. >>>>>>>>>> >>>>>>>>>>> I will upgrade the FW to P16, but I think my >>>>>>>>>>> best bet will be to update code base to 9 stable as unlike you, >>>>>>>>>>> I was seeing corruption for all three delete methods. >>>>>>>>>>> >>>>>>>>>>> thanks >>>>>>>>>>> ajit >>>>>>>>>>> >>>>>>>>>>> On Sat, May 18, 2013 at 4:15 AM, Steven Hartland < >>>>>>>>>>> killing@multiplay.co.uk >>>>>>>>>>> >**wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- From: "Steven Hartland" < >>>>>>>>>>> >>>>>>>>>>> killing@multiplay.co.uk> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> After initially seeing not issues, our overnight monitoring >>>>>>>>>>>> started >>>>>>>>>>>> >>>>>>>>>>>> moaning >>>>>>>>>>>> >>>>>>>>>>>> big time on the test box. So we checked and there was zpool >>>>>>>>>>>>> corruption >>>>>>>>>>>>> as >>>>>>>>>>>>> well >>>>>>>>>>>>> as a missing boot loader and a corrupt GPT, so I believe we have >>>>>>>>>>>>> reproduced >>>>>>>>>>>>> your issue. >>>>>>>>>>>>> >>>>>>>>>>>>> After recovering the machine I created 3 pools on 3 different >>>>>>>>>>>>> disks >>>>>>>>>>>>> each >>>>>>>>>>>>> running a different delete_method. >>>>>>>>>>>>> >>>>>>>>>>>>> We then re-ran the tests which resulted in the pool running with >>>>>>>>>>>>> delete_method >>>>>>>>>>>>> WS16 being so broken it had suspended IO. A reboot resulted in >>>>>>>>>>>>> it >>>>>>>>>>>>> once >>>>>>>>>>>>> again >>>>>>>>>>>>> reporting no partition table via gpart. >>>>>>>>>>>>> >>>>>>>>>>>>> A third test run again produced a corrupt pool for WS16. >>>>>>>>>>>>> >>>>>>>>>>>>> I've conducted a preliminary review of the CAM WS16 code path >>>>>>>>>>>>> along >>>>>>>>>>>>> with >>>>>>>>>>>>> SBC-3 >>>>>>>>>>>>> spec which didn't identify any obvious issues. >>>>>>>>>>>>> >>>>>>>>>>>>> Given we're both using LSI 2008 based controllers it could be FW >>>>>>>>>>>>> issue >>>>>>>>>>>>> specific >>>>>>>>>>>>> to WS16 but that's just speculation atm, so I'll continue to >>>>>>>>>>>>> investigate. >>>>>>>>>>>>> >>>>>>>>>>>>> If you could re-test you end without using WS16 to see if you >>>>>>>>>>>>> can >>>>>>>>>>>>> reproduce the >>>>>>>>>>>>> problem with either UNMAP or ATA_TRIM that would be a very >>>>>>>>>>>>> useful >>>>>>>>>>>>> data >>>>>>>>>>>>> point. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> After much playing I narrow down a test case of one delete >>>>>>>>>>>>> which >>>>>>>>>>>>> was >>>>>>>>>>>>> >>>>>>>>>>>>> causing >>>>>>>>>>>>> >>>>>>>>>>>> disc corruption for us (deleted the partition table instead of >>>>>>>>>>>> data >>>>>>>>>>>> in >>>>>>>>>>>> the middle of the disk). >>>>>>>>>>>> >>>>>>>>>>>> The conclusion is LSI 2008 HBA with FW below P13 will eat the >>>>>>>>>>>> data >>>>>>>>>>>> on >>>>>>>>>>>> your >>>>>>>>>>>> SATA >>>>>>>>>>>> disks if you use WS16 due to the following bug:- >>>>>>>>>>>> SCGCQ00230159 (DFCT) - Write same command to a SATA drive that >>>>>>>>>>>> doesn't >>>>>>>>>>>> support >>>>>>>>>>>> SCT write same may write wrong region. >>>>>>>>>>>> >>>>>>>>>>>> After updating here to P16, which we would generally be running, >>>>>>>>>>>> but >>>>>>>>>>>> test >>>>>>>>>>>> box >>>>>>>>>>>> was new and hadnt updated yet the corruption issue is no longer >>>>>>>>>>>> reproducable. >>>>>>>>>>>> >>>>>>>>>>>> So Ajit please check your FW version, I'm hoping to here your on >>>>>>>>>>>> something >>>>>>>>>>>> below P13, P12 possibly? >>>>>>>>>>>> >>>>>>>>>>>> If so then this is your issue, to fix simply update to P16 and >>>>>>>>>>>> the >>>>>>>>>>>> problem >>>>>>>>>>>> should be gone. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Steve >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ==============================************================== >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This e.mail is private and confidential between Multiplay (UK) >>>>>>>>>>>> Ltd. >>>>>>>>>>>> and >>>>>>>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>>>>>>> misdirection, >>>>>>>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>>>>>>> otherwise >>>>>>>>>>>> disseminating it or any information contained in it. >>>>>>>>>>>> In the event of misdirection, illegible or incomplete >>>>>>>>>>>> transmission >>>>>>>>>>>> please >>>>>>>>>>>> telephone +44 845 868 1337 >>>>>>>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ==============================**********================== >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> This e.mail is private and confidential between Multiplay (UK) >>>>>>>>>>> >>>>>>>>>> Ltd. and >>>>>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>>>>> misdirection, >>>>>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>>>>> otherwise >>>>>>>>>> disseminating it or any information contained in it. >>>>>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>>>>> please >>>>>>>>>> telephone +44 845 868 1337 >>>>>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ==============================********================== >>>>>>>>>> >>>>>>>>> >>>>>>>>> This e.mail is private and confidential between Multiplay (UK) >>>>>>>> Ltd. and >>>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>>> misdirection, >>>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>>> otherwise >>>>>>>> disseminating it or any information contained in it. >>>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>>> please >>>>>>>> telephone +44 845 868 1337 >>>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ==============================******================== >>>>>>> >>>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>>>> the person or entity to whom it is addressed. In the event of >>>>>> misdirection, >>>>>> the recipient is prohibited from using, copying, printing or otherwise >>>>>> disseminating it or any information contained in it. >>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>> please >>>>>> telephone +44 845 868 1337 >>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ==============================****================== >>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>> the person or entity to whom it is addressed. In the event of >>>> misdirection, >>>> the recipient is prohibited from using, copying, printing or otherwise >>>> disseminating it or any information contained in it. >>>> In the event of misdirection, illegible or incomplete transmission please >>>> telephone +44 845 868 1337 >>>> or return the E.mail to postmaster@multiplay.co.uk. >>>> >>>> >>>> >>> >> >> ==============================**================== >> This e.mail is private and confidential between Multiplay (UK) Ltd. and >> the person or entity to whom it is addressed. In the event of misdirection, >> the recipient is prohibited from using, copying, printing or otherwise >> disseminating it or any information contained in it. >> In the event of misdirection, illegible or incomplete transmission please >> telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >> >> > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 19:24:39 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0D09C2FF for ; Thu, 6 Jun 2013 19:24:39 +0000 (UTC) (envelope-from mxb@alumni.chalmers.se) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1C51353 for ; Thu, 6 Jun 2013 19:24:37 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id fp12so2293034lab.8 for ; Thu, 06 Jun 2013 12:24:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer:x-gm-message-state; bh=mQzCLsyEFPEpej4gVREKQYl2PKQeIZbLHInE8rRkbOA=; b=FrUp2SXsJd9wqvAnhSsvrwFix8GNv0Soy6HjIA9jAZ/6q4RtcB2Zd9Ml4FYWJbJmtb 1UUCtQas3qnp6/1ioIxA084Tx/IVYZ97AziDFQN2Q6J/t5yIE0ijQPy0ZdQQsaUuOInS 4ab6fEkc5JAm+tn7Zov2MOrBrUlVHuHRTkTtzgS4n7Kmtn5olaNiisAONGmQ+T7uDf+m uFpf5/hC9Og8XpZ6kLhQpK73013H6cErON8TlH4dSWSyMGUrQ7+ZAV8i8VU3K6O0qv9u uUJYHz/B60mQPIQZg4BwC+AkAUiU7tswk95YqXBWADhzbSUjCrNKo6yky8WfQIgUGzAn yMeQ== X-Received: by 10.112.61.199 with SMTP id s7mr528986lbr.53.1370546676512; Thu, 06 Jun 2013 12:24:36 -0700 (PDT) Received: from grey.home.unixconn.com (h-75-17.a183.priv.bahnhof.se. [46.59.75.17]) by mx.google.com with ESMTPSA id f9sm29294600lbf.4.2013.06.06.12.24.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 12:24:35 -0700 (PDT) From: mxb Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: zpool export/import on failover - The pool metadata is corrupted Message-Id: Date: Thu, 6 Jun 2013 21:24:34 +0200 To: "freebsd-fs@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQk3OIbYPTDY6EDV//ouiDNI+tTWduHPfwi2lCGlO0VjFu6kk3zwm6OI2M/8DajFgz9QeswK X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:24:39 -0000 Hello list, I have two-head ZFS setup with external disk enclosure over SAS = expander. This is a failover setup with CARP and devd triggering spool = export/import. One of two nodes is preferred master. Then master is rebooted, devd kicks in as of CARP becomes master and the = second node picks up ZFS-disks from external enclosure. Then master comes back, CARP becomes master, devd kicks in and pool gets = exported from the second node and imported on the first one. However, I have experienced metadata corruption several times with this = setup. Note, that ZIL(mirrored) resides on external enclosure. Only L2ARC is = both local and external - da1,da2, da13s2, da14s2 root@nfs2:/root # zpool import pool: jbod id: 17635654860276652744 state: FAULTED status: The pool metadata is corrupted. action: The pool cannot be imported due to damaged devices or data. see: http://illumos.org/msg/ZFS-8000-72 config: jbod FAULTED corrupted data raidz3-0 ONLINE da3 ONLINE da4 ONLINE da5 ONLINE da6 ONLINE da7 ONLINE da8 ONLINE da9 ONLINE da10 ONLINE da11 ONLINE da12 ONLINE cache da1 da2 da13s2 da14s2 logs mirror-1 ONLINE da13s1 ONLINE da14s1 ONLINE Any ideas what is going on? //mxb =20= From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 20:01:30 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 33A4B939 for ; Thu, 6 Jun 2013 20:01:30 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id D766C112C for ; Thu, 6 Jun 2013 20:01:29 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 8CC121A0986 for ; Fri, 7 Jun 2013 05:28:12 +1000 (EST) Date: Fri, 7 Jun 2013 05:28:11 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: fs@freebsd.org Subject: missed clustering for small block sizes in cluster_wbuild() Message-ID: <20130607044845.O24441@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=eqSHVfVX c=1 sm=1 a=S7OjstH4qeUA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=N13i1VaKTP4A:10 a=CGTDn-9qxvHUQwg02b0A:9 a=CjuIK1q_8ugA:10 a=7VLQcNi6lEzEuJ70:21 a=ZZlYl6MfCIyY2woO:21 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:01:30 -0000 Would someone please fix this fairly small bug is cluster_wbuild(). When the fs block size is 512 bytes and everything is contiguous, cluster_write() prepares a complete cluster but cluster_build() splits it into two with a runt of size PAGE_SIZE - 512 bytes for the second part. >From vfs_cluster.c: @ /* @ * From this location in the file, scan forward to see @ * if there are buffers with adjacent data that need to @ * be written as well. @ */ @ for (i = 0; i < len; ++i, ++start_lbn) { @ if (i != 0) { /* If not the first buffer */ @ s = splbio(); @ /* @ * If the adjacent data is not even in core it @ * can't need to be written. @ */ @ VI_LOCK(vp); @ if ((tbp = gbincore(vp, start_lbn)) == NULL || @ (tbp->b_vflags & BV_BKGRDINPROG)) { @ VI_UNLOCK(vp); @ splx(s); @ break; @ } @ @ /* @ * If it IS in core, but has different @ * characteristics, or is locked (which @ * means it could be undergoing a background @ * I/O or be in a weird state), then don't @ * cluster with it. @ */ @ if (BUF_LOCK(tbp, @ LK_EXCLUSIVE | LK_NOWAIT | LK_INTERLOCK, @ VI_MTX(vp))) { @ splx(s); @ break; @ } @ @ if ((tbp->b_flags & (B_VMIO | B_CLUSTEROK | @ B_INVAL | B_DELWRI | B_NEEDCOMMIT)) @ != (B_DELWRI | B_CLUSTEROK | @ (bp->b_flags & (B_VMIO | B_NEEDCOMMIT))) || @ tbp->b_wcred != bp->b_wcred) { @ BUF_UNLOCK(tbp); @ splx(s); @ break; @ } @ @ /* @ * Check that the combined cluster @ * would make sense with regard to pages @ * and would not be too large @ */ @ if ((tbp->b_bcount != size) || @ ((bp->b_blkno + (dbsize * i)) != @ tbp->b_blkno) || @ ((tbp->b_npages + bp->b_npages) > @ (vp->v_mount->mnt_iosize_max / PAGE_SIZE))) { This page count check is wrong. Usually mnt_iosize_max is 128K and PAGE_SIZE is 4K. This gives a limit of 32 pages, which is normally enough to hold 256 512-blocks (very sparsely and wastefully mapped, but that is another, much larger bug). The pages up to the 31st are built up right and hold 248 512-blocks. Then bp->b_npages is 31 and tbp->npages = 1. The sum is 32 so the 32nd page is started right. The 249th 512-block is allocated in it. Then for the next 512-block, bp->b_npages is 32 so the sum is 33 so we break out of the loop prematurely. The buffer containing 249 512-blocks is written out. cluster_wbuild() continues and builds and writes out a runt buffer containing the remaining 7 512-blocks. For a quick fix, I just removed this check. cluster_write() should never prepare a cluster too large to write out in 1 step. It uses mnt_stat.f_iosize instead mnt_iosize_max for the limit, and that should not be larger. But there may be a special case where the buffer contents is not aligned. Then an extra page might be needed. @ BUF_UNLOCK(tbp); @ splx(s); @ break; @ } @ /* @ * Ok, it's passed all the tests, @ * so remove it from the free list @ * and mark it busy. We will use it. @ */ @ bremfree(tbp); @ tbp->b_flags &= ~B_DONE; @ splx(s); @ } /* end of code for non-first buffers only */ @ /* check for latent dependencies to be handled */ @ if ((LIST_FIRST(&tbp->b_dep)) != NULL) { @ tbp->b_iocmd = BIO_WRITE; @ buf_start(tbp); @ } @ /* @ * If the IO is via the VM then we do some @ * special VM hackery (yuck). Since the buffer's @ * block size may not be page-aligned it is possible @ * for a page to be shared between two buffers. We @ * have to get rid of the duplication when building @ * the cluster. @ */ @ if (tbp->b_flags & B_VMIO) { @ vm_page_t m; @ @ if (i != 0) { /* if not first buffer */ @ for (j = 0; j < tbp->b_npages; j += 1) { @ m = tbp->b_pages[j]; @ if (m->flags & PG_BUSY) { @ bqrelse(tbp); @ goto finishcluster; @ } @ } @ } @ if (tbp->b_object != NULL) @ VM_OBJECT_LOCK(tbp->b_object); @ vm_page_lock_queues(); @ for (j = 0; j < tbp->b_npages; j += 1) { @ m = tbp->b_pages[j]; @ vm_page_io_start(m); @ vm_object_pip_add(m->object, 1); @ if ((bp->b_npages == 0) || @ (bp->b_pages[bp->b_npages - 1] != m)) { @ bp->b_pages[bp->b_npages] = m; @ bp->b_npages++; The number of new pages needed is the number of increments here, which I think is 1 less than bp->b_pages in most cases where the runt buffer is built. I think this is best fixed be fixed by removing the check above and checking here. Then back out of the changes. I don't know this code well enough to write the backing out easily. @ } @ } @ vm_page_unlock_queues(); @ if (tbp->b_object != NULL) @ VM_OBJECT_UNLOCK(tbp->b_object); @ } @ bp->b_bcount += size; @ bp->b_bufsize += size; @ @ s = splbio(); @ bundirty(tbp); @ tbp->b_flags &= ~B_DONE; @ tbp->b_ioflags &= ~BIO_ERROR; @ tbp->b_flags |= B_ASYNC; @ tbp->b_iocmd = BIO_WRITE; @ reassignbuf(tbp, tbp->b_vp); /* put on clean list */ @ VI_LOCK(tbp->b_vp); @ ++tbp->b_vp->v_numoutput; @ VI_UNLOCK(tbp->b_vp); @ splx(s); @ BUF_KERNPROC(tbp); @ TAILQ_INSERT_TAIL(&bp->b_cluster.cluster_head, @ tbp, b_cluster.cluster_entry); @ } The loss of i/o performance from this wasn't too bad on my disks. The bug mainly made it harder to see the size of other clustering bugs by watching iostat output. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 20:06:52 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7FF1E9F5 for ; Thu, 6 Jun 2013 20:06:52 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by mx1.freebsd.org (Postfix) with ESMTP id 5D50E1159 for ; Thu, 6 Jun 2013 20:06:52 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id w16so3774693pde.23 for ; Thu, 06 Jun 2013 13:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ipXIycMyF9wva91UXUmtgcU6cP6NNrWpdxJIIRXrC7A=; b=HEEEQiOVz758KZ5/+amCBLETLB8I9HbzDt/6PXGqFB+BhqNToByDYdGzukUcFNTLYp WgVPab5MyRNtqrIacDTzapgjudJ/T9cFgFWwMByT6y9Ek0/0EBtQhMfzGtB6uXRvuVrw J/vBVLbdzLPW9OxQ+OIJdKvhF6+hLJUgx4Eh0hvh8xnJiWp9rXrF0ysi8XBhqY7yXHzJ PBhFgNJGESZjlu6NJCWBNdav/Et+irVS9K3Gva0/ATaZJQ8g5ypVnDCleKmMzNl3rmEd BMiUUl+nI6sy40F/H3dSnjo0SH6eVfy58bHL8sS2A/41eiXpoPpzI5XUQlsuDlMX06ze 2I0w== MIME-Version: 1.0 X-Received: by 10.68.160.132 with SMTP id xk4mr40135226pbb.37.1370549205940; Thu, 06 Jun 2013 13:06:45 -0700 (PDT) Received: by 10.66.160.66 with HTTP; Thu, 6 Jun 2013 13:06:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 16:06:45 -0400 Message-ID: Subject: Re: zpool export/import on failover - The pool metadata is corrupted From: Outback Dingo To: mxb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:06:52 -0000 On Thu, Jun 6, 2013 at 3:24 PM, mxb wrote: > > Hello list, > > I have two-head ZFS setup with external disk enclosure over SAS expander. > This is a failover setup with CARP and devd triggering spool export/import. > One of two nodes is preferred master. > > Then master is rebooted, devd kicks in as of CARP becomes master and the > second node picks up ZFS-disks from external enclosure. > Then master comes back, CARP becomes master, devd kicks in and pool gets > exported from the second node and imported on the first one. > > However, I have experienced metadata corruption several times with this > setup. > Note, that ZIL(mirrored) resides on external enclosure. Only L2ARC is both > local and external - da1,da2, da13s2, da14s2 > > root@nfs2:/root # zpool import > pool: jbod > id: 17635654860276652744 > state: FAULTED > status: The pool metadata is corrupted. > action: The pool cannot be imported due to damaged devices or data. > see: http://illumos.org/msg/ZFS-8000-72 > config: > > jbod FAULTED corrupted data > raidz3-0 ONLINE > da3 ONLINE > da4 ONLINE > da5 ONLINE > da6 ONLINE > da7 ONLINE > da8 ONLINE > da9 ONLINE > da10 ONLINE > da11 ONLINE > da12 ONLINE > cache > da1 > da2 > da13s2 > da14s2 > logs > mirror-1 ONLINE > da13s1 ONLINE > da14s1 ONLINE > > Any ideas what is going on? > Best case scenerio, both nodes tried to import the disks simultaneously, split brain condition, or disks appear out of order and no using labels, we had a similar situation with geom_multipath, theres no quorum disks knowledge yet for FreeBSD using zfs in this configuration, we ran it similarly for a while, until we realized through research it was bad karma to let carp and devd control nodes without a fool proof way to be sure nodes were ready to export/import. though you did state "Then master comes back, CARP becomes master, devd kicks in and pool gets exported from the second node and imported on the first one." be nice to see how you managed that with scripts... even if both nodes booted simultaneously their both going to "fight" for master and try to import that pool. > //mxb > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 20:14:54 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 92880C4A for ; Thu, 6 Jun 2013 20:14:54 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by mx1.freebsd.org (Postfix) with ESMTP id 5122311AC for ; Thu, 6 Jun 2013 20:14:53 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id E21455348B3 for ; Thu, 6 Jun 2013 21:33:58 +0200 (CEST) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 72357172080; Thu, 6 Jun 2013 21:33:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 8xztYmocPT9n; Thu, 6 Jun 2013 21:33:46 +0200 (CEST) X-Originating-IP: 67.180.84.87 Received: from jdc.koitsu.org (c-67-180-84-87.hsd1.ca.comcast.net [67.180.84.87]) (Authenticated sender: jdc@koitsu.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 943B9172095; Thu, 6 Jun 2013 21:33:42 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id A18C273A1C; Thu, 6 Jun 2013 12:33:40 -0700 (PDT) Date: Thu, 6 Jun 2013 12:33:40 -0700 From: Jeremy Chadwick To: mxb Subject: Re: zpool export/import on failover - The pool metadata is corrupted Message-ID: <20130606193340.GA42205@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:14:54 -0000 On Thu, Jun 06, 2013 at 09:24:34PM +0200, mxb wrote: > > Hello list, > > I have two-head ZFS setup with external disk enclosure over SAS expander. > This is a failover setup with CARP and devd triggering spool export/import. > One of two nodes is preferred master. > > Then master is rebooted, devd kicks in as of CARP becomes master and the second node picks up ZFS-disks from external enclosure. > Then master comes back, CARP becomes master, devd kicks in and pool gets exported from the second node and imported on the first one. > > However, I have experienced metadata corruption several times with this setup. > Note, that ZIL(mirrored) resides on external enclosure. Only L2ARC is both local and external - da1,da2, da13s2, da14s2 > > root@nfs2:/root # zpool import > pool: jbod > id: 17635654860276652744 > state: FAULTED > status: The pool metadata is corrupted. > action: The pool cannot be imported due to damaged devices or data. > see: http://illumos.org/msg/ZFS-8000-72 > config: > > jbod FAULTED corrupted data > raidz3-0 ONLINE > da3 ONLINE > da4 ONLINE > da5 ONLINE > da6 ONLINE > da7 ONLINE > da8 ONLINE > da9 ONLINE > da10 ONLINE > da11 ONLINE > da12 ONLINE > cache > da1 > da2 > da13s2 > da14s2 > logs > mirror-1 ONLINE > da13s1 ONLINE > da14s1 ONLINE > > Any ideas what is going on? uname -a please. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 21:10:55 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C8F4DAD7 for ; Thu, 6 Jun 2013 21:10:55 +0000 (UTC) (envelope-from editor@callfortesting.org) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id A74D615E6 for ; Thu, 6 Jun 2013 21:10:55 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id rl6so2039773pac.1 for ; Thu, 06 Jun 2013 14:10:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=4HWJYffgZ7lizQ3HmaYnSwh5Jhfg1jqqhew7JlHDpyE=; b=ZtZFRrcXa49+D7+hy44epeSg9jjILhpN+/tGe7u+/t+sMzSYm7N+fx80W+pPLUpMQ5 MKt72OnFAHt2khhjvHc1/R4ZgwPI4KgwyWogulIJkTSoW68XNKlKA4Q0PgUpz2kiva0f x4RBPBON9K5dM768m12dtmizBKVA02l/bI1tqlt+2uOvq7nZ6hZaDuAsO4zGUH8+EC9k YN0aOSGSviflcjnHzG65dcPrx1SV6h58NkgERjzZpjhgJM8RkHTTkFV/MbYhErtPeARi MM8erGeZdgHEpcMqxSb8Gy46kzufqUCH8qC07A3tBbJrh2OjNSV36P55IgQFIjOol/Dy 0h1A== X-Received: by 10.68.170.193 with SMTP id ao1mr23658775pbc.18.1370553055103; Thu, 06 Jun 2013 14:10:55 -0700 (PDT) Received: from MacBook-4.local (c-98-246-202-204.hsd1.or.comcast.net. [98.246.202.204]) by mx.google.com with ESMTPSA id uv1sm74305155pbc.16.2013.06.06.14.10.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 14:10:54 -0700 (PDT) Message-ID: <51B0FADB.10302@callfortesting.org> Date: Thu, 06 Jun 2013 14:10:51 -0700 From: Michael Dexter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: ZFS panic on import under VMware Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkk7LCY0FLzy7Ef1dhRq2jvJOGsrj7RGMwtoWlChJz9gtHgeo4Is/K3PHR1Inc9F8cOSAZz X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:10:55 -0000 Hello all, I have encountered a FreeNAS under VMware system that gives "ONLINE" status for a pool with 'zfs import' but panics when a -f import is done under FreeNAS 8.3 x64, FreeBSD 10 and Solaris 11 live DVD. The host filesystem passes all checks. The panic reports: Stopped at traverse_prefetch_metadata+0x44: movq 0x50(%rax),%rcx I have posted screen shots of the import, panic and backtrace output: http://cft.lv/zfs/2013-07-06/ Any suggestions? Thanks, Michael From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 21:52:47 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C8EAD482 for ; Thu, 6 Jun 2013 21:52:47 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 8879F178C for ; Thu, 6 Jun 2013 21:52:47 +0000 (UTC) Received: from mfilter3-d.gandi.net (mfilter3-d.gandi.net [217.70.178.133]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id C2C4F41C061; Thu, 6 Jun 2013 23:52:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter3-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter3-d.gandi.net (mfilter3-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id xZPO2oAc-Xte; Thu, 6 Jun 2013 23:52:28 +0200 (CEST) X-Originating-IP: 67.180.84.87 Received: from jdc.koitsu.org (c-67-180-84-87.hsd1.ca.comcast.net [67.180.84.87]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0AE7F41C05D; Thu, 6 Jun 2013 23:52:26 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id A4DF373A1C; Thu, 6 Jun 2013 14:52:24 -0700 (PDT) Date: Thu, 6 Jun 2013 14:52:24 -0700 From: Jeremy Chadwick To: Michael Dexter Subject: Re: ZFS panic on import under VMware Message-ID: <20130606215224.GA44910@icarus.home.lan> References: <51B0FADB.10302@callfortesting.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B0FADB.10302@callfortesting.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:52:47 -0000 On Thu, Jun 06, 2013 at 02:10:51PM -0700, Michael Dexter wrote: > Hello all, > > I have encountered a FreeNAS under VMware system that gives "ONLINE" > status for a pool with 'zfs import' but panics when a -f import is > done under FreeNAS 8.3 x64, FreeBSD 10 and Solaris 11 live DVD. The > host filesystem passes all checks. > > The panic reports: > > Stopped at traverse_prefetch_metadata+0x44: movq 0x50(%rax),%rcx > > I have posted screen shots of the import, panic and backtrace output: > > http://cft.lv/zfs/2013-07-06/ > > Any suggestions? 1. On what OS (version, etc.) was the ZFS pool originally created? 2. Was the pool originally created with compression or dedup enabled? (Answers to both of these questions is extremely important) 3. How much memory are you allocating to the VMware instance? (This is in partial relation to question #2) 4. On what OS (version, etc.) are the panic/backtrace screenshots from? It looks to me like FreeBSD 10.x. 5. Is there a reason you didn't try FreeBSD 9.1-RELEASE? The state of FreeBSD 10.x (head/CURRENT) is usually in fluctuation, you should try something other than head. 6. You're using VMware Workstation; where did the source ZFS pool come from? Do you have physical disks attached to the machine and are using the "Use a physical disk" feature? If you're using "disk images" made by something, what did you use? Please provide all the details, how you did it, etc... 7. Is there some reason you cannot try this on bare metal? 8. On FreeBSD 9.x (see above) or 10.x, during boot, drop to the loader prompt and issue "set vfs.zfs.prefetch_disable=1" followed by "boot". See if that has any impact during the "zpool import" phase. Otherwise, ZFS experts are going to have to help you, and will probably require use of zdb(8) and a lot of attention. You may get faster and better support from Illumos/OpenIndiana or Solaris-related lists, especially if you are able to panic those with ZFS. I am certain they will be **extremely** interested (folks there are responsible for ZFS as a filesystem, not FreeBSD/FreeNAS/etc.). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 22:04:40 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94A0CB56 for ; Thu, 6 Jun 2013 22:04:40 +0000 (UTC) (envelope-from mxb@alumni.chalmers.se) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF2317FA for ; Thu, 6 Jun 2013 22:04:39 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id t11so3621873lbd.29 for ; Thu, 06 Jun 2013 15:04:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8tbn2dVNcK5B6YolsfHZfzlxWOCRi4AYyNhnfbFeeRs=; b=Q8vxrWS/kQ8H0QKF7aJy9z+Jy7s3lmHn5vvR503vb6LrQvde35ekTl66y5XHOejwUx WsIA25y8z/MFk6saCkncvt0ATMuCfsWOebm0oDNmvOKM+ESmv1a9tzaEljTMo+o84f5M reL2DAt90Ms0ol8wIFg7AQsuY6yB0HnkiLHMkbGuKdWb/XqOjM9WFa8Od97hxkoMX00K tNMa693XKlY4ECmZNbZLXEqdmheTU2j8RODQ0huqnP+8SyfkcNOZ712wGOXO3NCxTYtM aks+E2HAXokftKe+wONrkpFEVCjhimD+e/0tKowMDWW6UTQsB5UuUHOaYRfS8Nnlf4Fl YUxw== X-Received: by 10.152.18.234 with SMTP id z10mr18494303lad.29.1370556272501; Thu, 06 Jun 2013 15:04:32 -0700 (PDT) Received: from grey.home.unixconn.com (h-75-17.a183.priv.bahnhof.se. [46.59.75.17]) by mx.google.com with ESMTPSA id f8sm29440973lbr.10.2013.06.06.15.04.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 15:04:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: zpool export/import on failover - The pool metadata is corrupted From: mxb In-Reply-To: <20130606193340.GA42205@icarus.home.lan> Date: Fri, 7 Jun 2013 00:04:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34F6EC70-1812-44A2-AE6E-8DF8414404FE@alumni.chalmers.se> References: <20130606193340.GA42205@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkXYLDI3KNWZElELKN6Zo/tLXumtf7gW8xHdbPeokuN4ajAQcJY2HbMwSO+gaf5ngfUw3lz Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:04:40 -0000 root@nfs2:/root # uname -a FreeBSD nfs2 9.1-STABLE FreeBSD 9.1-STABLE #1: Tue May 21 21:42:21 CEST = 2013 root@nfs2:/usr/obj/usr/src/sys/GENERIC amd64 root@nfs2:/root # On 6 jun 2013, at 21:33, Jeremy Chadwick wrote: > On Thu, Jun 06, 2013 at 09:24:34PM +0200, mxb wrote: >>=20 >> Hello list, >>=20 >> I have two-head ZFS setup with external disk enclosure over SAS = expander. >> This is a failover setup with CARP and devd triggering spool = export/import. >> One of two nodes is preferred master. >>=20 >> Then master is rebooted, devd kicks in as of CARP becomes master and = the second node picks up ZFS-disks from external enclosure. >> Then master comes back, CARP becomes master, devd kicks in and pool = gets exported from the second node and imported on the first one. >>=20 >> However, I have experienced metadata corruption several times with = this setup. >> Note, that ZIL(mirrored) resides on external enclosure. Only L2ARC is = both local and external - da1,da2, da13s2, da14s2 >>=20 >> root@nfs2:/root # zpool import >> pool: jbod >> id: 17635654860276652744 >> state: FAULTED >> status: The pool metadata is corrupted. >> action: The pool cannot be imported due to damaged devices or data. >> see: http://illumos.org/msg/ZFS-8000-72 >> config: >>=20 >> jbod FAULTED corrupted data >> raidz3-0 ONLINE >> da3 ONLINE >> da4 ONLINE >> da5 ONLINE >> da6 ONLINE >> da7 ONLINE >> da8 ONLINE >> da9 ONLINE >> da10 ONLINE >> da11 ONLINE >> da12 ONLINE >> cache >> da1 >> da2 >> da13s2 >> da14s2 >> logs >> mirror-1 ONLINE >> da13s1 ONLINE >> da14s1 ONLINE >>=20 >> Any ideas what is going on? >=20 > uname -a please. >=20 > --=20 > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | >=20 From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 22:12:43 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 54C98203 for ; Thu, 6 Jun 2013 22:12:43 +0000 (UTC) (envelope-from mxb@alumni.chalmers.se) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id B6FC71857 for ; Thu, 6 Jun 2013 22:12:42 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id fq12so2904883lab.38 for ; Thu, 06 Jun 2013 15:12:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Q2zyLrlpSLRt0W+gZ/WvESlZMEpNhyCXzoSM4wpqfhc=; b=PK0X/KW8uQXzYcEEj0fFxW0gQ11w6JMWO+m3gUYNoxJLQ7HxTIu5xULtYUWBTvbAwm 3CDgUGRs3VhFol7zJnEDc7AitIMC/TpOfIFuuTqnMWA+ts2++Jm2E1FCdDcQhLIzxZJV wUyJQ9ziQBQmH9RYueS2iDstxli4o0gjjT4aq38URgxa/HCxn0h8ZAeMyhvvPLpby6zB 8ydK2Viksrb6RFaGPQ9tDyc49JNiZoH0pSaX6uI7hdEoPmimewGWQioMgygUhQhz9jtY Ac93A2xf1Nidr1qE61swhs5vQhbkv2qIeIR55Fb/RMThL1cnqqS012B7iNg9gvAbRs+Q 1LLg== X-Received: by 10.112.144.69 with SMTP id sk5mr821313lbb.64.1370556761613; Thu, 06 Jun 2013 15:12:41 -0700 (PDT) Received: from grey.home.unixconn.com (h-75-17.a183.priv.bahnhof.se. [46.59.75.17]) by mx.google.com with ESMTPSA id f9sm29461076lbf.4.2013.06.06.15.12.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 15:12:40 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: zpool export/import on failover - The pool metadata is corrupted From: mxb In-Reply-To: Date: Fri, 7 Jun 2013 00:12:39 +0200 Message-Id: <016B635E-4EDC-4CDF-AC58-82AC39CBFF56@alumni.chalmers.se> References: To: Outback Dingo X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkC1MeVAlH42wUcCbWVi2xfAeB3FD1IMBrZsjg8dEShP9Ncfsl7TsYX8GBFFnspoAg9ZAWG Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:12:43 -0000 Then MASTER goes down, CARP on the second node goes MASTER (devd.conf, = and script for lifting): root@nfs2:/root # cat /etc/devd.conf notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_UP"; action "/etc/zfs_switch.sh active"; }; notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_DOWN"; action "/etc/zfs_switch.sh backup"; }; root@nfs2:/root # cat /etc/zfs_switch.sh #!/bin/sh DATE=3D`date +%Y%m%d` HOSTNAME=3D`hostname` ZFS_POOL=3D"jbod" case $1 in active) echo "Switching to ACTIVE and importing ZFS" | mail -s = ''$DATE': '$HOSTNAME' switching to ACTIVE' root sleep 10 /sbin/zpool import -f jbod /etc/rc.d/mountd restart /etc/rc.d/nfsd restart ;; backup) echo "Switching to BACKUP and exporting ZFS" | mail -s = ''$DATE': '$HOSTNAME' switching to BACKUP' root /sbin/zpool export jbod /etc/rc.d/mountd restart /etc/rc.d/nfsd restart ;; *) exit 0 ;; esac This works, most of the time, but sometimes I'm forced to re-create = pool. Those machines suppose to go into prod. Loosing pool(and data inside it) stops me from deploy this setup. //mxb On 6 jun 2013, at 22:06, Outback Dingo wrote: >=20 >=20 >=20 > On Thu, Jun 6, 2013 at 3:24 PM, mxb wrote: >=20 > Hello list, >=20 > I have two-head ZFS setup with external disk enclosure over SAS = expander. > This is a failover setup with CARP and devd triggering spool = export/import. > One of two nodes is preferred master. >=20 > Then master is rebooted, devd kicks in as of CARP becomes master and = the second node picks up ZFS-disks from external enclosure. > Then master comes back, CARP becomes master, devd kicks in and pool = gets exported from the second node and imported on the first one. >=20 > However, I have experienced metadata corruption several times with = this setup. > Note, that ZIL(mirrored) resides on external enclosure. Only L2ARC is = both local and external - da1,da2, da13s2, da14s2 >=20 > root@nfs2:/root # zpool import > pool: jbod > id: 17635654860276652744 > state: FAULTED > status: The pool metadata is corrupted. > action: The pool cannot be imported due to damaged devices or data. > see: http://illumos.org/msg/ZFS-8000-72 > config: >=20 > jbod FAULTED corrupted data > raidz3-0 ONLINE > da3 ONLINE > da4 ONLINE > da5 ONLINE > da6 ONLINE > da7 ONLINE > da8 ONLINE > da9 ONLINE > da10 ONLINE > da11 ONLINE > da12 ONLINE > cache > da1 > da2 > da13s2 > da14s2 > logs > mirror-1 ONLINE > da13s1 ONLINE > da14s1 ONLINE >=20 > Any ideas what is going on? >=20 > Best case scenerio, both nodes tried to import the disks = simultaneously, split brain condition, or disks appear out of order and = no using labels, we had a similar situation with geom_multipath, theres = no quorum disks knowledge yet for FreeBSD using zfs in this = configuration, we ran it similarly for a while, until we realized = through research it was bad karma to let carp and devd control nodes = without a fool proof way to be sure nodes were ready to export/import. = though you did state >=20 > "Then master comes back, CARP becomes master, devd kicks in and pool = gets exported from the second node and imported on the first one." be = nice to see how you managed that with scripts... even if both nodes = booted simultaneously their both going to "fight" for master and try to = import that pool. >=20 >=20 > //mxb >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >=20 From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 22:23:04 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E74F37F for ; Thu, 6 Jun 2013 22:23:04 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 0B28118C9 for ; Thu, 6 Jun 2013 22:23:04 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id ro2so3865690pbb.13 for ; Thu, 06 Jun 2013 15:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jxKdCizdmK3jfutjYGlEqyekZl49SLaeh5FGYHyEH4k=; b=SEvPlA8GU6rHXGOL5RGPHrMMj2l16dLdBi4QHIxuCe/bmVluZkIpEZie28AXz+Bz3k Q1FFkjLhgGJcMx9GSJ26OHf945wvAOqdKI67jqZoDDbZnjwcyoBShPRQB924QSRGr8ML FFzJhP5AjdXiIUZWgzu4hwosUvX+u9jN2qMUKyP7xF8GiiOW7pQafzeyk7f5QCc2Tdvt 6owiVpQWf3Z/R8dXjN6u32QjQ3Bywucj9El3W+K93TqVWt/KUiHjiGZ485OvzWe809Vv /JhvxViB5OBYx3poN2HTU8Qqw9E900J0eCfps2TJefMzUkW5d4zmyM5HmjZNZgpqJ0Xj JCgg== MIME-Version: 1.0 X-Received: by 10.68.211.73 with SMTP id na9mr41075306pbc.90.1370557383858; Thu, 06 Jun 2013 15:23:03 -0700 (PDT) Received: by 10.66.160.66 with HTTP; Thu, 6 Jun 2013 15:23:03 -0700 (PDT) In-Reply-To: <016B635E-4EDC-4CDF-AC58-82AC39CBFF56@alumni.chalmers.se> References: <016B635E-4EDC-4CDF-AC58-82AC39CBFF56@alumni.chalmers.se> Date: Thu, 6 Jun 2013 18:23:03 -0400 Message-ID: Subject: Re: zpool export/import on failover - The pool metadata is corrupted From: Outback Dingo To: mxb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:23:04 -0000 On Thu, Jun 6, 2013 at 6:12 PM, mxb wrote: > > Then MASTER goes down, CARP on the second node goes MASTER (devd.conf, and > script for lifting): > > root@nfs2:/root # cat /etc/devd.conf > > > notify 30 { > match "system" "IFNET"; > match "subsystem" "carp0"; > match "type" "LINK_UP"; > action "/etc/zfs_switch.sh active"; > }; > > notify 30 { > match "system" "IFNET"; > match "subsystem" "carp0"; > match "type" "LINK_DOWN"; > action "/etc/zfs_switch.sh backup"; > }; > > root@nfs2:/root # cat /etc/zfs_switch.sh > #!/bin/sh > > DATE=`date +%Y%m%d` > HOSTNAME=`hostname` > > ZFS_POOL="jbod" > > > case $1 in > active) > echo "Switching to ACTIVE and importing ZFS" | mail -s ''$DATE': > '$HOSTNAME' switching to ACTIVE' root > sleep 10 > /sbin/zpool import -f jbod > /etc/rc.d/mountd restart > /etc/rc.d/nfsd restart > ;; > backup) > echo "Switching to BACKUP and exporting ZFS" | mail -s ''$DATE': > '$HOSTNAME' switching to BACKUP' root > /sbin/zpool export jbod > /etc/rc.d/mountd restart > /etc/rc.d/nfsd restart > ;; > *) > exit 0 > ;; > esac > > This works, most of the time, but sometimes I'm forced to re-create pool. > Those machines suppose to go into prod. > Loosing pool(and data inside it) stops me from deploy this setup. > > right this is the type of standard fair for the setup, but, what tells nodeA that nodeB has completed export of the pool?? sleep 10 isnt likely to cut it in all scenerios, hence there is no true mechanism, therfor it is feasible that NodeA is already trying to import said pool before NodeB has exported it fully. there in lies the potential for a problem > //mxb > > On 6 jun 2013, at 22:06, Outback Dingo wrote: > > > > > On Thu, Jun 6, 2013 at 3:24 PM, mxb wrote: > >> >> Hello list, >> >> I have two-head ZFS setup with external disk enclosure over SAS expander. >> This is a failover setup with CARP and devd triggering spool >> export/import. >> One of two nodes is preferred master. >> >> Then master is rebooted, devd kicks in as of CARP becomes master and the >> second node picks up ZFS-disks from external enclosure. >> Then master comes back, CARP becomes master, devd kicks in and pool gets >> exported from the second node and imported on the first one. >> >> However, I have experienced metadata corruption several times with this >> setup. >> Note, that ZIL(mirrored) resides on external enclosure. Only L2ARC is >> both local and external - da1,da2, da13s2, da14s2 >> >> root@nfs2:/root # zpool import >> pool: jbod >> id: 17635654860276652744 >> state: FAULTED >> status: The pool metadata is corrupted. >> action: The pool cannot be imported due to damaged devices or data. >> see: http://illumos.org/msg/ZFS-8000-72 >> config: >> >> jbod FAULTED corrupted data >> raidz3-0 ONLINE >> da3 ONLINE >> da4 ONLINE >> da5 ONLINE >> da6 ONLINE >> da7 ONLINE >> da8 ONLINE >> da9 ONLINE >> da10 ONLINE >> da11 ONLINE >> da12 ONLINE >> cache >> da1 >> da2 >> da13s2 >> da14s2 >> logs >> mirror-1 ONLINE >> da13s1 ONLINE >> da14s1 ONLINE >> >> Any ideas what is going on? >> > > Best case scenerio, both nodes tried to import the disks simultaneously, > split brain condition, or disks appear out of order and no using labels, we > had a similar situation with geom_multipath, theres no quorum disks > knowledge yet for FreeBSD using zfs in this configuration, we ran it > similarly for a while, until we realized through research it was bad karma > to let carp and devd control nodes without a fool proof way to be sure > nodes were ready to export/import. though you did state > > "Then master comes back, CARP becomes master, devd kicks in and pool gets > exported from the second node and imported on the first one." be nice to > see how you managed that with scripts... even if both nodes booted > simultaneously their both going to "fight" for master and try to import > that pool. > > >> //mxb >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > > > From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 22:32:38 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3F7319B1 for ; Thu, 6 Jun 2013 22:32:38 +0000 (UTC) (envelope-from mxb@alumni.chalmers.se) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by mx1.freebsd.org (Postfix) with ESMTP id A032D1933 for ; Thu, 6 Jun 2013 22:32:37 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id v10so3570612lbd.6 for ; Thu, 06 Jun 2013 15:32:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=2YaWQtg6Dih4hM9HV4GZ0TeTIzAFEQmtyiTlwsR01Jg=; b=C3NqmrTog5+oU5f4QpXNsszQX9Y4rXNDX8dH9hLaGjdd88hlMQiCcnqMPGN2nghr1i nNIb6xguSpEIwn+/Ye9++d0PQntsDsAA9I87aPy2DBf2LHjIVHqcAkf4UnhSoQR/Sbxr lammE5eirXAt6gpVVrv9SbjngzMtjm4Yq7d4XWkUFuM3FyGD9F8Aof0mivJMWHGa7WIx 7heSwqerS2pfngUqII24MkPvIIO6voIvS469cn2BFO/NB5lTiHgOg8zm8MXWPIPYClue Yw8V5rImXMI1C2TXh+0u8t73h2dKyAdrFD4Qr03G96EwXQdylPtR+xSXbXhTrk70IAVT rjDQ== X-Received: by 10.152.120.9 with SMTP id ky9mr1150817lab.71.1370557956199; Thu, 06 Jun 2013 15:32:36 -0700 (PDT) Received: from grey.home.unixconn.com (h-75-17.a183.priv.bahnhof.se. [46.59.75.17]) by mx.google.com with ESMTPSA id x8sm4122531lae.10.2013.06.06.15.32.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 15:32:35 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: zpool export/import on failover - The pool metadata is corrupted From: mxb In-Reply-To: Date: Fri, 7 Jun 2013 00:32:34 +0200 Message-Id: <4AEF62BB-BC52-41F7-9460-8FF9388AAEA9@alumni.chalmers.se> References: <016B635E-4EDC-4CDF-AC58-82AC39CBFF56@alumni.chalmers.se> To: Outback Dingo X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmn6fqDxxKaSiW360pfLy/B8ZkMLOdDO4qMo3noimW10iyUeeDn95QbuicxVLz6aYWlenYy Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:32:38 -0000 Should I increase sleep ? On 7 jun 2013, at 00:23, Outback Dingo wrote: >=20 >=20 >=20 > On Thu, Jun 6, 2013 at 6:12 PM, mxb wrote: >=20 > Then MASTER goes down, CARP on the second node goes MASTER (devd.conf, = and script for lifting): >=20 > root@nfs2:/root # cat /etc/devd.conf >=20 >=20 > notify 30 { > match "system" "IFNET"; > match "subsystem" "carp0"; > match "type" "LINK_UP"; > action "/etc/zfs_switch.sh active"; > }; >=20 > notify 30 { > match "system" "IFNET"; > match "subsystem" "carp0"; > match "type" "LINK_DOWN"; > action "/etc/zfs_switch.sh backup"; > }; >=20 > root@nfs2:/root # cat /etc/zfs_switch.sh > #!/bin/sh >=20 > DATE=3D`date +%Y%m%d` > HOSTNAME=3D`hostname` >=20 > ZFS_POOL=3D"jbod" >=20 >=20 > case $1 in > active) > echo "Switching to ACTIVE and importing ZFS" | mail -s = ''$DATE': '$HOSTNAME' switching to ACTIVE' root > sleep 10 > /sbin/zpool import -f jbod > /etc/rc.d/mountd restart > /etc/rc.d/nfsd restart > ;; > backup) > echo "Switching to BACKUP and exporting ZFS" | mail -s = ''$DATE': '$HOSTNAME' switching to BACKUP' root > /sbin/zpool export jbod > /etc/rc.d/mountd restart > /etc/rc.d/nfsd restart > ;; > *) > exit 0 > ;; > esac >=20 > This works, most of the time, but sometimes I'm forced to re-create = pool. Those machines suppose to go into prod. > Loosing pool(and data inside it) stops me from deploy this setup. >=20 >=20 > right this is the type of standard fair for the setup, but, what tells = nodeA that nodeB has completed export of the pool?? sleep 10 isnt likely = to cut it in all scenerios, hence there is no true mechanism, therfor it = is feasible that NodeA is already trying to import said pool before = NodeB has exported it fully. there in lies the potential for a problem > =20 > //mxb >=20 > On 6 jun 2013, at 22:06, Outback Dingo wrote: >=20 >>=20 >>=20 >>=20 >> On Thu, Jun 6, 2013 at 3:24 PM, mxb wrote: >>=20 >> Hello list, >>=20 >> I have two-head ZFS setup with external disk enclosure over SAS = expander. >> This is a failover setup with CARP and devd triggering spool = export/import. >> One of two nodes is preferred master. >>=20 >> Then master is rebooted, devd kicks in as of CARP becomes master and = the second node picks up ZFS-disks from external enclosure. >> Then master comes back, CARP becomes master, devd kicks in and pool = gets exported from the second node and imported on the first one. >>=20 >> However, I have experienced metadata corruption several times with = this setup. >> Note, that ZIL(mirrored) resides on external enclosure. Only L2ARC is = both local and external - da1,da2, da13s2, da14s2 >>=20 >> root@nfs2:/root # zpool import >> pool: jbod >> id: 17635654860276652744 >> state: FAULTED >> status: The pool metadata is corrupted. >> action: The pool cannot be imported due to damaged devices or data. >> see: http://illumos.org/msg/ZFS-8000-72 >> config: >>=20 >> jbod FAULTED corrupted data >> raidz3-0 ONLINE >> da3 ONLINE >> da4 ONLINE >> da5 ONLINE >> da6 ONLINE >> da7 ONLINE >> da8 ONLINE >> da9 ONLINE >> da10 ONLINE >> da11 ONLINE >> da12 ONLINE >> cache >> da1 >> da2 >> da13s2 >> da14s2 >> logs >> mirror-1 ONLINE >> da13s1 ONLINE >> da14s1 ONLINE >>=20 >> Any ideas what is going on? >>=20 >> Best case scenerio, both nodes tried to import the disks = simultaneously, split brain condition, or disks appear out of order and = no using labels, we had a similar situation with geom_multipath, theres = no quorum disks knowledge yet for FreeBSD using zfs in this = configuration, we ran it similarly for a while, until we realized = through research it was bad karma to let carp and devd control nodes = without a fool proof way to be sure nodes were ready to export/import. = though you did state >>=20 >> "Then master comes back, CARP becomes master, devd kicks in and pool = gets exported from the second node and imported on the first one." be = nice to see how you managed that with scripts... even if both nodes = booted simultaneously their both going to "fight" for master and try to = import that pool. >>=20 >>=20 >> //mxb >>=20 >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >>=20 >=20 >=20 From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 22:39:33 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7936CAB2 for ; Thu, 6 Jun 2013 22:39:33 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id 0228A197B for ; Thu, 6 Jun 2013 22:39:32 +0000 (UTC) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id C0ADDA80BE; Fri, 7 Jun 2013 00:39:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qfD2WC21NxB2; Fri, 7 Jun 2013 00:39:13 +0200 (CEST) X-Originating-IP: 67.180.84.87 Received: from jdc.koitsu.org (c-67-180-84-87.hsd1.ca.comcast.net [67.180.84.87]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3C698A80B6; Fri, 7 Jun 2013 00:39:13 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 4FB6D73A1C; Thu, 6 Jun 2013 15:39:11 -0700 (PDT) Date: Thu, 6 Jun 2013 15:39:11 -0700 From: Jeremy Chadwick To: mxb Subject: Re: zpool export/import on failover - The pool metadata is corrupted Message-ID: <20130606223911.GA45807@icarus.home.lan> References: <016B635E-4EDC-4CDF-AC58-82AC39CBFF56@alumni.chalmers.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016B635E-4EDC-4CDF-AC58-82AC39CBFF56@alumni.chalmers.se> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:39:33 -0000 On Fri, Jun 07, 2013 at 12:12:39AM +0200, mxb wrote: > > Then MASTER goes down, CARP on the second node goes MASTER (devd.conf, and script for lifting): > > root@nfs2:/root # cat /etc/devd.conf > > > notify 30 { > match "system" "IFNET"; > match "subsystem" "carp0"; > match "type" "LINK_UP"; > action "/etc/zfs_switch.sh active"; > }; > > notify 30 { > match "system" "IFNET"; > match "subsystem" "carp0"; > match "type" "LINK_DOWN"; > action "/etc/zfs_switch.sh backup"; > }; > > root@nfs2:/root # cat /etc/zfs_switch.sh > #!/bin/sh > > DATE=`date +%Y%m%d` > HOSTNAME=`hostname` > > ZFS_POOL="jbod" > > > case $1 in > active) > echo "Switching to ACTIVE and importing ZFS" | mail -s ''$DATE': '$HOSTNAME' switching to ACTIVE' root > sleep 10 > /sbin/zpool import -f jbod > /etc/rc.d/mountd restart > /etc/rc.d/nfsd restart > ;; > backup) > echo "Switching to BACKUP and exporting ZFS" | mail -s ''$DATE': '$HOSTNAME' switching to BACKUP' root > /sbin/zpool export jbod > /etc/rc.d/mountd restart > /etc/rc.d/nfsd restart > ;; > *) > exit 0 > ;; > esac > > This works, most of the time, but sometimes I'm forced to re-create pool. Those machines suppose to go into prod. > Loosing pool(and data inside it) stops me from deploy this setup. This script looks highly error-prone. Hasty hasty... :-) This script assumes that the "zpool" commands (import and export) always work/succeed; there is no exit code ($?) checking being used. Since this is run from within devd(8): where does stdout/stderr go to when running a program/script under devd(8)? Does it effectively go to the bit bucket (/dev/null)? If so, you'd never know if the import or export actually succeeded or not (the export sounds more likely to be the problem point). I imagine there would be some situations where the export would fail (some files on filesystems under pool "jbod" still in use), yet CARP is already blindly assuming everything will be fantastic. Surprise. I also do not know if devd.conf(5) "action" commands spawn a sub-shell (/bin/sh) or not. If they don't, you won't be able to use things like" 'action "/etc/zfs_switch.sh active >> /var/log/failover.log";'. You would then need to implement the equivalent of logging within your zfs_switch.sh script. You may want to consider the -f flag to zpool import/export (particularly export). However there are risks involved -- userland applications which have an fd/fh open on a file which is stored on a filesystem that has now completely disappeared can sometimes crash (segfault) or behave very oddly (100% CPU usage, etc.) depending on how they're designed. Basically what I'm trying to say is that devd(8) being used as a form of HA (high availability) and load balancing is not always possible. Real/true HA (especially with SANs) is often done very differently (now you know why it's often proprietary. :-) ) -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 22:51:18 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2EC46CEE for ; Thu, 6 Jun 2013 22:51:18 +0000 (UTC) (envelope-from mxb@alumni.chalmers.se) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mx1.freebsd.org (Postfix) with ESMTP id A6FA519E2 for ; Thu, 6 Jun 2013 22:51:17 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id 10so3180488lbf.22 for ; Thu, 06 Jun 2013 15:51:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Z/ULr2H7rJev4hAI1YZ+HOkoMoiXVWHSxrhL2bNls7o=; b=AWIRQRLW1pkjT2Dujt8J8s6qMLBrLo9CCUGAmFXXY12RzgGqO6+g8J0oYyR+fMr69F DSW3nJXDmwmqc9P5Q6GoB1He4k6lRBFXR7E2v3BKXu1y3Bd4bt7LJzx2dUoT1MpV+aQo VCfZojUN/BtepLA0UFfTLsujb1eCaJBHNwOD0Tci+Vu1EEfAmPIhmh9O8VTwW8+jq6OL GIx2fwZLzut1rWqXc1aBSdJeD4tU9g4ADn0sdT7gQaF1rECRw8iLhHdtb9GqsN5kS15I zKuxesz8kXqjnuhWYNuCJbcnkNa8EXFn4HmgOUJIV1zsVjvTPPHfzrxrYr/hMx3foqd/ uWuw== X-Received: by 10.112.199.5 with SMTP id jg5mr863578lbc.67.1370559076115; Thu, 06 Jun 2013 15:51:16 -0700 (PDT) Received: from grey.home.unixconn.com (h-75-17.a183.priv.bahnhof.se. [46.59.75.17]) by mx.google.com with ESMTPSA id o6sm9908260laj.2.2013.06.06.15.51.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 15:51:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: zpool export/import on failover - The pool metadata is corrupted From: mxb In-Reply-To: <20130606223911.GA45807@icarus.home.lan> Date: Fri, 7 Jun 2013 00:51:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <016B635E-4EDC-4CDF-AC58-82AC39CBFF56@alumni.chalmers.se> <20130606223911.GA45807@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQk3BSJ3+FvXJ0V0T4FcH55bBaPJz4BKVYql/T+jOA/r2YcgcvyzO+Ge2Qb10K0jxhdIIp23 Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:51:18 -0000 Sure, script is not perfects yet and does not handle many of stuff, but = moving highlight from zpool import/export to the script itself not that clever,as this works most of the time. Question is WHY ZFS corrupts metadata then it should not. Sometimes. I'v seen stale of zpool then manually importing/exporting pool. On 7 jun 2013, at 00:39, Jeremy Chadwick wrote: > On Fri, Jun 07, 2013 at 12:12:39AM +0200, mxb wrote: >>=20 >> Then MASTER goes down, CARP on the second node goes MASTER = (devd.conf, and script for lifting): >>=20 >> root@nfs2:/root # cat /etc/devd.conf >>=20 >>=20 >> notify 30 { >> match "system" "IFNET"; >> match "subsystem" "carp0"; >> match "type" "LINK_UP"; >> action "/etc/zfs_switch.sh active"; >> }; >>=20 >> notify 30 { >> match "system" "IFNET"; >> match "subsystem" "carp0"; >> match "type" "LINK_DOWN"; >> action "/etc/zfs_switch.sh backup"; >> }; >>=20 >> root@nfs2:/root # cat /etc/zfs_switch.sh >> #!/bin/sh >>=20 >> DATE=3D`date +%Y%m%d` >> HOSTNAME=3D`hostname` >>=20 >> ZFS_POOL=3D"jbod" >>=20 >>=20 >> case $1 in >> active) >> echo "Switching to ACTIVE and importing ZFS" | mail -s = ''$DATE': '$HOSTNAME' switching to ACTIVE' root >> sleep 10 >> /sbin/zpool import -f jbod >> /etc/rc.d/mountd restart >> /etc/rc.d/nfsd restart >> ;; >> backup) >> echo "Switching to BACKUP and exporting ZFS" | mail -s = ''$DATE': '$HOSTNAME' switching to BACKUP' root >> /sbin/zpool export jbod >> /etc/rc.d/mountd restart >> /etc/rc.d/nfsd restart >> ;; >> *) >> exit 0 >> ;; >> esac >>=20 >> This works, most of the time, but sometimes I'm forced to re-create = pool. Those machines suppose to go into prod. >> Loosing pool(and data inside it) stops me from deploy this setup. >=20 > This script looks highly error-prone. Hasty hasty... :-) >=20 > This script assumes that the "zpool" commands (import and export) = always > work/succeed; there is no exit code ($?) checking being used. >=20 > Since this is run from within devd(8): where does stdout/stderr go to > when running a program/script under devd(8)? Does it effectively go > to the bit bucket (/dev/null)? If so, you'd never know if the import = or > export actually succeeded or not (the export sounds more likely to be > the problem point). >=20 > I imagine there would be some situations where the export would fail > (some files on filesystems under pool "jbod" still in use), yet CARP = is > already blindly assuming everything will be fantastic. Surprise. >=20 > I also do not know if devd.conf(5) "action" commands spawn a sub-shell > (/bin/sh) or not. If they don't, you won't be able to use things = like" > 'action "/etc/zfs_switch.sh active >> /var/log/failover.log";'. You > would then need to implement the equivalent of logging within your > zfs_switch.sh script. >=20 > You may want to consider the -f flag to zpool import/export > (particularly export). However there are risks involved -- userland > applications which have an fd/fh open on a file which is stored on a > filesystem that has now completely disappeared can sometimes crash > (segfault) or behave very oddly (100% CPU usage, etc.) depending on = how > they're designed. >=20 > Basically what I'm trying to say is that devd(8) being used as a form = of > HA (high availability) and load balancing is not always possible. > Real/true HA (especially with SANs) is often done very differently = (now > you know why it's often proprietary. :-) ) >=20 > --=20 > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | >=20 From owner-freebsd-fs@FreeBSD.ORG Thu Jun 6 23:34:33 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 38305659 for ; Thu, 6 Jun 2013 23:34:33 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id CD6DB1C6D for ; Thu, 6 Jun 2013 23:34:32 +0000 (UTC) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id D8B86A80BC; Fri, 7 Jun 2013 01:34:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id z7Rn0FfDo8yc; Fri, 7 Jun 2013 01:34:20 +0200 (CEST) X-Originating-IP: 67.180.84.87 Received: from jdc.koitsu.org (c-67-180-84-87.hsd1.ca.comcast.net [67.180.84.87]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id A240FA80B4; Fri, 7 Jun 2013 01:34:19 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id E41CB73A1C; Thu, 6 Jun 2013 16:34:17 -0700 (PDT) Date: Thu, 6 Jun 2013 16:34:17 -0700 From: Jeremy Chadwick To: mxb Subject: Re: zpool export/import on failover - The pool metadata is corrupted Message-ID: <20130606233417.GA46506@icarus.home.lan> References: <016B635E-4EDC-4CDF-AC58-82AC39CBFF56@alumni.chalmers.se> <20130606223911.GA45807@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 23:34:33 -0000 On Fri, Jun 07, 2013 at 12:51:14AM +0200, mxb wrote: > > Sure, script is not perfects yet and does not handle many of stuff, but moving highlight from zpool import/export to the script itself not that > clever,as this works most of the time. > > Question is WHY ZFS corrupts metadata then it should not. Sometimes. > I'v seen stale of zpool then manually importing/exporting pool. > > > On 7 jun 2013, at 00:39, Jeremy Chadwick wrote: > > > On Fri, Jun 07, 2013 at 12:12:39AM +0200, mxb wrote: > >> > >> Then MASTER goes down, CARP on the second node goes MASTER (devd.conf, and script for lifting): > >> > >> root@nfs2:/root # cat /etc/devd.conf > >> > >> > >> notify 30 { > >> match "system" "IFNET"; > >> match "subsystem" "carp0"; > >> match "type" "LINK_UP"; > >> action "/etc/zfs_switch.sh active"; > >> }; > >> > >> notify 30 { > >> match "system" "IFNET"; > >> match "subsystem" "carp0"; > >> match "type" "LINK_DOWN"; > >> action "/etc/zfs_switch.sh backup"; > >> }; > >> > >> root@nfs2:/root # cat /etc/zfs_switch.sh > >> #!/bin/sh > >> > >> DATE=`date +%Y%m%d` > >> HOSTNAME=`hostname` > >> > >> ZFS_POOL="jbod" > >> > >> > >> case $1 in > >> active) > >> echo "Switching to ACTIVE and importing ZFS" | mail -s ''$DATE': '$HOSTNAME' switching to ACTIVE' root > >> sleep 10 > >> /sbin/zpool import -f jbod > >> /etc/rc.d/mountd restart > >> /etc/rc.d/nfsd restart > >> ;; > >> backup) > >> echo "Switching to BACKUP and exporting ZFS" | mail -s ''$DATE': '$HOSTNAME' switching to BACKUP' root > >> /sbin/zpool export jbod > >> /etc/rc.d/mountd restart > >> /etc/rc.d/nfsd restart > >> ;; > >> *) > >> exit 0 > >> ;; > >> esac > >> > >> This works, most of the time, but sometimes I'm forced to re-create pool. Those machines suppose to go into prod. > >> Loosing pool(and data inside it) stops me from deploy this setup. > > > > This script looks highly error-prone. Hasty hasty... :-) > > > > This script assumes that the "zpool" commands (import and export) always > > work/succeed; there is no exit code ($?) checking being used. > > > > Since this is run from within devd(8): where does stdout/stderr go to > > when running a program/script under devd(8)? Does it effectively go > > to the bit bucket (/dev/null)? If so, you'd never know if the import or > > export actually succeeded or not (the export sounds more likely to be > > the problem point). > > > > I imagine there would be some situations where the export would fail > > (some files on filesystems under pool "jbod" still in use), yet CARP is > > already blindly assuming everything will be fantastic. Surprise. > > > > I also do not know if devd.conf(5) "action" commands spawn a sub-shell > > (/bin/sh) or not. If they don't, you won't be able to use things like" > > 'action "/etc/zfs_switch.sh active >> /var/log/failover.log";'. You > > would then need to implement the equivalent of logging within your > > zfs_switch.sh script. > > > > You may want to consider the -f flag to zpool import/export > > (particularly export). However there are risks involved -- userland > > applications which have an fd/fh open on a file which is stored on a > > filesystem that has now completely disappeared can sometimes crash > > (segfault) or behave very oddly (100% CPU usage, etc.) depending on how > > they're designed. > > > > Basically what I'm trying to say is that devd(8) being used as a form of > > HA (high availability) and load balancing is not always possible. > > Real/true HA (especially with SANs) is often done very differently (now > > you know why it's often proprietary. :-) ) Add error checking to your script. That's my first and foremost recommendation. It's not hard to do, really. :-) After you do that and still experience the issue (e.g. you see no actual errors/issues during the export/import phases), I recommend removing the "cache" devices which are "independent" on each system from the pool entirely. Quoting you (for readers, since I snipped it from my previous reply): >>> Note, that ZIL(mirrored) resides on external enclosure. Only L2ARC >>> is both local and external - da1,da2, da13s2, da14s2 I interpret this to mean the primary and backup nodes (physical systems) have actual disks which are not part of the "external enclosure". If that's the case -- those disks are always going to vary in their contents and metadata. Those are never going to be 100% identical all the time (is this not obvious?). I'm surprised your stuff has worked at all using that model, honestly. ZFS is going to bitch/cry if it cannot verify the integrity of certain things, all the way down to the L2ARC. That's my understanding of it at least, meaning there must always be "some" kind of metadata that has to be kept/maintained there. Alternately you could try doing this: zpool remove jbod cache daX daY ... zpool export jbod Then on the other system: zpool import jbod zpool add jbod cache daX daY ... Where daX and daY are the disks which are independent to each system (not on the "external enclosure"). Finally, it would also be useful/worthwhile if you would provide "dmesg" from both systems and for you to explain the physical wiring along with what device (e.g. daX) correlates with what exact thing on each system. (We right now have no knowledge of that, and your terse explanations imply we do -- we need to know more) -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Fri Jun 7 08:03:51 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C267180 for ; Fri, 7 Jun 2013 08:03:51 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) by mx1.freebsd.org (Postfix) with ESMTP id 36F3A1F01 for ; Fri, 7 Jun 2013 08:03:51 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UkrPO-0008MT-Ce for freebsd-fs@freebsd.org; Fri, 07 Jun 2013 09:48:27 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UkrPL-0001LA-K7 for freebsd-fs@freebsd.org; Fri, 07 Jun 2013 09:48:23 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: zpool export/import on failover - The pool metadata is corrupted References: Date: Fri, 07 Jun 2013 09:48:24 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 897836312160ed0141c32cdc6ac56212 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 08:03:51 -0000 On Thu, 06 Jun 2013 21:24:34 +0200, mxb wrote: > > Hello list, > > I have two-head ZFS setup with external disk enclosure over SAS expander. > This is a failover setup with CARP and devd triggering spool > export/import. > One of two nodes is preferred master. > > Then master is rebooted, devd kicks in as of CARP becomes master and the > second node picks up ZFS-disks from external enclosure. > Then master comes back, CARP becomes master, devd kicks in and pool gets > exported from the second node and imported on the first one. > > However, I have experienced metadata corruption several times with this > setup. > Note, that ZIL(mirrored) resides on external enclosure. Only L2ARC is > both local and external - da1,da2, da13s2, da14s2 > > root@nfs2:/root # zpool import > pool: jbod > id: 17635654860276652744 > state: FAULTED > status: The pool metadata is corrupted. > action: The pool cannot be imported due to damaged devices or data. > see: http://illumos.org/msg/ZFS-8000-72 > config: > > jbod FAULTED corrupted data > raidz3-0 ONLINE > da3 ONLINE > da4 ONLINE > da5 ONLINE > da6 ONLINE > da7 ONLINE > da8 ONLINE > da9 ONLINE > da10 ONLINE > da11 ONLINE > da12 ONLINE > cache > da1 > da2 > da13s2 > da14s2 > logs > mirror-1 ONLINE > da13s1 ONLINE > da14s1 ONLINE > > Any ideas what is going on? > > //mxb I know the Oracle ZFS Appliance you can buy with clustering does a reboot of the node which should release the pool. The mechanism is called like this: http://en.wikipedia.org/wiki/STONITH Ronald. From owner-freebsd-fs@FreeBSD.ORG Fri Jun 7 15:13:42 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6BA9F99 for ; Fri, 7 Jun 2013 15:13:42 +0000 (UTC) (envelope-from pierre@lemazurier.fr) Received: from mail.lemazurier.fr (mail.lemazurier.fr [62.147.151.66]) by mx1.freebsd.org (Postfix) with ESMTP id 3FFC415E1 for ; Fri, 7 Jun 2013 15:13:41 +0000 (UTC) Received: from [172.18.8.191] (zup50-1-88-186-33-16.fbx.proxad.net [88.186.33.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lemazurier.fr (Postfix) with ESMTPSA id 9329A235EA for ; Fri, 7 Jun 2013 17:05:39 +0200 (CEST) Message-ID: <51B1F726.7090402@lemazurier.fr> Date: Fri, 07 Jun 2013 17:07:18 +0200 From: Pierre Lemazurier User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: [ZFS] Raid 10 performance issues References: <51B1EBD1.9010207@gmail.com> In-Reply-To: <51B1EBD1.9010207@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:13:42 -0000 Hi, i think i suffer of write and read performance issues on my zpool. About my system and hardware : uname -a FreeBSD bsdnas 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 sysinfo -a : http://www.privatepaste.com/b32f34c938 - 24 (4gbx6) GB DDR3 ECC : http://www.ec.kingston.com/ecom/configurator_new/partsinfo.asp?ktcpartno=KVR16R11D8/4HC - 14x this drive : http://www.wdc.com/global/products/specs/?driveID=1086&language=1 - server : http://www.supermicro.com/products/system/1u/5017/sys-5017r-wrf.cfm?parts=show - CPU : http://ark.intel.com/fr/products/64594/Intel-Xeon-Processor-E5-2620-15M-Cache-2_00-GHz-7_20-GTs-Intel-QPI - chassis : http://www.supermicro.com/products/chassis/4u/847/sc847e16-rjbod1.cfm - HBA sas connector : http://www.lsi.com/products/storagecomponents/Pages/LSISAS9200-8e.aspx - Cable between chassis and server : http://www.provantage.com/supermicro-cbl-0166l~7SUPA01R.htm I use this command for test write speed :dd if=/dev/zero of=test.dd bs=2M count=10000 I use this command for test read speed :dd if=test.dd of=/dev/null bs=2M count=10000 Of course no compression on zfs dataset. Test on one of this disk format with UFS : Write : some gstat raising : http://www.privatepaste.com/dd31fafaa6 speed around 140 mo/s and something like 1100 iops dd result : 20971520000 bytes transferred in 146.722126 secs (142933589 bytes/sec) Read : I think I read on RAM (20971520000 bytes transferred in 8.813298 secs (2379531480 bytes/sec)). Then I make the test on all the drive (dd if=/dev/gpt/disk14.nop of=/dev/null bs=2M count=10000) some gstat raising : http://www.privatepaste.com/d022b7c480 speed around 140 mo/s again an near 1100+ iops dd reslut : 20971520000 bytes transferred in 142.895212 secs (146761530 bytes/sec) ZFS - I make my zpool on this way : http://www.privatepaste.com/e74d9cc3b9 zpool status : http://www.privatepaste.com/0276801ef6 zpool get all : http://www.privatepaste.com/74b37a2429 zfs get all : http://www.privatepaste.com/e56f4a33f8 zfs-stats -a : http://www.privatepaste.com/f017890aa1 zdb : http://www.privatepaste.com/7d723c5556 With this setup I hope to have near 7x more speed for write and near 14x for read than the UFS device alone. Then for be realistic, something like 850 mo/s for write and 1700 mo/s for read. ZFS – test : Write : gstat raising : http://www.privatepaste.com/7cefb9393a zpool iostat -v 1 of a fastest try : http://www.privatepaste.com/8ade4defbe dd result : 20971520000 bytes transferred in 54.326509 secs (386027381 bytes/sec) 386 mo/s more than twice less than I expect. Read : I export and import the pool for limit the ARC effect. I don't know how to do better, I hope that sufficient. gstat raising : http://www.privatepaste.com/130ce43af1 zpool iostat -v 1 : http://privatepaste.com/eb5f9d3432 dd result : 20971520000 bytes transferred in 30.347214 secs (691052563 bytes/sec) 690 mo/s 2,5x less than I expect. It's appear to not be an hardware issue, when I do a dd test of each whole disk at the same time with the command dd if=/dev/gpt/diskX of=/dev/null bs=1M count=10000, I have this gstat raising : http://privatepaste.com/df9f63fd4d Near 130 mo/s for each device, something like I expect. In your opinion where the problem come from ? Forgive me for my English, please keep easy language, i'm not realy easy with English. I can give you more information if you need. Many thanks for your help. From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 09:24:48 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 70A4AD5F for ; Sat, 8 Jun 2013 09:24:48 +0000 (UTC) (envelope-from rcartwri@asu.edu) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 1016C1C3F for ; Sat, 8 Jun 2013 09:24:47 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id p58so3736136wes.12 for ; Sat, 08 Jun 2013 02:24:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=6oneIFVmRM4bjNFsJQuMqXQSWOalzllxIIUO201k3JQ=; b=Xc0XIsqlM59i7+BErD/HzVO7hUOIEkAnKY+gCFaIB46XGjfDkz2G+wSZX+p43PNZbn HejBVKbFrtCjkEi+4janc7d9cKOKx0iCtqpoI1mWWhwf4V0Efud5LcFHsh8WcDzU0DmL rcaBVIXTyoehfwMaB6q5DexTvSEQNj/upsdvS0kRY59hyYHMySJ34mYfqoi1WnO9uotS Zfj88Iz/x7JJ05rdfxQwzcnc+brap36q5eFyrGZhFfHjw+kSQtvogcya5rVclEn05Fur s7r302+pWAOVkuUgumMhqUwFTXoqVjzNSxLcUsp2HegyzTz6ed4dqFxw1+qONvaLPQdx Y+/A== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr670005wic.32.1370683486186; Sat, 08 Jun 2013 02:24:46 -0700 (PDT) Received: by 10.180.76.114 with HTTP; Sat, 8 Jun 2013 02:24:46 -0700 (PDT) Date: Sat, 8 Jun 2013 02:24:46 -0700 Message-ID: Subject: ZFS and Glabel From: "Reed A. Cartwright" To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlGDVUUKFzxNTRBWNN3+1j3JCbfBHV2+pTemHJ7iKr/GqGtB66TnGfpWoq6+qMo++uTivSF X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 09:24:48 -0000 I currently have a raidz2 pool that uses whole disks: da6, da7, etc. I want to label these using glabel and have zfs mount them using the labels. This way, if an HDD fails, I will be able to easily replace the drive. So my questions are a follows: 1) Can glabel be used with zfs and raw disks? Should it be? 2) Can I add a glabel after the disks have been placed in a pool? 3) How would I do this without losing data? E.g. glabel label /dev/da6 storage1 glabel ... zpool export storage zpool import -d /dev/label storage 4) Is there a better alternative that allows me the keep the data on the drives and relabel them? -- Reed A. Cartwright, PhD Assistant Professor of Genomics, Evolution, and Bioinformatics School of Life Sciences Center for Evolutionary Medicine and Informatics The Biodesign Institute Arizona State University - Address: The Biodesign Institute, PO Box 875301, Tempe, AZ 85287-5301 USA Packages: The Biodesign Institute, 1001 S. McAllister Ave, Tempe, AZ 85287-5301 USA Office: Biodesign A-224A, 1-480-965-9949 From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 09:58:06 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F1D3B159 for ; Sat, 8 Jun 2013 09:58:06 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id 93F411D10 for ; Sat, 8 Jun 2013 09:58:06 +0000 (UTC) Received: from mfilter5-d.gandi.net (mfilter5-d.gandi.net [217.70.178.132]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 0F71EA80B1; Sat, 8 Jun 2013 11:57:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter5-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter5-d.gandi.net (mfilter5-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id DkD+oKCMWn8u; Sat, 8 Jun 2013 11:57:47 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 03E78A80B8; Sat, 8 Jun 2013 11:57:46 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id DFB6673A1C; Sat, 8 Jun 2013 02:57:44 -0700 (PDT) Date: Sat, 8 Jun 2013 02:57:44 -0700 From: Jeremy Chadwick To: "Reed A. Cartwright" Subject: Re: ZFS and Glabel Message-ID: <20130608095744.GA4643@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 09:58:07 -0000 On Sat, Jun 08, 2013 at 02:24:46AM -0700, Reed A. Cartwright wrote: > I currently have a raidz2 pool that uses whole disks: da6, da7, etc. > I want to label these using glabel and have zfs mount them using the > labels. This way, if an HDD fails, I will be able to easily replace > the drive. Can I ask what you mean when you say "that way if a HDD fails I'll be able to easily replace the drive?" What about using labels makes the process of disk replacement "easier"? You may want to keep reading, particularly the very bottom of my mail, as I re-touch on this question there. > So my questions are a follows: > > 1) Can glabel be used with zfs and raw disks? Should it be? glabel(8) offers two methods of behaviour: a) "automatic", which stores GEOM metadata (i.e. the label) on the disk itself, which will conflict with ZFS (when using full/raw disks) since the last sector (I believe) is used for the GEOM label metadata, b) "manual" -- which does not store any metadata on the disk itself, except you have to manually set the label every time the disk appears in the system. If the system reboots, etc. the label is therefore lost, and you get to type them all in again. Therefore on a reboot, when ZFS goes to taste all the disks to import the pool, it won't find any of them. Your below example in (3) indicates you're wanting the "automatic" method, because you're using "glabel label" not "glabel create" (see glabel(8) for the difference). In the case of "automatic", when the kernel starts, GEOM labels would be tasted first (before ZFS has a chance to refer to them, which is good). > 2) Can I add a glabel after the disks have been placed in a pool? With the "automatic" method, I would probably say no, since the rest of the GEOM subsystem and/or other parts of the subsystems will probably have the block device (disk) "locked" from those kind of modifications, particularly if the pool is already actively imported (in use) at the time. Consider the fact that ZFS effectively would be saying "Okay I'm using LBAs 500 to 123456789" (where 123456789 is the last LBA on the disk), and then you come along and tell glabel "go ahead and stomp all over LBA 123456789". Bad idea. With the "manual" method, I would say yes, but again see the problem with the "manual" method described above. > 3) How would I do this without losing data? E.g. > > glabel label /dev/da6 storage1 > glabel ... > zpool export storage > zpool import -d /dev/label storage No, I don't think this would work. You have given no information about your existing pool/setup, so I cannot give you exact commands to use, but you'd probably need to use a combination of "zpool offline" (on a single disk), followed by doing the glabel work, followed by "zpool replace", rinse lather repeat for each disk in the pool. This would require a vdev type offers redundancy (ex. mirror, raidzX). Doing it from scratch would be done like this (note the glabel syntax here, as your above syntax is incorrect): glabel label -v mylabel1 /dev/da6 glabel label -v mylabel2 /dev/da7 zpool create storage mirror /dev/label/mylabel1 /dev/label/mylabel2 This would be if you wanted a RAID-1-like mirror across 2 disks, referenced by their GEOM labels, of course. > 4) Is there a better alternative that allows me the keep the data on > the drives and relabel them? Please explain what actual problem it is you're trying to solve via the use of labels. This topic comes up quite often on the mailing lists, and you will find that I am a very strong advocate of avoiding *any* kind of labelling mechanism. I can point you to past conversations if need be. Keep in mind I am strong advocate of KISS principle. If the crux of the problem is that your disk device names may change or shift depending on if a disk is online/available/plugged in at the time of boot, then doing what is called "wiring down" in CAM is the proper solution for this -- it requires a one-time modification of /boot/loader.conf and the result is that device names remain static regardless of disk presence or even if another controller is added to the system. This is the method I used for many, many years and had absolutely no problems, especially when replacing disks with ZFS; the last thing I wanted to deal with when doing a disk swap is "errrr, yeah, so now I get to remember some command syntaxes to 'label things', wow what if I mess this up". It's a hell of a lot easier to just yank the disk, wait a few seconds for CAM to notice the disk removal, insert the replacement disk, wait for CAM to notice it, then do "zpool replace pool daX", ensure resilvering starts via "zpool status" and walk out of the datacenter. The only caveat with "wiring down" is if you **change** controllers (e.g. moving from ahci(4) to mpt(4)) -- but all you have to do then is update loader.conf to reflect how the new controller behaves/shows devices on the bus. Again, a one-time deal. Let us know what issue it is you feel you'd be avoiding using labels. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 13:27:27 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5DD0C9B for ; Sat, 8 Jun 2013 13:27:27 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADD115E0 for ; Sat, 8 Jun 2013 13:27:27 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r58DRJ7a083167; Sat, 8 Jun 2013 07:27:19 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r58DRJ09083164; Sat, 8 Jun 2013 07:27:19 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 8 Jun 2013 07:27:19 -0600 (MDT) From: Warren Block To: "Reed A. Cartwright" Subject: Re: ZFS and Glabel In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 08 Jun 2013 07:27:19 -0600 (MDT) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 13:27:27 -0000 On Sat, 8 Jun 2013, Reed A. Cartwright wrote: > I currently have a raidz2 pool that uses whole disks: da6, da7, etc. > I want to label these using glabel and have zfs mount them using the > labels. This way, if an HDD fails, I will be able to easily replace > the drive. GPT labels are better. They work through the glabel mechanism but don't have any extra metadata at the end of the disk. > So my questions are a follows: > > 1) Can glabel be used with zfs and raw disks? Should it be? Yes to the first. "Should" is a judgement call, so it depends on you and your situation. This forum thread talks about GPT labels a bit. It also refers Jeremy Chadwick's hardware "wiring-down" solution (also a judgement call). http://forums.freebsd.org/showthread.php?t=39410 From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 13:38:11 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BA5D2F0 for ; Sat, 8 Jun 2013 13:38:11 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 116FF1651 for ; Sat, 8 Jun 2013 13:38:10 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r58Dc9aN083253; Sat, 8 Jun 2013 07:38:09 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r58Dc9vD083250; Sat, 8 Jun 2013 07:38:09 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 8 Jun 2013 07:38:09 -0600 (MDT) From: Warren Block To: Jeremy Chadwick Subject: Re: ZFS and Glabel In-Reply-To: <20130608095744.GA4643@icarus.home.lan> Message-ID: References: <20130608095744.GA4643@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 08 Jun 2013 07:38:09 -0600 (MDT) Cc: freebsd-fs@freebsd.org, "Reed A. Cartwright" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 13:38:11 -0000 On Sat, 8 Jun 2013, Jeremy Chadwick wrote: > On Sat, Jun 08, 2013 at 02:24:46AM -0700, Reed A. Cartwright wrote: >> I currently have a raidz2 pool that uses whole disks: da6, da7, etc. >> I want to label these using glabel and have zfs mount them using the >> labels. This way, if an HDD fails, I will be able to easily replace >> the drive. > > Can I ask what you mean when you say "that way if a HDD fails I'll be > able to easily replace the drive?" > > What about using labels makes the process of disk replacement "easier"? In general, the nice thing about labels is that they give a particular drive a static name. That name does not depend on the controller hardware or method of connection, it's not calculated in any way, so it remains the same. Most other ID methods are calculated in some way, and can/may change. From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 15:16:48 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56C5E1E33 for ; Sat, 8 Jun 2013 15:16:48 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFD6109A for ; Sat, 8 Jun 2013 15:16:47 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id e10so655640qcy.13 for ; Sat, 08 Jun 2013 08:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BEv8SpcOcu/+38njtWj3qKDrpLb65wbsMw5y+XK8TKc=; b=hT6w0CtosKj0eRhNvHw1VY0Xf/quDnc05MTWmeAvUnwc0KMJUw7FVs57QQ/63dCHTe hfYH9NeDR8PRHDwWwO+kbkiXYYzPKDaoSkvl/73YMFhLqtjInvHgR2BngvAsEdWXz0Lu vo4Z0kgEQM2QOvI94JdqVAx3jLAUCuqQlh+OfRsEI9mlhmxqAweUzeorX606F1FiFR2F pj1QDQ86sxLKUXSgkMox5QYHubYSc3n2qyLtReGxeSAaNstWnvqF2K9IPDC+1FqiN0iI YWGzmh4F32oMUic/G0S4K41xB8d0zVb/RyKggf/FJXcUrNlWv8Nlmf1aG5T0OreY34id WOTw== MIME-Version: 1.0 X-Received: by 10.49.62.33 with SMTP id v1mr2503736qer.53.1370704607523; Sat, 08 Jun 2013 08:16:47 -0700 (PDT) Received: by 10.49.36.36 with HTTP; Sat, 8 Jun 2013 08:16:47 -0700 (PDT) Received: by 10.49.36.36 with HTTP; Sat, 8 Jun 2013 08:16:47 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Jun 2013 08:16:47 -0700 Message-ID: Subject: Re: ZFS and Glabel From: Freddie Cash To: "Reed A. Cartwright" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 15:16:48 -0000 On 2013-06-08 2:24 AM, "Reed A. Cartwright" wrote: > > I currently have a raidz2 pool that uses whole disks: da6, da7, etc. > I want to label these using glabel and have zfs mount them using the > labels. This way, if an HDD fails, I will be able to easily replace > the drive. > > So my questions are a follows: > > 1) Can glabel be used with zfs and raw disks? Should it be? Yes. > 2) Can I add a glabel after the disks have been placed in a pool? Yes. > 3) How would I do this without losing data? zpool offline storage da6 glabel label da6 storage1 zpool replace storage da6 label/storage1 Wait for the resilver to finish. Then repeat the above steps for each disk. ZFS reserves about 1MB of the disk for "slack" space to allow for replacing drives when the size is the same but the total number of disk sectors is different. I did the above on two separate storage boxes with 24 drives each without any issues. From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 18:54:05 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EDEE15D3 for ; Sat, 8 Jun 2013 18:54:05 +0000 (UTC) (envelope-from smh@freebsd.org) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id B931E103A for ; Sat, 8 Jun 2013 18:54:05 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 35E6B20E7088A; Sat, 8 Jun 2013 18:54:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-1.4 required=8.0 tests=ALL_TRUSTED,AWL,BAYES_00, STOX_REPLY_TYPE,STOX_REPLY_TYPE_WITHOUT_QUOTES autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPA id 987B820E70847 for ; Sat, 8 Jun 2013 18:54:03 +0000 (UTC) Message-ID: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> From: "Steven Hartland" To: Subject: Changing the default for ZFS atime to off? Date: Sat, 8 Jun 2013 19:54:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 18:54:06 -0000 One of the first changes we make here when installing machines here to changing atime=off on all ZFS pool roots. I know there are a few apps which can rely on atime updates such as qmail and possibly postfix, but those seem like special cases for which admins should enable atime instead of the other way round. This is going to of particular interest for flash based storage which should avoid unnessacary writes to reduce wear, but it will also help improve performance in general. So what do people think is it worth considering changing the default from atime=on to atime=off moving forward? If so what about UFS, same change? Regards Steve From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 19:17:01 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E2323B7E for ; Sat, 8 Jun 2013 19:17:01 +0000 (UTC) (envelope-from rcartwri@asu.edu) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by mx1.freebsd.org (Postfix) with ESMTP id 7F78810BF for ; Sat, 8 Jun 2013 19:17:01 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ey16so2152287wid.10 for ; Sat, 08 Jun 2013 12:17:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=+u/Svsjj9op7X/Cz6VizUxrSKaCvbSrAQuyx2I91Isk=; b=o5UwYZxmqCdOPsK4jAZsvHr+MgTLclGnZZXftm6Ks2rzao5DjaOIor3B8RgrLSBBuQ JDfl0dw57g++TnqM7J3luKycBApBnlf0Q8Ou+n4DPQY487fufU/XzJK0ftm/bd7ZPqwz cR+fvl4ZgH37fJLZhPewU2yNOhESPpJkwwO3LElHXJvXCJ6VomnF6Xb/Gbh2gGJaYdA3 9cc23e4ZFp3tDO3Frk93i2UlTtOOUNYaXsQBlusNUm1BvjQPI37M4yW7LHiy6jwX8eiM hq73433oh2JnAV7no1+x1NfxXCdhj5WG81A5m61VKXfH6g6JaE4tdXSVa2pEkTq5dPp5 9PQg== MIME-Version: 1.0 X-Received: by 10.180.97.106 with SMTP id dz10mr1497944wib.2.1370719019998; Sat, 08 Jun 2013 12:16:59 -0700 (PDT) Received: by 10.180.76.114 with HTTP; Sat, 8 Jun 2013 12:16:59 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Jun 2013 12:16:59 -0700 Message-ID: Subject: Re: ZFS and Glabel From: "Reed A. Cartwright" To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm+4EDEWKOm9BZ+OJV9z0qxNwxiDcBxHkFgiVvqoy/FCswwSwFAuKag4MxEknMNUHRK9x6T X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 19:17:01 -0000 After reading through the thread this morning it seems like the two practical solutions are to 1) Wire-down the drive bays. 2) Take drives offline one at a time, label, and resilver them. Thanks. -- Reed A. Cartwright, PhD Assistant Professor of Genomics, Evolution, and Bioinformatics School of Life Sciences Center for Evolutionary Medicine and Informatics The Biodesign Institute Arizona State University - Address: The Biodesign Institute, PO Box 875301, Tempe, AZ 85287-5301 USA Packages: The Biodesign Institute, 1001 S. McAllister Ave, Tempe, AZ 85287-5301 USA Office: Biodesign A-224A, 1-480-965-9949 From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 19:27:56 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1F0AEC0; Sat, 8 Jun 2013 19:27:55 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id C27B21110; Sat, 8 Jun 2013 19:27:55 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r58JRslQ001982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Jun 2013 14:27:54 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Sat, 8 Jun 2013 14:27:54 -0500 From: "Teske, Devin" To: Steven Hartland Subject: Re: Changing the default for ZFS atime to off? Thread-Topic: Changing the default for ZFS atime to off? Thread-Index: AQHOZHmRVUWybNoNfkOgXzEPFJrPFJksh2iA Date: Sat, 8 Jun 2013 19:27:54 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F78158@ltcfiswmsgmb21> References: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> In-Reply-To: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-06-08_06:2013-06-08,2013-06-08,1970-01-01 signatures=0 Cc: Devin Teske , "fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 19:27:56 -0000 On Jun 8, 2013, at 11:54 AM, Steven Hartland wrote: > One of the first changes we make here when installing machines > here to changing atime=3Doff on all ZFS pool roots. >=20 > I know there are a few apps which can rely on atime updates > such as qmail and possibly postfix, but those seem like special > cases for which admins should enable atime instead of the other > way round. >=20 > This is going to of particular interest for flash based storage > which should avoid unnessacary writes to reduce wear, but it will > also help improve performance in general. >=20 > So what do people think is it worth considering changing the > default from atime=3Don to atime=3Doff moving forward? >=20 +1 we turn it off on every ZFS filesystem (but we also don't use ZFS for ro= ot) > If so what about UFS, same change? >=20 We leave atime enabled for UFS root partition, /usr partition, /tmp partiti= on, and /var But if/when we do use UFS for non-system partitions, we turn it off there t= oo. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 21:17:51 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C39C543B for ; Sat, 8 Jun 2013 21:17:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id 654C01456 for ; Sat, 8 Jun 2013 21:17:50 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r58LHgfJ030978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Jun 2013 07:17:43 +1000 Date: Sun, 9 Jun 2013 07:17:42 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: kpneal@pobox.com Subject: Re: Changing the default for ZFS atime to off? In-Reply-To: <20130608200522.GA77122@neutralgood.org> Message-ID: <20130609065036.C16484@besplex.bde.org> References: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> <20130608200522.GA77122@neutralgood.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=eqSHVfVX c=1 sm=1 a=NMlb1ukX6xkA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=yTEsr0NIU8MA:10 a=ybZZDoGAAAAA:8 a=Anu6Zu9ZMewo-w5oqFAA:9 a=CjuIK1q_8ugA:10 a=qIVjreYYsbEA:10 a=TleOiiLAuzeUhfIO:21 a=t_ueL28kgWCz3Drx:21 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 21:17:51 -0000 On Sat, 8 Jun 2013 kpneal@pobox.com wrote: > On Sat, Jun 08, 2013 at 07:54:04PM +0100, Steven Hartland wrote: >> One of the first changes we make here when installing machines >> here to changing atime=off on all ZFS pool roots. >> >> I know there are a few apps which can rely on atime updates >> such as qmail and possibly postfix, but those seem like special >> cases for which admins should enable atime instead of the other >> way round. > > I believe mutt also uses them. Basically, any mail program using mbox mail > folders uses them to correctly report which mailboxes have not been read > yet. > > There are probably other cases as well. I don't think they should be > discounted simply because nobody here who bothers to speak up runs into > them. > > Turning off atime creates surprises for users. Of course it can't be turned off by default. It is specified by POSIX. >> This is going to of particular interest for flash based storage >> which should avoid unnessacary writes to reduce wear, but it will >> also help improve performance in general. >> >> So what do people think is it worth considering changing the >> default from atime=on to atime=off moving forward? > > I vote no. At least, don't change it unless the filesystem is actually on > a flash device. Otherwise we risk breakage down the road because something > that used to work doesn't work on a fresh FreeBSD install. > > Has anyone done any kind of study to see exactly how much I/O is caused > by having atime updates be enabled? Does it _really_ make that much of > a difference to performance, and would it _really_ help prolong the life > of flash devices? Not me, but I always mount with -noatime except when running POSIX conformance tests, and also use my lazy update of inodes (IN_LAZYMOD) for atime timestamps on all (ffs1) inodes. IN_LAZYMOD is only used for block and character vnodes in -current, so it became unused when ffs stopped supporting device vnodes, and is still disabled for soft updates so it is even more unused. If the overhead were a real problem then file systems would use a special atime cache and back it with a special device (perhaps /dev/null). Sqillions of timestamps can be stored in compressed form in memory. IN_LAZYMOD basically stores them in uncompressed form in vnodes, using ordinary vnode caching. Updates of the timestamps should use a log, since if you have a million of them to sync then you want to write out a contiguous log with 1 million entries and not do a million seeks. Since they are very noncritical and even when critical are rarely critical across unmounts and reboots, the log could be discarded at unmount and/or remount to avoid the expense of replaying it. In many uses it wouldn't grow nearly as large as a million entries so it would then not need any backing or physical i/o. Most useless atime updates are probably for traversals of large directory hierarchies. There can easily be millions of files, but millions of directories are not so common, and reading all the files is even less common. In POSIX, readdir() is not required to be implemented using read(), so it could reasonably not be required to set atime. However, POSIX is careful to pessimize this by specifying atime updates for readdir() too (readdir() may buffer its input, but is required to mark atime for update whenever the directory is "actually read"). Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 21:33:48 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D86E841; Sat, 8 Jun 2013 21:33:48 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id BA91215EC; Sat, 8 Jun 2013 21:33:47 +0000 (UTC) Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 7234AA80B5; Sat, 8 Jun 2013 23:33:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id w7AhcTduo7HU; Sat, 8 Jun 2013 23:33:34 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 8D950A80B1; Sat, 8 Jun 2013 23:33:34 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id B0D6273A1C; Sat, 8 Jun 2013 14:33:31 -0700 (PDT) Date: Sat, 8 Jun 2013 14:33:31 -0700 From: Jeremy Chadwick To: Steven Hartland Subject: Re: Changing the default for ZFS atime to off? Message-ID: <20130608213331.GB18201@icarus.home.lan> References: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 21:33:48 -0000 On Sat, Jun 08, 2013 at 07:54:04PM +0100, Steven Hartland wrote: > One of the first changes we make here when installing machines > here to changing atime=off on all ZFS pool roots. > > I know there are a few apps which can rely on atime updates > such as qmail and possibly postfix, but those seem like special > cases for which admins should enable atime instead of the other > way round. > > This is going to of particular interest for flash based storage > which should avoid unnessacary writes to reduce wear, but it will > also help improve performance in general. > > So what do people think is it worth considering changing the > default from atime=on to atime=off moving forward? > > If so what about UFS, same change? I **strongly** oppose this change, for one key reason: the classic Berkeley UNIX mail spool format (known as "mbox"), which is still predominantly used on most UNIX systems today. Mail clients which read mbox files require a combination of atime and mtime to determine if new mail has arrived within the mailbox. If mtime > atime, then there's new mail. Not all mail clients support alternate methods of detection (for example mutt has check_mbox_size, which has had bugs/problems in the past (Google check_mbox_size), and is fallible in other ways). Further points: - FreeBSD comes with sendmail (MTA/MDA), which supports only mbox natively - FreeBSD comes with mail/Mail/mailx (client), which only supports only mbox natively - FreeBSD comes with biff/comsat, as well as from(1), which supports only mbox natively FACT: We have no idea how prevalent these programs/features are used throughout people's systems. Any responses on freebsd-fs@ will be the minority -- anyone familiar with FreeBSD knows that only when you change (break) something do people start crawling out of the woodwork (the recent fxp(4) situation on 8.4-RELEASE is proof). What this means is that "by default" we have to assume that people are reliant upon this type of functionality, and that by disabling it by default (on any filesystem type) we will cause a very serious problem. (Imagine telling your boss "the reason I didn't respond to your Email promptly is because the FreeBSD people disabled atime by default and thus new mail detection in my mail client stopped working"). Please read my blog post, circa 2009, for further details: http://koitsu.wordpress.com/2009/10/29/unix-mail-format-annoyances/ Note: switching to Maildir is not an option, as I explain in my blog (ZFS does not generally perform well with thousands of small files in a single directory, or if multiple mailboxes, thousands of files per multiple directories), and none of the above utilities that come with FreeBSD support anything but mbox. TL;DR -- Do not disable atime by default, you will anger many people. Yes, their existing filesystems will still have atime=on, but the instant the administrator builds a new box or upgrades + builds a new filesystem...... -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Jun 8 23:34:34 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EFBDFA5B for ; Sat, 8 Jun 2013 23:34:34 +0000 (UTC) (envelope-from prvs=18715e5890=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9440A1B8B for ; Sat, 8 Jun 2013 23:34:34 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004222836.msg for ; Sun, 09 Jun 2013 00:34:32 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 09 Jun 2013 00:34:32 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=18715e5890=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: fs@freebsd.org Message-ID: <01719722FD8A41B4A4366611972A703A@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" References: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> <20130608213331.GB18201@icarus.home.lan> Subject: Re: Changing the default for ZFS atime to off? Date: Sun, 9 Jun 2013 00:34:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 23:34:35 -0000 ----- Original Message ----- From: "Jeremy Chadwick" To: "Steven Hartland" Cc: Sent: Saturday, June 08, 2013 10:33 PM Subject: Re: Changing the default for ZFS atime to off? > On Sat, Jun 08, 2013 at 07:54:04PM +0100, Steven Hartland wrote: >> One of the first changes we make here when installing machines >> here to changing atime=off on all ZFS pool roots. >> >> I know there are a few apps which can rely on atime updates >> such as qmail and possibly postfix, but those seem like special >> cases for which admins should enable atime instead of the other >> way round. >> >> This is going to of particular interest for flash based storage >> which should avoid unnessacary writes to reduce wear, but it will >> also help improve performance in general. >> >> So what do people think is it worth considering changing the >> default from atime=on to atime=off moving forward? >> >> If so what about UFS, same change? > > I **strongly** oppose this change, for one key reason: the classic > Berkeley UNIX mail spool format (known as "mbox"), which is still > predominantly used on most UNIX systems today. > > Mail clients which read mbox files require a combination of atime and > mtime to determine if new mail has arrived within the mailbox. If > mtime > atime, then there's new mail. Not all mail clients support > alternate methods of detection (for example mutt has check_mbox_size, > which has had bugs/problems in the past (Google check_mbox_size), > and is fallible in other ways). .. To clarify when I say "by default" this only effect newly created pools / volumes, it would not effect any existing volumes and hence couldn't break existing installs. As I mentioned there are apps, mainly mail focused ones, which rely on on atime, but thats easy to keep working by ensuring these are stored on volumes which do have atime=on. The messaging and changes to installers which support ZFS root installs, such as mfsbsd, would need to be included in this but I don't see that as a blocker. I suggesting this now as it seems like its time to consider that the vast majority of systems don't need this option for all volumes and the performance and reliability of systems are in question if we don't consider it. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.