From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 00:10:08 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B4BC1065692 for ; Sun, 24 Jan 2010 00:10:08 +0000 (UTC) (envelope-from stevenschlansker@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id EF9378FC13 for ; Sun, 24 Jan 2010 00:10:07 +0000 (UTC) Received: by ywh35 with SMTP id 35so1917335ywh.7 for ; Sat, 23 Jan 2010 16:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=ZT8435wGnxWsBZFTd13hKa8PyMJLfG1eqd6RXLWZ4Ss=; b=O9x/Ae600C5JBjdMAfzowFNjBgGjqkuDAaNkapsDpT6bwSNFGLcYJlqq5/0jBplAnH 8oTBeH52qP2w4jH9f89J8fCgWBad7J/oUuAyFsjpX7ceysR3g3H39k6h43wAZyC0B3Pg iay33bUMHVmg1/Rd0KDicFH4xdrW1drnZafIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=LoDglPkc0x6bHmfedGZCdFahVL0ljQC+05/HT8oxdB/Agw/iSBZdi8aEVgcLr18k+2 2n7hJPfqPDgli+5JQGRAGEXP+EbbDw/VAsIaAAGRIl5tLkCYWuunHV/Wr5CtdvmSTkYG mRfMKIImkji1uXGNmsCKdtQBkp/ZABF9SlBHU= Received: by 10.101.6.30 with SMTP id j30mr5815131ani.200.1264291807115; Sat, 23 Jan 2010 16:10:07 -0800 (PST) Received: from ?192.168.42.3? (70-36-134-162.dsl.dynamic.sonic.net [70.36.134.162]) by mx.google.com with ESMTPS id 13sm2085856gxk.13.2010.01.23.16.10.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 16:10:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Schlansker In-Reply-To: <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> Date: Sat, 23 Jan 2010 16:09:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> To: Rich X-Mailer: Apple Mail (2.1077) Cc: freebsd-fs Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:10:08 -0000 Perhaps you could create a new filesystem, say mirrors_new Move all files that you can read Destroy the bugged filesystem Rename the new filesystem over the old one Restore the missing files from backup Sound reasonable? On Jan 23, 2010, at 3:41 PM, Rich wrote: > I have no files named 0x0. >=20 > I have a number of files which, on attempting to do anything to them > (stat, mv, rm), EIO occurs, the checksum error number on three of the > disks in that pool ticks up, and /var/log/messages reports what I > reported in my initial post. (i discovered this due to FreeBSD's daily > check-for-setuid-bits-in-strange-places find command reporting EIO on > some files.) >=20 > My original post in this thread is about how to resolve this. >=20 > - Rich >=20 > On Sat, Jan 23, 2010 at 6:34 PM, Wes Morgan = wrote: >> On Sat, 23 Jan 2010, Rich wrote: >>=20 >>> On Sat, Jan 23, 2010 at 4:21 PM, Wes Morgan = wrote: >>>> On Sat, 23 Jan 2010, Rich wrote: >>>>=20 >>>>> I already diagnosed the bad hardware - one of the two sticks of = RAM >>>>> had gone bad, and fails memtest in the other machine. >>>>>=20 >>>>> pool: rigatoni >>>>> state: ONLINE >>>>> status: One or more devices has experienced an error resulting in = data >>>>> corruption. Applications may be affected. >>>>> action: Restore the file in question if possible. Otherwise = restore the >>>>> entire pool from backup. >>>>> see: http://www.sun.com/msg/ZFS-8000-8A >>>>> scrub: scrub completed after 15h28m with 1 errors on Thu Jan 21 = 18:09:25 2010 >>>>> config: >>>>>=20 >>>>> NAME STATE READ WRITE CKSUM >>>>> rigatoni ONLINE 0 0 1 >>>>> da4 ONLINE 0 0 2 >>>>> da5 ONLINE 0 0 2 >>>>> da7 ONLINE 0 0 0 >>>>> da6 ONLINE 0 0 0 >>>>> da2 ONLINE 0 0 2 >>>>>=20 >>>>> errors: Permanent errors have been detected in the following = files: >>>>>=20 >>>>> rigatoni/mirrors:<0x0> >>>>=20 >>>> Can you post your entire pool filesystem structure? That message = above >>>> looks like an unreferenced block or corrupted metadata rather than = an >>>> actual file. Also, if it's part of a snapshot, you simply have to = destroy >>>> the snapshot. >>>>=20 >>>> I had a pool become corrupted due to bad memory, and all of the = files were >>>> still able to be manipulated. The only time EIO popped up was on = the >>>> specific block that had a checksum error. >>>=20 >>> # zfs list -r -t all rigatoni >>> NAME USED AVAIL REFER MOUNTPOINT >>> rigatoni 5.73T 984G 19K /rigatoni >>> rigatoni/logs_bitch 269M 984G 269M /rigatoni/logs_bitch >>> rigatoni/mirrors 5.73T 984G 5.73T /mirrors >>>=20 >>> No snapshots here. :/ >>>=20 >>> EIO only pops up on the files I mentioned above - everything else in >>> those directories, including renaming that directory, is fine. >>=20 >> I must have missed it, what files is it showing besides the <0x0> = address? >> Or do you have a file named "<0x0>"? >=20 >=20 >=20 > --=20 >=20 > Life is a yo-yo, and mankind ties knots in the string. > _______________________________________________ > 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 Sun Jan 24 00:15:07 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C05F106566B for ; Sun, 24 Jan 2010 00:15:07 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD5A8FC0A for ; Sun, 24 Jan 2010 00:15:06 +0000 (UTC) Received: by pxi13 with SMTP id 13so1662038pxi.3 for ; Sat, 23 Jan 2010 16:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pbAOg+z9kuCSEo6Jw7Gvkzc1GTxADwHZey7MzZEyp1M=; b=LFLD2SEaTBY9ajtv/5ovkGA0Reto7//tZFcJgz/LkhV3OYLyXYQXzCm5HqqyfZZFVo tnwPOzb2hs5xO7gHVphaPe8bWDG8/8xuyjARXRYjURHab1DLMhBiHqexEI6x+dWfbIv3 qdFt1E0d64EfPtDUcxpsD4DvkMNPwm6fR/dmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Rga+9cKA3J3Mf6/8Q4RM+eOnn6BGWL7d+7CaktBNEg2LHXj924QlxSJM1Xv9aVBQlZ kJyy6V/rnAZC8GIVnqC9d+v2zVsl/dJVOzWEnPh9mOUizRPIKvwrlNXq4/VXrRvpCInH CKixjxudmVKRKKJATc3Ps6gDk7Bx/5rYz5XPg= MIME-Version: 1.0 Received: by 10.114.188.8 with SMTP id l8mr3296086waf.12.1264292106477; Sat, 23 Jan 2010 16:15:06 -0800 (PST) In-Reply-To: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> Date: Sat, 23 Jan 2010 19:15:06 -0500 Message-ID: <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> From: Rich To: Steven Schlansker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:15:07 -0000 If there were no other option, certainly. I claim this is still Bad Behavior, and should be resolvable without doing something like that. - Rich On Sat, Jan 23, 2010 at 7:09 PM, Steven Schlansker wrote: > Perhaps you could create a new filesystem, say mirrors_new > Move all files that you can read > Destroy the bugged filesystem > Rename the new filesystem over the old one > Restore the missing files from backup > > Sound reasonable? > > On Jan 23, 2010, at 3:41 PM, Rich wrote: > >> I have no files named 0x0. >> >> I have a number of files which, on attempting to do anything to them >> (stat, mv, rm), EIO occurs, the checksum error number on three of the >> disks in that pool ticks up, and /var/log/messages reports what I >> reported in my initial post. (i discovered this due to FreeBSD's daily >> check-for-setuid-bits-in-strange-places find command reporting EIO on >> some files.) >> >> My original post in this thread is about how to resolve this. >> >> - Rich >> >> On Sat, Jan 23, 2010 at 6:34 PM, Wes Morgan wrot= e: >>> On Sat, 23 Jan 2010, Rich wrote: >>> >>>> On Sat, Jan 23, 2010 at 4:21 PM, Wes Morgan wr= ote: >>>>> On Sat, 23 Jan 2010, Rich wrote: >>>>> >>>>>> I already diagnosed the bad hardware - one of the two sticks of RAM >>>>>> had gone bad, and fails memtest in the other machine. >>>>>> >>>>>> =A0 pool: rigatoni >>>>>> =A0state: ONLINE >>>>>> status: One or more devices has experienced an error resulting in da= ta >>>>>> =A0 =A0 =A0 corruption. =A0Applications may be affected. >>>>>> action: Restore the file in question if possible. =A0Otherwise resto= re the >>>>>> =A0 =A0 =A0 entire pool from backup. >>>>>> =A0 =A0see: http://www.sun.com/msg/ZFS-8000-8A >>>>>> =A0scrub: scrub completed after 15h28m with 1 errors on Thu Jan 21 1= 8:09:25 2010 >>>>>> config: >>>>>> >>>>>> =A0 =A0 =A0 NAME =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM >>>>>> =A0 =A0 =A0 rigatoni =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 1 >>>>>> =A0 =A0 =A0 =A0 da4 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 2 >>>>>> =A0 =A0 =A0 =A0 da5 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 2 >>>>>> =A0 =A0 =A0 =A0 da7 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >>>>>> =A0 =A0 =A0 =A0 da6 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >>>>>> =A0 =A0 =A0 =A0 da2 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 2 >>>>>> >>>>>> errors: Permanent errors have been detected in the following files: >>>>>> >>>>>> =A0 =A0 =A0 =A0 rigatoni/mirrors:<0x0> >>>>> >>>>> Can you post your entire pool filesystem structure? That message abov= e >>>>> looks like an unreferenced block or corrupted metadata rather than an >>>>> actual file. Also, if it's part of a snapshot, you simply have to des= troy >>>>> the snapshot. >>>>> >>>>> I had a pool become corrupted due to bad memory, and all of the files= were >>>>> still able to be manipulated. The only time EIO popped up was on the >>>>> specific block that had a checksum error. >>>> >>>> # zfs list -r -t all rigatoni >>>> NAME =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0USED =A0AVAIL =A0REFER =A0MOUN= TPOINT >>>> rigatoni =A0 =A0 =A0 =A0 =A0 =A0 5.73T =A0 984G =A0 =A019K =A0/rigaton= i >>>> rigatoni/logs_bitch =A0 269M =A0 984G =A0 269M =A0/rigatoni/logs_bitch >>>> rigatoni/mirrors =A0 =A0 5.73T =A0 984G =A05.73T =A0/mirrors >>>> >>>> No snapshots here. :/ >>>> >>>> EIO only pops up on the files I mentioned above - everything else in >>>> those directories, including renaming that directory, is fine. >>> >>> I must have missed it, what files is it showing besides the <0x0> addre= ss? >>> Or do you have a file named "<0x0>"? >> >> >> >> -- >> >> Life is a yo-yo, and mankind ties knots in the string. >> _______________________________________________ >> 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 A foolish consistency is the hobgoblin of little minds. -- Ralph Waldo Emer= son From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 00:34:11 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4826E106566C for ; Sun, 24 Jan 2010 00:34:11 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 04B468FC0C for ; Sun, 24 Jan 2010 00:34:10 +0000 (UTC) Received: by email.octopus.com.au (Postfix, from userid 1002) id 718665CB91E; Sun, 24 Jan 2010 11:10:00 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: * X-Spam-Status: No, score=1.9 required=10.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.3 Received: from [10.7.0.130] (unknown [59.167.250.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 1F6175CB917; Sun, 24 Jan 2010 11:09:56 +1100 (EST) Message-ID: <4B5B94B8.7070509@modulus.org> Date: Sun, 24 Jan 2010 11:30:48 +1100 From: Andrew Snow User-Agent: Thunderbird 2.0.0.21 (X11/20090623) MIME-Version: 1.0 To: Rich , freebsd-fs@freebsd.org References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> In-Reply-To: <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:34:11 -0000 Rich wrote: > I claim this is still Bad Behavior, and should be resolvable without > doing something like that. I cannot agree that silent corruption (which would have happened with any other filesystem) is preferable to what ZFS is doing here. You had bad RAM, and no redundancy in a huge RAID0, I think it would be reasonable to have to restore from backups or recreate the data and not pin blame on ZFS. - Andrew From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 00:38:49 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00EA2106566C for ; Sun, 24 Jan 2010 00:38:49 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8625C8FC0C for ; Sun, 24 Jan 2010 00:38:48 +0000 (UTC) Received: by fxm26 with SMTP id 26so28490fxm.13 for ; Sat, 23 Jan 2010 16:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=w+kTOBGMYMF4H5a3AKA3c23aKMlGkb87AtfOd770RY8=; b=xgWSlT+8Te0Q1xr70hzva2NJScld8Q3Y6BZHYaHovwiQhyoo0hjlPXCejNWPijSO2G L8Zw6/NiyjZzaY1A8N7tcqHCplcz5NBG5NBFd7OHDIN6sLfGhhxXatzCg6Hfu7kb4oau Vj8Kpby9KR9fD3Fau10adWyQ9p2UYS8Gl8w9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RICIdxK1a5M3MdNwcVHjlTEdqIF5Fy317q1m926Bp7d4a3VMjfNb3HKRgNX7MjESUv /30R2IIDr9VeFrKYc22u9YKWusSfFHjlwgUf+7CgrDzKNNIN9PtwRyaQuiIAzDJXO3+4 rjHerleZEMFQWnPKvoi+XSTZh647UWhL2t4UM= MIME-Version: 1.0 Received: by 10.239.167.131 with SMTP id g3mr517897hbe.14.1264293527349; Sat, 23 Jan 2010 16:38:47 -0800 (PST) In-Reply-To: <4B5B94B8.7070509@modulus.org> References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> Date: Sat, 23 Jan 2010 19:38:47 -0500 Message-ID: <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> From: Rich To: Andrew Snow Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:38:49 -0000 I'm not claiming that restoring data from backups is unreasonable, or that silent data corruption is better. I'm claiming that my inability to delete the corrupted data in order to restore from backups without nuking unaffected data or remaking the filesystem is unreasonable. - Rich On Sat, Jan 23, 2010 at 7:30 PM, Andrew Snow wrote: > Rich wrote: >> >> I claim this is still Bad Behavior, and should be resolvable without >> doing something like that. > > I cannot agree that silent corruption (which would have happened with any > other filesystem) is preferable to what ZFS is doing here. > > You had bad RAM, and no redundancy in a huge RAID0, I think it would be > reasonable to have to restore from backups or recreate the data and not pin > blame on ZFS. > > > - Andrew > -- BOFH excuse #208: Your mail is being routed through Germany ... and they're censoring us. From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 00:40:19 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DB131065670 for ; Sun, 24 Jan 2010 00:40:19 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD9B68FC1A for ; Sun, 24 Jan 2010 00:40:18 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-214-156.shv.bellsouth.net [98.67.214.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id 7F59B90A7B00; Sat, 23 Jan 2010 18:40:17 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id o0O0eDcq005533; Sat, 23 Jan 2010 18:40:14 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Sat, 23 Jan 2010 18:40:13 -0600 (CST) From: Wes Morgan X-X-Sender: morganw@volatile To: Rich In-Reply-To: <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> Message-ID: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3224958491-39306717-1264292171=:2160" Content-ID: X-Virus-Scanned: clamav-milter 0.95.3 at warped X-Virus-Status: Clean Cc: freebsd-fs Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:40:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3224958491-39306717-1264292171=:2160 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: On Sat, 23 Jan 2010, Rich wrote: > I have no files named 0x0. > > I have a number of files which, on attempting to do anything to them > (stat, mv, rm), EIO occurs, the checksum error number on three of the > disks in that pool ticks up, and /var/log/messages reports what I > reported in my initial post. (i discovered this due to FreeBSD's daily > check-for-setuid-bits-in-strange-places find command reporting EIO on > some files.) > > My original post in this thread is about how to resolve this. Do these bad files show up on "zpool status -v" after a scrub? This really sounds much more like an issue of corrupt metadata. ZFS keeps multiple copies of filesystem metadata even on non-redundant pools (ditto blocks). You said there was bad ram in this machine at one point, which may mean that *all* of the metadata was corrupt. In my encounter with a bad stick of ram, the data was correct but the stored checksums were wrong. I was able to "recover" the data by simply changing zfs_read() to not report EIO when it encounters an ECKSUM error from the zfs layer -- essentially ignoring the checksum error. I have no idea what this might do if the metadata itself is corrupt, so that could be risky. Another option is the zdb solution mentioned earlier. > > On Sat, Jan 23, 2010 at 6:34 PM, Wes Morgan wrote: > > On Sat, 23 Jan 2010, Rich wrote: > > > >> On Sat, Jan 23, 2010 at 4:21 PM, Wes Morgan wrote: > >> > On Sat, 23 Jan 2010, Rich wrote: > >> > > >> >> I already diagnosed the bad hardware - one of the two sticks of RAM > >> >> had gone bad, and fails memtest in the other machine. > >> >> > >> >>   pool: rigatoni > >> >>  state: ONLINE > >> >> status: One or more devices has experienced an error resulting in data > >> >>       corruption.  Applications may be affected. > >> >> action: Restore the file in question if possible.  Otherwise restore the > >> >>       entire pool from backup. > >> >>    see: http://www.sun.com/msg/ZFS-8000-8A > >> >>  scrub: scrub completed after 15h28m with 1 errors on Thu Jan 21 18:09:25 2010 > >> >> config: > >> >> > >> >>       NAME        STATE     READ WRITE CKSUM > >> >>       rigatoni    ONLINE       0     0     1 > >> >>         da4       ONLINE       0     0     2 > >> >>         da5       ONLINE       0     0     2 > >> >>         da7       ONLINE       0     0     0 > >> >>         da6       ONLINE       0     0     0 > >> >>         da2       ONLINE       0     0     2 > >> >> > >> >> errors: Permanent errors have been detected in the following files: > >> >> > >> >>         rigatoni/mirrors:<0x0> > >> > > >> > Can you post your entire pool filesystem structure? That message above > >> > looks like an unreferenced block or corrupted metadata rather than an > >> > actual file. Also, if it's part of a snapshot, you simply have to destroy > >> > the snapshot. > >> > > >> > I had a pool become corrupted due to bad memory, and all of the files were > >> > still able to be manipulated. The only time EIO popped up was on the > >> > specific block that had a checksum error. > >> > >> # zfs list -r -t all rigatoni > >> NAME                  USED  AVAIL  REFER  MOUNTPOINT > >> rigatoni             5.73T   984G    19K  /rigatoni > >> rigatoni/logs_bitch   269M   984G   269M  /rigatoni/logs_bitch > >> rigatoni/mirrors     5.73T   984G  5.73T  /mirrors > >> > >> No snapshots here. :/ > >> > >> EIO only pops up on the files I mentioned above - everything else in > >> those directories, including renaming that directory, is fine. > > > > I must have missed it, what files is it showing besides the <0x0> address? > > Or do you have a file named "<0x0>"? > > > > --3224958491-39306717-1264292171=:2160-- From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 02:13:24 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA607106566C for ; Sun, 24 Jan 2010 02:13:24 +0000 (UTC) (envelope-from pl@ninthfloor.org) Received: from mail.ninthfloor.org (ninthfloor.org [IPv6:2001:470:1f07:ea::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6609C8FC0C for ; Sun, 24 Jan 2010 02:13:24 +0000 (UTC) Received: from ninthfloor.org (ninthfloor.org [IPv6:2001:470:1f07:ea::1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pl) by mail.ninthfloor.org (Postfix) with ESMTPSA id 595511C143 for ; Sun, 24 Jan 2010 02:13:23 +0000 (UTC) Date: Sun, 24 Jan 2010 02:13:18 +0000 From: Paride Legovini To: freebsd-fs@freebsd.org Message-ID: <20100124021318.GA1881@ninthfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Can't export using nfs4 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 02:13:24 -0000 Hello, I hope this is the right place where to ask for help about this issue. I'm playing with nfs4 but with no luck, the system is set up in the following way. The kernel (8.0-STABLE) is built with: options NFSD options NFSCL The relevant part of rc.conf is: # grep nfs /etc/rc.conf nfs_server_enable="YES" nfsv4_server_enable="YES" nfsuserd_enable="YES" nfs_client_enable="YES" Then I have a couple of trivial exports: # cat /etc/exports V4: /usr /home (No, you can't reach them from the Internet!) Finally I set up /var/db/nfs-stablerestart as explained in nfsv4(4). Everything works fine for /home, but /usr doesn't get exported at all. In fact: # showmount -e Exports list on localhost: /home Everyone and the same evidence is given by mount: /dev/ada0s1f on /usr (ufs, local, noatime, soft-updates) /dev/ada0s1g on /home (ufs, NFS exported, local, noatime, soft-updates) (/home is not 'NFS exported'.) There's nothing relevant in the dmesg on in /var/log/messages. Any suggestion? Thank you! Paride From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 03:15:14 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B21531065692 for ; Sun, 24 Jan 2010 03:15:14 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECAC8FC1D for ; Sun, 24 Jan 2010 03:15:14 +0000 (UTC) Received: from dereel.lemis.com (121-200-1-204.cust.aussiebb.net [121.200.1.204]) by w3.lemis.com (Postfix) with ESMTP id 1E79D3BACE; Sun, 24 Jan 2010 03:04:57 +0000 (UTC) Received: by dereel.lemis.com (Postfix, from userid 1004) id 872A2A1098; Sun, 24 Jan 2010 14:04:51 +1100 (EST) Date: Sun, 24 Jan 2010 14:04:51 +1100 From: Greg 'groggy' Lehey To: Rich Message-ID: <20100124030451.GB88876@dereel.lemis.com> References: <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline In-Reply-To: <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 03:15:14 -0000 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [sequence recovered] On Saturday, 23 January 2010 at 19:38:47 -0500, Rich wrote: > On Sat, Jan 23, 2010 at 7:30 PM, Andrew Snow wrote: >> Rich wrote: >>> >>> I claim this is still Bad Behavior, and should be resolvable without >>> doing something like that. >> >> I cannot agree that silent corruption (which would have happened with any >> other filesystem) is preferable to what ZFS is doing here. >> >> You had bad RAM, and no redundancy in a huge RAID0, I think it would be >> reasonable to have to restore from backups or recreate the data and not pin >> blame on ZFS. > > I'm not claiming that restoring data from backups is unreasonable, or > that silent data corruption is better. > > I'm claiming that my inability to delete the corrupted data in order > to restore from backups without nuking unaffected data or remaking the > filesystem is unreasonable. You have a file system with broken metadata. How can ZFS know how to work around this corruption? By continuing things could get worse. I haven't been following this thread, but the way I see it: Reasonable: to be able to mount the file system read-only and recover what data you can from it. Unreasonable: to expect the file system to repair corruption of an unknown type. The only safe path is to create the file system from scratch. This has nothing to do with how you recover the data. Greg -- See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAktbuNMACgkQIubykFB6QiPQMgCeLGly2NzemOpmhGFy/gMZsq7E E/MAn0Xjji6KbsY2btFmlYxFlCoGK0Ad =EMrR -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 04:14:10 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26F7C1065670 for ; Sun, 24 Jan 2010 04:14:10 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by mx1.freebsd.org (Postfix) with ESMTP id C6ACD8FC0C for ; Sun, 24 Jan 2010 04:14:09 +0000 (UTC) Received: by qyk39 with SMTP id 39so1359370qyk.27 for ; Sat, 23 Jan 2010 20:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=U/yyoWiz2fHZnRBcQsyFdfZx20XdCFP1DLdtvun796E=; b=mPxhHiM7tOAHfgVu2yaN8yemhRMbkwnl3pb6xeW0iLNG4byCfb2/KPP10dWQgvlK3J BjPd/cbdXfO65+O3ZYuMkg3/p9KSgCrqfu67Pv9zFtMfTAmzygSoIuF6gvQabv6giNlN EEUUqjuKLwdZO15HR43L2W/gGCJh/pLd9pqXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=WvaH9rbNxrFuagTDpnDZ0hQIV5qNyjxjtutvSWBhlIecmnPUYH5/RE5e8UTsVrhQvG x/sYIYUFn0B0z1MBuWMhshMo3LNcFOqmgHfkVtQLrWl/kwuMYSeSWww74kTpObbWLiCD R6peB8Qm3UYZTt26tM0hlVKNpEf+vGmEJBqc8= Received: by 10.224.109.17 with SMTP id h17mr3182765qap.144.1264306449092; Sat, 23 Jan 2010 20:14:09 -0800 (PST) Received: from centel.dataix.local (ppp-21.4.dialinfree.com [209.172.21.4]) by mx.google.com with ESMTPS id 6sm8621788qwk.41.2010.01.23.20.14.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 20:14:08 -0800 (PST) Sender: "J. Hellenthal" Date: Sat, 23 Jan 2010 23:13:54 -0500 From: jhell To: Rich In-Reply-To: <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> Message-ID: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 04:14:10 -0000 On Sat, 23 Jan 2010 19:38, rincebrain@ wrote: > I'm not claiming that restoring data from backups is unreasonable, or > that silent data corruption is better. > > I'm claiming that my inability to delete the corrupted data in order > to restore from backups without nuking unaffected data or remaking the > filesystem is unreasonable. > > - Rich > > On Sat, Jan 23, 2010 at 7:30 PM, Andrew Snow wrote: >> Rich wrote: >>> >>> I claim this is still Bad Behavior, and should be resolvable without >>> doing something like that. >> >> I cannot agree that silent corruption (which would have happened with any >> other filesystem) is preferable to what ZFS is doing here. >> >> You had bad RAM, and no redundancy in a huge RAID0, I think it would be >> reasonable to have to restore from backups or recreate the data and not pin >> blame on ZFS. >> >> >> - Andrew >> > Rich, Can you try the following please and then report back. Setting failmode to continue might let you continue a removal. zpool set failmode=continue what_is_it_rigatoni? This should be inherited by effected drives. zfs set checksum=off what_is_it_rigatoni? Remove the said effected files at this point. Turn your failmode back to its default state which is "wait" and then turn your checksum back to on state or whatever you had it at previously. zpool clear what_is_it_rigatoni? zpool scrub what_is_it_rigatoni? We will wait for you here... -- jhell From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 04:17:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B22E9106566B for ; Sun, 24 Jan 2010 04:17:05 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 42B018FC13 for ; Sun, 24 Jan 2010 04:17:04 +0000 (UTC) Received: by fxm26 with SMTP id 26so83190fxm.13 for ; Sat, 23 Jan 2010 20:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hXL5UZbSBKx0/zCLSo9vFIkWHNBtJ4ohfD2WAGjRLFk=; b=CUpxwndxWSCL4Y7x5FISvt4ir6DNlsStNpXulH2AJL78oIeSdrexYskVJ1k/GDF8IU 5OAmSoa36bov8xxgqzBuM4EsXnFaoHVmcvUv++xfqMmUckAGqoScDUuM4sIOpquk+0EL P45Z3bH+/iaWCySq8o9+dDNDhuwngntsbPVak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HONXLcej+G3ELkTYvIM+486RX0kyqwaApQvcQVLGeMqQMlToJovT8HaOSCbUjJPAVo ZHCHuLHzL+DfGmbu625VdSIokejhmTdGuA0pXiZXvTpW6EoZof+jOHgKpuTPQETRxNX0 ufM/K8ss0RlViCWPLff88OzMyBgqIHYI9ZvBc= MIME-Version: 1.0 Received: by 10.239.167.131 with SMTP id g3mr535472hbe.14.1264306624163; Sat, 23 Jan 2010 20:17:04 -0800 (PST) In-Reply-To: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> Date: Sat, 23 Jan 2010 23:17:03 -0500 Message-ID: <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> From: Rich To: jhell Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 04:17:05 -0000 > Can you try the following please and then report back. > > Setting failmode to continue might let you continue a removal. > zpool set failmode=continue what_is_it_rigatoni? > > This should be inherited by effected drives. > zfs set checksum=off what_is_it_rigatoni? > > Remove the said effected files at this point. [root@manticore ~]# zpool set failmode=continue rigatoni [root@manticore ~]# zfs set checksum=off rigatoni [root@manticore ~]# mv /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979 /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo19791 mv: rename /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979 to /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo19791: Input/output error [root@manticore ~]# rm -f /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979 rm: /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979: Input/output error :/ - Rich From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 05:16:02 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68F2E106566B for ; Sun, 24 Jan 2010 05:16:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by mx1.freebsd.org (Postfix) with ESMTP id 1435C8FC16 for ; Sun, 24 Jan 2010 05:16:01 +0000 (UTC) Received: by qyk39 with SMTP id 39so1372413qyk.27 for ; Sat, 23 Jan 2010 21:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=wiixVMc3sBnB2SwTNDLUDFPD/zmjop0gwcwkgOF2hiQ=; b=p+JL+oeX/8yr03WsHng35ByiXwTLIq2nH/LEYFJdPUYiswBbhCOPWOyiRLrlKALhMf BRGoa4T4FqgF8Koc+Y4iyFlzND+VCwfB0F6SMtArvW9BVjmLPa1V+F0Jrorm4aN8eQDZ Qt6DEI3fJ6By/sMjpC+4ftgfek9GysE6yI9Hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=PCZuImhqRUEfqhUoVBLh/Xsu3J0qoMURvpQprBVHd+/Cj6QGxMgG5lyAG6LIZmpadG /X05db/m2nzGovIfs7Eyo8iyIRcum3SwZXfE0jkZQt66mt9szRpLaGdY2H4hKwZn4+fU zPrkawR1kjgm4a1advT1Ofo7y/uF9YyR9B8no= Received: by 10.224.39.149 with SMTP id g21mr3243034qae.52.1264310161402; Sat, 23 Jan 2010 21:16:01 -0800 (PST) Received: from centel.dataix.local (ppp-21.4.dialinfree.com [209.172.21.4]) by mx.google.com with ESMTPS id 21sm3372677qyk.12.2010.01.23.21.15.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 21:15:55 -0800 (PST) Sender: "J. Hellenthal" Date: Sun, 24 Jan 2010 00:15:16 -0500 From: jhell To: Rich In-Reply-To: <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> Message-ID: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 05:16:02 -0000 On Sat, 23 Jan 2010 23:17, rincebrain@ wrote: >> Can you try the following please and then report back. >> >> Setting failmode to continue might let you continue a removal. >> zpool set failmode=continue what_is_it_rigatoni? >> >> This should be inherited by effected drives. >> zfs set checksum=off what_is_it_rigatoni? >> >> Remove the said effected files at this point. > > [root@manticore ~]# zpool set failmode=continue rigatoni > [root@manticore ~]# zfs set checksum=off rigatoni > [root@manticore ~]# mv > /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979 > /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo19791 > mv: rename /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979 > to /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo19791: > Input/output error > [root@manticore ~]# rm -f > /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979 > rm: /mirrors/geocities/from-asheesh-home/swebb3/www.geocities.com/JMcgo1979: > Input/output error > > :/ > > - Rich > I had my fingers crossed for you to... :( >From what I see and what was already mentioned earlier in this thread is meta data corruption but the checksum errors do not span across the whole pool of vdevs. These are, correct me if I am wrong USB mass storage devices ? SSD ? In the arrangement of the devices on the system are da2,4,5 on the same hub and da6,7 on another ? If this is the case you may have consolidated your errors down to being a USB problem and narrowed down to where they are connected to. What happened to da1,3 ? Were these once connected to the system ? and if so did you start noticing this problem occur roughly about the same period they were removed ? Will zpool(8) allow a removal of a vdevs in operation and copy the data to the leftover vdevs if there is free space ? As in: (maybe possibly with -f) zpool remove da2 zpool remove da4 zpool remove da5 Maybe if it is a possibility, replace each with another daN device if one is available and continue operations from this point to see if you can most likely rm the files in question as they are unlikely to be recoverable. Fingers crossed, -- jhell From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 05:28:57 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42ED7106566B for ; Sun, 24 Jan 2010 05:28:57 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id C5D908FC08 for ; Sun, 24 Jan 2010 05:28:56 +0000 (UTC) Received: by fxm26 with SMTP id 26so98315fxm.13 for ; Sat, 23 Jan 2010 21:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iBNFAIOksWlGJXAx95WMi+PXf3AKiPhvnv9+QALUzZA=; b=YAFL8iF+luxjTEeskvKlrtX3t1Ue3YtbwFPiD1QvArIozCxGkmuj28C8YY5lgBEYnS wR4AV1HAtG2eV36QftlhrQJ41CUBLg/y79M1t78q0djKBxxIP3kBo4FmlJ/PBJbGIPPx iPfETqhAAy05bVI67qCzBA0L21o5hTgJblgeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=A8FL3f0lS2W3byKv3nETl+k2qNL46fwadepBZyOzfuBSp8mp9akOLSGO9+ZmAXg2vk xsSno6Y4z5vwo/5179QYhcoOnBT6FKIJc9L50ETX+QWCm1cZ2lHUPoTMR9jc3IbjKFvC iXYtuiaaYIEBw5Tj7U9IY0QhUCAmVyZQ40PzU= MIME-Version: 1.0 Received: by 10.239.185.78 with SMTP id b14mr567093hbh.89.1264310935759; Sat, 23 Jan 2010 21:28:55 -0800 (PST) In-Reply-To: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> Date: Sun, 24 Jan 2010 00:28:55 -0500 Message-ID: <5da0588e1001232128w5a551674od0805c2ff0b884ad@mail.gmail.com> From: Rich To: jhell Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 05:28:57 -0000 On Sun, Jan 24, 2010 at 12:15 AM, jhell wrote: > From what I see and what was already mentioned earlier in this thread is > meta data corruption but the checksum errors do not span across the whole > pool of vdevs. These are, correct me if I am wrong USB mass storage devices > ? SSD ? 1.5T Seagate 7200RPM drives. > In the arrangement of the devices on the system are da2,4,5 on the same hub > and da6,7 on another ? If this is the case you may have consolidated your > errors down to being a USB problem and narrowed down to where they are > connected to. ...no. All five are on the same SATA controller. These behaviors persist independent of which SATA controller they are plugged into, and I've tried all seven in the machine. > What happened to da1,3 ? Were these once connected to the system ? and if so > did you start noticing this problem occur roughly about the same period they > were removed ? da1,3 are being used in another disk pool, and were never a part of this pool. This is not an issue of a faulty SATA controller or SATA drives. This is an issue of "there was a single faulty stick of RAM in the machine". I have sixteen disks in this machine. These three are having issues only on these particular files, and only on these files, not on random portions of the disk. The disks never report read errors - the ZFS layer is what reports them. SMART is not reporting any difficulties in reading any sectors of these disks. I could be mistaken, but I do not believe there to be a faulty controller in play at this time. I've rotated the drives among the spares of the 24 ports on the SATA controller in question, as well as the on-motherboard controller, and this behavior has persisted. - Rich From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 05:51:58 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F3331065672 for ; Sun, 24 Jan 2010 05:51:58 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by mx1.freebsd.org (Postfix) with ESMTP id EC21A8FC0A for ; Sun, 24 Jan 2010 05:51:57 +0000 (UTC) Received: by qyk39 with SMTP id 39so1379227qyk.27 for ; Sat, 23 Jan 2010 21:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=cSCoQyGyhPlNcbByJePmL188GZTugxmrzrJuU9zMcoQ=; b=GKQFCtehSDrwKXJxC//g8gRZMgg0qAMwGtd4VtkqAf/U6c9LCkJPixmuMsl43dTDc3 tEMR4tAWtNP1PduTmnZdy6C+FZ/fbGBuMm+tMMxf/d5lj3uZRdrUNSPgd+HAEJ5gU7ex CsKWXj70UlG71vG3AIF0rTJb7PwOnEvbPaOh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=yEOTn5WbgsDxalBrwK3oPchmWr/RwTPfVECQRc7KlphgHGFHW6p6zKCCj9FlAnuQnX SZKdyOK59NU2tZsYQuGduBRW7H8jfZbLKK3zz5Ey6KAaX9LIqJIIVETAuI5eF9xNS8zx HCQoStF+xn6+vYypTpy5/HvGam35KIHB27dMs= Received: by 10.224.81.204 with SMTP id y12mr3208857qak.358.1264312317178; Sat, 23 Jan 2010 21:51:57 -0800 (PST) Received: from centel.dataix.local (ppp-21.4.dialinfree.com [209.172.21.4]) by mx.google.com with ESMTPS id 20sm1540083qyk.13.2010.01.23.21.51.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 21:51:56 -0800 (PST) Sender: "J. Hellenthal" Date: Sun, 24 Jan 2010 00:51:13 -0500 From: jhell To: Rich In-Reply-To: <5da0588e1001232128w5a551674od0805c2ff0b884ad@mail.gmail.com> Message-ID: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> <5da0588e1001232128w5a551674od0805c2ff0b884ad@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 05:51:58 -0000 On Sun, 24 Jan 2010 00:28, rincebrain@ wrote: > On Sun, Jan 24, 2010 at 12:15 AM, jhell wrote: >> From what I see and what was already mentioned earlier in this thread is >> meta data corruption but the checksum errors do not span across the whole >> pool of vdevs. These are, correct me if I am wrong USB mass storage devices >> ? SSD ? > > 1.5T Seagate 7200RPM drives. > >> In the arrangement of the devices on the system are da2,4,5 on the same hub >> and da6,7 on another ? If this is the case you may have consolidated your >> errors down to being a USB problem and narrowed down to where they are >> connected to. > > ...no. > > All five are on the same SATA controller. These behaviors persist > independent of which SATA controller they are plugged into, and I've > tried all seven in the machine. > >> What happened to da1,3 ? Were these once connected to the system ? and if so >> did you start noticing this problem occur roughly about the same period they >> were removed ? > > da1,3 are being used in another disk pool, and were never a part of this pool. > > This is not an issue of a faulty SATA controller or SATA drives. > > This is an issue of "there was a single faulty stick of RAM in the machine". > Yeah I read this earlier, My apologies it slipped while I was writing "mind went into multi-write single read mode". > I have sixteen disks in this machine. These three are having issues > only on these particular files, and only on these files, not on random > portions of the disk. The disks never report read errors - the ZFS > layer is what reports them. SMART is not reporting any difficulties in > reading any sectors of these disks. > > > I could be mistaken, but I do not believe there to be a faulty > controller in play at this time. I've rotated the drives among the > spares of the 24 ports on the SATA controller in question, as well as > the on-motherboard controller, and this behavior has persisted. > > - Rich > As I was thinking earlier... you mentioned you scrubbed multiple times with no difference. When I was mentioning the attempt to remove/replace I was thinking this will cause a "re-silvering" of the drives possibly fixing meta-data for the effected disks if good meta-data still exists somewhere. Might be worth a shot but I would start with the replace of the devices that are showing the errors until you can clear the errors successfully without them showing up again and/or until you have replaced all disks. Best of luck. -- jhell From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 13:25:15 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D62591065676 for ; Sun, 24 Jan 2010 13:25:15 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 20AA38FC18 for ; Sun, 24 Jan 2010 13:25:15 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-214-156.shv.bellsouth.net [98.67.214.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id AC2FA86B0A06; Sun, 24 Jan 2010 07:25:13 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id o0ODP9fr016362; Sun, 24 Jan 2010 07:25:09 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Sun, 24 Jan 2010 07:25:09 -0600 (CST) From: Wes Morgan X-X-Sender: morganw@volatile To: jhell In-Reply-To: Message-ID: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> <5da0588e1001232128w5a551674od0805c2ff0b884ad@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.3 at warped X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org, Rich Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 13:25:16 -0000 On Sun, 24 Jan 2010, jhell wrote: > > On Sun, 24 Jan 2010 00:28, rincebrain@ wrote: > > On Sun, Jan 24, 2010 at 12:15 AM, jhell wrote: > > > From what I see and what was already mentioned earlier in this thread is > > > meta data corruption but the checksum errors do not span across the whole > > > pool of vdevs. These are, correct me if I am wrong USB mass storage > > > devices > > > ? SSD ? > > > > 1.5T Seagate 7200RPM drives. > > > > > In the arrangement of the devices on the system are da2,4,5 on the same > > > hub > > > and da6,7 on another ? If this is the case you may have consolidated your > > > errors down to being a USB problem and narrowed down to where they are > > > connected to. > > > > ...no. > > > > All five are on the same SATA controller. These behaviors persist > > independent of which SATA controller they are plugged into, and I've > > tried all seven in the machine. > > > > > What happened to da1,3 ? Were these once connected to the system ? and if > > > so > > > did you start noticing this problem occur roughly about the same period > > > they > > > were removed ? > > > > da1,3 are being used in another disk pool, and were never a part of this > > pool. > > > > This is not an issue of a faulty SATA controller or SATA drives. > > > > This is an issue of "there was a single faulty stick of RAM in the machine". > > > > Yeah I read this earlier, My apologies it slipped while I was writing "mind > went into multi-write single read mode". > > > I have sixteen disks in this machine. These three are having issues > > only on these particular files, and only on these files, not on random > > portions of the disk. The disks never report read errors - the ZFS > > layer is what reports them. SMART is not reporting any difficulties in > > reading any sectors of these disks. > > > > > > I could be mistaken, but I do not believe there to be a faulty > > controller in play at this time. I've rotated the drives among the > > spares of the 24 ports on the SATA controller in question, as well as > > the on-motherboard controller, and this behavior has persisted. > > > > - Rich > > > > As I was thinking earlier... you mentioned you scrubbed multiple times with no > difference. When I was mentioning the attempt to remove/replace I was thinking > this will cause a "re-silvering" of the drives possibly fixing meta-data for > the effected disks if good meta-data still exists somewhere. > > Might be worth a shot but I would start with the replace of the devices that > are showing the errors until you can clear the errors successfully without > them showing up again and/or until you have replaced all disks. This is a non-redundant pool. The remove command will not work. Replace will, but for that pool to function at all, *every* device must be present. If the metadata was recoverable, I think that the scrub would have reported "xxx kb repaired". >From http://dlc.sun.com/osol/docs/content/ZFSADMIN/gbbwl.html: If the object number to a file path cannot be successfully translated, either due to an error or because the object doesn't have a real file path associated with it , as is the case for a dnode_t, then the dataset name followed by the object's number is displayed. For example: monkey/dnode:<0x0> Which seems to be precisely your error. Continuing: Then, try removing the file with the rm command. If this command doesn't work, the corruption is within the file's metadata, and ZFS cannot determine which blocks belong to the file in order to remove the corruption. If the corruption is within a directory or a file's metadata, the only choice is to move the file elsewhere. You can safely move any file or directory to a less convenient location, allowing the original object to be restored in place." In other words, either move the files out of the way or restore the pool. I'd wager that any other filesystem would have simply wiped out entire directory trees or possibly just panicked with this kind of corruption. From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 13:44:34 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F4AD106566B for ; Sun, 24 Jan 2010 13:44:34 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCED8FC0C for ; Sun, 24 Jan 2010 13:44:33 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so557462fgg.13 for ; Sun, 24 Jan 2010 05:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JNNQyC5GDhg7Pb5VvcG/vBRl2siqK7BJGsw8jpOb4II=; b=CTARryoj36x7s+t5d00G4n7b0Is2IpFg9MvqAM0aqWdk5lCFLGD6/SakBU0UmT6xCS U1c+HD+3fjPqloipZj16eA6o95X39x8xbKkEWwOeMILNZQzZW8ALIvEfy4671f18Qh0P ffIoCXYL16Cvt1nI/1KmeCgCEp/pvY9N4vxBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Zllm3lgCfHolSI24vvY2vFvTN4L2UzEYe/7ngsYb6YGS9eFUOnWIDcDB7Tq83NrGnY 6KkQCMC0D6RmQwSi8qhlF6YmNGtklWcDIUG2fzLGFYNE264fa+iNYjLvhe8vNZ/Sa8Bs 0Mokk3ZENkAubmT6sT7jUsFQ2045jz24b2BeA= MIME-Version: 1.0 Received: by 10.239.163.67 with SMTP id o3mr588682hbd.22.1264340672804; Sun, 24 Jan 2010 05:44:32 -0800 (PST) In-Reply-To: References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> <5da0588e1001232128w5a551674od0805c2ff0b884ad@mail.gmail.com> Date: Sun, 24 Jan 2010 08:44:32 -0500 Message-ID: <5da0588e1001240544q61e3bebbka7ad1248343be26d@mail.gmail.com> From: Rich To: Wes Morgan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 13:44:34 -0000 > This is a non-redundant pool. The remove command will not work. Replace > will, but for that pool to function at all, *every* device must be > present. If the metadata was recoverable, I think that the scrub would > have reported "xxx kb repaired". Actually, zpool remove can't be used for that either - zpool detach gets used for anything that's "live". > From http://dlc.sun.com/osol/docs/content/ZFSADMIN/gbbwl.html: > > =A0 =A0If the object number to a file path cannot be successfully transla= ted, > =A0 =A0either due to an error or because the object doesn't have a real f= ile > =A0 =A0path associated with it , as is the case for a dnode_t, then the > =A0 =A0dataset name followed by the object's number is displayed. For > =A0 =A0example: > > =A0 =A0 monkey/dnode:<0x0> > > Which seems to be precisely your error. Continuing: > > =A0 =A0Then, try removing the file with the rm command. If this command > =A0 =A0doesn't work, the corruption is within the file's metadata, and ZF= S > =A0 =A0cannot determine which blocks belong to the file in order to remov= e > =A0 =A0the corruption. > > =A0 =A0If the corruption is within a directory or a file's metadata, the = only > =A0 =A0choice is to move the file elsewhere. You can safely move any file= or > =A0 =A0directory to a less convenient location, allowing the original obj= ect > =A0 =A0to be restored in place." > > In other words, either move the files out of the way or restore the pool. > I'd wager that any other filesystem would have simply wiped out entire > directory trees or possibly just panicked with this kind of corruption. I'm presuming you mean "to another FS", since we already saw rm reports EIE= IO. I've started that process, and I'll get out the backups for all the other d= ata. Thanks to everyone for being so helpful, and especially to you, Wes, for citing exactly what was going on with the manual. All hail manuals! :) - Rich From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 16:36:23 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C1E1106566B; Sun, 24 Jan 2010 16:36:23 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 037438FC0C; Sun, 24 Jan 2010 16:36:22 +0000 (UTC) Received: by ywh35 with SMTP id 35so2155988ywh.7 for ; Sun, 24 Jan 2010 08:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=i/+uDXn7ijsjDRMI+huRYoteHW8xWKP71eiWT2QtTwI=; b=XB5DGEvb22DO3uAcGFpTzF8+VqgdyknX3ERVi5zdtuvJajCWjxSwKlv2n1rswFcVlr XZ5OJp0ns7wOrDGTckhxS+jfMOR/Et2iQjUDEBnHQ4D/t+N9nr5SKO98KcYLsARBg0p/ sHZta9cRKYK4BOROZL0bhv8jdoREApwcQJIKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SmdO0NyTLyazmK8ukteUiPIdDrSe3JRmt41SOdrf/DH9VvBOpKR1Wwbxn+hup7o9wv jyvG34zoxkjvwFFHzJIl6CtHlu38DBqlij9Bb3CyreeFMGblF1Hf7awFv+GU7wqEpuOO ypaMXtb0imTmte4srJrrS70UPeDZgAKG7RuJ0= MIME-Version: 1.0 Received: by 10.100.235.36 with SMTP id i36mr3795152anh.104.1264350982055; Sun, 24 Jan 2010 08:36:22 -0800 (PST) Date: Sun, 24 Jan 2010 18:36:22 +0200 Message-ID: From: Dan Naumov To: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 16:36:23 -0000 Note: Since my issue is slow performance right off the bat and not performance degradation over time, I decided to start a separate discussion. After installing a fresh pure ZFS 8.0 system and building all my ports, I decided to do some benchmarking. At this point, about a dozen of ports has been built installed and the system has been up for about 11 hours, No heavy background services have been running, only SSHD and NTPD: ================================================================================== bonnie -s 8192: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 8192 23821 61.7 22311 19.2 13928 13.7 25029 49.6 44806 17.2 135.0 3.1 During the process, TOP looks like this: last pid: 83554; load averages: 0.31, 0.31, 0.37 up 0+10:59:01 17:24:19 33 processes: 2 running, 31 sleeping CPU: 0.1% user, 0.0% nice, 14.1% system, 0.7% interrupt, 85.2% idle Mem: 45M Active, 4188K Inact, 568M Wired, 144K Cache, 1345M Free Swap: 3072M Total, 3072M Free Oh wow, that looks low, alright, lets run it again, just to be sure: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 8192 18235 46.7 23137 19.9 13927 13.6 24818 49.3 44919 17.3 134.3 2.1 OK, let's reboot the machine and see what kind of numbers we get on a fresh boot: =============================================================== -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 8192 21041 53.5 22644 19.4 13724 12.8 25321 48.5 43110 14.0 143.2 3.3 Nope, no help from the reboot, still very low speed. Here is my pool: =============================================================== zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad10s1a ONLINE 0 0 0 ad8s1a ONLINE 0 0 0 =============================================================== diskinfo -c -t /dev/ad10 /dev/ad10 512 # sectorsize 2000398934016 # mediasize in bytes (1.8T) 3907029168 # mediasize in sectors 3876021 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. WD-WCAVY0301430 # Disk ident. I/O command overhead: time to read 10MB block 0.164315 sec = 0.008 msec/sector time to read 20480 sectors 3.030396 sec = 0.148 msec/sector calculated command overhead = 0.140 msec/sector Seek times: Full stroke: 250 iter in 7.309334 sec = 29.237 msec Half stroke: 250 iter in 5.156117 sec = 20.624 msec Quarter stroke: 500 iter in 8.147588 sec = 16.295 msec Short forward: 400 iter in 2.544309 sec = 6.361 msec Short backward: 400 iter in 2.007679 sec = 5.019 msec Seq outer: 2048 iter in 0.392994 sec = 0.192 msec Seq inner: 2048 iter in 0.332582 sec = 0.162 msec Transfer rates: outside: 102400 kbytes in 1.576734 sec = 64944 kbytes/sec middle: 102400 kbytes in 1.381803 sec = 74106 kbytes/sec inside: 102400 kbytes in 2.145432 sec = 47729 kbytes/sec =============================================================== diskinfo -c -t /dev/ad8 /dev/ad8 512 # sectorsize 2000398934016 # mediasize in bytes (1.8T) 3907029168 # mediasize in sectors 3876021 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. WD-WCAVY1611513 # Disk ident. I/O command overhead: time to read 10MB block 0.176820 sec = 0.009 msec/sector time to read 20480 sectors 2.966564 sec = 0.145 msec/sector calculated command overhead = 0.136 msec/sector Seek times: Full stroke: 250 iter in 7.993339 sec = 31.973 msec Half stroke: 250 iter in 5.944923 sec = 23.780 msec Quarter stroke: 500 iter in 9.744406 sec = 19.489 msec Short forward: 400 iter in 2.511171 sec = 6.278 msec Short backward: 400 iter in 2.233714 sec = 5.584 msec Seq outer: 2048 iter in 0.427523 sec = 0.209 msec Seq inner: 2048 iter in 0.341185 sec = 0.167 msec Transfer rates: outside: 102400 kbytes in 1.516305 sec = 67533 kbytes/sec middle: 102400 kbytes in 1.351877 sec = 75747 kbytes/sec inside: 102400 kbytes in 2.090069 sec = 48994 kbytes/sec =============================================================== The exact same disks, on the exact same machine, are well capable of 65+ mb/s throughput (tested with ATTO multiple times) with different block sizes using Windows 2008 Server and NTFS. So what would be the cause of these very low Bonnie result numbers in my case? Should I try some other benchmark and if so, with what parameters? - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 17:42:23 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577091065670; Sun, 24 Jan 2010 17:42:23 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id DFCC28FC1C; Sun, 24 Jan 2010 17:42:22 +0000 (UTC) Received: by yxe1 with SMTP id 1so2275433yxe.3 for ; Sun, 24 Jan 2010 09:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=j88x6XhvR75nuWm2yTKP7/tyUJkjzQo0D5wtSP5t/Gs=; b=NH2HzacZQP2uCFh5RJWrbwrJrlt8RcQ5rex70CUV4KW8vReXnVG0sESFFh6wQBuzA9 r6wIFcX+QUSMFBdbGpZ0FeRer3PQnqsTWp+5PJWXA9VFqD2vszEkVMMlF4CF+oAxLRmM 3y+4TBhF2sxcUyHlYofpJf9ODXk/eF1HMuBN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=cO7S2cshb89hsDgyAqO9AzCVXz6C+xdAI/1JC1SmD1cESNpsUqHKAPShRTE3cKyGvY VVAv/Ez07pniyN8THgxN+uHSgMxU2vXcbnzqZedZNRztIa4KPo7CyFZzmyv/HMqHAZpf wBTYDvk9GXaO7O7EDLL41VJYTdG8jVszUFebI= MIME-Version: 1.0 Received: by 10.101.6.22 with SMTP id j22mr6557167ani.224.1264354942041; Sun, 24 Jan 2010 09:42:22 -0800 (PST) In-Reply-To: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> Date: Sun, 24 Jan 2010 19:42:22 +0200 Message-ID: From: Dan Naumov To: Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 17:42:23 -0000 On Sun, Jan 24, 2010 at 7:05 PM, Jason Edwards wrote: > Hi Dan, > > I read on FreeBSD mailinglist you had some performance issues with ZFS. > Perhaps i can help you with that. > > You seem to be running a single mirror, which means you won't have any speed > benefit regarding writes, and usually RAID1 implementations offer little to > no acceleration to read requests also; some even just read from the master > disk and don't touch the 'slave' mirrored disk unless when writing. ZFS is > alot more modern however, although i did not test performance of its mirror > implementation. > > But, benchmarking I/O can be tricky: > > 1) you use bonnie, but bonnie's tests are performed without a 'cooldown' > period between the tests; meaning that when test 2 starts, data from test 1 > is still being processed. For single disks and simple I/O this is not so > bad, but for large write-back buffers and more complex I/O buffering, this > may be inappropriate. I had patched bonnie some time in the past, but if you > just want a MB/s number you can use DD for that. > > 2) The diskinfo tiny benchmark is single queue only i assume, meaning that > it would not scale well or at all on RAID-arrays. Actual filesystems on > RAID-arrays use multiple-queue; meaning it would not read one sector at a > time, but read 8 blocks (of 16KiB) "ahead"; this is called read-ahead and > for traditional UFS filesystems its controlled by the sysctl vfs.read_max > variable. ZFS works differently though, but you still need a "real" > benchmark. > > 3) You need low-latency hardware; in particular, no PCI controller should be > used. Only PCI-express based controllers or chipset-integrated Serial ATA > cotrollers have proper performance. PCI can hurt performance very badly, and > has high interrupt CPU usage. Generally you should avoid PCI. PCI-express is > fine though, its a completely different interface that is in many ways the > opposite of what PCI was. > > 4) Testing actual realistic I/O performance (in IOps) is very difficult. But > testing sequential performance should be alot easier. You may try using dd > for this. > > > For example, you can use dd on raw devices: > > dd if=/dev/ad4 of=/dev/null bs=1M count=1000 > > I will explain each parameter: > > if=/dev/ad4 is the input file, the "read source" > > of=/dev/null is the output file, the "write destination". /dev/null means it > just goes no-where; so this is a read-only benchmark > > bs=1M is the blocksize, howmuch data to transfer per time. default is 512 or > the sector size; but that's very slow. A value between 64KiB and 1024KiB is > appropriate. bs=1M will select 1MiB or 1024KiB. > > count=1000 means transfer 1000 pieces, and with bs=1M that means 1000 * 1MiB > = 1000MiB. > > > > This example was raw reading sequentially from the start of the device > /dev/ad4. If you want to test RAIDs, you need to work at the filesystem > level. You can use dd for that too: > > dd if=/dev/zero of=/path/to/ZFS/mount/zerofile.000 bs=1M count=2000 > > This command will read from /dev/zero (all zeroes) and write to a file on > ZFS-mounted filesystem, it will create the file "zerofile.000" and write > 2000MiB of zeroes to that file. > So this command tests write-performance of the ZFS-mounted filesystem. To > test read performance, you need to clear caches first by unmounting that > filesystem and re-mounting it again. This would free up memory containing > parts of the filesystem as cached (reported in top as "Inact(ive)" instead > of "Free"). > > Please do make sure you double-check a dd command before running it, and run > as normal user instead of root. A wrong dd command may write to the wrong > destination and do things you don't want. The only real thing you need to > check is the write destination (of=....). That's where dd is going to write > to, so make sure its the target you intended. A common mistake made by > myself was to write dd of=... if=... (starting with of instead of if) and > thus actually doing something the other way around than what i was meant to > do. This can be disastrous if you work with live data, so be careful! ;-) > > Hope any of this was helpful. During the dd benchmark, you can of course > open a second SSH terminal and start "gstat" to see the devices current I/O > stats. > > Kind regards, > Jason Hi and thanks for your tips, I appreciate it :) [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test1 bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 36.206372 secs (29656156 bytes/sec) [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test2 bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec) This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the bonnie results. It also sadly seems to confirm the very slow speed :( The disks are attached to a 4-port Sil3124 controller and again, my Windows benchmarks showing 65mb/s+ were done on exact same machine, with same disks attached to the same controller. Only difference was that in Windows the disks weren't in a mirror configuration but were tested individually. I do understand that a mirror setup offers roughly the same write speed as individual disk, while the read speed usually varies from "equal to individual disk speed" to "nearly the throughput of both disks combined" depending on the implementation, but there is no obvious reason I am seeing why my setup offers both read and write speeds roughly 1/3 to 1/2 of what the individual disks are capable of. Dmesg shows: atapci0: port 0x1000-0x100f mem 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on pci4 ad8: 1907729MB at ata4-master SATA300 ad10: 1907729MB at ata5-master SATA300 I do recall also testing an alternative configuration in the past, where I would boot off an UFS disk and have the ZFS mirror consist of 2 discs directly. The bonnie numbers in that case were in line with my expectations, I was seeing 65-70mb/s. Note: again, exact same hardware, exact same disks attached to the exact same controller. In my knowledge, Solaris/OpenSolaris has an issue where they have to automatically disable disk cache if ZFS is used on top of partitions instead of raw disks, but to my knowledge (I recall reading this from multiple reputable sources) this issue does not affect FreeBSD. - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 17:52:24 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE28E106566C for ; Sun, 24 Jan 2010 17:52:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A4A308FC0A for ; Sun, 24 Jan 2010 17:52:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANcXXEuDaFvK/2dsb2JhbADULYQ7BA X-IronPort-AV: E=Sophos;i="4.49,335,1262581200"; d="scan'208";a="62764292" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 24 Jan 2010 12:52:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id E509E109C28B; Sun, 24 Jan 2010 12:52:22 -0500 (EST) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0r+vmC1OWPT; Sun, 24 Jan 2010 12:52:22 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 72E0B109C285; Sun, 24 Jan 2010 12:52:22 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o0OI31P23975; Sun, 24 Jan 2010 13:03:02 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 24 Jan 2010 13:03:01 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Paride Legovini In-Reply-To: <20100124021318.GA1881@ninthfloor.org> Message-ID: References: <20100124021318.GA1881@ninthfloor.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: Can't export using nfs4 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 17:52:25 -0000 On Sun, 24 Jan 2010, Paride Legovini wrote: > > Then I have a couple of trivial exports: > > # cat /etc/exports > V4: /usr > /home > The "V4: /usr" only says that "/usr" is the root of the NFSv4 tree and defines what hosts are allowed to perform NFSv4 state (read lock) related Ops. (These don't use a file/filehandle, so they aren't directly related to what file system(s) are exported.) You still need to export /usr, for example: V4: /usr /usr /home rick ps: The rest looked ok, although I'm not sure what showmount will say, since it uses the Mount protocol, which NFSv4 doesn't use. pss: You should have nfsuserd, mountd and nfsd running and both mountd and nfsd should have the "-e" option. "ps axl" should show that mountd had the "-e" and, if that's the case, nfsd should have gotten it too. From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 18:12:31 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8994D106568D; Sun, 24 Jan 2010 18:12:31 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 1F9728FC0A; Sun, 24 Jan 2010 18:12:30 +0000 (UTC) Received: by ywh35 with SMTP id 35so2189749ywh.7 for ; Sun, 24 Jan 2010 10:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Nudg+xoe53eItQvs+LtVZir/9Twc7UMwOIIF8NZIsgM=; b=ZRf6dBnvdGEUdr0v09fxRZJNHAokhpKN/nvlt0N3hnFR9w5DqTPV552wYi5Yat3npp SDYb0DVgP678/UtCaEK5JFyP3daj1nv2/n8uMwHKT3MS9BnEL8Ocfn5lfVDQsE8jvI3Q RVXzXpTbxBI87YPlVNrt5geZ4x877uLiVmfyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=rUJ/STK6QLdsQzCXy8kDc/qaR25SFK4zcrq2oVZwD0vxqprTFmRcyWUhMaHBNL2O1O u7N6+Vcnje1HN0SNK1VjJXaLq+Zw1lYP20N6ZGCSAznkkWMwQo6HSawNs7N8lnhekRMt VUwO8JVoQQohG/x5eX0yWXkcSk3FYknvPmQYQ= MIME-Version: 1.0 Received: by 10.101.135.23 with SMTP id m23mr6524863ann.222.1264356750021; Sun, 24 Jan 2010 10:12:30 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> Date: Sun, 24 Jan 2010 20:12:29 +0200 Message-ID: From: Dan Naumov To: Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 18:12:31 -0000 On Sun, Jan 24, 2010 at 7:42 PM, Dan Naumov wrote: > On Sun, Jan 24, 2010 at 7:05 PM, Jason Edwards wrote: >> Hi Dan, >> >> I read on FreeBSD mailinglist you had some performance issues with ZFS. >> Perhaps i can help you with that. >> >> You seem to be running a single mirror, which means you won't have any speed >> benefit regarding writes, and usually RAID1 implementations offer little to >> no acceleration to read requests also; some even just read from the master >> disk and don't touch the 'slave' mirrored disk unless when writing. ZFS is >> alot more modern however, although i did not test performance of its mirror >> implementation. >> >> But, benchmarking I/O can be tricky: >> >> 1) you use bonnie, but bonnie's tests are performed without a 'cooldown' >> period between the tests; meaning that when test 2 starts, data from test 1 >> is still being processed. For single disks and simple I/O this is not so >> bad, but for large write-back buffers and more complex I/O buffering, this >> may be inappropriate. I had patched bonnie some time in the past, but if you >> just want a MB/s number you can use DD for that. >> >> 2) The diskinfo tiny benchmark is single queue only i assume, meaning that >> it would not scale well or at all on RAID-arrays. Actual filesystems on >> RAID-arrays use multiple-queue; meaning it would not read one sector at a >> time, but read 8 blocks (of 16KiB) "ahead"; this is called read-ahead and >> for traditional UFS filesystems its controlled by the sysctl vfs.read_max >> variable. ZFS works differently though, but you still need a "real" >> benchmark. >> >> 3) You need low-latency hardware; in particular, no PCI controller should be >> used. Only PCI-express based controllers or chipset-integrated Serial ATA >> cotrollers have proper performance. PCI can hurt performance very badly, and >> has high interrupt CPU usage. Generally you should avoid PCI. PCI-express is >> fine though, its a completely different interface that is in many ways the >> opposite of what PCI was. >> >> 4) Testing actual realistic I/O performance (in IOps) is very difficult. But >> testing sequential performance should be alot easier. You may try using dd >> for this. >> >> >> For example, you can use dd on raw devices: >> >> dd if=/dev/ad4 of=/dev/null bs=1M count=1000 >> >> I will explain each parameter: >> >> if=/dev/ad4 is the input file, the "read source" >> >> of=/dev/null is the output file, the "write destination". /dev/null means it >> just goes no-where; so this is a read-only benchmark >> >> bs=1M is the blocksize, howmuch data to transfer per time. default is 512 or >> the sector size; but that's very slow. A value between 64KiB and 1024KiB is >> appropriate. bs=1M will select 1MiB or 1024KiB. >> >> count=1000 means transfer 1000 pieces, and with bs=1M that means 1000 * 1MiB >> = 1000MiB. >> >> >> >> This example was raw reading sequentially from the start of the device >> /dev/ad4. If you want to test RAIDs, you need to work at the filesystem >> level. You can use dd for that too: >> >> dd if=/dev/zero of=/path/to/ZFS/mount/zerofile.000 bs=1M count=2000 >> >> This command will read from /dev/zero (all zeroes) and write to a file on >> ZFS-mounted filesystem, it will create the file "zerofile.000" and write >> 2000MiB of zeroes to that file. >> So this command tests write-performance of the ZFS-mounted filesystem. To >> test read performance, you need to clear caches first by unmounting that >> filesystem and re-mounting it again. This would free up memory containing >> parts of the filesystem as cached (reported in top as "Inact(ive)" instead >> of "Free"). >> >> Please do make sure you double-check a dd command before running it, and run >> as normal user instead of root. A wrong dd command may write to the wrong >> destination and do things you don't want. The only real thing you need to >> check is the write destination (of=....). That's where dd is going to write >> to, so make sure its the target you intended. A common mistake made by >> myself was to write dd of=... if=... (starting with of instead of if) and >> thus actually doing something the other way around than what i was meant to >> do. This can be disastrous if you work with live data, so be careful! ;-) >> >> Hope any of this was helpful. During the dd benchmark, you can of course >> open a second SSH terminal and start "gstat" to see the devices current I/O >> stats. >> >> Kind regards, >> Jason > > Hi and thanks for your tips, I appreciate it :) > > [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test1 bs=1M count=1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 36.206372 secs (29656156 bytes/sec) > > [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test2 bs=1M count=4096 > 4096+0 records in > 4096+0 records out > 4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec) > > This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and > 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the > bonnie results. It also sadly seems to confirm the very slow speed :( > The disks are attached to a 4-port Sil3124 controller and again, my > Windows benchmarks showing 65mb/s+ were done on exact same machine, > with same disks attached to the same controller. Only difference was > that in Windows the disks weren't in a mirror configuration but were > tested individually. I do understand that a mirror setup offers > roughly the same write speed as individual disk, while the read speed > usually varies from "equal to individual disk speed" to "nearly the > throughput of both disks combined" depending on the implementation, > but there is no obvious reason I am seeing why my setup offers both > read and write speeds roughly 1/3 to 1/2 of what the individual disks > are capable of. Dmesg shows: > > atapci0: port 0x1000-0x100f mem > 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on > pci4 > ad8: 1907729MB at ata4-master SATA300 > ad10: 1907729MB at ata5-master SATA300 > > I do recall also testing an alternative configuration in the past, > where I would boot off an UFS disk and have the ZFS mirror consist of > 2 discs directly. The bonnie numbers in that case were in line with my > expectations, I was seeing 65-70mb/s. Note: again, exact same > hardware, exact same disks attached to the exact same controller. In > my knowledge, Solaris/OpenSolaris has an issue where they have to > automatically disable disk cache if ZFS is used on top of partitions > instead of raw disks, but to my knowledge (I recall reading this from > multiple reputable sources) this issue does not affect FreeBSD. > > - Sincerely, > Dan Naumov To add some additional info, for good measure I decided to check if disk write cache is enabled and sure enough it was: [jago@atombsd /var/log]$ sysctl hw.ata hw.ata.setmax: 0 hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma_check_80pin: 1 hw.ata.ata_dma: 1 Also if you want to see/know the exact way the system was built and installed, here is the build script I used: http://jago.pp.fi/zfsinst.sh The reason me (and this script) use MBR partitioning instead of GPT is because my motherboard cannot reliably boot off GPT, but this should not be really relevant to the performance issues shown. - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 18:12:36 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F93106568B for ; Sun, 24 Jan 2010 18:12:36 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 14B7D8FC21 for ; Sun, 24 Jan 2010 18:12:35 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o0OICYOP020782; Sun, 24 Jan 2010 12:12:35 -0600 (CST) Date: Sun, 24 Jan 2010 12:12:34 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Dan Naumov In-Reply-To: Message-ID: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Sun, 24 Jan 2010 12:12:35 -0600 (CST) Cc: freebsd-fs@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 18:12:36 -0000 On Sun, 24 Jan 2010, Dan Naumov wrote: > > This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and > 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the > bonnie results. It also sadly seems to confirm the very slow speed :( > The disks are attached to a 4-port Sil3124 controller and again, my > Windows benchmarks showing 65mb/s+ were done on exact same machine, > with same disks attached to the same controller. Only difference was > that in Windows the disks weren't in a mirror configuration but were > tested individually. I do understand that a mirror setup offers > roughly the same write speed as individual disk, while the read speed > usually varies from "equal to individual disk speed" to "nearly the > throughput of both disks combined" depending on the implementation, > but there is no obvious reason I am seeing why my setup offers both > read and write speeds roughly 1/3 to 1/2 of what the individual disks > are capable of. Dmesg shows: There is a mistatement in the above in that a "mirror setup offers roughly the same write speed as individual disk". It is possible for a mirror setup to offer a similar write speed to an individual disk, but it is also quite possible to get 1/2 (or even 1/3) the speed. ZFS writes to a mirror pair requires two independent writes. If these writes go down independent I/O paths, then there is hardly any overhead from the 2nd write. If the writes go through a bandwidth-limited shared path then they will contend for that bandwidth and you will see much less write performance. As a simple test, you can temporarily remove the mirror device from the pool and see if the write performance dramatically improves. Before doing that, it is useful to see the output of 'iostat -x 30' while under heavy write load to see if one device shows a much higher svc_t value than the other. > expectations, I was seeing 65-70mb/s. Note: again, exact same > hardware, exact same disks attached to the exact same controller. In > my knowledge, Solaris/OpenSolaris has an issue where they have to > automatically disable disk cache if ZFS is used on top of partitions > instead of raw disks, but to my knowledge (I recall reading this from > multiple reputable sources) this issue does not affect FreeBSD. Does FreeBSD always enable the disk write caches? Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 18:29:54 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E4B3106568D; Sun, 24 Jan 2010 18:29:54 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id A40A48FC17; Sun, 24 Jan 2010 18:29:53 +0000 (UTC) Received: by ywh35 with SMTP id 35so2195803ywh.7 for ; Sun, 24 Jan 2010 10:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Jd59GblytqTsj/A2jL+22mSk53JxWa7kKpN2Tgprzag=; b=fJgnzGR/GnQ1t0OKMUyoXZkAoPpLFO3lPDjBTvvAP7Pa/eNs9edsqR+fpAObo7R1s4 TdgieZBAfaiTRbntM5vFqyuj1/+GYRFZa89XQowAgSsUP4JsCwrl66qzILFqjhSuI3vK 7+FWh/UZStxlHbEeByew33jvhYweVqf1S8Nmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W9lTWgQ4payHtP/RFPn1cchDjsPrvIwRzSdhPO4wyAQJGnIyVZ+5O0WSGqq4wV/R2e /sKogAa96O7PgkgzNMgIIiLoMzfwbYK+xqpGzZmzFcw5By8iAP+5RTDlaR5FAmzOFK54 Pu6HOpQcJKrlY+ijAA58U6HqgHfE587eKxIOM= MIME-Version: 1.0 Received: by 10.101.12.6 with SMTP id p6mr6559698ani.248.1264357792623; Sun, 24 Jan 2010 10:29:52 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> Date: Sun, 24 Jan 2010 20:29:52 +0200 Message-ID: From: Dan Naumov To: Bob Friesenhahn , sub.mesa@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 18:29:54 -0000 On Sun, Jan 24, 2010 at 8:12 PM, Bob Friesenhahn wrote: > On Sun, 24 Jan 2010, Dan Naumov wrote: >> >> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and >> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the >> bonnie results. It also sadly seems to confirm the very slow speed :( >> The disks are attached to a 4-port Sil3124 controller and again, my >> Windows benchmarks showing 65mb/s+ were done on exact same machine, >> with same disks attached to the same controller. Only difference was >> that in Windows the disks weren't in a mirror configuration but were >> tested individually. I do understand that a mirror setup offers >> roughly the same write speed as individual disk, while the read speed >> usually varies from "equal to individual disk speed" to "nearly the >> throughput of both disks combined" depending on the implementation, >> but there is no obvious reason I am seeing why my setup offers both >> read and write speeds roughly 1/3 to 1/2 of what the individual disks >> are capable of. Dmesg shows: > > There is a mistatement in the above in that a "mirror setup offers roughl= y > the same write speed as individual disk". =A0It is possible for a mirror = setup > to offer a similar write speed to an individual disk, but it is also quit= e > possible to get 1/2 (or even 1/3) the speed. ZFS writes to a mirror pair > requires two independent writes. =A0If these writes go down independent I= /O > paths, then there is hardly any overhead from the 2nd write. =A0If the wr= ites > go through a bandwidth-limited shared path then they will contend for tha= t > bandwidth and you will see much less write performance. > > As a simple test, you can temporarily remove the mirror device from the p= ool > and see if the write performance dramatically improves. Before doing that= , > it is useful to see the output of 'iostat -x 30' while under heavy write > load to see if one device shows a much higher svc_t value than the other. Ow, ow, WHOA: atombsd# zpool offline tank ad8s1a [jago@atombsd ~]$ dd if=3D/dev/zero of=3D/home/jago/test3 bs=3D1M count=3D1= 024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 16.826016 secs (63814382 bytes/sec) Offlining one half of the mirror bumps DD write speed from 28mb/s to 64mb/s! Let's see how Bonnie results change: Mirror with both parts attached: -------Sequential Output-------- ---Sequential Input-- --Rand= om-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seek= s--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec = %CPU 8192 18235 46.7 23137 19.9 13927 13.6 24818 49.3 44919 17.3 134.3 = 2.1 Mirror with 1 half offline: -------Sequential Output-------- ---Sequential Input-- --Rand= om-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seek= s--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec = %CPU 1024 22888 58.0 41832 35.1 22764 22.0 26775 52.3 54233 18.3 166.0 = 1.6 Ok, the Bonnie results have improved, but only very little. - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 18:40:37 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ADBF106566C; Sun, 24 Jan 2010 18:40:37 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id CFA748FC18; Sun, 24 Jan 2010 18:40:36 +0000 (UTC) Received: by ywh35 with SMTP id 35so2199414ywh.7 for ; Sun, 24 Jan 2010 10:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cYTS0m2zo4yDD/C80NV/kKNkjUleB0nYq6cDz3m1o8M=; b=E/QHnw9cxELemG6LgKrCQFM00BIeOJXlPkCLLH7bNWlgqbmNLl95XVNSie0qyuFBGt ak510/HzecvrOJg+q7TJpoobuntrIl0o0A+HM+9FIcNC+yrA2AtxSFyfSnUTiatyN2xw QW06WJsoILZcAjyLjPI27iCMpw8JpBftAOuRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=McVl6IfCbStweIGUId0p5GYs2NDRQnZfA1tzwHQ4QcA5KKsoBb4f9oKiWRc3HdXftV 9VRwxZO786iWEOOvqUU3lht82fN4Yts15TFkg4Ghcsm5dfCcGkdhor15ubMc/JrB2HL1 8s/vXLjqqAvey+UrP2bOMluaxJ6sKYt9MUQMw= MIME-Version: 1.0 Received: by 10.101.133.37 with SMTP id k37mr6619685ann.237.1264358436052; Sun, 24 Jan 2010 10:40:36 -0800 (PST) In-Reply-To: <883b2dc51001241034u40c97fdet83eb1e6edb5f4df4@mail.gmail.com> References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <883b2dc51001241034u40c97fdet83eb1e6edb5f4df4@mail.gmail.com> Date: Sun, 24 Jan 2010 20:40:36 +0200 Message-ID: From: Dan Naumov To: Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 18:40:37 -0000 On Sun, Jan 24, 2010 at 8:34 PM, Jason Edwards wrote: >> ZFS writes to a mirror pair >> requires two independent writes. =A0If these writes go down independent = I/O >> paths, then there is hardly any overhead from the 2nd write. =A0If the >> writes >> go through a bandwidth-limited shared path then they will contend for th= at >> bandwidth and you will see much less write performance. > > What he said may confirm my suspicion on PCI. So if you could try the sam= e > with "real" Serial ATA via chipset or PCI-e controller you can confirm th= is > story. I would be very interested. :P > > Kind regards, > Jason This wouldn't explain why ZFS mirror on 2 disks directly, on the exact same controller (with the OS running off a separate disks) results in "expected" performance, while having the OS run off/on a ZFS mirror running on top of MBR-partitioned disks, on the same controller, results in very low speed. - Dan From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 22:22:22 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1764106568D for ; Sun, 24 Jan 2010 22:22:22 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 5C60F8FC0A for ; Sun, 24 Jan 2010 22:22:22 +0000 (UTC) Received: by fxm26 with SMTP id 26so504887fxm.13 for ; Sun, 24 Jan 2010 14:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:newsgroups:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EsVLB3AoYxVdcmOhg/E17qMGAwiszH33kOdv6DLGnkc=; b=KeZs8mx3sPtgIvFFstTBBUMInJngHEd+n5wrAaq/qEI/euXhjn4bJEgr1+ylmhClRE 9YsrBQduyrTPWC45Ut3EnusLxqw5hyfxuRv0LRrnvINCLKde0Ia1tajIVk/uQiFlXKvm EwXY0pZ0rD8QFyMHoTYuTTD7mT8KJoElhrSts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:newsgroups:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; b=DG3i9KcESzUrIT7CyydH8AUK9G+opbU/AauE4kC2h4h5vL1F/2q4JqJIg7uZHyTZNF d+Jg2MIF3N1mNz+3nnTobUvW5vI9PvaSejp751QbMx7kp4eNk3DgoxtjiDh9yr/u6Qiu oYflKNK6cosVrMSRCknDJG+YVqe/vFdZH6UzM= Received: by 10.223.92.142 with SMTP id r14mr5880299fam.93.1264370080984; Sun, 24 Jan 2010 13:54:40 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2415845fxm.8.2010.01.24.13.54.39 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 13:54:40 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5CC167.5010604@FreeBSD.org> Date: Sun, 24 Jan 2010 23:53:43 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 Newsgroups: lucky.freebsd.fs,lucky.freebsd.questions,lucky.freebsd.stable To: Dan Naumov References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> In-Reply-To: <1264368182.00211075.1264355402@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 22:22:23 -0000 Dan Naumov wrote: > This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and > 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the > bonnie results. It also sadly seems to confirm the very slow speed :( > The disks are attached to a 4-port Sil3124 controller and again, my > Windows benchmarks showing 65mb/s+ were done on exact same machine, > with same disks attached to the same controller. Only difference was > that in Windows the disks weren't in a mirror configuration but were > tested individually. I do understand that a mirror setup offers > roughly the same write speed as individual disk, while the read speed > usually varies from "equal to individual disk speed" to "nearly the > throughput of both disks combined" depending on the implementation, > but there is no obvious reason I am seeing why my setup offers both > read and write speeds roughly 1/3 to 1/2 of what the individual disks > are capable of. Dmesg shows: > > atapci0: port 0x1000-0x100f mem > 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on > pci4 > ad8: 1907729MB at ata4-master SATA300 > ad10: 1907729MB at ata5-master SATA300 8.0-RELEASE, and especially 8-STABLE provide alternative, much more functional driver for this controller, named siis(4). If your SiI3124 card installed into proper bus (PCI-X or PCIe x4/x8), it can be really fast (up to 1GB/s was measured). -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 22:46:26 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2ECF106566B; Sun, 24 Jan 2010 22:46:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AA5A68FC08; Sun, 24 Jan 2010 22:46:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0OMkQJ5065849; Sun, 24 Jan 2010 22:46:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0OMkQwc065845; Sun, 24 Jan 2010 22:46:26 GMT (envelope-from linimon) Date: Sun, 24 Jan 2010 22:46:26 GMT Message-Id: <201001242246.o0OMkQwc065845@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143184: [zfs] [lor] zfs/bufwait LOR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 22:46:26 -0000 Synopsis: [zfs] [lor] zfs/bufwait LOR Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 24 22:46:13 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143184 From owner-freebsd-fs@FreeBSD.ORG Sun Jan 24 23:30:06 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B71106568D for ; Sun, 24 Jan 2010 23:30:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D9FC08FC2A for ; Sun, 24 Jan 2010 23:30:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0ONU5G8000228 for ; Sun, 24 Jan 2010 23:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0ONU5gs000227; Sun, 24 Jan 2010 23:30:05 GMT (envelope-from gnats) Date: Sun, 24 Jan 2010 23:30:05 GMT Message-Id: <201001242330.o0ONU5gs000227@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Pedro F. Giffuni" Cc: Subject: Re: kern/142924: Small cleanup for the inode struct in ext2fs (based on UFS) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Pedro F. Giffuni" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 23:30:06 -0000 The following reply was made to PR kern/142924; it has been noted by GNATS. From: "Pedro F. Giffuni" To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/142924: Small cleanup for the inode struct in ext2fs (based on UFS) Date: Sun, 24 Jan 2010 15:20:12 -0800 (PST) --0-1285154270-1264375212=:24175 Content-Type: text/plain; charset=us-ascii I added the equivalent to ufs_lookup.c 1.34: Bug fixes for currently harmless bugs that could rise to bite the unwary if the code were called in slightly different ways. - In ufs_lookup() there is an off-by-one error in the test that checks if dp->i_diroff is outside the range of the the current directory size. This is completely harmless, since the following while-loop condition 'dp->i_offset < endsearch' is never met, so the code immediately does a second pass starting at dp->i_offset = 0. - Again in ufs_lookup(), the condition in a sanity check is wrong for directories that are longer than one block. This bug means that --0-1285154270-1264375212=:24175 Content-Type: application/octet-stream; name=patch-ext2fs Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=patch-ext2fs ZGlmZiAtcnUgZXh0MmZzLmJzZC9leHQyX2xvb2t1cC5jIGV4dDJmcy9leHQy X2xvb2t1cC5jCi0tLSBleHQyZnMuYnNkL2V4dDJfbG9va3VwLmMJMjAxMC0w MS0xNyAxOTowMjozMC4wMDAwMDAwMDAgKzAwMDAKKysrIGV4dDJmcy9leHQy X2xvb2t1cC5jCTIwMTAtMDEtMjQgMTg6MTA6MTIuMDAwMDAwMDAwICswMDAw CkBAIC0zNDcsNiArMzQ3LDcgQEAKIAkJc2xvdG5lZWRlZCA9IChzaXplb2Yo c3RydWN0IGRpcmVjdCkgLSBNQVhOQU1MRU4gKwogCQkJY25wLT5jbl9uYW1l bGVuICsgMykgJn4gMzsgKi8KIAl9CisJYm1hc2sgPSBWRlNUT0VYVDIodmRw LT52X21vdW50KS0+dW1fbW91bnRwLT5tbnRfc3RhdC5mX2lvc2l6ZSAtIDE7 CiAKIAkvKgogCSAqIElmIHRoZXJlIGlzIGNhY2hlZCBpbmZvcm1hdGlvbiBv biBhIHByZXZpb3VzIHNlYXJjaCBvZgpAQCAtMzU5LDkgKzM2MCw4IEBACiAJ ICogcHJvZmlsaW5nIHRpbWUgYW5kIGhlbmNlIGhhcyBiZWVuIHJlbW92ZWQg aW4gdGhlIGludGVyZXN0CiAJICogb2Ygc2ltcGxpY2l0eS4KIAkgKi8KLQli bWFzayA9IFZGU1RPRVhUMih2ZHAtPnZfbW91bnQpLT51bV9tb3VudHAtPm1u dF9zdGF0LmZfaW9zaXplIC0gMTsKIAlpZiAobmFtZWlvcCAhPSBMT09LVVAg fHwgaV9kaXJvZmYgPT0gMCB8fAotCSAgICBpX2Rpcm9mZiA+IGRwLT5pX3Np emUpIHsKKwkgICAgaV9kaXJvZmYgPj0gZHAtPmlfc2l6ZSkgewogCQllbnRy eW9mZnNldGluYmxvY2sgPSAwOwogCQlpX29mZnNldCA9IDA7CiAJCW51bWRp cnBhc3NlcyA9IDE7CkBAIC01NTAsMTAgKzU1MCwxMCBAQAogCSAqIENoZWNr IHRoYXQgZGlyZWN0b3J5IGxlbmd0aCBwcm9wZXJseSByZWZsZWN0cyBwcmVz ZW5jZQogCSAqIG9mIHRoaXMgZW50cnkuCiAJICovCi0JaWYgKGVudHJ5b2Zm c2V0aW5ibG9jayArIEVYVDJfRElSX1JFQ19MRU4oZXAtPmUyZF9uYW1sZW4p CisJaWYgKGRwLT5pX29mZnNldCArIEVYVDJfRElSX1JFQ19MRU4oZXAtPmUy ZF9uYW1sZW4pCiAJCT4gZHAtPmlfc2l6ZSkgewogCQlleHQyX2RpcmJhZChk cCwgaV9vZmZzZXQsICJpX3NpemUgdG9vIHNtYWxsIik7Ci0JCWRwLT5pX3Np emUgPSBlbnRyeW9mZnNldGluYmxvY2srRVhUMl9ESVJfUkVDX0xFTihlcC0+ ZTJkX25hbWxlbik7CisJCWRwLT5pX3NpemUgPSBkcC0+aV9vZmZzZXQrRVhU Ml9ESVJfUkVDX0xFTihlcC0+ZTJkX25hbWxlbik7CiAJCWRwLT5pX2ZsYWcg fD0gSU5fQ0hBTkdFIHwgSU5fVVBEQVRFOwogCX0KIAlicmVsc2UoYnApOwpk aWZmIC1ydSBleHQyZnMuYnNkL2V4dDJfdmZzb3BzLmMgZXh0MmZzL2V4dDJf dmZzb3BzLmMKLS0tIGV4dDJmcy5ic2QvZXh0Ml92ZnNvcHMuYwkyMDEwLTAx LTE3IDE5OjAyOjU2LjAwMDAwMDAwMCArMDAwMAorKysgZXh0MmZzL2V4dDJf dmZzb3BzLmMJMjAxMC0wMS0xOCAxNTo0MzoyMC4wMDAwMDAwMDAgKzAwMDAK QEAgLTk0NSw5ICs5NDUsOCBAQAogCX0KIAogCS8qCi0JICogRmluaXNoIGlu b2RlIGluaXRpYWxpemF0aW9uIG5vdyB0aGF0IGFsaWFzaW5nIGhhcyBiZWVu IHJlc29sdmVkLgorCSAqIEZpbmlzaCBpbm9kZSBpbml0aWFsaXphdGlvbi4K IAkgKi8KLQlpcC0+aV9kZXZ2cCA9IHVtcC0+dW1fZGV2dnA7CiAKIAkvKgog CSAqIFNldCB1cCBhIGdlbmVyYXRpb24gbnVtYmVyIGZvciB0aGlzIGlub2Rl IGlmIGl0IGRvZXMgbm90CmRpZmYgLXJ1IGV4dDJmcy5ic2QvaW5vZGUuaCBl eHQyZnMvaW5vZGUuaAotLS0gZXh0MmZzLmJzZC9pbm9kZS5oCTIwMTAtMDEt MTcgMTk6MDM6MjEuMDAwMDAwMDAwICswMDAwCisrKyBleHQyZnMvaW5vZGUu aAkyMDEwLTAxLTE4IDE1OjQzOjIwLjAwMDAwMDAwMCArMDAwMApAQCAtNjIs NyArNjIsNiBAQAogICovCiBzdHJ1Y3QgaW5vZGUgewogCXN0cnVjdAl2bm9k ZSAgKmlfdm5vZGU7LyogVm5vZGUgYXNzb2NpYXRlZCB3aXRoIHRoaXMgaW5v ZGUuICovCi0Jc3RydWN0CXZub2RlICAqaV9kZXZ2cDsvKiBWbm9kZSBmb3Ig YmxvY2sgSS9PLiAqLwogCXN0cnVjdAlleHQybW91bnQgKmlfdW1wOwogCXVf aW50MzJfdCBpX2ZsYWc7CS8qIGZsYWdzLCBzZWUgYmVsb3cgKi8KIAlpbm9f dAkgIGlfbnVtYmVyOwkvKiBUaGUgaWRlbnRpdHkgb2YgdGhlIGlub2RlLiAq LwpAQCAtMTQzLDYgKzE0Miw5IEBACiAjZGVmaW5lCUlOX1NQQUNFQ09VTlRF RAkweDAwODAJCS8qIEJsb2NrcyB0byBiZSBmcmVlZCBpbiBmcmVlIGNvdW50 LiAqLwogI2RlZmluZSBJTl9MQVpZQUNDRVNTICAgMHgwMTAwCQkvKiBQcm9j ZXNzIElOX0FDQ0VTUyBhZnRlciB0aGUKIAkJCQkJICAgIHN1c3BlbnNpb24g ZmluaXNoZWQgKi8KKworI2RlZmluZSBpX2RldnZwIGlfdW1wLT51bV9kZXZ2 cAorCiAjaWZkZWYgX0tFUk5FTAogLyoKICAqIFN0cnVjdHVyZSB1c2VkIHRv IHBhc3MgYXJvdW5kIGxvZ2ljYWwgYmxvY2sgcGF0aHMgZ2VuZXJhdGVkIGJ5 Cg== --0-1285154270-1264375212=:24175-- From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 00:14:28 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92D251065679; Mon, 25 Jan 2010 00:14:28 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 132E78FC16; Mon, 25 Jan 2010 00:14:27 +0000 (UTC) Received: by gxk6 with SMTP id 6so1170273gxk.13 for ; Sun, 24 Jan 2010 16:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3YpQos/pk73Wtl6z7um1EgvYkoli8EkkyMGyYzrDFrI=; b=spW34RSIABu2YFypcGftfCPTkErZI9haz41QGL4j1ytdv26WZK8oMCiXFgEKW3U9SB aeLTtrXwxtyTlV732rXZZGeE9/Yaij/J6EN7/uFMrscbCtl4n2dL+G1tI7xTDQxARxcm 0kuqr2ZydgxS1HzSiAsyygBE0OMNhiMG21YKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TqUujur+bzY1vb7yDeTumzF9zpQMrVEkDEq2HL4hCwv+KIK59tEBRCBDxhZ2EA125j FdDIv9gpSzVWY03vXguqD07gXp7R/kWjXHwZ6OsBD7jbjFIZe2ldcDoMOEyHZyBabean swg/9My9JaxZzHL2sJd5BNT1se73+L+BH4irQ= MIME-Version: 1.0 Received: by 10.101.10.24 with SMTP id n24mr7044299ani.78.1264378467375; Sun, 24 Jan 2010 16:14:27 -0800 (PST) In-Reply-To: <4B5CC167.5010604@FreeBSD.org> References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 02:14:27 +0200 Message-ID: From: Dan Naumov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 00:14:28 -0000 On Sun, Jan 24, 2010 at 11:53 PM, Alexander Motin wrote: > Dan Naumov wrote: >> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and >> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the >> bonnie results. It also sadly seems to confirm the very slow speed :( >> The disks are attached to a 4-port Sil3124 controller and again, my >> Windows benchmarks showing 65mb/s+ were done on exact same machine, >> with same disks attached to the same controller. Only difference was >> that in Windows the disks weren't in a mirror configuration but were >> tested individually. I do understand that a mirror setup offers >> roughly the same write speed as individual disk, while the read speed >> usually varies from "equal to individual disk speed" to "nearly the >> throughput of both disks combined" depending on the implementation, >> but there is no obvious reason I am seeing why my setup offers both >> read and write speeds roughly 1/3 to 1/2 of what the individual disks >> are capable of. Dmesg shows: >> >> atapci0: port 0x1000-0x100f mem >> 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on >> pci4 >> ad8: 1907729MB at ata4-master SATA300 >> ad10: 1907729MB at ata5-master SATA300 > > 8.0-RELEASE, and especially 8-STABLE provide alternative, much more > functional driver for this controller, named siis(4). If your SiI3124 > card installed into proper bus (PCI-X or PCIe x4/x8), it can be really > fast (up to 1GB/s was measured). > > -- > Alexander Motin Sadly, it seems that utilizing the new siis driver doesn't do much good: Before utilizing siis: iozone -s 4096M -r 512 -i0 -i1 random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 4194304 512 28796 28766 51610 50695 After enabling siis in loader.conf (and ensuring the disks show up as ada): iozone -s 4096M -r 512 -i0 -i1 random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 4194304 512 28781 28897 47214 50540 I've checked with the manufacturer and it seems that the Sil3124 in this NAS is indeed a PCI card. More info on the card in question is available at http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ I have the card described later on the page, the one with 4 SATA ports and no eSATA. Alright, so it being PCI is probably a bottleneck in some ways, but that still doesn't explain the performance THAT bad, considering that same hardware, same disks, same disk controller push over 65mb/s in both reads and writes in Win2008. And agian, I am pretty sure that I've had "close to expected" results when I was booting an UFS FreeBSD installation off an SSD (attached directly to SATA port on the motherboard) while running the same kinds of benchmarks with Bonnie and DD on a ZFS mirror made directly on top of 2 raw disks. - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 00:29:59 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A424E1065670; Mon, 25 Jan 2010 00:29:59 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 22C368FC18; Mon, 25 Jan 2010 00:29:58 +0000 (UTC) Received: by ywh35 with SMTP id 35so2328435ywh.7 for ; Sun, 24 Jan 2010 16:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I1rTt5+AtkuF3NDO8eiHPav4aNN1MzV8f6fQzMt6M2o=; b=nFlhTdrrGcnTNDP04CbMdgueZF/TVHKYCOVrjUvV6M3mRPZPJ0/r196MVWaVuzBFg6 3RHTPgiiOV8yZYJsOK7cnGYtvs08DSHgNUWuH6a7A9QOZFt3LmPeQJCKnxAthWD+SPmo hsr26e9Duu/8GRoWPTFLzae7X6pO9K2NY2AlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RRz4XmYnSpIYQbMaj1fTu0CAk1gV4frh4LkR8pa1zHdsw/IZPK4UBITtNoCxTFpzlC Mt5CyAzj6TNixWqSV6WsL/wZxqfIc/hGECFd7Y9v6Pah7HtkqRWwQ0OBvQhWuq5VpLjI 7bvpH6+MyRP9T/V6vP85ZOYwEfpQKLStuPjWc= MIME-Version: 1.0 Received: by 10.101.186.1 with SMTP id n1mr6994422anp.124.1264379389237; Sun, 24 Jan 2010 16:29:49 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 02:29:49 +0200 Message-ID: From: Dan Naumov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 00:29:59 -0000 On Mon, Jan 25, 2010 at 2:14 AM, Dan Naumov wrote: > On Sun, Jan 24, 2010 at 11:53 PM, Alexander Motin wrote= : >> Dan Naumov wrote: >>> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and >>> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the >>> bonnie results. It also sadly seems to confirm the very slow speed :( >>> The disks are attached to a 4-port Sil3124 controller and again, my >>> Windows benchmarks showing 65mb/s+ were done on exact same machine, >>> with same disks attached to the same controller. Only difference was >>> that in Windows the disks weren't in a mirror configuration but were >>> tested individually. I do understand that a mirror setup offers >>> roughly the same write speed as individual disk, while the read speed >>> usually varies from "equal to individual disk speed" to "nearly the >>> throughput of both disks combined" depending on the implementation, >>> but there is no obvious reason I am seeing why my setup offers both >>> read and write speeds roughly 1/3 to 1/2 of what the individual disks >>> are capable of. Dmesg shows: >>> >>> atapci0: port 0x1000-0x100f mem >>> 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on >>> pci4 >>> ad8: 1907729MB at ata4-master SATA300 >>> ad10: 1907729MB at ata5-master SATA300 >> >> 8.0-RELEASE, and especially 8-STABLE provide alternative, much more >> functional driver for this controller, named siis(4). If your SiI3124 >> card installed into proper bus (PCI-X or PCIe x4/x8), it can be really >> fast (up to 1GB/s was measured). >> >> -- >> Alexander Motin > > Sadly, it seems that utilizing the new siis driver doesn't do much good: > > Before utilizing siis: > > iozone -s 4096M -r 512 -i0 -i1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0random > random =A0 =A0bkwd =A0 record =A0 stride > =A0 =A0 =A0 =A0 =A0 =A0 =A0KB =A0reclen =A0 write rewrite =A0 =A0read =A0= =A0reread =A0 =A0read > write =A0 =A0read =A0rewrite =A0 =A0 read =A0 fwrite frewrite =A0 fread = =A0freread > =A0 =A0 =A0 =A0 4194304 =A0 =A0 512 =A0 28796 =A0 28766 =A0 =A051610 =A0 = =A050695 > > After enabling siis in loader.conf (and ensuring the disks show up as ada= ): > > iozone -s 4096M -r 512 -i0 -i1 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0random > random =A0 =A0bkwd =A0 record =A0 stride > =A0 =A0 =A0 =A0 =A0 =A0 =A0KB =A0reclen =A0 write rewrite =A0 =A0read =A0= =A0reread =A0 =A0read > write =A0 =A0read =A0rewrite =A0 =A0 read =A0 fwrite frewrite =A0 fread = =A0freread > =A0 =A0 =A0 =A0 4194304 =A0 =A0 512 =A0 28781 =A0 28897 =A0 =A047214 =A0 = =A050540 Just to add to the numbers above, exact same benchmark, on 1 disk (detached 2nd disk from the mirror) while using the siis driver: random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 4194304 512 57760 56371 68867 74047 - Dan From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 05:33:09 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B4D31065692; Mon, 25 Jan 2010 05:33:09 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id BF0E48FC0A; Mon, 25 Jan 2010 05:33:08 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o0P5X7BA024156; Sun, 24 Jan 2010 23:33:07 -0600 (CST) Date: Sun, 24 Jan 2010 23:33:07 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Dan Naumov In-Reply-To: Message-ID: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Sun, 24 Jan 2010 23:33:07 -0600 (CST) Cc: freebsd-fs@freebsd.org, Alexander Motin , Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 05:33:09 -0000 On Mon, 25 Jan 2010, Dan Naumov wrote: > > I've checked with the manufacturer and it seems that the Sil3124 in > this NAS is indeed a PCI card. More info on the card in question is > available at http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ > I have the card described later on the page, the one with 4 SATA ports > and no eSATA. Alright, so it being PCI is probably a bottleneck in > some ways, but that still doesn't explain the performance THAT bad, > considering that same hardware, same disks, same disk controller push > over 65mb/s in both reads and writes in Win2008. And agian, I am > pretty sure that I've had "close to expected" results when I was The slow PCI bus and this card look like the bottleneck to me. Remember that your Win2008 tests were with just one disk, your zfs performance with just one disk was similar to Win2008, and your zfs performance with a mirror was just under 1/2 that. I don't think that your performance results are necessarily out of line for the hardware you are using. On an old Sun SPARC workstation with retrofitted 15K RPM drives on Ultra-160 SCSI channel, I see a zfs mirror write performance of 67,317KB/second and a read performance of 124,347KB/second. The drives themselves are capable of 100MB/second range performance. Similar to yourself, I see 1/2 the write performance due to bandwidth limitations. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 07:00:59 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6626D1065676; Mon, 25 Jan 2010 07:00:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8CAE68FC29; Mon, 25 Jan 2010 07:00:58 +0000 (UTC) Received: by fxm26 with SMTP id 26so689533fxm.13 for ; Sun, 24 Jan 2010 23:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=p6eu0eZZ0xKVt/XSKpZZv3bpWEX+BO2tnASnZOTfEdI=; b=akjh+F4rYocKFdx5jCLmq8q9J8ADZajKCHIAu1a551RSIutwk4Q4n02bBMA8y4efPE 0NOHAkM5FZLoAsU/doxkAVrOsMw7vMzONTtNfJUpJxbDrwMgXRF81iThvdkZaSWhV2gp Uij9axdqnqu6L29u73Cp334YacXUlQYp05Hs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=HWOJBXaf7RbmnT473CpKL2PGOPv+IIvS8mh7560RQ529+PleQ4ENllw317EOMeiRX9 ss03Rv2p7sbIGfRHci6LNMDiUt2FHzcZH/M+jhRIMiinj9qiCNrHV3Ql+vVG7jAnsBHz yvDBYpB/9h+ouYgOu2Sz1zaiyDI09j3uHXUzI= Received: by 10.223.17.155 with SMTP id s27mr6428939faa.13.1264402857645; Sun, 24 Jan 2010 23:00:57 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm2542816fxm.6.2010.01.24.23.00.56 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 23:00:57 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5D41A6.5080203@FreeBSD.org> Date: Mon, 25 Jan 2010 09:00:54 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Dan Naumov References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 07:00:59 -0000 Dan Naumov wrote: > On Mon, Jan 25, 2010 at 2:14 AM, Dan Naumov wrote: >> On Sun, Jan 24, 2010 at 11:53 PM, Alexander Motin wrote: >>> Dan Naumov wrote: >>>> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and >>>> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the >>>> bonnie results. It also sadly seems to confirm the very slow speed :( >>>> The disks are attached to a 4-port Sil3124 controller and again, my >>>> Windows benchmarks showing 65mb/s+ were done on exact same machine, >>>> with same disks attached to the same controller. Only difference was >>>> that in Windows the disks weren't in a mirror configuration but were >>>> tested individually. I do understand that a mirror setup offers >>>> roughly the same write speed as individual disk, while the read speed >>>> usually varies from "equal to individual disk speed" to "nearly the >>>> throughput of both disks combined" depending on the implementation, >>>> but there is no obvious reason I am seeing why my setup offers both >>>> read and write speeds roughly 1/3 to 1/2 of what the individual disks >>>> are capable of. Dmesg shows: >>>> >>>> atapci0: port 0x1000-0x100f mem >>>> 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on >>>> pci4 >>>> ad8: 1907729MB at ata4-master SATA300 >>>> ad10: 1907729MB at ata5-master SATA300 >>> 8.0-RELEASE, and especially 8-STABLE provide alternative, much more >>> functional driver for this controller, named siis(4). If your SiI3124 >>> card installed into proper bus (PCI-X or PCIe x4/x8), it can be really >>> fast (up to 1GB/s was measured). >>> >>> -- >>> Alexander Motin >> Sadly, it seems that utilizing the new siis driver doesn't do much good: >> >> Before utilizing siis: >> >> iozone -s 4096M -r 512 -i0 -i1 >> random >> random bkwd record stride >> KB reclen write rewrite read reread read >> write read rewrite read fwrite frewrite fread freread >> 4194304 512 28796 28766 51610 50695 >> >> After enabling siis in loader.conf (and ensuring the disks show up as ada): >> >> iozone -s 4096M -r 512 -i0 -i1 >> >> random >> random bkwd record stride >> KB reclen write rewrite read reread read >> write read rewrite read fwrite frewrite fread freread >> 4194304 512 28781 28897 47214 50540 > > Just to add to the numbers above, exact same benchmark, on 1 disk > (detached 2nd disk from the mirror) while using the siis driver: > > random > random bkwd record stride > KB reclen write rewrite read reread read > write read rewrite read fwrite frewrite fread freread > 4194304 512 57760 56371 68867 74047 If both parts of mirror uses same controller, it doubles it's bus traffic. That may reduce bandwidth twice. The main benefit of siis(4) is a command queuing. You should receive more benefits on multithread random I/O. -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 07:34:53 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83C381065672; Mon, 25 Jan 2010 07:34:53 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id F408C8FC1A; Mon, 25 Jan 2010 07:34:52 +0000 (UTC) Received: by yxe1 with SMTP id 1so2622784yxe.3 for ; Sun, 24 Jan 2010 23:34:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JPV6jRzwieQnlULeFbANGq33ETf6qoWOFzZvsS7JwUU=; b=Px0wT+TVXcSQg2pTyl1dwQnGUu4xjUpIb2mwLE8kiWEia9qmnYrHYMR6XS8m/QKwQ0 GBo48VVmQWg8R8sk6ji7Bnp/eGndAL/hfNaDgK85jWk3GTWK7uxQ4Gw5oTmbudWQ14P1 qcjATXHI7zzitK4ZS7mgD41rwVLJiktiAKXOo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tSAtR80zCR1KORgccYf7rdboVg/kELJ0IKa8LtX6wZETdeRY9O5xS/b+TRbCdADWIo blDYI7JU04wIAJK7ZimMNQ5jzp1eKVghPmyDkKNG2drg6CFphDL4hFhT38/Ap150Cl+P d1PFoV18tWHDfBq22RYDJiLozD0AU+sf5saR4= MIME-Version: 1.0 Received: by 10.101.2.23 with SMTP id e23mr7310095ani.206.1264404892197; Sun, 24 Jan 2010 23:34:52 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 09:34:52 +0200 Message-ID: From: Dan Naumov To: Bob Friesenhahn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Alexander Motin , Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 07:34:53 -0000 On Mon, Jan 25, 2010 at 7:33 AM, Bob Friesenhahn wrote: > On Mon, 25 Jan 2010, Dan Naumov wrote: >> >> I've checked with the manufacturer and it seems that the Sil3124 in >> this NAS is indeed a PCI card. More info on the card in question is >> available at >> http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ >> I have the card described later on the page, the one with 4 SATA ports >> and no eSATA. Alright, so it being PCI is probably a bottleneck in >> some ways, but that still doesn't explain the performance THAT bad, >> considering that same hardware, same disks, same disk controller push >> over 65mb/s in both reads and writes in Win2008. And agian, I am >> pretty sure that I've had "close to expected" results when I was > > The slow PCI bus and this card look like the bottleneck to me. Remember t= hat > your Win2008 tests were with just one disk, your zfs performance with jus= t > one disk was similar to Win2008, and your zfs performance with a mirror w= as > just under 1/2 that. > > I don't think that your performance results are necessarily out of line f= or > the hardware you are using. > > On an old Sun SPARC workstation with retrofitted 15K RPM drives on Ultra-= 160 > SCSI channel, I see a zfs mirror write performance of 67,317KB/second and= a > read performance of 124,347KB/second. =A0The drives themselves are capabl= e of > 100MB/second range performance. Similar to yourself, I see 1/2 the write > performance due to bandwidth limitations. > > Bob There is lots of very sweet irony in my particular situiation. Initially I was planning to use a single X25-M 80gb SSD in the motherboard sata port for the actual OS installation as well as to dedicate 50gb of it to a become a designaed L2ARC vdev for my ZFS mirrors. The SSD attached to the motherboard port would be recognized only as a SATA150 device for some reason, but I was still seeing 150mb/s throughput and sub 0.1 ms latencies on that disk simply because of how crazy good the X25-M's are. However I ended up having very bad issues with the Icydock 2,5" to 3,5" converter jacket I was using to keep/fit the SSD in the system and it would randomly drop write IO on heavy load due to bad connectors. Having finally figured out the cause of my OS installations to the SSD going belly up during applying updates, I decided to move the SSD to my desktop and use it there instead, additionally thinking that my perhaps my idea of the SSD was crazy overkill for what I need the system to do. Ironically now that I am seeing how horrible the performance is when I am operating on the mirror through this PCI card, I realize that actually, my idea was pretty bloody brilliant, I just didn't really know why at the time. An L2ARC device on the motherboard port would really help me with random read IO, but to work around the utterly poor write performance, I would also need a dedicaled SLOG ZIL device. The catch is that while L2ARC devices and be removed from the pool at will (should the device up and die all of a sudden), the dedicated ZILs cannot and currently a "missing" ZIL device will render the pool it's included in be unable to import and become inaccessible. There is some work happening in Solaris to implement removing SLOGs from a pool, but that work hasn't yet found it's way in FreeBSD yet. - Sincerely, Dan Naumov - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 08:32:21 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28EB5106566B; Mon, 25 Jan 2010 08:32:21 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 966868FC0A; Mon, 25 Jan 2010 08:32:20 +0000 (UTC) Received: by ywh35 with SMTP id 35so2538895ywh.7 for ; Mon, 25 Jan 2010 00:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g5zFN5gisNK7vcHBmsGGkEdHWsTjCP+1nRHAdd6EGCk=; b=ozR3+lulCZ7MWvjNi1AV+lTeXB7JwvwG7U9rGyvl8/VGareW7S9rwNYF72DBHvttdX e0RDM3vnTIoVllZQhrhd0zpw/fHrRdc4qInK8ocaqYE+J8fmmoELncO4Tgz8vnazTw/i uPy9Vs1tfhz6O0ICQguA/wgDOx5DGnKAJlUC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VqsNGlty9c/zOBZpkqNtxRFYD7stzBA95/5YhqdMOZp4W/9+6hJKBoF5kOkCsgfQvX RBGtak27CpYRcAFwmNXfXKr/BhIM6onDdyaks6j30qBXv/B1XJKpUFpoAYh3BxoQcbdH jjV5T3hkJM+YH5R1JdMroeuTVa9zpK3FYnTz4= MIME-Version: 1.0 Received: by 10.101.6.22 with SMTP id j22mr7317943ani.224.1264408339787; Mon, 25 Jan 2010 00:32:19 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 10:32:19 +0200 Message-ID: From: Dan Naumov To: Bob Friesenhahn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Alexander Motin , Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 08:32:21 -0000 On Mon, Jan 25, 2010 at 9:34 AM, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 7:33 AM, Bob Friesenhahn > wrote: >> On Mon, 25 Jan 2010, Dan Naumov wrote: >>> >>> I've checked with the manufacturer and it seems that the Sil3124 in >>> this NAS is indeed a PCI card. More info on the card in question is >>> available at >>> http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ >>> I have the card described later on the page, the one with 4 SATA ports >>> and no eSATA. Alright, so it being PCI is probably a bottleneck in >>> some ways, but that still doesn't explain the performance THAT bad, >>> considering that same hardware, same disks, same disk controller push >>> over 65mb/s in both reads and writes in Win2008. And agian, I am >>> pretty sure that I've had "close to expected" results when I was >> >> The slow PCI bus and this card look like the bottleneck to me. Remember = that >> your Win2008 tests were with just one disk, your zfs performance with ju= st >> one disk was similar to Win2008, and your zfs performance with a mirror = was >> just under 1/2 that. >> >> I don't think that your performance results are necessarily out of line = for >> the hardware you are using. >> >> On an old Sun SPARC workstation with retrofitted 15K RPM drives on Ultra= -160 >> SCSI channel, I see a zfs mirror write performance of 67,317KB/second an= d a >> read performance of 124,347KB/second. =A0The drives themselves are capab= le of >> 100MB/second range performance. Similar to yourself, I see 1/2 the write >> performance due to bandwidth limitations. >> >> Bob > > There is lots of very sweet irony in my particular situiation. > Initially I was planning to use a single X25-M 80gb SSD in the > motherboard sata port for the actual OS installation as well as to > dedicate 50gb of it to a become a designaed L2ARC vdev for my ZFS > mirrors. The SSD attached to the motherboard port would be recognized > only as a SATA150 device for some reason, but I was still seeing > 150mb/s throughput and sub 0.1 ms latencies on that disk simply > because of how crazy good the X25-M's are. However I ended up having > very bad issues with the Icydock 2,5" to 3,5" converter jacket I was > using to keep/fit the SSD in the system and it would randomly drop > write IO on heavy load due to bad connectors. Having finally figured > out the cause of my OS installations to the SSD going belly up during > applying updates, I decided to move the SSD to my desktop and use it > there instead, additionally thinking that my perhaps my idea of the > SSD was crazy overkill for what I need the system to do. Ironically > now that I am seeing how horrible the performance is when I am > operating on the mirror through this PCI card, I realize that > actually, my idea was pretty bloody brilliant, I just didn't really > know why at the time. > > An L2ARC device on the motherboard port would really help me with > random read IO, but to work around the utterly poor write performance, > I would also need a dedicaled SLOG ZIL device. The catch is that while > L2ARC devices and be removed from the pool at will (should the device > up and die all of a sudden), the dedicated ZILs cannot and currently a > "missing" ZIL device will render the pool it's included in be unable > to import and become inaccessible. There is some work happening in > Solaris to implement removing SLOGs from a pool, but that work hasn't > yet found it's way in FreeBSD yet. > > > - Sincerely, > Dan Naumov OK final question: if/when I go about adding more disks to the system and want redundancy, am I right in thinking that: ZFS pool of disk1+disk2 mirror + disk3+disk4 mirror (a la RAID10) would completely murder my write and read performance even way below the current 28mb/s / 50mb/s I am seeing with 2 disks on that PCI controller and that in order to have the least negative impact, I should simply have 2 independent mirrors in 2 independent pools (with the 5th disk slot in the NAS given to a non-redundant single disk running off the one available SATA port on the motherboard)? - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 08:58:50 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE221065670; Mon, 25 Jan 2010 08:58:50 +0000 (UTC) (envelope-from wonslung@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id E1E558FC13; Mon, 25 Jan 2010 08:58:49 +0000 (UTC) Received: by fxm26 with SMTP id 26so754536fxm.13 for ; Mon, 25 Jan 2010 00:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yILrgnuSr+kV0FohkSJQBB2hXNICQ/BGuFH3nOOhtdk=; b=RwfNgDn9ihjqjNUKyFxs1NznV3Q9lMBxiI0triZUCsk5iKyZ8jYuwy7CIfkbGk/PZx 7P37KRNSFBUNuzZ7+4nNhGXON30uXc7+GU6rRrCQl1CG03HB0ZjItGNg14ytfYzqSlZB gOhJT862QLnK+Xn1WVlvL0itT2h2wlfGe4UUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WBr7xcZ5R+ZAslVVAsJzl4cBriv/h2gCislho34tKZ5ruTY+gwFd7jxzbcsZVpxqw0 v7zuO8SJ7qHHJyiUsE8iz8MURXrYfF3vHBj/dl3BwRu1GAICPT9AJDD0cN5+RQahUjQE e2k6Q1BRAy2yCymFkq/br2DtRBjfzrVfsMmoQ= MIME-Version: 1.0 Received: by 10.103.84.15 with SMTP id m15mr3186048mul.43.1264409928645; Mon, 25 Jan 2010 00:58:48 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 03:58:48 -0500 Message-ID: From: Thomas Burgess To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jason Edwards , FreeBSD-STABLE Mailing List , Alexander Motin , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 08:58:50 -0000 It depends on the bandwidth of the bus that it is on and the controller itself. I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you get a lot more bandwidth.. On Mon, Jan 25, 2010 at 3:32 AM, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 9:34 AM, Dan Naumov wrote: > > On Mon, Jan 25, 2010 at 7:33 AM, Bob Friesenhahn > > wrote: > >> On Mon, 25 Jan 2010, Dan Naumov wrote: > >>> > >>> I've checked with the manufacturer and it seems that the Sil3124 in > >>> this NAS is indeed a PCI card. More info on the card in question is > >>> available at > >>> http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ > >>> I have the card described later on the page, the one with 4 SATA ports > >>> and no eSATA. Alright, so it being PCI is probably a bottleneck in > >>> some ways, but that still doesn't explain the performance THAT bad, > >>> considering that same hardware, same disks, same disk controller push > >>> over 65mb/s in both reads and writes in Win2008. And agian, I am > >>> pretty sure that I've had "close to expected" results when I was > >> > >> The slow PCI bus and this card look like the bottleneck to me. Remember > that > >> your Win2008 tests were with just one disk, your zfs performance with > just > >> one disk was similar to Win2008, and your zfs performance with a mirror > was > >> just under 1/2 that. > >> > >> I don't think that your performance results are necessarily out of line > for > >> the hardware you are using. > >> > >> On an old Sun SPARC workstation with retrofitted 15K RPM drives on > Ultra-160 > >> SCSI channel, I see a zfs mirror write performance of 67,317KB/second > and a > >> read performance of 124,347KB/second. The drives themselves are capable > of > >> 100MB/second range performance. Similar to yourself, I see 1/2 the write > >> performance due to bandwidth limitations. > >> > >> Bob > > > > There is lots of very sweet irony in my particular situiation. > > Initially I was planning to use a single X25-M 80gb SSD in the > > motherboard sata port for the actual OS installation as well as to > > dedicate 50gb of it to a become a designaed L2ARC vdev for my ZFS > > mirrors. The SSD attached to the motherboard port would be recognized > > only as a SATA150 device for some reason, but I was still seeing > > 150mb/s throughput and sub 0.1 ms latencies on that disk simply > > because of how crazy good the X25-M's are. However I ended up having > > very bad issues with the Icydock 2,5" to 3,5" converter jacket I was > > using to keep/fit the SSD in the system and it would randomly drop > > write IO on heavy load due to bad connectors. Having finally figured > > out the cause of my OS installations to the SSD going belly up during > > applying updates, I decided to move the SSD to my desktop and use it > > there instead, additionally thinking that my perhaps my idea of the > > SSD was crazy overkill for what I need the system to do. Ironically > > now that I am seeing how horrible the performance is when I am > > operating on the mirror through this PCI card, I realize that > > actually, my idea was pretty bloody brilliant, I just didn't really > > know why at the time. > > > > An L2ARC device on the motherboard port would really help me with > > random read IO, but to work around the utterly poor write performance, > > I would also need a dedicaled SLOG ZIL device. The catch is that while > > L2ARC devices and be removed from the pool at will (should the device > > up and die all of a sudden), the dedicated ZILs cannot and currently a > > "missing" ZIL device will render the pool it's included in be unable > > to import and become inaccessible. There is some work happening in > > Solaris to implement removing SLOGs from a pool, but that work hasn't > > yet found it's way in FreeBSD yet. > > > > > > - Sincerely, > > Dan Naumov > > OK final question: if/when I go about adding more disks to the system > and want redundancy, am I right in thinking that: ZFS pool of > disk1+disk2 mirror + disk3+disk4 mirror (a la RAID10) would completely > murder my write and read performance even way below the current 28mb/s > / 50mb/s I am seeing with 2 disks on that PCI controller and that in > order to have the least negative impact, I should simply have 2 > independent mirrors in 2 independent pools (with the 5th disk slot in > the NAS given to a non-redundant single disk running off the one > available SATA port on the motherboard)? > > - Sincerely, > Dan Naumov > _______________________________________________ > 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 Mon Jan 25 09:33:36 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51D1F106566C for ; Mon, 25 Jan 2010 09:33:36 +0000 (UTC) (envelope-from mjyo7hanbe@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA168FC16 for ; Mon, 25 Jan 2010 09:33:35 +0000 (UTC) Received: by gxk6 with SMTP id 6so1479784gxk.13 for ; Mon, 25 Jan 2010 01:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=saXIZMcrAvFku2Ix7+3xS+oE16huHGbGlU9KjCESpew=; b=uqy67OP3XEtbdabGDoeU8U8KuUcSCcXFoGAdCI4I47WgvxBuVNk7f+wKleDgWxkomo LdBLcVRQ1fAu/hlefFrzwhDy4S2JmSGR/yHp6V03jV1etNDqDqti45/2yH7We6+NXT74 75ZK6uoSCyANE74AltvBz8OCLuS8LVgTnZXhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=c3lIvEMEkvfiMAS8mA75CZuHiyQgyzsq5piuzs12ECQmkZ2sRX/yv1qObPpY+yqLxk HKbHrbbAe1Xec55QvG4+/zGKOPoXCULyg/i0ciTMuOTwgkjGXeR9fCurpJ5sYCSk12Vw uazfl+08z98pBS8Lqx0Q7CbqCjx2jty+Sc8ow= Received: by 10.101.10.6 with SMTP id n6mr6344674ani.60.1264410212558; Mon, 25 Jan 2010 01:03:32 -0800 (PST) Received: from d17-098.csce.kyushu-u.ac.jp (d17-098.csce.kyushu-u.ac.jp [133.5.17.98]) by mx.google.com with ESMTPS id 5sm1670160ywd.57.2010.01.25.01.03.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 01:03:32 -0800 (PST) Message-ID: <4B5969DC.9000605@gmail.com> Date: Fri, 22 Jan 2010 18:03:24 +0900 From: Jun Furukawa User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: I want to hook X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 09:33:36 -0000 I want to make an automatic encryption system by hooking functions for read and write. Here is the list of the candidates for that. (This is from "The Design and Implementation of the FreeBSD Section8.9 Figure8.32") write() read() (/usr/src/sys/kern/sys_generic.c) | | vn_write() vn_read() (/usr/srs/sys/kern/vfs_vnoops.c) | | ffs_write() ffs_read() (/usr/src/sys/ufs/ffs/ffs_vnops.c) | | ffs_balloc() ufs_bitmap() I want to encrypt data when that is copied to external devices like USB mass storage devices. If possible could you tell me what function I should hook to achieve that? I tried to hook write(), read() systemcall functions to do that by referencing the book, "Designing BSD Rootkits: An Introduction to Kernel Hacking". However I realized that I cannot achieve my goal by that method because the only information about the file I can get by the arguments of write(), and read() is file descriptors. From my investigation, I think we cannot specify whether a file is written to or read from USB mass storage devices with a file descriptor. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 10:00:14 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BC641065672 for ; Mon, 25 Jan 2010 10:00:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 50E2F8FC0C for ; Mon, 25 Jan 2010 10:00:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PA0Erm077337 for ; Mon, 25 Jan 2010 10:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PA0Eqo077336; Mon, 25 Jan 2010 10:00:14 GMT (envelope-from gnats) Date: Mon, 25 Jan 2010 10:00:14 GMT Message-Id: <201001251000.o0PA0Eqo077336@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Peter Jeremy Cc: Subject: Re: kern/143184: [zfs] [lor] zfs/bufwait LOR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Jeremy List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 10:00:14 -0000 The following reply was made to PR kern/143184; it has been noted by GNATS. From: Peter Jeremy To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/143184: [zfs] [lor] zfs/bufwait LOR Date: Mon, 25 Jan 2010 20:51:40 +1100 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Archive followup in -stable: On 2010-Jan-25 11:24:11 +0200, Kostik Belousov wrote: >On Mon, Jan 25, 2010 at 07:07:00PM +1100, Peter Jeremy wrote: >> I had the following crop up recently in 8-STABLE/amd64 from end of >> November. It's been reported as kern/143184. >Basically, page containing the buffer for read(2) is swapped out. >This causes page fault in copyout(9) and entry into vm subsystem >while zfs vnode lock is held. > >If the buffer is backed by e.g. UFS vnode instead of anonymous >memory, you would get UFS/zfs LOR. > >The problem is generic, I am working on the solution in collaboration >with Peter Holm, basing on the Jeff Roberson idea. --=20 Peter Jeremy --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktdaawACgkQ/opHv/APuIeonwCgp1EIoAGldB1BjSpDlmC3Pr40 pv4AnRukj/ieQrITLKCn33yzGcgeWNC6 =+uuT -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 11:07:00 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2796C106568B for ; Mon, 25 Jan 2010 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EF2998FC24 for ; Mon, 25 Jan 2010 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PB6xTn038753 for ; Mon, 25 Jan 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PB6x35038751 for freebsd-fs@FreeBSD.org; Mon, 25 Jan 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Jan 2010 11:06:59 GMT Message-Id: <201001251106.o0PB6x35038751@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 Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 11:07:00 -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/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142924 fs [ext2fs] [patch] Small cleanup for the inode struct in o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142872 fs [zfs] ZFS ZVOL Lockmgr Deadlock o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142594 fs [zfs] Modification time reset to 1 Jan 1970 after fsyn o kern/142558 fs [msdosfs] patch] Minor updates to fs/msdosfs headers ( 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/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142271 fs [zfs] [patch] race condition on zpool create o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs(/ufs) o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141718 fs [zfs] [panic] kernel panic when 'zfs rename' is used o o kern/141685 fs [zfs] zfs corruption on adaptec 5805 raid controller 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/141257 fs [gvinum] No puedo crear RAID5 por SW con gvinum o kern/141235 fs [disklabel] 8.0 no longer provides /dev entries for al o kern/141177 fs [zfs] fsync() on FIFO causes panic() on zfs 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/140682 fs [netgraph] [panic] random panic in netgraph o kern/140661 fs [zfs] /boot/loader fails to work on a GPT/ZFS-only sys o kern/140640 fs [zfs] snapshot crash o kern/140433 fs [zfs] [panic] panic while replaying ZIL after crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity 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 o bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr 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 o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135594 fs [zfs] Single dataset unresponsive with Samba 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/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w 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/131995 fs [nfs] Failure to mount NFSv4 server 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/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv 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/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour 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 s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz 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/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B 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 bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani 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 kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex 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 kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk 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 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic 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 f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in 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/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi 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 kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi 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 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/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 161 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 11:29:25 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45CA0106566B; Mon, 25 Jan 2010 11:29:25 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 012338FC12; Mon, 25 Jan 2010 11:29:25 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NZN87-000GvC-Hy; Mon, 25 Jan 2010 11:29:15 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NZN87-000JtL-Gy; Mon, 25 Jan 2010 11:29:15 +0000 Date: Mon, 25 Jan 2010 11:29:15 +0000 Message-Id: To: dan.naumov@gmail.com, wonslung@gmail.com In-Reply-To: From: Pete French Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, mav@freebsd.org, freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 11:29:25 -0000 > I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you > get a lot more bandwidth.. I would goalong with that - I have precisely the same controller, with a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 meg/second out of them if I try. My controller is, however on PCI-X, not PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( -pete. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 12:55:21 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08FA106570A for ; Mon, 25 Jan 2010 12:55:21 +0000 (UTC) (envelope-from pl@ninthfloor.org) Received: from mail.ninthfloor.org (ninthfloor.org [IPv6:2001:470:1f07:ea::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA468FCE6 for ; Mon, 25 Jan 2010 12:55:01 +0000 (UTC) Received: from ninthfloor.org (ninthfloor.org [IPv6:2001:470:1f07:ea::1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pl) by mail.ninthfloor.org (Postfix) with ESMTPSA id ED35E1C0F6; Mon, 25 Jan 2010 12:54:59 +0000 (UTC) Date: Mon, 25 Jan 2010 12:54:48 +0000 From: Paride Legovini To: Rick Macklem Message-ID: <20100125125448.GA27245@ninthfloor.org> References: <20100124021318.GA1881@ninthfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: Can't export using nfs4 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 12:55:22 -0000 On Sun, Jan 24, 2010 at 01:03:01PM -0500, Rick Macklem wrote: > On Sun, 24 Jan 2010, Paride Legovini wrote: > > >Then I have a couple of trivial exports: > > > ># cat /etc/exports > >V4: /usr > >/home > > The "V4: /usr" only says that "/usr" is the root of the NFSv4 tree and > defines what hosts are allowed to perform NFSv4 state (read lock) related > Ops. > > You still need to export /usr, for example: > V4: /usr > /usr This solved the issue, thank you! Paride From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 16:30:06 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95FE2106568D for ; Mon, 25 Jan 2010 16:30:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6BE1E8FC14 for ; Mon, 25 Jan 2010 16:30:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PGU6Gp019042 for ; Mon, 25 Jan 2010 16:30:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PGU6T6019037; Mon, 25 Jan 2010 16:30:06 GMT (envelope-from gnats) Date: Mon, 25 Jan 2010 16:30:06 GMT Message-Id: <201001251630.o0PGU6T6019037@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Aditya Sarawgi Cc: Subject: Re: kern/142597: [ext2fs] ext2fs does not work on filesystems with really big directories X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Aditya Sarawgi List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:30:06 -0000 The following reply was made to PR kern/142597; it has been noted by GNATS. From: Aditya Sarawgi To: bug-followup@FreeBSD.org, vermaden@interia.pl Cc: Subject: Re: kern/142597: [ext2fs] ext2fs does not work on filesystems with really big directories Date: Mon, 25 Jan 2010 21:54:54 +0000 On Sun, Jan 10, 2010 at 09:43:26PM +0000, linimon@FreeBSD.org wrote: > Old Synopsis: ext2fs does not work on filesystems with really big directories > New Synopsis: [ext2fs] ext2fs does not work on filesystems with really big directories > > Responsible-Changed-From-To: freebsd-bugs->freebsd-fs > Responsible-Changed-By: linimon > Responsible-Changed-When: Sun Jan 10 21:43:16 UTC 2010 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=142597 > _______________________________________________ > 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" Hi, Can you give a rough estimate of the number of files you have in the directory, and if possible at what value is this breaking. The current code supports large_file and I don't think dir_index maybe causing this, the only thing dir_index would do is make the lookup faster. The other thing I would like to know is that when you do ls big_dir do you get the prompt back or ls keeps waiting. Thanks Aditya Sarawgi From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 16:40:01 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E06061065670; Mon, 25 Jan 2010 16:40:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B8B468FC21; Mon, 25 Jan 2010 16:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PGe1AI028599; Mon, 25 Jan 2010 16:40:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PGe1cb028595; Mon, 25 Jan 2010 16:40:01 GMT (envelope-from linimon) Date: Mon, 25 Jan 2010 16:40:01 GMT Message-Id: <201001251640.o0PGe1cb028595@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143212: [nfs] NFSv4 client strange work ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:40:02 -0000 Synopsis: [nfs] NFSv4 client strange work ... Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 25 16:39:44 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143212 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 17:04:02 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 732B91065672; Mon, 25 Jan 2010 17:04:02 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com [209.85.223.199]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF368FC12; Mon, 25 Jan 2010 17:04:01 +0000 (UTC) Received: by iwn37 with SMTP id 37so3748506iwn.30 for ; Mon, 25 Jan 2010 09:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=Kwc/e4Cr0JlaU+TkwDYYtG0ZkN6fjBWBKotxxdJN3ng=; b=gbCe6ZursasSKl2MtrjlsnrDUM/V1yUAOzYUEtw9li2wq2Vm7ZoKce2l9wdh88q+Zl 7ybsGpcgsaa6DCgJU9fZl/0h1Gk/mcxZ+zp7IF4CQ/Zrr0OBEB6Uzr1GrpBMyu4r2oJW tSbAGjNyO/eJb/3WOQNSbc8SDAdzdIdT9JUKg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=dh/U8VA/Cyw3jhAfRIsFsoqDixTKgn14Sz42ZCBrHQurD9U/n+/sxNFNEZOT5IuFsC Q9E24rkBf1RFjU4IVSAU8RSx45DAMqszD/Q1rvDyy2fX3EY7kNTAp2X1KyaYXHQE0UMJ 2gT0Sc+gewrpLxVNGxN6uBSsljPlxOmBlVBSk= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.149.9 with SMTP id r9mr3885943ibv.74.1264439040810; Mon, 25 Jan 2010 09:04:00 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Jan 2010 09:04:00 -0800 X-Google-Sender-Auth: 06ca1031c6b56ef4 Message-ID: From: Artem Belevich To: Pete French Content-Type: text/plain; charset=ISO-8859-1 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, mav@freebsd.org, dan.naumov@gmail.com, freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:04:02 -0000 aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 controllers when I tried it with 6 and 8 disks. I think the problem is that MV8 only does 32K per transfer and that does seem to matter when you have 8 drives hooked up to it. I don't have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was noticeably lower than that of LSI1068 in the same configuration. Both LSI1068 and MV2 were on the same PCI-X bus. It could be a driver limitation. The driver for Marvel SATA controllers in NetBSD seems a bit more advanced compared to what's in FreeBSD. I wish intel would make cheap multi-port PCIe SATA card based on their AHCI controllers. --Artem On Mon, Jan 25, 2010 at 3:29 AM, Pete French wrote: >> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you >> get a lot more bandwidth.. > > I would goalong with that - I have precisely the same controller, with > a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 > meg/second out of them if I try. My controller is, however on PCI-X, not > PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( > > -pete. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 17:40:56 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EE71106566B; Mon, 25 Jan 2010 17:40:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id A0D708FC1C; Mon, 25 Jan 2010 17:40:55 +0000 (UTC) Received: by fxm27 with SMTP id 27so1035750fxm.3 for ; Mon, 25 Jan 2010 09:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=jyVLdTkQZoMWraDkskVuVR3bPC8wn5sQeuUCWzwb9Q8=; b=S4RSwRySSyrX++8NofKAKsDgLvcnI4jg/4pWfM7m5tgiUKLN0z3C5AYaEZsBYxSzG2 LGSlNxxoVy7q7HPyvULC1PyV7/9SOKqheWIgbbdeypj1c0v7K0jqUOe9YFCWpQal+qpY 0o0rJA6OlSeI4E+iEZtwaXSOL9bi0bmVE4U1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Hrb7I+C0KBOdAAeBbBOLrVO5EBykitEpMIvD0VaaTjhO/4ikrrimK1hS0Zg2P3Qusy ktWjJmtlNsV43ipa6CPbwVDpnmhsekLE0Wb4j9w/ZpODVC38IVUn2vZvossqPGedNnMm FJGyKw5xVsBsGKH3idE7LtLbullHt8cpNACN8= Received: by 10.223.16.72 with SMTP id n8mr6510981faa.26.1264441254397; Mon, 25 Jan 2010 09:40:54 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2850502fxm.12.2010.01.25.09.40.52 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 09:40:53 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5DD7A2.4000101@FreeBSD.org> Date: Mon, 25 Jan 2010 19:40:50 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Artem Belevich References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , dan.naumov@gmail.com, freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:40:56 -0000 Artem Belevich wrote: > aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 > controllers when I tried it with 6 and 8 disks. > I think the problem is that MV8 only does 32K per transfer and that > does seem to matter when you have 8 drives hooked up to it. I don't > have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was > noticeably lower than that of LSI1068 in the same configuration. Both > LSI1068 and MV2 were on the same PCI-X bus. It could be a driver > limitation. The driver for Marvel SATA controllers in NetBSD seems a > bit more advanced compared to what's in FreeBSD. I also wouldn't recommend to use Marvell 88SXx0xx controllers now. While potentially they are interesting, lack of documentation and numerous hardware bugs make existing FreeBSD driver very limited there. > I wish intel would make cheap multi-port PCIe SATA card based on their > AHCI controllers. Indeed. Intel on-board AHCI SATA controllers are fastest from all I have tested. Unluckily, they are not producing discrete versions. :( Now, if discrete solution is really needed, I would still recommend SiI3124, but with proper PCI-X 64bit/133MHz bus or built-in PCIe x8 bridge. They are fast and have good new siis driver. > On Mon, Jan 25, 2010 at 3:29 AM, Pete French > wrote: >>> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you >>> get a lot more bandwidth.. >> I would goalong with that - I have precisely the same controller, with >> a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 >> meg/second out of them if I try. My controller is, however on PCI-X, not >> PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 18:03:00 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5B521065679; Mon, 25 Jan 2010 18:03:00 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 251B78FC0C; Mon, 25 Jan 2010 18:02:59 +0000 (UTC) Received: by ywh35 with SMTP id 35so2926521ywh.7 for ; Mon, 25 Jan 2010 10:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nZtf3l4PCbMY400oXJwuloFDENM2ZdBfDGqzTYpxpm8=; b=rYZu0wav4efSK1MEUAd3tPW8fI9bFybJCPS2kISQ1m6hRinY1X8wDU7FxgZbA6YeST dNftvcTu0aBtzeH+S1gmiByDcOY+dn9iRcmcH/ZzPw1f+PBWIaT2WpiHgQhem50QuRdQ z3TshhsoiainWblREgVwBnixzWm4q1sSpQYDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CRhUR5DCk0bSfYEo88AX2XIqcuJoVI/kjNBON5laZmfQdCz3PPexzXqPcIB4YJXypa MeY/Vjp4SuPfjD4LhlBjxvBytIfLOkzYWClMpThWU5h4eTqClDnR/7WT0n+LPSL4Lsw6 BPhybnwnYJTCzKZTopDB8htoq0o1pl7psznUw= MIME-Version: 1.0 Received: by 10.100.200.9 with SMTP id x9mr8457030anf.76.1264442578767; Mon, 25 Jan 2010 10:02:58 -0800 (PST) In-Reply-To: <4B5DD7A2.4000101@FreeBSD.org> References: <4B5DD7A2.4000101@FreeBSD.org> Date: Mon, 25 Jan 2010 20:02:58 +0200 Message-ID: From: Dan Naumov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:03:00 -0000 On Mon, Jan 25, 2010 at 7:40 PM, Alexander Motin wrote: > Artem Belevich wrote: >> aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 >> controllers when I tried it with 6 and 8 disks. >> I think the problem is that MV8 only does 32K per transfer and that >> does seem to matter when you have 8 drives hooked up to it. I don't >> have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was >> noticeably lower than that of LSI1068 in the same configuration. Both >> LSI1068 and MV2 were on the same PCI-X bus. It could be a driver >> limitation. The driver for Marvel SATA controllers in NetBSD seems a >> bit more advanced compared to what's in FreeBSD. > > I also wouldn't recommend to use Marvell 88SXx0xx controllers now. While > potentially they are interesting, lack of documentation and numerous > hardware bugs make existing FreeBSD driver very limited there. > >> I wish intel would make cheap multi-port PCIe SATA card based on their >> AHCI controllers. > > Indeed. Intel on-board AHCI SATA controllers are fastest from all I have > tested. Unluckily, they are not producing discrete versions. :( > > Now, if discrete solution is really needed, I would still recommend > SiI3124, but with proper PCI-X 64bit/133MHz bus or built-in PCIe x8 > bridge. They are fast and have good new siis driver. > >> On Mon, Jan 25, 2010 at 3:29 AM, Pete French >> wrote: >>>> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you >>>> get a lot more bandwidth.. >>> I would goalong with that - I have precisely the same controller, with >>> a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 >>> meg/second out of them if I try. My controller is, however on PCI-X, not >>> PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( > > -- > Alexander Motin Alexander, since you seem to be experienced in the area, what do you think of these 2 for use in a FreeBSD8 ZFS NAS: http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 18:32:39 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93530106568D; Mon, 25 Jan 2010 18:32:39 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id C24748FC1C; Mon, 25 Jan 2010 18:32:38 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so305433fga.13 for ; Mon, 25 Jan 2010 10:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=x52Et8PK7t/Kk68XZ2LAGn4xrdE0aigYg/9K5/J6bTY=; b=QCzegvUd6v1jeoLJErwP7BrHyd/3FD3AxHaR/ptUe5za64cJZCnqsJjBIaZtW82beX 8VymcaNCSpoXZVIBweUkERirdkgD7dYQuceyZLTT2bq7M9lbOqdJJwarkrZIx+Gqxnhg 3CcinNPcFB1DKCkwXU57BSMTcHEiA+8bXSzTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=HG7WH0gRwWw9v2f9nAeNpDlXNCmbWhJUjP4maw0fyy97CX9NTBdAJO7NvOpHqdHYUN 1rFH/HLIHYgX4qBgRKjK3J4taZlGwJyvfx9O3SYRD017mG/xPDnhyBTCauk06Ec4IrvT UVQ1WeV9fGbWGNobkbbRwv8PIVwZAMjWboxrI= Received: by 10.87.65.9 with SMTP id s9mr11295928fgk.48.1264444357606; Mon, 25 Jan 2010 10:32:37 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm2873540fxm.3.2010.01.25.10.32.35 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 10:32:36 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5DE3C1.4060508@FreeBSD.org> Date: Mon, 25 Jan 2010 20:32:33 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Dan Naumov References: <4B5DD7A2.4000101@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:32:39 -0000 Dan Naumov wrote: > Alexander, since you seem to be experienced in the area, what do you > think of these 2 for use in a FreeBSD8 ZFS NAS: > > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y Unluckily I haven't yet touched Atom family close yet, so I can't say about it's performance. But higher desktop level (even bit old) ICH9R chipset there is IMHO a good option. It is MUCH better then ICH7, often used with previous Atoms. If I had nice small Mini-ITX case with 6 drive bays, I would definitely look for some board like that to build home storage. -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 18:39:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CB5E10656EE; Mon, 25 Jan 2010 18:39:05 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 989868FC1F; Mon, 25 Jan 2010 18:39:04 +0000 (UTC) Received: by yxe1 with SMTP id 1so3074706yxe.3 for ; Mon, 25 Jan 2010 10:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QCTb72G72iYvVessua3UeOR1nv/wXzNbeFrePJ64fAM=; b=j5ZN1Xhf1AGy965Hcf1bq4lg8Cui34jMifLHy3BzxYGT5HnXA5vKOzuLsy7XGP7KWX NkFDH1GBU+PqJNvXms1E/YjkFGskS3BCnQqf1E2wAjcdBdRur3cdSReZ9GHZJWlL8A2u t3F4qp/Whbofiqqf91BT+qFtmMRo57SQEWscM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TeP6Pq0aiLvuPulbRUWW0eRnyII7jmtG66WAcj2IWxCsgXlgHNlfKh+uQMeLRvtfhP cawR3OGk48NAe+q0cDWksQSJ6U1/WkZMzP5Ko9LyNVuwhw4wePqsyN9iXYX4kaQCba0D qZX3VwMfc9/WrYNT2Rl6BDpphjU79qsyJ3CHM= MIME-Version: 1.0 Received: by 10.100.220.13 with SMTP id s13mr5484672ang.101.1264444741488; Mon, 25 Jan 2010 10:39:01 -0800 (PST) In-Reply-To: <4B5DE3C1.4060508@FreeBSD.org> References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> Date: Mon, 25 Jan 2010 20:39:01 +0200 Message-ID: From: Dan Naumov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:39:05 -0000 On Mon, Jan 25, 2010 at 8:32 PM, Alexander Motin wrote: > Dan Naumov wrote: >> Alexander, since you seem to be experienced in the area, what do you >> think of these 2 for use in a FreeBSD8 ZFS NAS: >> >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y > > Unluckily I haven't yet touched Atom family close yet, so I can't say > about it's performance. But higher desktop level (even bit old) ICH9R > chipset there is IMHO a good option. It is MUCH better then ICH7, often > used with previous Atoms. If I had nice small Mini-ITX case with 6 drive > bays, I would definitely look for some board like that to build home > storage. > > -- > Alexander Motin CPU-performance-wise, I am not really worried. The current system is an Atom 330 and even that is a bit overkill for what I do with it and from what I am seeing, the new Atom D510 used on those boards is a tiny bit faster. What I want and care about for this system are reliability, stability, low power use, quietness and fast disk read/write speeds. I've been hearing some praise of ICH9R and 6 native SATA ports should be enough for my needs. AFAIK, the Intel 82574L network cards included on those are also very well supported? - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 19:06:13 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E10F10656A8 for ; Mon, 25 Jan 2010 19:06:13 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mx1.freebsd.org (Postfix) with ESMTP id E7CE78FC12 for ; Mon, 25 Jan 2010 19:06:12 +0000 (UTC) Received: by pzk6 with SMTP id 6so1177876pzk.3 for ; Mon, 25 Jan 2010 11:06:12 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.114.118.17 with SMTP id q17mr4748517wac.219.1264445025518; Mon, 25 Jan 2010 10:43:45 -0800 (PST) Date: Tue, 26 Jan 2010 03:43:45 +0900 X-Google-Sender-Auth: b42ab15bb4a76ef3 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 19:06:13 -0000 Hi, After googling a bit and finding out that changing the few parameters on my wd green drives with wdidle3 and wdtler shouldn't cause any data loss, decided to go ahead and change the parameters. Now after changing the parameters so that the drives don't try to park their heads every 8 seconds and the TLER kicks in earlier, one of the raidz1 vdevs of course went south. First raidz1 is 3x1.5TB drives (which seems to be fine) and the second one (which now reports UNAVAIL) is 3x1.0TB which apparently got the short straw now reports "corrupted data", all the drives are online but of course the whole tank is unavailable due the second raidz1 being unavailable. I immediately went back to the old settings with the utilities but this didn't change the situation. Getting the data back from backups is a rather long process due the small pipes involved and could take a week or more, I'd rather hear if there is any other options to recover from the mess... After checking the logs carefully, it seems that the ada1 device permanently lost some sectors. Before twiddling with the parameters, it was 1953525168 sectors (953869MB), now it reports 1953523055 (953868MB). So, would removing it and maybe export/import get me back to degraded state and then I could just replace the now suddenly-lost-some-sectors drive? -- br, Tommi From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 19:21:53 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D541065679 for ; Mon, 25 Jan 2010 19:21:53 +0000 (UTC) (envelope-from stevenschlansker@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 72F5D8FC21 for ; Mon, 25 Jan 2010 19:21:52 +0000 (UTC) Received: by fxm27 with SMTP id 27so1147315fxm.3 for ; Mon, 25 Jan 2010 11:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Miou5iY++P743ijvj46BA0m4hBSOIhcjPVVIXGgoTDo=; b=F2CkGNQJ/P8sFhVfoHMwRfrRVJDg7rEJBLWFzDVkvzOd+NKJr9JoCIQKdjTfYI2wOl RVZDFjXE3Wo0K0fm/zf+AAZU4NYc6VIKyUkABHeqxkP+8bq7JRzND0JJQY9a0ApWqP6W I3UXXzgMbkN/QFTC4gZcBrnFkOO1y65G+GM1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=rZchi9H/jZR5vIF19H1tIsP9Bw9lE+MhObrElwIIKrre4Ec1AJsGAt7Wi5ov5JchNA 7kV5I+t+5aI6jzu3fDDCf3sfTCzf2cjuu3xH8godsqHfal1VvcKen5hdHqYvNMosoRjJ y523kymBPvYAUIdFa3YTw3q1Gy+xAYHGlSGf0= Received: by 10.223.127.206 with SMTP id h14mr7298552fas.96.1264447312215; Mon, 25 Jan 2010 11:21:52 -0800 (PST) Received: from ?10.0.1.4? (c-67-188-116-141.hsd1.ca.comcast.net [67.188.116.141]) by mx.google.com with ESMTPS id 14sm2901940fxm.11.2010.01.25.11.21.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 11:21:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Steven Schlansker In-Reply-To: Date: Mon, 25 Jan 2010 11:21:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> References: To: =?iso-8859-1?Q?Tommi_L=E4tti?= X-Mailer: Apple Mail (2.1077) Cc: freebsd-fs@freebsd.org Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 19:21:54 -0000 On Jan 25, 2010, at 10:43 AM, Tommi L=E4tti wrote: > After checking the logs carefully, it seems that the ada1 device > permanently lost some sectors. Before twiddling with the parameters, > it was 1953525168 sectors (953869MB), now it reports 1953523055 > (953868MB). So, would removing it and maybe export/import get me back > to degraded state and then I could just replace the now > suddenly-lost-some-sectors drive? That will probably work. I had a similar problem a bit ago where suddenly my drives were too small, causing the UNAVAIL corrupted-data problem. I managed to fix it by using gconcat to stitch an extra MB of space from the boot drive onto it. Not a very good = solution, but the best I found until FreeBSD gets shrink support (which sadly = seems like it may be a long while) Failing that, you could use OpenSolaris to import it (as it does have = minimal support for opening mismatched sized vdevs), copy the data off, destroy, = and restore. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 19:29:45 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F48106566B for ; Mon, 25 Jan 2010 19:29:45 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id E93E98FC14 for ; Mon, 25 Jan 2010 19:29:44 +0000 (UTC) Received: by iwn42 with SMTP id 42so820432iwn.9 for ; Mon, 25 Jan 2010 11:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=xu1TR3eRXoYZXXs3m8bbz0BIUyQdQc8lpCDNd5guGzE=; b=jKYK2vjlZlrLlbOIib+dmYKFBudlIty5rcEoioXlXHV92DxjXTjkyS/jIZXgZG+k5F G+xRlBZu/ulrTAQHrfpv62v0vXb5Q+wRf5EtQc0WyJhAajJL/tEbafAQndkXB60j9wKZ F8vL5tlfsetOE9qZawL8zhTkr3f5sQAZL6Gvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uorFH9k8HvOqcdc9nOtB6G6nLRV46I3tp0tE3jhU7yQMc6cyJlx72ELh5/V9GZI7Z7 oBiKaAFd8Cf4x35gG4a2KpPex4FipylKSffHNkUR/kHJF3/aHgo8545FLhihyBvOgUj3 RX4OLgY8HGUO2+OvpmCwQ90ha6HTTXrBF0Jk4= MIME-Version: 1.0 Received: by 10.231.152.75 with SMTP id f11mr4693670ibw.50.1264447783872; Mon, 25 Jan 2010 11:29:43 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Jan 2010 11:29:43 -0800 Message-ID: From: Freddie Cash To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 19:29:45 -0000 On Mon, Jan 25, 2010 at 10:43 AM, Tommi L=C3=A4tti wrote: > After googling a bit and finding out that changing the few parameters > on my wd green drives with wdidle3 and wdtler shouldn't cause any data > loss, decided to go ahead and change the parameters. > > Are those RE2/RE4-GP or Caviar Green drives? Just curious, as we have 8 of the Caviar Green drives in our storage server now, and I can't find anything that says that wdidle3/wdtler will work with them. Everything I've seen says they only work with the RE2/RE4-GP drives. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 20:34:58 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49458106568F; Mon, 25 Jan 2010 20:34:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 76CD48FC1E; Mon, 25 Jan 2010 20:34:57 +0000 (UTC) Received: by fxm27 with SMTP id 27so1227178fxm.3 for ; Mon, 25 Jan 2010 12:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=oVRY+Su/J/ScL502cZEdc1r1uSa5EvtN93PVQdchD0o=; b=FGTtx1cDTPAeJRDstvzHKdeOkCM3ekxgGXpwWF1xQ80SMxL+gTIHci1KDgM6u25t2q qT4cox8B7nu4N8cbLlBeipX2pcBXUowktMbZ558RjMbf7nv3nTMtvSp7/uAnphN/q0fp mUx/PZhy7GmvVX0jdKdDu6Lke8iPTCv8rHGro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=coVQ4Fk86R9Sl0f9yQf5PXg4DpDXRGJlYVgRINB64IgoxeUsMVwL7uq1U0E/kf8CZZ 2oNhyJz4gRyLaRW+EglzVEPDVspd9WwvIUKx1C8Do75VWIbV4LHnqiiHpnfIlYzn7imF 9NvFniMqUnWaV2L9QWUaGT6ItQWZ89TT3g3Ts= Received: by 10.223.3.135 with SMTP id 7mr7452629fan.21.1264451696497; Mon, 25 Jan 2010 12:34:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm2944360fxm.11.2010.01.25.12.34.55 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 12:34:56 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5E006D.1000302@FreeBSD.org> Date: Mon, 25 Jan 2010 22:34:53 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Chris Whitehouse References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> <4B5DFE78.3010805@onetel.com> In-Reply-To: <4B5DFE78.3010805@onetel.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Jan 2010 21:52:34 +0000 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , Dan Naumov , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:34:58 -0000 Chris Whitehouse wrote: > Dan Naumov wrote: >> >> CPU-performance-wise, I am not really worried. The current system is >> an Atom 330 and even that is a bit overkill for what I do with it and >> from what I am seeing, the new Atom D510 used on those boards is a >> tiny bit faster. What I want and care about for this system are >> reliability, stability, low power use, quietness and fast disk >> read/write speeds. I've been hearing some praise of ICH9R and 6 native >> SATA ports should be enough for my needs. AFAIK, the Intel 82574L >> network cards included on those are also very well supported? > > These might be interesting then > www.fit-pc.com > The Intel US15W SCH chipset or System Controller Hub as it's called is > mentioned in hardware notes for 8.0R and 7.2R but only for snd_hda, I > don't know if this means other functions are supported or not. This > thread says it is supported > http://mail-index.netbsd.org/port-i386/2010/01/03/msg001695.html Intel US15W (SCH) chipset heavily stripped and tuned for netbooks. It has no SATA, only one PATA channel. It is mostly supported by FreeBSD, but with exception of video, which makes it close to useless. it has only one benefit - low power consumption. -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 20:38:01 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 566911065676; Mon, 25 Jan 2010 20:38:01 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from woodbine.london.02.net (woodbine.london.02.net [87.194.255.145]) by mx1.freebsd.org (Postfix) with ESMTP id 142208FC12; Mon, 25 Jan 2010 20:37:59 +0000 (UTC) Received: from eco.config (93.97.24.219) by woodbine.london.02.net (8.5.016.1) id 4A2032960754C3CB; Mon, 25 Jan 2010 20:26:32 +0000 Message-ID: <4B5DFE78.3010805@onetel.com> Date: Mon, 25 Jan 2010 20:26:32 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Dan Naumov References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Jan 2010 21:52:45 +0000 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , Alexander Motin , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:38:01 -0000 Dan Naumov wrote: > > CPU-performance-wise, I am not really worried. The current system is > an Atom 330 and even that is a bit overkill for what I do with it and > from what I am seeing, the new Atom D510 used on those boards is a > tiny bit faster. What I want and care about for this system are > reliability, stability, low power use, quietness and fast disk > read/write speeds. I've been hearing some praise of ICH9R and 6 native > SATA ports should be enough for my needs. AFAIK, the Intel 82574L > network cards included on those are also very well supported? > These might be interesting then www.fit-pc.com The Intel US15W SCH chipset or System Controller Hub as it's called is mentioned in hardware notes for 8.0R and 7.2R but only for snd_hda, I don't know if this means other functions are supported or not. This thread says it is supported http://mail-index.netbsd.org/port-i386/2010/01/03/msg001695.html Chris > - Sincerely, > Dan Naumov > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 20:57:22 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 211B1106566B; Mon, 25 Jan 2010 20:57:22 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from april.london.02.net (april.london.02.net [87.194.255.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6DF8FC12; Mon, 25 Jan 2010 20:57:21 +0000 (UTC) Received: from eco.config (93.97.24.219) by april.london.02.net (8.5.016.1) id 4A23ECF807794BCD; Mon, 25 Jan 2010 20:57:20 +0000 Message-ID: <4B5E05B0.1050807@onetel.com> Date: Mon, 25 Jan 2010 20:57:20 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Motin References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> <4B5DFE78.3010805@onetel.com> <4B5E006D.1000302@FreeBSD.org> In-Reply-To: <4B5E006D.1000302@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Jan 2010 21:52:55 +0000 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , Dan Naumov , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:57:22 -0000 Alexander Motin wrote: > Chris Whitehouse wrote: >> Dan Naumov wrote: >>> CPU-performance-wise, I am not really worried. The current system is >>> an Atom 330 and even that is a bit overkill for what I do with it and >>> from what I am seeing, the new Atom D510 used on those boards is a >>> tiny bit faster. What I want and care about for this system are >>> reliability, stability, low power use, quietness and fast disk >>> read/write speeds. I've been hearing some praise of ICH9R and 6 native >>> SATA ports should be enough for my needs. AFAIK, the Intel 82574L >>> network cards included on those are also very well supported? >> These might be interesting then >> www.fit-pc.com >> The Intel US15W SCH chipset or System Controller Hub as it's called is >> mentioned in hardware notes for 8.0R and 7.2R but only for snd_hda, I >> don't know if this means other functions are supported or not. This >> thread says it is supported >> http://mail-index.netbsd.org/port-i386/2010/01/03/msg001695.html > > Intel US15W (SCH) chipset heavily stripped and tuned for netbooks. It > has no SATA, only one PATA channel. It is mostly supported by FreeBSD, > but with exception of video, which makes it close to useless. it has > only one benefit - low power consumption. > The intel spec sheet does say single PATA but according to the fit-pc website it has SATA and miniSD. Still as you say without video support it's not much use, which is useful to know as I had been looking at these. Ok I will go away now :O Chris From owner-freebsd-fs@FreeBSD.ORG Mon Jan 25 23:52:40 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37BEB106566C for ; Mon, 25 Jan 2010 23:52:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4137A8FC15 for ; Mon, 25 Jan 2010 23:52:39 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-224.lns6.adl6.internode.on.net [121.45.156.224]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0PNG4TQ084912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 Jan 2010 09:46:05 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 26 Jan 2010 09:45:57 +1030 User-Agent: KMail/1.9.10 References: <4B5DE3C1.4060508@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1284787.2vsuEm6DAF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001260946.01541.doconnor@gsoft.com.au> X-Spam-Score: -1.682 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 X-Mailman-Approved-At: Tue, 26 Jan 2010 00:07:26 +0000 Cc: sub.mesa@gmail.com, Pete French , Alexander Motin , Dan Naumov , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 23:52:40 -0000 --nextPart1284787.2vsuEm6DAF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 26 Jan 2010, Dan Naumov wrote: > CPU-performance-wise, I am not really worried. The current system is > an Atom 330 and even that is a bit overkill for what I do with it and > from what I am seeing, the new Atom D510 used on those boards is a > tiny bit faster. What I want and care about for this system are > reliability, stability, low power use, quietness and fast disk > read/write speeds. I've been hearing some praise of ICH9R and 6 > native SATA ports should be enough for my needs. AFAIK, the Intel > 82574L network cards included on those are also very well supported? You might want to consider an Athlon (maybe underclock it) - the AMD IXP=20 700/800 south bridge seems to work well with FreeBSD (in my=20 experience). These boards (eg Gigabyte GA-MA785GM-US2H) have 6 SATA ports (one may be=20 eSATA though) and PATA, they seem ideal really.. You can use PATA with=20 CF to boot and connect 5 disks plus a DVD drive. The CPU is not fanless however, but the other stuff is, on the plus side=20 you won't have to worry about CPU power :) Also, the onboard video works well with radeonhd and is quite fast. One other downside is the onboard network isn't great (Realtek) but I=20 put an em card in mine. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1284787.2vsuEm6DAF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLXiYx5ZPcIHs/zowRAkB2AJ9XVkRqtWestP2Y3LC+ygn4pqqZUACcDzLz DvH9w9HtCsd2NJKnfFB1wHk= =p8ya -----END PGP SIGNATURE----- --nextPart1284787.2vsuEm6DAF-- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 00:11:01 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 283361065676 for ; Tue, 26 Jan 2010 00:11:01 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: from web110515.mail.gq1.yahoo.com (web110515.mail.gq1.yahoo.com [67.195.8.120]) by mx1.freebsd.org (Postfix) with SMTP id EAD538FC1E for ; Tue, 26 Jan 2010 00:11:00 +0000 (UTC) Received: (qmail 65958 invoked by uid 60001); 25 Jan 2010 23:44:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264463059; bh=lItq8spPMhE4siLdt3cJEtcVAQbdqeQsCr7zK/K21W0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=HXysMSFqVyZfRQSDG/mbCwnYazk1kmkMyl7du7zXNh+/IdW3DLyqAZm4od7FML1HdnhN7xQJ8WllQ5OBW/B2uMXYcVXa8lKfeyJIzLsH38AWXQVGoIGgYUYhLnsGVl4ixeHVW6wBppenGBIUhWYEg5WbI53XxHvUGxTFpDfblZ0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=I2K6HiEzSags6IWxueCeGWrJVWlT83nwcEMA2cSWseXdtkk8GS6XgJXtdfYnCwd4fany2BKoXWVMIVI/q0tUi9DZSXUfat+R7xKrOt3v/ccBZej045znhr13Rys6pPf7F60IspDTauB1sxrPL7kYN4uXCYpHmhms2oIVrgtwDRw=; Message-ID: <419976.64363.qm@web110515.mail.gq1.yahoo.com> X-YMail-OSG: dK1Ak4oVM1kGAkxXG18SG2hVmUAU4qYTosgzNZUHc8GRQX6Ff0HIzZ5ijFG3T_NZKOzlX7KqLg.tPvg9h9b7Y7B5067XqWLrVR.ALZ6l2jt_SZsDzL4yforw6ZiwcuysUNEzC9f0cBMJOBJOFRHfAKXO5.NmvizQJcKbXoYEQTTf30GGQzNH2Ywqq6EIyZzsboY26wNGD2tj6P.l01RPe0JDfB7.8zVKAC1AzqKmOU7eRyG06.4Luc6IH4lXTEXauiaTNmirKp8VR8ynpkMou3yAjXLrBYmlQNzPnDr3chnyZf46Q5_LDNcVjg-- Received: from [71.174.61.120] by web110515.mail.gq1.yahoo.com via HTTP; Mon, 25 Jan 2010 15:44:19 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 Date: Mon, 25 Jan 2010 15:44:19 -0800 (PST) From: Paul Pathiakis To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ZFS - scrub lead to corruption? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 00:11:01 -0000 Hi, My ZFS-only machine running on 8.0-stable as of ???? is down hard. It is a mirrored pair of Segate 1500 GB drives (yes, I know the firmware history of these drives and they are a late version.) The sequence of events is as follows: 1) cvsup ports 2) portupgrade -a -r -p 3) everything completes successfully. 4) cvsup the latest 8.0 code. 5) make buildworld 6) while it was compiling, it requested m4 and said "not found" 7) which m4 -> not found 8) I find that /usr/bin/m4 is "there" with ls /usr/bin/m4. 9) cd /usr/ports/devel/m4 -> /usr 10) make; make deinstall; make package; no issues. 11) cd /usr/src; make buildworld. Same behavior. 12) ls -sal /usr/bin/m4 -> Panic 13) Reboot 14) zpool status web everything is fine and online. :-) No errors. 15) zpool scrub web 16) scrub continues to over 75% (I wasn't watching for the exact #) and then *panic* level 12 17) I reboot single user. 18) It mounts the web at / 19) At that point, I'm deciding what to do and .... Panic level 12 (I assume ZFS was scrubbing in the background and killed me. 20) Help! How do I recover from this and what additional information does anyone need? I know there's no fsck on ZFS but how do I rollback prior to the writes that caused this? Also, I never enabled snapshots or anything else outside of mirroring. Thank you for the help, Paul From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 04:07:11 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF7B9106566B for ; Tue, 26 Jan 2010 04:07:11 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id B1DB28FC13 for ; Tue, 26 Jan 2010 04:07:11 +0000 (UTC) Received: by pxi13 with SMTP id 13so2944671pxi.3 for ; Mon, 25 Jan 2010 20:07:11 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.114.6.8 with SMTP id 8mr5205463waf.73.1264478831311; Mon, 25 Jan 2010 20:07:11 -0800 (PST) In-Reply-To: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> References: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> Date: Tue, 26 Jan 2010 13:07:11 +0900 X-Google-Sender-Auth: 5a7049937cfcaab8 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: Steven Schlansker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 04:07:11 -0000 2010/1/26 Steven Schlansker : > > On Jan 25, 2010, at 10:43 AM, Tommi L=C3=A4tti wrote: >> After checking the logs carefully, it seems that the ada1 device >> permanently lost some sectors. Before twiddling with the parameters, >> it was 1953525168 sectors (953869MB), now it reports 1953523055 >> (953868MB). So, would removing it and maybe export/import get me back >> to degraded state and then I could just replace the now >> suddenly-lost-some-sectors drive? > > That will probably work. =C2=A0I had a similar problem a bit > ago where suddenly my drives were too small, causing the UNAVAIL > corrupted-data problem. =C2=A0I managed to fix it by using gconcat to sti= tch > an extra MB of space from the boot drive onto it. =C2=A0Not a very good s= olution, > but the best I found until FreeBSD gets shrink support (which sadly seems > like it may be a long while) > > Failing that, you could use OpenSolaris to import it (as it does have min= imal > support for opening mismatched sized vdevs), copy the data off, destroy, = and restore. Forgot to reply-all... --clip-- I just tried just to boot up the system without the 'reduced' drive to see if would automatically go to reduced state. What I got after booting up was that one of the labels had vanished and now it had mixed up the drives it seems. GRR. I guess that's an easy one to recover from, although now I suspect that the zfs is writing to the disks while it scans for the pools and making my life harder at the same time. Maybe I'll just go to the opensol way and try it from there. Copying data locally is quite fast. --clip-- After thinking overnight I'm a bit curious why the whole filesystem failed on that single vdev causing the whole pool loss. Shouldn't the zfs just disregard the disk and just go to degraded state? I've had normal catastrophic disk failures on this setup before and normal replace drive+resilver has worked just fine. Maybe a bug? --=20 br, Tommi From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 04:13:18 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D3A21065670 for ; Tue, 26 Jan 2010 04:13:18 +0000 (UTC) (envelope-from stevenschlansker@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 127678FC08 for ; Tue, 26 Jan 2010 04:13:17 +0000 (UTC) Received: by yxe1 with SMTP id 1so3468377yxe.3 for ; Mon, 25 Jan 2010 20:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Lr5jwIwxGFv5URZNZEVpTaN45thmBKElnMlHA7bWRKo=; b=tuKQBjnpJXwWXm5obbRmqTb3hYpwWwrCMP1LNTOH1tHPVf9mMQKZIROLpBxW+wAFGW BP6qLlhkto5APAK+l7XP1IzbKEJQdXzjOuT7UO6d/CjaKBQ+e24j11ETe6ATedZU6BTn DIhksFipKf5VtGRtkw7nIGck1SQFbyuEEu0yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Ok1zL5KBLMNOTGfd7XS/yv6ILUHx1YrrEWhtu42A69WmlxMOpnLMOBTn2mjO2kiAaE P5Q1Z+cAi5sC7UN5sE4XiPmd/asHWK/pAnST9LFZxkdggGqamXogGOp1+BxRppbg00PI 7Jj6gXXidiw78AqeKISDwaQ2Tp8+KhfSQZWuY= Received: by 10.150.120.33 with SMTP id s33mr1719121ybc.163.1264479171739; Mon, 25 Jan 2010 20:12:51 -0800 (PST) Received: from ?10.0.1.4? (c-67-188-116-141.hsd1.ca.comcast.net [67.188.116.141]) by mx.google.com with ESMTPS id 6sm1906448yxg.12.2010.01.25.20.12.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 20:12:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Steven Schlansker In-Reply-To: Date: Mon, 25 Jan 2010 20:12:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <02786740-7076-4C92-89EE-E1EFC2120E33@gmail.com> References: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> To: =?iso-8859-1?Q?Tommi_L=E4tti?= X-Mailer: Apple Mail (2.1077) Cc: freebsd-fs@freebsd.org Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 04:13:18 -0000 On Jan 25, 2010, at 8:07 PM, Tommi L=E4tti wrote: > 2010/1/26 Steven Schlansker : >>=20 >> On Jan 25, 2010, at 10:43 AM, Tommi L=E4tti wrote: >>> After checking the logs carefully, it seems that the ada1 device >>> permanently lost some sectors. Before twiddling with the parameters, >>> it was 1953525168 sectors (953869MB), now it reports 1953523055 >>> (953868MB). So, would removing it and maybe export/import get me = back >>> to degraded state and then I could just replace the now >>> suddenly-lost-some-sectors drive? >>=20 >> That will probably work. I had a similar problem a bit >> ago where suddenly my drives were too small, causing the UNAVAIL >> corrupted-data problem. I managed to fix it by using gconcat to = stitch >> an extra MB of space from the boot drive onto it. Not a very good = solution, >> but the best I found until FreeBSD gets shrink support (which sadly = seems >> like it may be a long while) >>=20 >> Failing that, you could use OpenSolaris to import it (as it does have = minimal >> support for opening mismatched sized vdevs), copy the data off, = destroy, and restore. >=20 > After thinking overnight I'm a bit curious why the whole filesystem > failed on that single vdev causing the whole pool loss. Shouldn't the > zfs just disregard the disk and just go to degraded state? I've had > normal catastrophic disk failures on this setup before and normal > replace drive+resilver has worked just fine. I poked through the code - the problem is that ZFS identifies the drive as valid (due to correct metadata+checksums) and then tries to assemble = the array. At some point it checks the size, realizes that the drive is = smaller, and rejects the entire array. It isn't smart enough (yet?) to realize = that only rejecting the one drive would allow it to be only degraded... From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 05:49:32 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 030E41065670 for ; Tue, 26 Jan 2010 05:49:32 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mx1.freebsd.org (Postfix) with ESMTP id D79DB8FC12 for ; Tue, 26 Jan 2010 05:49:31 +0000 (UTC) Received: by pzk6 with SMTP id 6so14136pzk.3 for ; Mon, 25 Jan 2010 21:49:31 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.114.45.13 with SMTP id s13mr5190611was.167.1264484971271; Mon, 25 Jan 2010 21:49:31 -0800 (PST) In-Reply-To: <02786740-7076-4C92-89EE-E1EFC2120E33@gmail.com> References: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> <02786740-7076-4C92-89EE-E1EFC2120E33@gmail.com> Date: Tue, 26 Jan 2010 14:49:31 +0900 X-Google-Sender-Auth: 689106bd8656bee2 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: Steven Schlansker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 05:49:32 -0000 > I poked through the code - the problem is that ZFS identifies the drive > as valid (due to correct metadata+checksums) and then tries to assemble t= he > array. =C2=A0At some point it checks the size, realizes that the drive is= smaller, > and rejects the entire array. =C2=A0It isn't smart enough (yet?) to reali= ze that > only rejecting the one drive would allow it to be only degraded... A nice feature indeed. So I would have been screwed anyway. Currently installing opensol on a spare hard-drive for the evening's recovery attempts. I wonder if the newest opensol dev version is the way to go (has way newer zfs version, maybe more... options). Any hints to offer for the procedure? Just force import the pool and hope the best? --=20 br, Tommi From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 05:52:17 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D459F1065670 for ; Tue, 26 Jan 2010 05:52:17 +0000 (UTC) (envelope-from stevenschlansker@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 8873D8FC15 for ; Tue, 26 Jan 2010 05:52:17 +0000 (UTC) Received: by ywh35 with SMTP id 35so3396605ywh.7 for ; Mon, 25 Jan 2010 21:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=FztRAFd2nwPP7erRasm6OGa+MvJ0t/a5msYGkOpuzlE=; b=GLDz1DWMeOBgzSDkYxkLB5MKVd0Cc5o4QWUhCRlLqj/42Zr5GH37m31RU2o502VDCp 3Cn8HeEVhyNU4irqxkCI7P2+ZbpMNTTsKMLEXurySLRKIP6f0uXDEb56043ha6V+tZDY c2ICYAUU/gHb4aSd90IQJWgfmIwSkVeHLTlsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MMAhQ3se1lW9r1U8e3IgRlSlemvb9QMGjL0lTKkK7tBShEtuaoj14+5mP7VmxE0+k7 70GcRhvrDzmpPAIu93g74WO9JW8U2tbuXSFMA1MiWA9Flr+NqEeMIAwYUWjisL7dgaDO rDqD2yAXp7wDQB6Mz0dRNCMjwQNJTjCgEINzc= Received: by 10.101.181.32 with SMTP id i32mr902959anp.7.1264485123035; Mon, 25 Jan 2010 21:52:03 -0800 (PST) Received: from ?192.168.42.3? (70-36-134-162.dsl.dynamic.sonic.net [70.36.134.162]) by mx.google.com with ESMTPS id 35sm1925503yxh.33.2010.01.25.21.51.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 21:52:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Steven Schlansker In-Reply-To: Date: Mon, 25 Jan 2010 21:51:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> <02786740-7076-4C92-89EE-E1EFC2120E33@gmail.com> To: =?iso-8859-1?Q?Tommi_L=E4tti?= X-Mailer: Apple Mail (2.1077) Cc: freebsd-fs@freebsd.org Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 05:52:17 -0000 On Jan 25, 2010, at 9:49 PM, Tommi L=E4tti wrote: >> I poked through the code - the problem is that ZFS identifies the = drive >> as valid (due to correct metadata+checksums) and then tries to = assemble the >> array. At some point it checks the size, realizes that the drive is = smaller, >> and rejects the entire array. It isn't smart enough (yet?) to = realize that >> only rejecting the one drive would allow it to be only degraded... >=20 > A nice feature indeed. So I would have been screwed anyway. >=20 > Currently installing opensol on a spare hard-drive for the evening's > recovery attempts. I wonder if the newest opensol dev version is the > way to go (has way newer zfs version, maybe more... options). >=20 > Any hints to offer for the procedure? Just force import the pool and > hope the best? >=20 I used a usb stick from genunix.org, although to install the damn thing = to a USB drive I had to get a solaris VM running to use the usbcopy tool. It was = a fairly recent dev build, but I'd guess the last release might do okay = too... Other than that, it all worked as expected. No particular hangups. Just the usual fifteen minutes of shock at what a wasteland the Solaris userland is... (so many PATH entries! so confusing!) From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 05:58:43 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49C58106566B for ; Tue, 26 Jan 2010 05:58:43 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1498FC14 for ; Tue, 26 Jan 2010 05:58:43 +0000 (UTC) Received: by pwi15 with SMTP id 15so3032995pwi.3 for ; Mon, 25 Jan 2010 21:58:42 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.114.187.17 with SMTP id k17mr3003763waf.1.1264485522839; Mon, 25 Jan 2010 21:58:42 -0800 (PST) In-Reply-To: References: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> <02786740-7076-4C92-89EE-E1EFC2120E33@gmail.com> Date: Tue, 26 Jan 2010 14:58:42 +0900 X-Google-Sender-Auth: 9b24895261391888 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: Steven Schlansker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 05:58:43 -0000 > Other than that, it all worked as expected. =C2=A0No particular hangups. > Just the usual fifteen minutes of shock at what a wasteland > the Solaris userland is... (so many PATH entries! =C2=A0so confusing!) I'm actually liking it a bit ;) And the newest opensol zfs versions have the dedupe too. I'm really loving it on my netapps and I have some stuff on this box that could benefit. --=20 br, Tommi From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 06:17:06 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FC141065694 for ; Tue, 26 Jan 2010 06:17:06 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id EBF368FC19 for ; Tue, 26 Jan 2010 06:17:05 +0000 (UTC) Received: by pxi13 with SMTP id 13so3000768pxi.3 for ; Mon, 25 Jan 2010 22:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fG9xy6HciwqcVpGn5YEckEr6J+T9ObxJVmJgCXDYWy8=; b=qoJzWWaJlZPDHDwkTfGg/TTsgO6m4cqpyD7v/Sq/dTiH+CmZek6KXk+ia3qTin8FRx 20+Ms1iiWh84rOClOs82MMyxMyO3fhA6F6nT3X0Yv0m2fiAWOT9mx0uxL2oU0iTHxJCY OSOd1ugXhtJrK4S6hheeBsGPNEcgn4fAr2IaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SPQrmoDVe6PjmJCYW7XP+naHholYkRZpT7cwnvyuPygGdieszcEQ9NopIljuQPeQmE CZg1uN8yz1k5JjjAPG7wD4+zNJw5imxDlmX+eN7HIKJ9C4nEsft5MXi8WdN7y6dBYDl9 hR0rMtAZPkoXN0S95PtyRgJIG6wZa8UUDytTI= MIME-Version: 1.0 Received: by 10.115.103.4 with SMTP id f4mr5243783wam.34.1264486625440; Mon, 25 Jan 2010 22:17:05 -0800 (PST) In-Reply-To: <419976.64363.qm@web110515.mail.gq1.yahoo.com> References: <419976.64363.qm@web110515.mail.gq1.yahoo.com> Date: Mon, 25 Jan 2010 22:17:05 -0800 Message-ID: From: Xin LI To: Paul Pathiakis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS - scrub lead to corruption? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 06:17:06 -0000 Hi, On Mon, Jan 25, 2010 at 3:44 PM, Paul Pathiakis wrote= : > Hi, > > My ZFS-only machine running on 8.0-stable as of ???? is down hard. =C2=A0= It is a mirrored pair of Segate 1500 GB drives (yes, I know the firmware hi= story of these drives and they are a late version.) =C2=A0The sequence of e= vents is as follows: [...] > 16) scrub continues to over 75% (I wasn't watching for the exact #) and t= hen *panic* level 12 Do you have console access to the server? Try setting up a crash dump and see if you can obtain a backtrace? By the way, 'zpool status -x' may give some information that is useful. Cheers, --=20 Xin LI http://www.delphij.net From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 06:23:52 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1677D106566C for ; Tue, 26 Jan 2010 06:23:52 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id CC57B8FC1E for ; Tue, 26 Jan 2010 06:23:51 +0000 (UTC) Received: by iwn42 with SMTP id 42so1323508iwn.9 for ; Mon, 25 Jan 2010 22:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=04bA2+8G99fYy/yPdnmEDRhQMRGuFOuvin5Kx9YsvKk=; b=UqqpZLMpxBdh4SYpPr9dA3gDFHLi+gPfyT1qMjKM/B5eSP/LyqJZ5iey862JpdSTm9 uKLsYAvbHZmlVpA+s7fLKxGKYGODBkt+J2P0h3kDQcYeaO5FXcBtdfaOdcriW3vWHaJb FHxxCY1UEO7P7F0ccMY/GiikPtpIdTIvgmQdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=FqgLfctyv7uo7FZXmWUFdfNOQGo9ikqiyNI/2lwouEyjWMOriu63Ta27UFcUf4IfYq a1fCBQ638Td1xFBUXmVEsH9k6JWzSoybIS+cCrpWGNgkKiuiAConXA65GthLWYfVhaxa loM5bn8X2y24PAkogtOzSRplaJGnREjezVt1o= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.149.12 with SMTP id r12mr1704810ibv.86.1264487031042; Mon, 25 Jan 2010 22:23:51 -0800 (PST) In-Reply-To: References: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> <02786740-7076-4C92-89EE-E1EFC2120E33@gmail.com> Date: Mon, 25 Jan 2010 22:23:50 -0800 X-Google-Sender-Auth: ade01540a08020b9 Message-ID: From: Artem Belevich To: Steven Schlansker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, =?ISO-8859-1?Q?Tommi_L=E4tti?= Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 06:23:52 -0000 There is a windows tool that creates USB stick image from ISO. http://devzone.sites.pid0.org/OpenSolaris/opensolaris-liveusb-creator Importing/exporting pool created on FreeBSD did work fine for me. The pool built with labeled GPT slices (/dev/gpt/blah). OpenSolaris did use its own funky names but that's about all that was different. Just don't upgrade pool or filesystem by accident. If you do, you will not be able to use it back on FreeBSD. --Artem On Mon, Jan 25, 2010 at 9:51 PM, Steven Schlansker wrote: > > On Jan 25, 2010, at 9:49 PM, Tommi L=E4tti wrote: > >>> I poked through the code - the problem is that ZFS identifies the drive >>> as valid (due to correct metadata+checksums) and then tries to assemble= the >>> array. =A0At some point it checks the size, realizes that the drive is = smaller, >>> and rejects the entire array. =A0It isn't smart enough (yet?) to realiz= e that >>> only rejecting the one drive would allow it to be only degraded... >> >> A nice feature indeed. So I would have been screwed anyway. >> >> Currently installing opensol on a spare hard-drive for the evening's >> recovery attempts. I wonder if the newest opensol dev version is the >> way to go (has way newer zfs version, maybe more... options). >> >> Any hints to offer for the procedure? Just force import the pool and >> hope the best? >> > > I used a usb stick from genunix.org, although to install the damn thing t= o a USB > drive I had to get a solaris VM running to use the usbcopy tool. =A0It wa= s a > fairly recent dev build, but I'd guess the last release might do okay too= ... > > Other than that, it all worked as expected. =A0No particular hangups. > Just the usual fifteen minutes of shock at what a wasteland > the Solaris userland is... (so many PATH entries! =A0so confusing!) > > _______________________________________________ > 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 Tue Jan 26 07:22:48 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5ECC1065672 for ; Tue, 26 Jan 2010 07:22:48 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id A47E08FC16 for ; Tue, 26 Jan 2010 07:22:48 +0000 (UTC) Received: by pxi13 with SMTP id 13so3027200pxi.3 for ; Mon, 25 Jan 2010 23:22:48 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.114.187.17 with SMTP id k17mr3055307waf.1.1264490567859; Mon, 25 Jan 2010 23:22:47 -0800 (PST) In-Reply-To: References: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> <02786740-7076-4C92-89EE-E1EFC2120E33@gmail.com> Date: Tue, 26 Jan 2010 16:22:47 +0900 X-Google-Sender-Auth: ef476f1a7ede5026 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: Artem Belevich Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 07:22:48 -0000 2010/1/26 Artem Belevich : > Importing/exporting pool created on FreeBSD did work fine for me. The > pool built with labeled GPT slices (/dev/gpt/blah). OpenSolaris did > use its own funky names but that's about all that was different. Half of my arrays is on labels, but I guess OpenSol will figure it out. > Just don't upgrade pool or filesystem by accident. If you do, you will > not be able to use it back on FreeBSD. I don't think I'm re-importing the pool back to bsd, going to play it safe and just copying the data off and then re-create the pool. -- br, Tommi From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 10:27:59 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 550371065670 for ; Tue, 26 Jan 2010 10:27:59 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 31B658FC14 for ; Tue, 26 Jan 2010 10:27:58 +0000 (UTC) Received: by pxi13 with SMTP id 13so3100412pxi.3 for ; Tue, 26 Jan 2010 02:27:58 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.115.116.7 with SMTP id t7mr5381578wam.132.1264501678645; Tue, 26 Jan 2010 02:27:58 -0800 (PST) In-Reply-To: References: <3F785019-DB0E-4385-97EB-7CE69A11647A@gmail.com> <02786740-7076-4C92-89EE-E1EFC2120E33@gmail.com> Date: Tue, 26 Jan 2010 19:27:58 +0900 X-Google-Sender-Auth: 98fb97888d987aa3 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: slight zfs problem after playing with WDIDLE3 and WDTLER X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 10:27:59 -0000 2010/1/26 Tommi L=C3=A4tti : > 2010/1/26 Artem Belevich : >> Importing/exporting pool created on FreeBSD did work fine for me. The >> pool built with labeled GPT slices (/dev/gpt/blah). OpenSolaris did >> use its own funky names but that's about all that was different. > > Half of my arrays is on labels, but I guess OpenSol will figure it out. > >> Just don't upgrade pool or filesystem by accident. If you do, you will >> not be able to use it back on FreeBSD. > > I don't think I'm re-importing the pool back to bsd, going to play it > safe and just copying the data off and then re-create the pool. Ohshit it worked # zpool status tank pool: tank state: ONLINE status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 c8t1d0p0 ONLINE 0 0 0 c8t2d0s2 ONLINE 0 0 0 c8t3d0p0 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 c8t0d0p0 ONLINE 0 0 0 c8t4d0p0 ONLINE 0 0 0 c8t5d0p0 ONLINE 0 0 0 errors: No known data errors I just did zpool import -f tank and that was it, not complaints. The opensol kernel still sees that the one of the drives has less sectors but doesn't seem to be bothered. Now starts the real work, moving 3.26TB of data... :/ Thanks everyone for the good ideas :) --=20 br, Tommi From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 12:06:12 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0040B106566C for ; Tue, 26 Jan 2010 12:06:11 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id 500308FC08 for ; Tue, 26 Jan 2010 12:06:10 +0000 (UTC) Received: (qmail 883 invoked from network); 26 Jan 2010 13:06:09 +0100 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 26 Jan 2010 13:06:09 +0100 Date: Tue, 26 Jan 2010 13:06:07 +0100 From: Kai Gallasch To: freebsd-fs@freebsd.org Message-ID: <20100126130607.3204351d@orwell.free.de> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.2; powerpc-apple-darwin9.8.0) X-Face: 7"x0zA5=*cXGZw-xjU<">'+!3(KXTUXZVLD42KVN{'go[UQr"Mc.e(XW92N8plZ(9x.{x; I<|95e+b&GH-36\15F~L$YD*Y +u}o&KV?6.%"mJIkaY3G>BKNt`1|Y+%K1P4t; 47D65&(Y7h5Ll-[ltkhamx.-; ,jggK'}oMpUgEHFG YQ"9oXKAl>!d,J}T{)@uxvfu?YFWC*\~h+,^f Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: zfs problem with processes stuck in state zfs and zilog- X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 12:06:12 -0000 Hi. Some mail services (qmail, dovecot) on one of my freebsd jails became unavailable. The jail is using zfs as a filesystem. After logging in I found that I could not kill processes related to the unavailable services running inside the jail and that the jail could not be restartet. top revealed the following: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 8320 root 1 44 0 4772K 1088K zilog- 1 0:58 0.00% multilog 8336 qmaill 1 44 0 4772K 1088K zilog- 6 0:21 0.00% multilog 8464 mysql 2 44 0 108M 70356K STOP 7 0:21 0.00% mysqld 8292 spamd 1 44 0 4772K 1088K zilog- 7 0:18 0.00% multilog 8295 nobody 1 44 0 4772K 1088K zilog- 2 0:10 0.00% multilog 8298 qmaill 1 44 0 4772K 1088K zilog- 3 0:01 0.00% multilog 8294 root 1 44 0 4772K 1088K zilog- 4 0:01 0.00% multilog 8304 qmaill 1 44 0 4772K 1088K zilog- 1 0:01 0.00% multilog 34278 www 1 63 0 29852K 14828K zfs 4 0:00 0.00% perl 34368 www 1 76 0 29852K 14828K zfs 4 0:00 0.00% perl 8319 root 1 44 0 4772K 1088K zilog- 2 0:00 0.00% multilog 4311 qmaild 1 59 0 2792K 1040K zilog- 1 0:00 0.00% qmail-queue 32203 qmaild 1 60 0 2792K 1040K zilog- 0 0:00 0.00% qmail-queue 16225 qmaild 1 59 0 2792K 1040K zilog- 4 0:00 0.00% qmail-queue 32254 qmaild 1 60 0 2792K 1040K zilog- 0 0:00 0.00% qmail-queue 16545 qmaild 1 57 0 2792K 1040K zilog- 4 0:00 0.00% qmail-queue 4521 qmaild 1 56 0 2792K 1040K zilog- 5 0:00 0.00% qmail-queue 8327 root 1 44 0 4772K 1088K zilog- 6 0:00 0.00% multilog 36733 qmaild 1 52 0 2792K 1040K zilog- 4 0:00 0.00% qmail-queue 47903 root 1 44 0 10284K 3412K pause 0 0:00 0.00% tcsh 35517 qmaild 1 63 0 2792K 1040K zilog- 4 0:00 0.00% qmail-queue 35492 qmaild 1 63 0 2792K 1040K zilog- 0 0:00 0.00% qmail-queue 62826 qmaild 1 53 0 2792K 1040K zilog- 4 0:00 0.00% qmail-queue 69033 qmaild 1 53 0 2792K 1040K zilog- 0 0:00 0.00% qmail-queue 66010 qmaild 1 50 0 2792K 1040K zilog- 4 0:00 0.00% qmail-queue 40947 qmaild 1 50 0 2792K 1040K zilog- 0 0:00 0.00% qmail-queue 27726 qmaild 1 51 0 2792K 1040K zilog- 0 0:00 0.00% qmail-queue 35520 qmaild 1 53 0 2792K 1040K zilog- 6 0:00 0.00% qmail-queue 30639 root 1 44 0 12164K 3420K zfs 1 0:00 0.00% perl 23538 root 1 44 0 12164K 3420K zfs 1 0:00 0.00% perl 4834 root 1 76 0 12164K 3420K zfs 1 0:00 0.00% perl 26410 root 1 47 0 12164K 3420K zfs 0 0:00 0.00% perl 97136 root 1 76 0 12164K 3420K zfs 4 0:00 0.00% perl 9290 root 1 44 0 12164K 3420K zfs 1 0:00 0.00% perl 18127 root 1 44 0 12164K 3420K zfs 5 0:00 0.00% perl 12553 root 1 44 0 12164K 3420K zfs 4 0:00 0.00% perl 21574 root 1 44 0 12164K 3420K zfs 4 0:00 0.00% perl 2323 root 1 44 0 12164K 3420K zfs 0 0:00 0.00% perl 68707 root 1 45 0 12164K 3420K zfs 2 0:00 0.00% perl 9294 root 1 44 0 12164K 3420K zfs 1 0:00 0.00% perl 40393 root 1 44 0 12164K 3420K zfs 1 0:00 0.00% perl 41985 root 1 44 0 12164K 3420K zfs 0 0:00 0.00% perl 21672 root 1 44 0 12164K 3420K zfs 0 0:00 0.00% perl 10420 root 1 44 0 12164K 3420K zfs 4 0:00 0.00% perl 6965 root 1 44 0 12164K 3420K zfs 6 0:00 0.00% perl 14132 root 1 44 0 12164K 3420K zfs 1 0:00 0.00% perl 14867 root 1 44 0 12164K 3420K zfs 4 0:00 0.00% perl 77145 root 1 44 0 12164K 3420K zfs 4 0:00 0.00% perl 16534 root 1 44 0 12164K 3420K zfs 0 0:00 0.00% perl 25130 root 1 44 0 12164K 3420K zfs 0 0:00 0.00% perl 63026 root 1 44 0 12164K 3420K zfs 4 0:00 0.00% perl 44663 root 1 44 0 12164K 3420K zfs 4 0:00 0.00% perl 28139 root 1 44 0 12164K 3420K zfs 0 0:00 0.00% perl 34440 root 1 44 0 12164K 3420K zfs 4 0:00 0.00% perl 35619 qmaild 1 46 0 2792K 1040K zilog- 0 0:00 0.00% qmail-queue 26146 root 1 44 0 12164K 3420K zfs 0 0:00 0.00% perl Because the server is in active use, there was no time for me to look into this further - and no trace of the problem in syslog. Any suggestions how to debug this problem and find out what's wrong here? Does the state zilog- give any hint? BTW: FreeBSD 8.0-STABLE-amd64 / zpool version 13 --Kai -- You had mail, but the super-user read it, laughed and deleted it! From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 16:04:40 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1F941065693 for ; Tue, 26 Jan 2010 16:04:40 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABB08FC12 for ; Tue, 26 Jan 2010 16:04:40 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o0QG4d1a028899; Tue, 26 Jan 2010 10:04:39 -0600 (CST) Date: Tue, 26 Jan 2010 10:04:39 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Xin LI In-Reply-To: Message-ID: References: <419976.64363.qm@web110515.mail.gq1.yahoo.com> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Tue, 26 Jan 2010 10:04:39 -0600 (CST) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS - scrub lead to corruption? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:04:40 -0000 On Mon, 25 Jan 2010, Xin LI wrote: >> 16) scrub continues to over 75% (I wasn't watching for the exact #) >> and then *panic* level 12 > > Do you have console access to the server? Try setting up a crash dump > and see if you can obtain a backtrace? > > By the way, 'zpool status -x' may give some information that is useful. Since scrub automatically re-starts after system reboots, it should help to use 'zpool scrub -s pool' immediately after boot (assuming there is enough time to do a console login) to stop the existing scrub. This may defer the panic enough to figure out what is going wrong. I used to get system panics here (Solaris 10) during scrub, but it was eventually determined that a flaky fiber channel card was to blame. Two systems paniced here during 'zfs scrub' and both times it was due to problems with an adaptor card. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 18:03:47 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32027106568D for ; Tue, 26 Jan 2010 18:03:47 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: from web110504.mail.gq1.yahoo.com (web110504.mail.gq1.yahoo.com [67.195.8.252]) by mx1.freebsd.org (Postfix) with SMTP id 002988FC1A for ; Tue, 26 Jan 2010 18:03:46 +0000 (UTC) Received: (qmail 76607 invoked by uid 60001); 26 Jan 2010 18:03:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264529026; bh=C5dWfDgOVH7xUwMg0dy2a1VVVHapctK2AKxbHBKIM8Q=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QnqNF//RHqVss3AEHRzu5sC0FXTapbKOpmqv0Np6aa17ef7vQ75oVl9tX8640ZtO+HxAN58Mtca0CzUjFch5H/QQjaVjtiw4zclgnJNtmwB4qybFMccuf1xFJr9s2jnk7vk8AxKV/zz2WFy5n8Ev48F83uOKRc4nIjivKGuGfgQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2iC1bFpFwC/y751YxvdINfTbvgUEc6qo93tRrBwEG2oJsZh9wOXGU0gF7aC8Dwqug2TedquUpKG4xpVEYA17NdRUMeBbMtFNNjS97jWXQhsMHZFUdydRVeO4f38ahLONveH6+4cFmk6fUSS6u3yaf5w93cK7UKAmjZNZsvj6boA=; Message-ID: <422431.76479.qm@web110504.mail.gq1.yahoo.com> X-YMail-OSG: n6r3MdQVM1mMPgEoVq5e79WxkXmEaknf36S9IE9UPvth5ObYCVz7Azmje4B2BSSx2IwSNIsLO.d.T2f5nN8u0PqWm1WNlFkBuh0YlRTJLoP8paHPwSmEW1g1onDX31mQ19x4FWHTm6XVqqyX6KHX9zt38ORVq15EHVdK_YpaRj3EgIOPSZOx42lKnanbC54XovYaNWOTBj0my8CWpwcJ5OjtP7wfkTHoT9oJfWwNaGuHAA84ekllYXsHEwyo74cSVRLE0q6D6QdTUzugUMKBVImZ3SJqdm2qfankGAYURSyrHZk31XsL6lDikFZ0sj_zvc6oLum58ZoAMwFwXagxcuQj9YxbdESeA5BDCfmpVYwv0fUgJ4gW3xnPzXhxP9EO1n9Q40yUGf_BhQMVzobm78dul3mNBR.2SrkcTUJ_tZNcikoeEDEvm3cyEWXmzvNC77R_HV6v4b0N0oUiyY2CT0Xs6J1488MOieqef84Gsxm.UzowTemEiHuDTZn2Z0Nj7bAYiAWoJA-- Received: from [71.174.61.120] by web110504.mail.gq1.yahoo.com via HTTP; Tue, 26 Jan 2010 10:03:46 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <419976.64363.qm@web110515.mail.gq1.yahoo.com> Date: Tue, 26 Jan 2010 10:03:46 -0800 (PST) From: Paul Pathiakis To: Bob Friesenhahn , Xin LI In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS - scrub lead to corruption? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:03:47 -0000 From: Bob Friesenhahn To: Xin LI Cc: Paul Pathiakis ; freebsd-fs@freebsd.org Sent: Tue, January 26, 2010 11:04:39 AM Subject: Re: ZFS - scrub lead to corruption? On Mon, 25 Jan 2010, Xin LI wrote: >> 16) scrub continues to over 75% (I wasn't watching for the exact #) and then *panic* level 12 > > Do you have console access to the server? Try setting up a crash dump > and see if you can obtain a backtrace? > > By the way, 'zpool status -x' may give some information that is useful. Since scrub automatically re-starts after system reboots, it should help to use 'zpool scrub -s pool' immediately after boot (assuming there is enough time to do a console login) to stop the existing scrub. This may defer the panic enough to figure out what is going wrong. I used to get system panics here (Solaris 10) during scrub, but it was eventually determined that a flaky fiber channel card was to blame. Two systems paniced here during 'zfs scrub' and both times it was due to problems with an adaptor card. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Thank you, Bob. It worked fine. I'm up and working on the machine as I'm typing this. The zpool status says everything's fine. (??!!) That's a relief. However, why did the scrub cause it to crash? I'd like to ask this list a serious question: What can I do to check what is causing scrub to panic the machine? Is there any other consistency tool that I can run on ZFS to see if something is corrupted/wrong? As a forward action, I'm going to cvsup STABLE again and try rebuilding. I'm about to check to see if m4 is still there but I'm worried that the /usr/bin directory is where my trouble exists and I'll be crashing again. Please let me know. (Bob, BTW, I just checked into OpenSolaris bootable CD it's nice, you may want to check it out - FreeBSD is still a passion due to it's BSD storied history.) Thanks! Paul I'd like to ask this list From owner-freebsd-fs@FreeBSD.ORG Tue Jan 26 18:34:53 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AF4D10656BB for ; Tue, 26 Jan 2010 18:34:53 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 330708FC46 for ; Tue, 26 Jan 2010 18:34:52 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o0QIYpca029796; Tue, 26 Jan 2010 12:34:51 -0600 (CST) Date: Tue, 26 Jan 2010 12:34:51 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Paul Pathiakis In-Reply-To: <422431.76479.qm@web110504.mail.gq1.yahoo.com> Message-ID: References: <419976.64363.qm@web110515.mail.gq1.yahoo.com> <422431.76479.qm@web110504.mail.gq1.yahoo.com> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-535438535-1264530891=:17824" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Tue, 26 Jan 2010 12:34:51 -0600 (CST) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS - scrub lead to corruption? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:34:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-535438535-1264530891=:17824 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 26 Jan 2010, Paul Pathiakis wrote: > > Thank you, Bob.  It worked fine.  I'm up and working on the machine > as I'm typing this.  The zpool status says everything's fine. > (??!!)  That's a relief.  However, why did the scrub cause it to > crash?  Zfs scrub is often the most intense thing you will do with your computer. It tends to uncover problems which are not necessarily related to zfs. If you are not using ECC memory, then bad memory is the first thing you should check for. > Please let me know.  (Bob, BTW, I just checked into OpenSolaris > bootable CD it's nice, you may want to check it out - FreeBSD is > still a passion due to it's BSD storied history.) OpenSolaris has not been quite to the state where I feel that I should use it. Perhaps in three months (next OpenSolaris release) the situation will have changed. Meanwhile my FreeBSD system has been solid as a rock since 2003. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ---559023410-535438535-1264530891=:17824-- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 27 18:12:30 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57FDE10657E7 for ; Wed, 27 Jan 2010 18:12:30 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 26A2D8FC1B for ; Wed, 27 Jan 2010 18:12:29 +0000 (UTC) Received: by pzk40 with SMTP id 40so271713pzk.7 for ; Wed, 27 Jan 2010 10:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Dm1oyqSOnUdIf8Ji/26PKBBMAhrpgQke0T2DQwLGKlQ=; b=nuPnq/9L/teyMb9cTCxrvsShJ79fvPhtmUIYdYfQkW2bu/Y2wjofCTjRyovezqzKaG ljB31WGXFSGU/6shGmge8oTtyVldqBNBALEIyrFC6CUIQ53pJ0fs+Vup2CqfVRxPPYzN JRxQ0efheh42Ec5jN/qlEi2NyZfWmiuq5G5XA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=l7MdgQnaW969vMx4QuzYE9xaKOO01B2VIQi3i6/5BxWnDtRot9sTUeyVJhuITMJz/7 s8iDrMz1UTrw3/K8CfxImFwJkFjQLVmY1UZOtnz3BXS/ibxtQ7gd7zWMHJ0/Yi8ZMvP7 2TcZP86ieq/A0eDsjEkVtA7grzv2LTvVL/C/U= MIME-Version: 1.0 Received: by 10.142.151.18 with SMTP id y18mr441211wfd.338.1264614108139; Wed, 27 Jan 2010 09:41:48 -0800 (PST) Date: Wed, 27 Jan 2010 11:41:48 -0600 Message-ID: <179b97fb1001270941m2d8e9c8au20abc798c16b9c11@mail.gmail.com> From: Brandon Gooch To: stable-list freebsd , freebsd-fs@freebsd.org, freebsd-emulation@freebsd.org Content-Type: multipart/mixed; boundary=000e0cd328beb19215047e28eab4 Cc: Subject: ZFS and sh(1) panic: spin lock [lock addr] (smp rendezvous) held by [sh(1) proc tid] too long X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:12:30 -0000 --000e0cd328beb19215047e28eab4 Content-Type: text/plain; charset=ISO-8859-1 The machine, a Dell Optiplex 755, has been locking up recently. The situation usually occurs while using VirtualBox (running a 64-bit Windows 7 instance) and doing anything else in another xterm (such as rebuilding a port). I've been unable to reliably reproduce it (I'm in an X session and the machine will not panic "properly"). However, while rebuilding Xorg today at ttyv0 and runnning VBoxHeadless on ttyv1, I managed to trigger what I believe is the lockup. I've attached a textdump in hopes that someone may be able to take a look and provide clues or instruction on debugging this. Thanks! -Brandon --000e0cd328beb19215047e28eab4 Content-Type: application/octet-stream; name="textdump.tar.0" Content-Disposition: attachment; filename="textdump.tar.0" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g4yelkku0 ZGRiLnR4dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADA2MDAAAAAAMAAAAAAA AAAwAAAAAAAAADE0MDAwMAAAAAAAADExMzMwMDY1MjE1ACAgNzA2NgAgAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAAAHJvb3QAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd2hlZWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABk YjowOmtkYi5lbnRlci5wYW5pYz4gIHJ1biBsb2NraW5mbwpkYjoxOmxvY2tpbmZvPiBzaG93IGxv Y2tzCk5vIHN1Y2ggY29tbWFuZApkYjoxOmxvY2tzPiAgc2hvdyBhbGxsb2NrcwpObyBzdWNoIGNv bW1hbmQKZGI6MTphbGxsb2Nrcz4gIHNob3cgbG9ja2Vkdm5vZHMKTG9ja2VkIHZub2RlcwpkYjow OmtkYi5lbnRlci5wYW5pYz4gIHNob3cgcGNwdQpjcHVpZCAgICAgICAgPSAwCmR5bmFtaWMgcGNw dSAgICA9IDB4NTMyMTgwCmN1cnRocmVhZCAgICA9IDB4ZmZmZmZmMDA4MTEyNmFlMDogcGlkIDE5 MTggImNvbnNvbGUta2l0LWRhZW1vbiIKY3VycGNiICAgICAgID0gMHhmZmZmZmY4MGU4YzkxZDQw CmZwY3VydGhyZWFkICA9IG5vbmUKaWRsZXRocmVhZCAgID0gMHhmZmZmZmYwMDAxODZkNzQwOiBw aWQgMTEgImlkbGU6IGNwdTAiCmN1cnBtYXAgICAgICAgICA9IDAKdHNzcCAgICAgICAgICAgID0g MHhmZmZmZmZmZjgwOGEwYzAwCmNvbW1vbnRzc3AgICAgICA9IDB4ZmZmZmZmZmY4MDhhMGMwMApy c3AwICAgICAgICAgICAgPSAweGZmZmZmZjgwZThjOTFkNDAKZ3MzMnAgICAgICAgICAgID0gMHhm ZmZmZmZmZjgwODlmYTM4CmxkdCAgICAgICAgICAgICA9IDB4ZmZmZmZmZmY4MDg5ZmE3OAp0c3Mg ICAgICAgICAgICAgPSAweGZmZmZmZmZmODA4OWZhNjgKZGI6MDprZGIuZW50ZXIucGFuaWM+ICBi dApUcmFjaW5nIHBpZCAxOTE4IHRpZCAxMDAyMTUgdGQgMHhmZmZmZmYwMDgxMTI2YWUwCmtkYl9l bnRlcigpIGF0IGtkYl9lbnRlcisweDNkCnBhbmljKCkgYXQgcGFuaWMrMHgxN2IKX210eF9sb2Nr X3NwaW5fZmFpbGVkKCkgYXQgX210eF9sb2NrX3NwaW5fZmFpbGVkKzB4MzkKX210eF9sb2NrX3Nw aW4oKSBhdCBfbXR4X2xvY2tfc3BpbisweGIyCnNtcF90bGJfc2hvb3Rkb3duKCkgYXQgc21wX3Rs Yl9zaG9vdGRvd24rMHhmYQpwbWFwX2ludmFsaWRhdGVfcmFuZ2UoKSBhdCBwbWFwX2ludmFsaWRh dGVfcmFuZ2UrMHhhZQp2bV90aHJlYWRfc3RhY2tfZGlzcG9zZSgpIGF0IHZtX3RocmVhZF9zdGFj a19kaXNwb3NlKzB4MmUKdGhyZWFkX2ZyZWUoKSBhdCB0aHJlYWRfZnJlZSsweDNjCnRocmVhZF9y ZWFwKCkgYXQgdGhyZWFkX3JlYXArMHhhMAp0aHJlYWRfYWxsb2MoKSBhdCB0aHJlYWRfYWxsb2Mr MHgxOApjcmVhdGVfdGhyZWFkKCkgYXQgY3JlYXRlX3RocmVhZCsweGFkCmtlcm5fdGhyX25ldygp IGF0IGtlcm5fdGhyX25ldysweDdjCnRocl9uZXcoKSBhdCB0aHJfbmV3KzB4NjgKc3lzY2FsbCgp IGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQot LS0gc3lzY2FsbCAoNDU1LCBGcmVlQlNEIEVMRjY0LCB0aHJfbmV3KSwgcmlwID0gMHg4MDE4N2Q0 OGMsIHJzcCA9IDB4N2ZmZmZmZmZlN2U4LCByYnAgPSAweDgwMWMwOGVjMCAtLS0KZGI6MDprZGIu ZW50ZXIucGFuaWM+ICBwcwogIHBpZCAgcHBpZCAgcGdycCAgIHVpZCAgIHN0YXRlICAgd21lc2cg ICAgICAgICB3Y2hhbiAgICAgICAgY21kCjcwMDQzIDUxMTU5IDQzMjIwICAgICAwICBSKyAgICAg IENQVSAxICAgICAgICAgICAgICAgICAgICAgICBzaAo4ODI2NyAgICAgMSA4ODI2NiAgNzc3NyAg UiAgICAgICAodGhyZWFkZWQpICAgICAgICAgICAgICAgICAgVkJveFNWQwoxMDA0MDMgICAgICAg ICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAwODExNThjODAgVkJveFNWQwox MDA0MDIgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAwMTZjODc0 MDAgVkJveFNWQwoxMDA0MDEgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZm ZmZmZjAwMWY2MjA4MDAgVkJveFNWQwoxMDA0MDAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVkJveFNWQwoxMDAzOTkgICAgICAgICAgICAgICAg ICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAxMzBiMWJjMDAgVkJveFNWQwoxMDAzOTggICAg ICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAxMzBiMWJjODAgVkJveFNW QwoxMDAzOTcgICAgICAgICAgICAgICAgICAgUyAgICAgICBzZWxlY3QgICAweGZmZmZmZjAwMjg1 ZDhiYzAgVkJveFNWQwoxMDAzMzYgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAw eGZmZmZmZjAxOWE2NzdjMDAgaW5pdGlhbCB0aHJlYWQKODgyNjQgODgyNjMgODgyNjMgIDc3Nzcg IFMrICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMTMwNDBlOGMwIGluaXRpYWwgdGhyZWFkCjg4MjYz IDcxMDQ3IDg4MjYzICA3Nzc3ICBSKyAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBW Qm94SGVhZGxlc3MKMTAwNDE2ICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhm ZmZmZmYwMDI3OWYxNjgwIFZCb3hIZWFkbGVzcwoxMDA0MTUgICAgICAgICAgICAgICAgICAgUyAg ICAgICB1Y29uZCAgICAweGZmZmZmZjAwMWJlMmUyMDAgVkJveEhlYWRsZXNzCjEwMDQxNCAgICAg ICAgICAgICAgICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDAwNmI2YTEwMCBWQm94SGVh ZGxlc3MKMTAwNDEzICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYw MDI4NzRlYjAwIFZCb3hIZWFkbGVzcwoxMDA0MTIgICAgICAgICAgICAgICAgICAgUyAgICAgICB1 Y29uZCAgICAweGZmZmZmZjAwODEwMzY4MDAgVkJveEhlYWRsZXNzCjEwMDQxMSAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWQm94SGVhZGxlc3MK MTAwNDEwICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMTMwYjJk NjgwIFZCb3hIZWFkbGVzcwoxMDA0MDkgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAg ICAweGZmZmZmZjAwODExNThkMDAgVkJveEhlYWRsZXNzCjEwMDQwOCAgICAgICAgICAgICAgICAg ICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDA4MTc0OTY4MCBWQm94SGVhZGxlc3MKMTAwNDA3 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZC b3hIZWFkbGVzcwoxMDA0MDYgICAgICAgICAgICAgICAgICAgUnVuICAgICBDUFUgMyAgICAgICAg ICAgICAgICAgICAgICAgVkJveEhlYWRsZXNzCjEwMDQwNCAgICAgICAgICAgICAgICAgICBTICAg ICAgIHVjb25kICAgIDB4ZmZmZmZmMDAxZmEwYzg4MCBWQm94SGVhZGxlc3MKMTAwMzk2ICAgICAg ICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMTlhNjc3MjgwIFZCb3hIZWFk bGVzcwoxMDAzOTUgICAgICAgICAgICAgICAgICAgUyAgICAgICBzZWxlY3QgICAweGZmZmZmZjAw Mjg3OTA2NDAgVkJveEhlYWRsZXNzCjEwMDM5NCAgICAgICAgICAgICAgICAgICBTICAgICAgIHdh aXQgICAgIDB4ZmZmZmZmMDAzMzc2MTQ2MCBWQm94SGVhZGxlc3MKMTAwMzc5ICAgICAgICAgICAg ICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMDFmODA5MDgwIGluaXRpYWwgdGhyZWFk CjUxMTU5IDUxMTIwIDQzMjIwICAgICAwICBTKyAgICAgIHdhaXQgICAgIDB4ZmZmZmZmMDEzMDc1 ZDQ2MCBzaAo1MTEyMCA1MDc5OCA0MzIyMCAgICAgMCAgUysgICAgICB3YWl0ICAgICAweGZmZmZm ZjAwODExMWUwMDAgc2gKNTA3OTggNDMyMjAgNDMyMjAgICAgIDAgIFMrICAgICAgd2FpdCAgICAg MHhmZmZmZmYwMWE0YzczOGMwIHNoCjQ5MTc3ICAgICAxIDQ5MTc3ICAgICAwICBTcyAgICAgIGFj Y2VwdCAgIDB4ZmZmZmZmMDA4MTA1MjMwZSBuZXRzZXJ2ZXIKNzEwNDcgIDE5MDQgNzEwNDcgIDc3 NzcgIFMrICAgICAgcGF1c2UgICAgMHhmZmZmZmYwMDA2YzU5MGEwIHRjc2gKNDMyMjAgIDE5NzUg NDMyMjAgICAgIDAgIFMrICAgICAgd2FpdCAgICAgMHhmZmZmZmYwMDA2YzU4MDAwIHNoCjExOTYy ICAgICAxIDExOTYxICA3Nzc3ICBSICAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBW Qm94U1ZDCjEwMDMxMyAgICAgICAgICAgICAgICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZm MDAxNjQzMjU4MCBWQm94U1ZDCjEwMDM0MyAgICAgICAgICAgICAgICAgICBTICAgICAgIHVjb25k ICAgIDB4ZmZmZmZmMDAwNjdlYjA4MCBWQm94U1ZDCjEwMDM0MSAgICAgICAgICAgICAgICAgICBT ICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDEzMGIxYmEwMCBWQm94U1ZDCjEwMDM0MCAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWQm94U1ZDCjEw MDMzOSAgICAgICAgICAgICAgICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDE5YTZlOGEw MCBWQm94U1ZDCjEwMDMzOCAgICAgICAgICAgICAgICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZm ZmZmMDAwNjdlYjE4MCBWQm94U1ZDCjEwMDMzNyAgICAgICAgICAgICAgICAgICBTICAgICAgIHVj b25kICAgIDB4ZmZmZmZmMDAwNjdlYjIwMCBWQm94U1ZDCjEwMDMyMSAgICAgICAgICAgICAgICAg ICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDE5YTRlNjc4MCBpbml0aWFsIHRocmVhZAogMTk3 NSAgMTkwMyAgMTk3NSAgNzc3NyAgUysgICAgICBwYXVzZSAgICAweGZmZmZmZjAwODExNTY1MDAg dGNzaAogMTkxOCAgICAgMSAgMTkxOCAgICAgMCAgUnMgICAgICAodGhyZWFkZWQpICAgICAgICAg ICAgICAgICAgY29uc29sZS1raXQtZGFlbW9uCjEwMDIzNSAgICAgICAgICAgICAgICAgICBTICAg ICAgIHdhaXR2dCAgIDB4ZmZmZmZmZmY4MDgyZDYyMCBjb25zb2xlLWtpdC1kYWVtb24KMTAwMjQy ICAgICAgICAgICAgICAgICAgIFMgICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZmZjgwODJkNjU4IGNv bnNvbGUta2l0LWRhZW1vbgoxMDAyNDEgICAgICAgICAgICAgICAgICAgUyAgICAgICB3YWl0dnQg ICAweGZmZmZmZmZmODA4MmQ2NTAgY29uc29sZS1raXQtZGFlbW9uCjEwMDI0MCAgICAgICAgICAg ICAgICAgICBTICAgICAgIHdhaXR2dCAgIDB4ZmZmZmZmZmY4MDgyZDY0OCBjb25zb2xlLWtpdC1k YWVtb24KMTAwMjM5ICAgICAgICAgICAgICAgICAgIFMgICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZm ZjgwODJkNjQwIGNvbnNvbGUta2l0LWRhZW1vbgoxMDAyMzggICAgICAgICAgICAgICAgICAgUyAg ICAgICB3YWl0dnQgICAweGZmZmZmZmZmODA4MmQ2MzggY29uc29sZS1raXQtZGFlbW9uCjEwMDIz NyAgICAgICAgICAgICAgICAgICBTICAgICAgIHdhaXR2dCAgIDB4ZmZmZmZmZmY4MDgyZDYzMCBj b25zb2xlLWtpdC1kYWVtb24KMTAwMjM2ICAgICAgICAgICAgICAgICAgIFMgICAgICAgd2FpdHZ0 ICAgMHhmZmZmZmZmZjgwODJkNjI4IGNvbnNvbGUta2l0LWRhZW1vbgoxMDAyMzQgICAgICAgICAg ICAgICAgICAgUyAgICAgICB3YWl0dnQgICAweGZmZmZmZmZmODA4MmQ2MTggY29uc29sZS1raXQt ZGFlbW9uCjEwMDIzMyAgICAgICAgICAgICAgICAgICBTICAgICAgIHdhaXR2dCAgIDB4ZmZmZmZm ZmY4MDgyZDYxMCBjb25zb2xlLWtpdC1kYWVtb24KMTAwMjMyICAgICAgICAgICAgICAgICAgIFMg ICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZmZjgwODJkNjA4IGNvbnNvbGUta2l0LWRhZW1vbgoxMDAy MzEgICAgICAgICAgICAgICAgICAgUyAgICAgICB3YWl0dnQgICAweGZmZmZmZmZmODA4MmQ2MDAg Y29uc29sZS1raXQtZGFlbW9uCjEwMDIzMCAgICAgICAgICAgICAgICAgICBTICAgICAgIHdhaXR2 dCAgIDB4ZmZmZmZmZmY4MDgyZDVmOCBjb25zb2xlLWtpdC1kYWVtb24KMTAwMjI5ICAgICAgICAg ICAgICAgICAgIFMgICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZmZjgwODJkNWYwIGNvbnNvbGUta2l0 LWRhZW1vbgoxMDAyMjcgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZm ZjAwODEyOGZlMDAgY29uc29sZS1raXQtZGFlbW9uCjEwMDIxNSAgICAgICAgICAgICAgICAgICBS dW4gICAgIENQVSAwICAgICAgICAgICAgICAgICAgICAgICBjb25zb2xlLWtpdC1kYWVtb24KIDE5 MTAgICAgIDEgIDE5MTAgICAgIDAgIFNzKyAgICAgdHR5aW4gICAgMHhmZmZmZmYwMDA2MjlhOGE4 IGdldHR5CiAxOTA5ICAgICAxICAxOTA5ICAgICAwICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZm MDAwNjI5YWNhOCBnZXR0eQogMTkwOCAgICAgMSAgMTkwOCAgICAgMCAgU3MrICAgICB0dHlpbiAg ICAweGZmZmZmZjAwMDYyOWIwYTggZ2V0dHkKIDE5MDcgICAgIDEgIDE5MDcgICAgIDAgIFNzKyAg ICAgdHR5aW4gICAgMHhmZmZmZmYwMDA2MjliNGE4IGdldHR5CiAxOTA2ICAgICAxICAxOTA2ICAg ICAwICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZmMDAwNjI4YzBhOCBnZXR0eQogMTkwNSAgICAg MSAgMTkwNSAgICAgMCAgU3MrICAgICB0dHlpbiAgICAweGZmZmZmZjAwMDYyNTg4YTggZ2V0dHkK IDE5MDQgICAgIDEgIDE5MDQgICAgIDAgIFNzKyAgICAgd2FpdCAgICAgMHhmZmZmZmYwMDgxMzIw MDAwIGxvZ2luCiAxOTAzICAgICAxICAxOTAzICAgICAwICBTcysgICAgIHdhaXQgICAgIDB4ZmZm ZmZmMDA4MTMyMDQ2MCBsb2dpbgogMTgyOCAgICAgMSAgMTgyOCAgICAgMCAgU3MgICAgICBuYW5z bHAgICAweGZmZmZmZmZmODA4MzI5ZTggY3JvbgogMTgyMSAgICAgMSAgMTgyMSAgICAyNSAgU3Mg ICAgICBwYXVzZSAgICAweGZmZmZmZjAwODEzMjU5NjAgc2VuZG1haWwKIDE4MTcgICAgIDEgIDE4 MTcgICAgIDAgIFJzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbmRtYWlsCiAx ODA0ICAgICAxICAxODA0ICAgICAwICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDA4MTE1ODFj MCBzc2hkCiAxNzA1ICAgICAxICAxNzA1ICAgNTU2ICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZm MDA4MTE1ODM0MCBkYnVzLWRhZW1vbgogMTY0NSAgICAgMSAgMTY0NSAgICAgMCAgU3MgICAgICBz ZWxlY3QgICAweGZmZmZmZjAwODExNTg0YzAgcG93ZXJkCiAxNTUzICAgICAxICAxNTUzICAgICAw ICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDA4MTE1ODA0MCBzc2hkCiAxNTE4ICAxNTE3ICAx NTE3ICAgICAwICBSICAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBuZnNkCjEwMDE4 NCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBu ZnNkOiBzZXJ2aWNlCjEwMDE4MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBuZnNkOiBzZXJ2aWNlCjEwMDE4MiAgICAgICAgICAgICAgICAgICBS dW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZnNkOiBzZXJ2aWNlCjEwMDEyNiAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZnNk OiBtYXN0ZXIKIDE1MTcgICAgIDEgIDE1MTcgICAgIDAgIFNzICAgICAgc2VsZWN0ICAgMHhmZmZm ZmYwMDgxMDM2OTQwIG5mc2QKIDE1MTUgICAgIDEgIDE1MTUgICAgIDAgIFNzICAgICAgc2VsZWN0 ICAgMHhmZmZmZmYwMDA2ZjA2ZDQwIG1vdW50ZAogMTQyNiAgICAgMSAgMTQyNiAgICAgMCAgU3Mg ICAgICBzZWxlY3QgICAweGZmZmZmZjAwMDZmNzkzYzAgYW1kCiAxMzk5ICAgICAxICAxMzk5ICAg ICAwICBScyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBycGNiaW5kCiAxMzc0ICAg ICAxICAxMzc0ICAgICAwICBScyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzeXNs b2dkCiAxMTU0ICAgICAxICAxMTU0ICAgICAwICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDAw NmYwNjBjMCBkZXZkCiAgOTUyICAgICAxICAgOTUyICAgICAwICBTcyAgICAgIHNlbGVjdCAgIDB4 ZmZmZmZmMDAwNmVlNTU0MCBtb3VzZWQKICA3NDMgICAgIDEgICA3NDMgICAgNjUgIFNzICAgICAg c2VsZWN0ICAgMHhmZmZmZmYwMDA2ZWViNWMwIGRoY2xpZW50CiAgNzI5ICAgICAxICAgNzI5ICAg ICAwICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDAwNmYwNzY0MCBkaGNsaWVudAogIDU3MSAg ICAgMSAgIDU3MSAgICA2NSAgU3MgICAgICBzZWxlY3QgICAweGZmZmZmZjAwMDZmMDY1YzAgZGhj bGllbnQKICA1NTMgICAgIDEgICA1NTMgICAgIDAgIFNzICAgICAgc2VsZWN0ICAgMHhmZmZmZmYw MDA2ZGQ5OTQwIGRoY2xpZW50CiAgMTA0ICAgICAwICAgICAwICAgICAwICBTTCAgICAgICh0aHJl YWRlZCkgICAgICAgICAgICAgICAgICBuZ19xdWV1ZQoxMDAxNDggICAgICAgICAgICAgICAgICAg RCAgICAgICBzbGVlcCAgICAweGZmZmZmZmZmODBlNGNlYjAgW25nX3F1ZXVlM10KMTAwMTQ3ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgc2xlZXAgICAgMHhmZmZmZmZmZjgwZTRjZWIwIFtuZ19x dWV1ZTJdCjEwMDE0NiAgICAgICAgICAgICAgICAgICBEICAgICAgIHNsZWVwICAgIDB4ZmZmZmZm ZmY4MGU0Y2ViMCBbbmdfcXVldWUxXQoxMDAxMjEgICAgICAgICAgICAgICAgICAgRCAgICAgICBz bGVlcCAgICAweGZmZmZmZmZmODBlNGNlYjAgW25nX3F1ZXVlMF0KICAgMjIgICAgIDAgICAgIDAg ICAgIDAgIFNMICAgICAgbTp3MSAgICAgMHhmZmZmZmYwMDA2NDNhYzAwIFtnX21pcnJvciBzd2Fw XQogICAyMSAgICAgMCAgICAgMCAgICAgMCAgU0wgICAgICBmbG93Y2xlYSAweGZmZmZmZmZmODA4 NTcxOTAgW2Zsb3djbGVhbmVyXQogICAyMCAgICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW3NvZnRkZXBmbHVzaF0KICAgMTkgICAgIDAgICAgIDAg ICAgIDAgIFNMICAgICAgdmxydXd0ICAgMHhmZmZmZmYwMDA2NDM3MDAwIFt2bmxydV0KICAgMTgg ICAgIDAgICAgIDAgICAgIDAgIFJMICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtz eW5jZXJdCiAgIDE3ICAgICAwICAgICAwICAgICAwICBSTCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbYnVmZGFlbW9uXQogICAxNiAgICAgMCAgICAgMCAgICAgMCAgU0wgICAgICBw Z3plcm8gICAweGZmZmZmZmZmODA4Njg0NGMgW3BhZ2V6ZXJvXQogICAgOSAgICAgMCAgICAgMCAg ICAgMCAgU0wgICAgICBwc2xlZXAgICAweGZmZmZmZmZmODA4Njc3ZTggW3ZtZGFlbW9uXQogICAg OCAgICAgMCAgICAgMCAgICAgMCAgU0wgICAgICBwc2xlZXAgICAweGZmZmZmZmZmODA4Njc3YWMg W3BhZ2VkYWVtb25dCiAgIDE1ICAgICAwICAgICAwICAgICAwICBTTCAgICAgIElQUlQgRXZlIDB4 ZmZmZmZmMDAwNjI0MGM5MCBbVElNRVJdCiAgICA3ICAgICAwICAgICAwICAgICAwICBSTCAgICAg ICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICB6ZnNrZXJuCjEwMDExMSAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbdHhnX3RocmVhZF9lbnRl cl0KMTAwMTEwICAgICAgICAgICAgICAgICAgIEQgICAgICAgdHgtPnR4X3EgMHhmZmZmZmYwMDA2 NmZkMjYwIFt0eGdfdGhyZWFkX2VudGVyXQoxMDAxMDggICAgICAgICAgICAgICAgICAgRCAgICAg ICB2Z2VvbTppbyAweGZmZmZmZjAwMDY0ZjBhOTAgW3ZkZXYgZ3B0L2Rpc2sxXQoxMDAxMDcgICAg ICAgICAgICAgICAgICAgRCAgICAgICB2Z2VvbTppbyAweGZmZmZmZjAwMDY0ZjBkMTAgW3ZkZXYg Z3B0L2Rpc2swXQoxMDAwNjkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW2wyYXJjX2ZlZWRfdGhyZWFkXQoxMDAwNjggICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2FyY19yZWNsYWltX3RocmVh ZF0KICAgIDYgICAgIDAgICAgIDAgICAgIDAgIFJMICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtmZGMwXQogICAxNCAgICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAodGhyZWFkZWQp ICAgICAgICAgICAgICAgICAgdXNiCjEwMDA2MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbdXNidXM2XQoxMDAwNjIgICAgICAgICAgICAgICAg ICAgRCAgICAgICBXQ1RSTCAgICAweGZmZmZmZjAwMDYzYTAwYjAgW3VzYnVzNl0KMTAwMDYxICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwNDAwZDIwIFt1c2J1 czZdCjEwMDA2MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAw MDQwMGNjOCBbdXNidXM2XQoxMDAwNTkgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjgwMDAzZjdlZjAgW3VzYnVzNV0KMTAwMDU4ICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2Y3ZTk4IFt1c2J1czVdCjEwMDA1NyAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNmN2U0MCBbdXNidXM1XQox MDAwNTYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzZjdk ZTggW3VzYnVzNV0KMTAwMDU1ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmY4MDAwM2VlZWYwIFt1c2J1czRdCjEwMDA1NCAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmODAwMDNlZWU5OCBbdXNidXM0XQoxMDAwNTMgICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzZWVlNDAgW3VzYnVzNF0KMTAwMDUy ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2VlZGU4IFt1 c2J1czRdCjEwMDA1MSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm ODAwMDNlNWVmMCBbdXNidXMzXQoxMDAwNTAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGZmZmZmZjgwMDAzZTVlOTggW3VzYnVzM10KMTAwMDQ5ICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2U1ZTQwIFt1c2J1czNdCjEwMDA0OCAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNlNWRlOCBbdXNidXMz XQoxMDAwNDUgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAz ZGNkZDAgW3VzYnVzMl0KMTAwMDQ0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAg MHhmZmZmZmY4MDAwM2RjZDc4IFt1c2J1czJdCjEwMDA0MyAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNkY2QyMCBbdXNidXMyXQoxMDAwNDIgICAgICAgICAg ICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzZGNjYzggW3VzYnVzMl0KMTAw MDQwICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2QzZWYw IFt1c2J1czFdCjEwMDAzOSAgICAgICAgICAgICAgICAgICBMICAgICAgKnVoY2kxICAgIDB4ZmZm ZmZmMDAwMTYxZTBjMCBbdXNidXMxXQoxMDAwMzggICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjgwMDAzZDNlNDAgW3VzYnVzMV0KMTAwMDM3ICAgICAgICAgICAgICAg ICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2QzZGU4IFt1c2J1czFdCjEwMDAzNSAg ICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNjYWVmMCBbdXNi dXMwXQoxMDAwMzQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgw MDAzY2FlOTggW3VzYnVzMF0KMTAwMDMzICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmY4MDAwM2NhZTQwIFt1c2J1czBdCjEwMDAzMiAgICAgICAgICAgICAgICAgICBE ICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNjYWRlOCBbdXNidXMwXQogICAgNSAgICAgMCAg ICAgMCAgICAgMCAgU0wgICAgICBjY2Jfc2NhbiAweGZmZmZmZmZmODA4MTZjZTAgW3hwdF90aHJk XQogICAxMyAgICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW3lhcnJvd10KICAgIDQgICAgIDAgICAgIDAgICAgIDAgIFNMICAgICAgLSAgICAgICAg MHhmZmZmZmZmZjgwODJlZTA4IFtnX2Rvd25dCiAgICAzICAgICAwICAgICAwICAgICAwICBTTCAg ICAgIC0gICAgICAgIDB4ZmZmZmZmZmY4MDgyZWUwMCBbZ191cF0KICAgIDIgICAgIDAgICAgIDAg ICAgIDAgIFJMICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtnX2V2ZW50XQogICAx MiAgICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAodGhyZWFkZWQpICAgICAgICAgICAgICAgICAg aW50cgoxMDAwNjcgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW2lycTE6IGF0a2JkMF0KMTAwMDY2ICAgICAgICAgICAgICAgICAgIEkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2kwOiB1YXJ0XQoxMDAwNjQgICAgICAgICAg ICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTI1ODogYWhj aTBdCjEwMDA0NyAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbaXJxMjM6IHVoY2kyIGVoY2kxXQoxMDAwNDYgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTI1NzogaGRhYzBdCjEwMDA0MSAg ICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJx MjI6IGVoY2kwXQoxMDAwMzYgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW2lycTE3OiB1aGNpMSB1aGNpM10KMTAwMDMxICAgICAgICAgICAgICAg ICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtpcnExNjogdWhjaTArXQox MDAwMjkgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW2lycTE4OiBybDAgYXRhcGNpMCtdCjEwMDAyOCAgICAgICAgICAgICAgICAgICBJICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJxOTogYWNwaTBdCjEwMDAyNyAgICAgICAg ICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpMjogY2Ft YmlvXQoxMDAwMjUgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW3N3aTY6IHRhc2sgcXVldWVdCjEwMDAyNCAgICAgICAgICAgICAgICAgICBJICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNjogR2lhbnQgdGFza3FdCjEwMDAy MiAgICAgICAgICAgICAgICAgICBSdW4gICAgIENQVSAyICAgICAgICAgICAgICAgICAgICAgICBb c3dpNTogK10KMTAwMDEyICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtzd2k0OiBjbG9ja10KMTAwMDExICAgICAgICAgICAgICAgICAgIEkgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2k0OiBjbG9ja10KMTAwMDEwICAgICAg ICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2k0OiBj bG9ja10KMTAwMDA5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtzd2k0OiBjbG9ja10KMTAwMDA4ICAgICAgICAgICAgICAgICAgIEkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2kxOiBuZXRpc3IgMF0KMTAwMDA3ICAgICAg ICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2kzOiB2 bV0KICAgMTEgICAgIDAgICAgIDAgICAgIDAgIFJMICAgICAgKHRocmVhZGVkKSAgICAgICAgICAg ICAgICAgIGlkbGUKMTAwMDA2ICAgICAgICAgICAgICAgICAgIENhblJ1biAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtpZGxlOiBjcHUwXQoxMDAwMDUgICAgICAgICAgICAgICAgICAgQ2Fu UnVuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lkbGU6IGNwdTFdCjEwMDAwNCAgICAg ICAgICAgICAgICAgICBDYW5SdW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaWRsZTog Y3B1Ml0KMTAwMDAzICAgICAgICAgICAgICAgICAgIENhblJ1biAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtpZGxlOiBjcHUzXQogICAgMSAgICAgMCAgICAgMSAgICAgMCAgU0xzICAgICB3 YWl0ICAgICAweGZmZmZmZjAwMDE4NWQ4YzAgW2luaXRdCiAgIDEwICAgICAwICAgICAwICAgICAw ICBTTCAgICAgIGF1ZGl0X3dvIDB4ZmZmZmZmZmY4MDg2NWQxMCBbYXVkaXRdCiAgICAwICAgICAw ICAgICAwICAgICAwICBTTHMgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBrZXJuZWwK MTAwMTQ1ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2Yjk1 NjgwIFt6aWxfY2xlYW5dCjEwMDE0NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmMDAwNmI5NWQ4MCBbemlsX2NsZWFuXQoxMDAxNDMgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDZiOTY1ODAgW3ppbF9jbGVhbl0KMTAwMTQyICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2YjU3ZDgwIFt6aWxf Y2xlYW5dCjEwMDE0MSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm MDAwNmI2NjU4MCBbemlsX2NsZWFuXQoxMDAxNDAgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwMDZiNjZjMDAgW3ppbF9jbGVhbl0KMTAwMTM5ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2YjY4MDAwIFt6aWxfY2xlYW5dCjEw MDEzOCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNmI2ODY4 MCBbemlsX2NsZWFuXQoxMDAxMzcgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAw eGZmZmZmZjAwMDZiNjk5ODAgW3ppbF9jbGVhbl0KMTAwMTM2ICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2YjE0YTgwIFt6aWxfY2xlYW5dCjEwMDEzNSAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNmI1NDM4MCBbemlsX2Ns ZWFuXQoxMDAxMzQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAw MDZiNTRiMDAgW3ppbF9jbGVhbl0KMTAwMTMzICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAg ICAgICAgMHhmZmZmZmYwMDA2YjEzMzgwIFt6aWxfY2xlYW5dCjEwMDEzMiAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNmIxMjU4MCBbemlsX2NsZWFuXQoxMDAx MzEgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDZiMTEwODAg W3ppbF9jbGVhbl0KMTAwMTMwICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmYwMDA2YjEwMjgwIFt6aWxfY2xlYW5dCjEwMDExMiAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjQyODAwMCBbemlsX2NsZWFuXQoxMDAxMDkgICAgICAg ICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY0NDIzMDAgW3pmc192bl9y ZWxlX3Rhc2txXQoxMDAxMDYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZm ZmZmZjAwMDY2NWIxMDAgW3NwYV96aW9dCjEwMDEwNSAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjE4MCBbc3BhX3ppb10KMTAwMTA0ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjViMjAwIFtzcGFfemlvXQoxMDAx MDMgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWIyODAg W3NwYV96aW9dCjEwMDEwMiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwNjY1YjMwMCBbc3BhX3ppb10KMTAwMTAxICAgICAgICAgICAgICAgICAgIEQgICAgICAg LSAgICAgICAgMHhmZmZmZmYwMDA2NjViMzgwIFtzcGFfemlvXQoxMDAxMDAgICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWI0MDAgW3NwYV96aW9dCjEwMDA5 OSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjQ4MCBb c3BhX3ppb183XQoxMDAwOTggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZm ZmZmZjAwMDY2NWI0ODAgW3NwYV96aW9fNl0KMTAwMDk3ICAgICAgICAgICAgICAgICAgIEQgICAg ICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjViNDgwIFtzcGFfemlvXzVdCjEwMDA5NiAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjQ4MCBbc3BhX3ppb180 XQoxMDAwOTUgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2 NWI0ODAgW3NwYV96aW9fM10KMTAwMDk0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmYwMDA2NjViNDgwIFtzcGFfemlvXzJdCjEwMDA5MyAgICAgICAgICAgICAgICAg ICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjQ4MCBbc3BhX3ppb18xXQoxMDAwOTIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWI0ODAgW3Nw YV96aW9fMF0KMTAwMDkxICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZm ZmYwMDA2NjViNTAwIFtzcGFfemlvXzddCjEwMDA5MCAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjUwMCBbc3BhX3ppb182XQoxMDAwODkgICAgICAgICAg ICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWI1MDAgW3NwYV96aW9fNV0K MTAwMDg4ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjVi NTAwIFtzcGFfemlvXzRdCjEwMDA4NyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmMDAwNjY1YjUwMCBbc3BhX3ppb18zXQoxMDAwODYgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWI1MDAgW3NwYV96aW9fMl0KMTAwMDg1ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjViNTAwIFtzcGFf emlvXzFdCjEwMDA4NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm MDAwNjY1YjUwMCBbc3BhX3ppb18wXQoxMDAwODMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwMDY2NWI1ODAgW3NwYV96aW9dCjEwMDA4MiAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjYwMCBbc3BhX3ppb10KMTAwMDgx ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjViNjgwIFtz cGFfemlvXQoxMDAwNzEgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZm ZjAwMDYyOTdiODAgW2R1bW15bmV0XQoxMDAwMzAgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwMDE5YWMwMDAgW2VtMCB0YXNrcV0KMTAwMDIzICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDAxOTNkMzgwIFt0aHJlYWQgdGFza3Fd CjEwMDAyMSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwMThm MmQwMCBba3F1ZXVlIHRhc2txXQoxMDAwMjAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGZmZmZmZjAwMDE4ZjJjMDAgW2FjcGlfdGFza18yXQoxMDAwMTkgICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDE4ZjJjMDAgW2FjcGlfdGFza18xXQox MDAwMTggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDE4ZjJj MDAgW2FjcGlfdGFza18wXQoxMDAwMTYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjAwMDE4NWE2ODAgW2Zpcm13YXJlIHRhc2txXQoxMDAwMDAgICAgICAgICAgICAg ICAgICAgRCAgICAgICBzY2hlZCAgICAweGZmZmZmZmZmODA4MmVmMDAgW3N3YXBwZXJdCmRiOjA6 a2RiLmVudGVyLnBhbmljPiAgYWxsdHJhY2UKClRyYWNpbmcgY29tbWFuZCBzaCBwaWQgNzAwNDMg dGlkIDEwMDMzMyB0ZCAweGZmZmZmZjAxOWE3NDFhZTAKY3B1c3RvcF9oYW5kbGVyKCkgYXQgY3B1 c3RvcF9oYW5kbGVyKzB4NDAKaXBpX25taV9oYW5kbGVyKCkgYXQgaXBpX25taV9oYW5kbGVyKzB4 MzAKdHJhcCgpIGF0IHRyYXArMHgxOTUKbm1pX2NhbGx0cmFwKCkgYXQgbm1pX2NhbGx0cmFwKzB4 OAotLS0gdHJhcCAweDEzLCByaXAgPSAweGZmZmZmZmZmODA1YTBhY2IsIHJzcCA9IDB4ZmZmZmZm ODAwMDAyM2ZlMCwgcmJwID0gMHhmZmZmZmY4MGU4ZWRmNDIwIC0tLQpzbXBfdGxiX3Nob290ZG93 bigpIGF0IHNtcF90bGJfc2hvb3Rkb3duKzB4OWIKcG1hcF9pbnZhbGlkYXRlX3BhZ2UoKSBhdCBw bWFwX2ludmFsaWRhdGVfcGFnZSsweDdiCnBtYXBfcmVtb3ZlX3B0ZSgpIGF0IHBtYXBfcmVtb3Zl X3B0ZSsweGVmCnBtYXBfcmVtb3ZlKCkgYXQgcG1hcF9yZW1vdmUrMHgyZDQKdm1fbWFwX2RlbGV0 ZSgpIGF0IHZtX21hcF9kZWxldGUrMHhmNAp2bV9tYXBfcmVtb3ZlKCkgYXQgdm1fbWFwX3JlbW92 ZSsweDUxCnVtYV9sYXJnZV9mcmVlKCkgYXQgdW1hX2xhcmdlX2ZyZWUrMHg1NQpmcmVlKCkgYXQg ZnJlZSsweDc3CmFyY19idWZfZGVzdHJveSgpIGF0IGFyY19idWZfZGVzdHJveSsweDEwMQphcmNf aGRyX2Rlc3Ryb3koKSBhdCBhcmNfaGRyX2Rlc3Ryb3krMHgyMjUKYXJjX2J1Zl9yZW1vdmVfcmVm KCkgYXQgYXJjX2J1Zl9yZW1vdmVfcmVmKzB4ZWMKZGJ1Zl9uZXdfc2l6ZSgpIGF0IGRidWZfbmV3 X3NpemUrMHhkOApkbm9kZV9zZXRfYmxrc3ooKSBhdCBkbm9kZV9zZXRfYmxrc3orMHgyYWUKZG11 X29iamVjdF9zZXRfYmxvY2tzaXplKCkgYXQgZG11X29iamVjdF9zZXRfYmxvY2tzaXplKzB4NGMK emZzX2dyb3dfYmxvY2tzaXplKCkgYXQgemZzX2dyb3dfYmxvY2tzaXplKzB4NDUKemZzX2ZyZWVi c2Rfd3JpdGUoKSBhdCB6ZnNfZnJlZWJzZF93cml0ZSsweDlkMwpWT1BfV1JJVEVfQVBWKCkgYXQg Vk9QX1dSSVRFX0FQVisweGM2CnZuX3dyaXRlKCkgYXQgdm5fd3JpdGUrMHgyZDcKZG9maWxld3Jp dGUoKSBhdCBkb2ZpbGV3cml0ZSsweDg1Cmtlcm5fd3JpdGV2KCkgYXQga2Vybl93cml0ZXYrMHg2 MAp3cml0ZSgpIGF0IHdyaXRlKzB4NTUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rf c3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNCwgRnJlZUJTRCBF TEY2NCwgd3JpdGUpLCByaXAgPSAweDgwMDliY2EzYywgcnNwID0gMHg3ZmZmZmZmZmFlOTgsIHJi cCA9IDB4ODAwYzFjMDAwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDg4MjY3IHRp ZCAxMDA0MDMgdGQgMHhmZmZmZmYwMDgxMTU5M2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3 aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3Np Z25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBh dCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0 KCkgYXQgZG9fY3Zfd2FpdCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9j dl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0 IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10 eF9vcCksIHJpcCA9IDB4ODAxMzQ2MjljLCByc3AgPSAweDdmZmZmZjliOGRmOCwgcmJwID0gMHg4 MDI0M2MzYzAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgODgyNjcgdGlkIDEwMDQw MiB0ZCAweGZmZmZmZjAwOTlhNTgwMDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4 MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygp IGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVw cV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBk b19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQr MHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rf c3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwg cmlwID0gMHg4MDEzNDYyOWMsIHJzcCA9IDB4N2ZmZmZmYTM5ZDc4LCByYnAgPSAweDgwMjQzYzU4 MCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCA4ODI2NyB0aWQgMTAwNDAxIHRkIDB4 ZmZmZmZmMDAyZGFjMjNhMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlf c3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xl ZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3RpbWVkd2FpdF9zaWcoKSBhdCBzbGVlcHFf dGltZWR3YWl0X3NpZysweDE5Cl9zbGVlcCgpIGF0IF9zbGVlcCsweDFhMwpkb19jdl93YWl0KCkg YXQgZG9fY3Zfd2FpdCsweDY0MApfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93 YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhm YXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9v cCksIHJpcCA9IDB4ODAxMzQ2MjljLCByc3AgPSAweDdmZmZmZmFiYWNjOCwgcmJwID0gMHg4MDI0 M2M3NDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgODgyNjcgdGlkIDEwMDQwMCB0 ZCAweGZmZmZmZjAxOWE3MzZhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4 Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0 IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV90aW1lZHdhaXRfc2lnKCkgYXQgc2xl ZXBxX3RpbWVkd2FpdF9zaWcrMHgxOQpfc2xlZXAoKSBhdCBfc2xlZXArMHgxYTMKZG9fY3Zfd2Fp dCgpIGF0IGRvX2N2X3dhaXQrMHg2NDAKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3Bf Y3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBh dCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3Vt dHhfb3ApLCByaXAgPSAweDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmZiM2JlMjgsIHJicCA9IDB4 ODAyNDNjYWMwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDg4MjY3IHRpZCAxMDAz OTkgdGQgMHhmZmZmZmYwMTMwYjM1NzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsw eDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMo KSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVl cHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQg ZG9fY3Zfd2FpdCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0 KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0 X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCks IHJpcCA9IDB4ODAxMzQ2MjljLCByc3AgPSAweDdmZmZmZmJiY2UyOCwgcmJwID0gMHg4MDIwOTYx YzAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgODgyNjcgdGlkIDEwMDM5OCB0ZCAw eGZmZmZmZjAxMzBiMzUzYTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1p X3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNs ZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0 X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93 YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1Ywpz eXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2Fs bCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0g MHg4MDEzNDYyOWMsIHJzcCA9IDB4N2ZmZmZmYmRkZGY4LCByYnAgPSAweDgwMjA5NjM4MCAtLS0K ClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCA4ODI2NyB0aWQgMTAwMzk3IHRkIDB4ZmZmZmZm MDAwNmNiYWFlMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNo KCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2Nh dGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4 YwpfY3Zfd2FpdF9zaWcoKSBhdCBfY3Zfd2FpdF9zaWcrMHgxMjAKc2VsdGR3YWl0KCkgYXQgc2Vs dGR3YWl0KzB4ZjYKcG9sbCgpIGF0IHBvbGwrMHg0NTgKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgy OGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoMjA5 LCBGcmVlQlNEIEVMRjY0LCBwb2xsKSwgcmlwID0gMHg4MDExOTkwMmMsIHJzcCA9IDB4N2ZmZmZm YmZlODQ4LCByYnAgPSAweDdmZmZmZmJmZTg5NCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZD IHBpZCA4ODI2NyB0aWQgMTAwMzM2IHRkIDB4ZmZmZmZmMDE5YTc0MGFlMApzY2hlZF9zd2l0Y2go KSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNs ZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBx X3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgy NmIKZG9fY3Zfd2FpdCgpIGF0IGRvX2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBh dCBfX3VtdHhfb3BfY3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0 X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJT RCBFTEY2NCwgX3VtdHhfb3ApLCByaXAgPSAweDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmZmZmU3 MjgsIHJicCA9IDB4ODAyMDA0MWMwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hYUENPTUlQQ0Qg cGlkIDg4MjY0IHRpZCAxMDAzMTkgdGQgMHhmZmZmZmYwMTlhNGMxM2EwCnNjaGVkX3N3aXRjaCgp IGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xl ZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFf dGltZWR3YWl0X3NpZygpIGF0IHNsZWVwcV90aW1lZHdhaXRfc2lnKzB4MTkKX2N2X3RpbWVkd2Fp dF9zaWcoKSBhdCBfY3ZfdGltZWR3YWl0X3NpZysweDEyOQpzZWx0ZHdhaXQoKSBhdCBzZWx0ZHdh aXQrMHg4ZApwb2xsKCkgYXQgcG9sbCsweDQ1OApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpY ZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICgyMDksIEZy ZWVCU0QgRUxGNjQsIHBvbGwpLCByaXAgPSAweDgwMTAwZTAyYywgcnNwID0gMHg3ZmZmZmZmZmU1 NDgsIHJicCA9IDB4NzA5YjZlZGMgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveEhlYWRsZXNzIHBp ZCA4ODI2MyB0aWQgMTAwNDE2IHRkIDB4ZmZmZmZmMDAzZjJkNGFlMApzY2hlZF9zd2l0Y2goKSBh dCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVw cV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dh aXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIK ZG9fY3Zfd2FpdCgpIGF0IGRvX2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBf X3VtdHhfb3BfY3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5 c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBF TEY2NCwgX3VtdHhfb3ApLCByaXAgPSAweDgwMDY1YzI5YywgcnNwID0gMHg3ZmZmZmY1YWZkYjgs IHJicCA9IDB4ODAzMGYzMjAwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBwaWQg ODgyNjMgdGlkIDEwMDQxNSB0ZCAweGZmZmZmZjAwM2YyZDUwMDAKc2NoZWRfc3dpdGNoKCkgYXQg c2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFf Y2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0 X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRv X2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191 bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNj YWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxG NjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDA2NWMyOWMsIHJzcCA9IDB4N2ZmZmZmNWQwZGM4LCBy YnAgPSAweDgwMzBmMzNjMCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4 MjYzIHRpZCAxMDA0MTQgdGQgMHhmZmZmZmYwMDNmMmQ1M2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNj aGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2Nh dGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9z aWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19j dl93YWl0KCkgYXQgZG9fY3Zfd2FpdCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10 eF9vcF9jdl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2Fs bCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0 LCBfdW10eF9vcCksIHJpcCA9IDB4ODAwNjVjMjljLCByc3AgPSAweDdmZmZmZjVmMWQzOCwgcmJw ID0gMHg4MDMwZjM3NDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveEhlYWRsZXNzIHBpZCA4ODI2 MyB0aWQgMTAwNDEzIHRkIDB4ZmZmZmZmMDAzZjJkNTc0MApzY2hlZF9zd2l0Y2goKSBhdCBzY2hl ZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRj aF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2ln KCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9fY3Zf d2FpdCgpIGF0IGRvX2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhf b3BfY3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwo KSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwg X3VtdHhfb3ApLCByaXAgPSAweDgwMDY1YzI5YywgcnNwID0gMHg3ZmZmZmY2MTJkMzgsIHJicCA9 IDB4ODAzMGYzOTAwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBwaWQgODgyNjMg dGlkIDEwMDQxMiB0ZCAweGZmZmZmZjAwOTlhNThhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRf c3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hf c2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygp IGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dh aXQoKSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29w X2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkg YXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91 bXR4X29wKSwgcmlwID0gMHg4MDA2NWMyOWMsIHJzcCA9IDB4N2ZmZmZmNjkzZDY4LCByYnAgPSAw eDgwMmMyMDkwMCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4MjYzIHRp ZCAxMDA0MTEgdGQgMHhmZmZmZmYwMDNmMmQ1YWUwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3 aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3Np Z25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBh dCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgprZXJuX3NpZ3Rp bWVkd2FpdCgpIGF0IGtlcm5fc2lndGltZWR3YWl0KzB4NjE1CnNpZ3dhaXRpbmZvKCkgYXQgc2ln d2FpdGluZm8rMHg2ZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkg YXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICgzNDYsIEZyZWVCU0QgRUxGNjQsIHNp Z3dhaXRpbmZvKSwgcmlwID0gMHg4MDBiZWRkZWMsIHJzcCA9IDB4N2ZmZmZmNzE0ZTc4LCByYnAg PSAweDgwMzBmM2FjMCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4MjYz IHRpZCAxMDA0MTAgdGQgMHhmZmZmZmYwMTMwYjJlMDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVk X3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNo X3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWco KSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93 YWl0KCkgYXQgZG9fY3Zfd2FpdCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9v cF9jdl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgp IGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBf dW10eF9vcCksIHJpcCA9IDB4ODAwNjVjMjljLCByc3AgPSAweDdmZmZmZjc5NWUwOCwgcmJwID0g MHg4MDJjM2JhYzAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveEhlYWRsZXNzIHBpZCA4ODI2MyB0 aWQgMTAwNDA5IHRkIDB4ZmZmZmZmMDA4MTE1OTAwMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9z d2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9z aWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkg YXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9fY3Zfd2Fp dCgpIGF0IGRvX2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3Bf Y3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBh dCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3Vt dHhfb3ApLCByaXAgPSAweDgwMDY1YzI5YywgcnNwID0gMHg3ZmZmZmY4MTZkNjgsIHJicCA9IDB4 ODAyYzIwYWMwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBwaWQgODgyNjMgdGlk IDEwMDQwOCB0ZCAweGZmZmZmZjAxMzAxODk3NDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dp dGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2ln bmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0 IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQo KSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2 X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQg WGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4 X29wKSwgcmlwID0gMHg4MDA2NWMyOWMsIHJzcCA9IDB4N2ZmZmZmODk3ZDY4LCByYnAgPSAweDgw MmMyMGM4MCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4MjYzIHRpZCAx MDA0MDcgdGQgMHhmZmZmZmYwMTMwMTg5M2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRj aCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25h bHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfdGltZWR3YWl0X3NpZygp IGF0IHNsZWVwcV90aW1lZHdhaXRfc2lnKzB4MTkKcnRTZW1FdmVudE11bHRpV2FpdCgpIGF0IHJ0 U2VtRXZlbnRNdWx0aVdhaXQrMHgxYmEKZ19hQWRhcHRlcnMoKSBhdCBnX2FBZGFwdGVycysweDY3 MDMKZ19hQWRhcHRlcnMoKSBhdCAweGZmZmZmZmZmODBlNjI3MWEKZ19hQWRhcHRlcnMoKSBhdCAw eGZmZmZmZmZmODBlNjJhN2IKc3VwZHJ2SU9DdGwoKSBhdCBzdXBkcnZJT0N0bCsweDE3YmQKVkJv eERydkZyZWVCU0RJT0N0bCgpIGF0IFZCb3hEcnZGcmVlQlNESU9DdGwrMHgxZjYKZGV2ZnNfaW9j dGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJuX2lvY3RsKCkgYXQga2Vybl9pb2N0bCsw eGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFz dF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg1NCwgRnJlZUJT RCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMGM4YzlmYywgcnNwID0gMHg3ZmZmZmY5OThkNjgs IHJicCA9IDB4N2ZmZmZmOTk4ZDcwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBw aWQgODgyNjMgdGlkIDEwMDQwNiB0ZCAweGZmZmZmZjAxYTRjNjRhZTAKY3B1c3RvcF9oYW5kbGVy KCkgYXQgY3B1c3RvcF9oYW5kbGVyKzB4NDAKaXBpX25taV9oYW5kbGVyKCkgYXQgaXBpX25taV9o YW5kbGVyKzB4MzAKdHJhcCgpIGF0IHRyYXArMHgxOTUKbm1pX2NhbGx0cmFwKCkgYXQgbm1pX2Nh bGx0cmFwKzB4OAotLS0gdHJhcCAweDEzLCByaXAgPSAweGZmZmZmZmZmODAzNzdmZDYsIHJzcCA9 IDB4ZmZmZmZmODAwMDAzMWZlMCwgcmJwID0gMHhmZmZmZmY4MGU5MDAxNzQwIC0tLQpzbXBfcmVu ZGV6dm91c19hY3Rpb24oKSBhdCBzbXBfcmVuZGV6dm91c19hY3Rpb24rMHg5NgpYcmVuZGV6dm91 cygpIGF0IFhyZW5kZXp2b3VzKzB4ODkKLS0tIGludGVycnVwdCwgcmlwID0gMHhmZmZmZmZmZjgw ZTVlOTMwLCByc3AgPSAweGZmZmZmZjgwZTkwMDE4MDAsIHJicCA9IDB4ZmZmZmZmODBlOTAwMTkz MCAtLS0KZ19hQWRhcHRlcnMoKSBhdCBnX2FBZGFwdGVycysweGRmOTAKZ19hQWRhcHRlcnMoKSBh dCBnX2FBZGFwdGVycysweDc3NTIKZ19hQWRhcHRlcnMoKSBhdCAweGZmZmZmZmZmODBlOTI3MTcK Z19hQWRhcHRlcnMoKSBhdCAweGZmZmZmZmZmODBlNjJkMTUKc3VwZHJ2SU9DdGxGYXN0KCkgYXQg c3VwZHJ2SU9DdGxGYXN0KzB4NWEKVkJveERydkZyZWVCU0RJT0N0bCgpIGF0IFZCb3hEcnZGcmVl QlNESU9DdGwrMHgxMjUKZGV2ZnNfaW9jdGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJu X2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxs KCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUx Ci0tLSBzeXNjYWxsICg1NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMGM4Yzlm YywgcnNwID0gMHg3ZmZmZmZhOTllMzgsIHJicCA9IDB4N2ZmZmZmYTk5ZTQwIC0tLQoKVHJhY2lu ZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBwaWQgODgyNjMgdGlkIDEwMDQwNCB0ZCAweGZmZmZmZjAw MmRhYzJhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgp IGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRj aF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMK X3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4ODcx Cl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkg YXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0t LSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDA2NWMy OWMsIHJzcCA9IDB4N2ZmZmZmYjliZDc4LCByYnAgPSAweDgwMjI2NmM4MCAtLS0KClRyYWNpbmcg Y29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4MjYzIHRpZCAxMDAzOTYgdGQgMHhmZmZmZmYwMTlh NzM2NzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBh dCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hf c2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9z bGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQgZG9fY3Zfd2FpdCsweDg3MQpf X3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0 IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0g c3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCksIHJpcCA9IDB4ODAwNjVjMjlj LCByc3AgPSAweDdmZmZmZmJiY2RmOCwgcmJwID0gMHg4MDBlOTkxYzAgLS0tCgpUcmFjaW5nIGNv bW1hbmQgVkJveEhlYWRsZXNzIHBpZCA4ODI2MyB0aWQgMTAwMzk1IHRkIDB4ZmZmZmZmMDA5OWE3 M2FlMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQg bWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3Np Z25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4YwpfY3Zf d2FpdF9zaWcoKSBhdCBfY3Zfd2FpdF9zaWcrMHgxMjAKc2VsdGR3YWl0KCkgYXQgc2VsdGR3YWl0 KzB4ZjYKcG9sbCgpIGF0IHBvbGwrMHg0NTgKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZh c3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoMjA5LCBGcmVl QlNEIEVMRjY0LCBwb2xsKSwgcmlwID0gMHg4MDBjMzgwMmMsIHJzcCA9IDB4N2ZmZmZmYmRkODE4 LCByYnAgPSAweDdmZmZmZmJkZDg5NCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3Mg cGlkIDg4MjYzIHRpZCAxMDAzOTQgdGQgMHhmZmZmZmYwMDgxMzFmNzQwCnNjaGVkX3N3aXRjaCgp IGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xl ZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFf d2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2 YgprZXJuX3dhaXQoKSBhdCBrZXJuX3dhaXQrMHg4MTcKd2FpdDQoKSBhdCB3YWl0NCsweDM1CnN5 c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxs KzB4ZTEKLS0tIHN5c2NhbGwgKDcsIEZyZWVCU0QgRUxGNjQsIHdhaXQ0KSwgcmlwID0gMHg4MDBj MDUyM2MsIHJzcCA9IDB4N2ZmZmZmYmZlZWM4LCByYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5k IFZCb3hIZWFkbGVzcyBwaWQgODgyNjMgdGlkIDEwMDM3OSB0ZCAweGZmZmZmZjAwMmRhZDk3NDAK c2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3 aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxz KzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkg YXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9v cF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2Fs bCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxs ICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDA2NWMyOWMsIHJzcCA9 IDB4N2ZmZmZmZmZjNWI4LCByYnAgPSAweDgwMGUwNDFjMCAtLS0KClRyYWNpbmcgY29tbWFuZCBz aCBwaWQgNTExNTkgdGlkIDEwMDI2OCB0ZCAweGZmZmZmZjAxMzAxM2IwMDAKc2NoZWRfc3dpdGNo KCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2Zgpz bGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVw cV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4 MjZiCmtlcm5fd2FpdCgpIGF0IGtlcm5fd2FpdCsweDgxNwp3YWl0NCgpIGF0IHdhaXQ0KzB4MzUK c3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2Nh bGwrMHhlMQotLS0gc3lzY2FsbCAoNywgRnJlZUJTRCBFTEY2NCwgd2FpdDQpLCByaXAgPSAweDgw MDkzNTIzYywgcnNwID0gMHg3ZmZmZmZmZmM0NDgsIHJicCA9IDB4YThkNCAtLS0KClRyYWNpbmcg Y29tbWFuZCBzaCBwaWQgNTExMjAgdGlkIDEwMDE5MSB0ZCAweGZmZmZmZjAwMDZjMzFhZTAKc2No ZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRj aCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4 MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQg X3NsZWVwKzB4MjZiCmtlcm5fd2FpdCgpIGF0IGtlcm5fd2FpdCsweDgxNwp3YWl0NCgpIGF0IHdh aXQ0KzB4MzUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhm YXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNywgRnJlZUJTRCBFTEY2NCwgd2FpdDQpLCBy aXAgPSAweDgwMDkzNTIzYywgcnNwID0gMHg3ZmZmZmZmZmM0NTgsIHJicCA9IDB4YThkNCAtLS0K ClRyYWNpbmcgY29tbWFuZCBzaCBwaWQgNTA3OTggdGlkIDEwMDI4NCB0ZCAweGZmZmZmZjAxMzBi MzVhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0 IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9z aWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3Ns ZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmtlcm5fd2FpdCgpIGF0IGtlcm5fd2FpdCsweDgxNwp3YWl0 NCgpIGF0IHdhaXQ0KzB4MzUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2Fs bCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNywgRnJlZUJTRCBFTEY2NCwg d2FpdDQpLCByaXAgPSAweDgwMDkzNTIzYywgcnNwID0gMHg3ZmZmZmZmZmM2MjgsIHJicCA9IDB4 YThkNCAtLS0KClRyYWNpbmcgY29tbWFuZCBuZXRzZXJ2ZXIgcGlkIDQ5MTc3IHRpZCAxMDAzMjIg dGQgMHhmZmZmZmYwMTlhNGZkNzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEw OAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBh dCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFf d2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgprZXJuX2FjY2VwdCgpIGF0IGtl cm5fYWNjZXB0KzB4MWUyCmFjY2VwdCgpIGF0IGFjY2VwdCsweDc1CnN5c2NhbGwoKSBhdCBzeXNj YWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2Nh bGwgKDMwLCBGcmVlQlNEIEVMRjY0LCBhY2NlcHQpLCByaXAgPSAweDgwMDgwZGQyYywgcnNwID0g MHg3ZmZmZmZmZmRlODgsIHJicCA9IDB4NCAtLS0KClRyYWNpbmcgY29tbWFuZCB0Y3NoIHBpZCA3 MTA0NyB0aWQgMTAwMTQ5IHRkIDB4ZmZmZmZmMDAwNjUzYmFlMApzY2hlZF9zd2l0Y2goKSBhdCBz Y2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9j YXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRf c2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKa2Vy bl9zaWdzdXNwZW5kKCkgYXQga2Vybl9zaWdzdXNwZW5kKzB4YjAKc2lnc3VzcGVuZCgpIGF0IHNp Z3N1c3BlbmQrMHgzNApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkg YXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0LCBGcmVlQlNEIEVMRjY0LCB3cml0 ZSksIHJpcCA9IDB4ODAwOTRjZThjLCByc3AgPSAweDdmZmZmZmZmZTYwOCwgcmJwID0gMHg4MDBj NWFkMDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgc2ggcGlkIDQzMjIwIHRpZCAxMDAxNTIgdGQgMHhm ZmZmZmYwMDA2YzMxMDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9z d2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVl cHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9z aWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgprZXJuX3dhaXQoKSBhdCBrZXJuX3dhaXQr MHg4MTcKd2FpdDQoKSBhdCB3YWl0NCsweDM1CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhm YXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDcsIEZyZWVC U0QgRUxGNjQsIHdhaXQ0KSwgcmlwID0gMHg4MDA5MzUyM2MsIHJzcCA9IDB4N2ZmZmZmZmZkOWE4 LCByYnAgPSAweGE4ZDQgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgMTE5NjIgdGlk IDEwMDMxMyB0ZCAweGZmZmZmZjAwMTYzZmIzYTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dp dGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2ln bmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0 IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQo KSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2 X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQg WGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4 X29wKSwgcmlwID0gMHg4MDEzNDYyOWMsIHJzcCA9IDB4N2ZmZmZmOTk3ZGY4LCByYnAgPSAweDgw MjAwYWU0MCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCAxMTk2MiB0aWQgMTAwMzQz IHRkIDB4ZmZmZmZmMDAwNmM1MTNhMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgx MDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkg YXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBx X3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9fY3Zfd2FpdCgpIGF0IGRv X2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3BfY3Zfd2FpdCsw eDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9z eXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3VtdHhfb3ApLCBy aXAgPSAweDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmY5YjhkZjgsIHJicCA9IDB4ODAyMDk2MWMw IC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDExOTYyIHRpZCAxMDAzNDEgdGQgMHhm ZmZmZmYwMTMwYjM2NzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9z d2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVl cHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9z aWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQgZG9fY3Zfd2Fp dCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0KzB4NWMKc3lz Y2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwr MHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCksIHJpcCA9IDB4 ODAxMzQ2MjljLCByc3AgPSAweDdmZmZmZmEzOWQ3OCwgcmJwID0gMHg4MDI0M2M1ODAgLS0tCgpU cmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgMTE5NjIgdGlkIDEwMDM0MCB0ZCAweGZmZmZmZjAw MDZkYmUwMDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgp IGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRj aF9zaWduYWxzKzB4MzFmCnNsZWVwcV90aW1lZHdhaXRfc2lnKCkgYXQgc2xlZXBxX3RpbWVkd2Fp dF9zaWcrMHgxOQpfc2xlZXAoKSBhdCBfc2xlZXArMHgxYTMKZG9fY3Zfd2FpdCgpIGF0IGRvX2N2 X3dhaXQrMHg2NDAKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3BfY3Zfd2FpdCsweDVj CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNj YWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3VtdHhfb3ApLCByaXAg PSAweDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmZhYmFjYzgsIHJicCA9IDB4ODAyNDNjNzQwIC0t LQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDExOTYyIHRpZCAxMDAzMzkgdGQgMHhmZmZm ZmYwMTlhNzQxM2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0 Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFf Y2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfdGltZWR3YWl0X3NpZygpIGF0IHNsZWVwcV90aW1l ZHdhaXRfc2lnKzB4MTkKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MWEzCmRvX2N2X3dhaXQoKSBhdCBk b19jdl93YWl0KzB4NjQwCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQr MHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rf c3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwg cmlwID0gMHg4MDEzNDYyOWMsIHJzcCA9IDB4N2ZmZmZmYjNiZTI4LCByYnAgPSAweDgwMjQzY2Fj MCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCAxMTk2MiB0aWQgMTAwMzM4IHRkIDB4 ZmZmZmZmMDAwNmM1MWFlMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlf c3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xl ZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRf c2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9fY3Zfd2FpdCgpIGF0IGRvX2N2X3dh aXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3BfY3Zfd2FpdCsweDVjCnN5 c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxs KzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3VtdHhfb3ApLCByaXAgPSAw eDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmZiYmNlMjgsIHJicCA9IDB4ODAyMDk2MzgwIC0tLQoK VHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDExOTYyIHRpZCAxMDAzMzcgdGQgMHhmZmZmZmYw MDA2YzdhMDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2go KSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0 Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhj Cl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQgZG9fY3Zfd2FpdCsweDg3 MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0KzB4NWMKc3lzY2FsbCgp IGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQot LS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCksIHJpcCA9IDB4ODAxMzQ2 MjljLCByc3AgPSAweDdmZmZmZmJkZGRmOCwgcmJwID0gMHg4MDIwOTY1NDAgLS0tCgpUcmFjaW5n IGNvbW1hbmQgVkJveFNWQyBwaWQgMTE5NjIgdGlkIDEwMDMyMSB0ZCAweGZmZmZmZjAxOWE0ZmRh ZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1p X3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWdu YWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVw KCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10 eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lz Y2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNj YWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDEzNDYyOWMsIHJz cCA9IDB4N2ZmZmZmZmZlNjU4LCByYnAgPSAweDgwMjAwNDFjMCAtLS0KClRyYWNpbmcgY29tbWFu ZCB0Y3NoIHBpZCAxOTc1IHRpZCAxMDAyMDggdGQgMHhmZmZmZmYwMDgxMWY3NzQwCnNjaGVkX3N3 aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgx NmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpz bGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVl cCsweDI2YgprZXJuX3NpZ3N1c3BlbmQoKSBhdCBrZXJuX3NpZ3N1c3BlbmQrMHhiMApzaWdzdXNw ZW5kKCkgYXQgc2lnc3VzcGVuZCsweDM0CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0 X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQsIEZyZWVCU0Qg RUxGNjQsIHdyaXRlKSwgcmlwID0gMHg4MDA5NGNlOGMsIHJzcCA9IDB4N2ZmZmZmZmZlNjA4LCBy YnAgPSAweDgwMGM1YWUwMCAtLS0KClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVtb24g cGlkIDE5MTggdGlkIDEwMDIzNSB0ZCAweGZmZmZmZjAwMTYzZmIwMDAKc2NoZWRfc3dpdGNoKCkg YXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVl cHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93 YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZi CnNjdHR5X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwrMHhhZWIKdHR5X2lvY3RsKCkgYXQgdHR5X2lv Y3RsKzB4NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lvY3Rs X2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhm Ngppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rf c3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0Qg RUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDE5MWM5ZmMsIHJzcCA9IDB4N2ZmZmZmYWRkZjM4LCBy YnAgPSAweDkgLS0tCgpUcmFjaW5nIGNvbW1hbmQgY29uc29sZS1raXQtZGFlbW9uIHBpZCAxOTE4 IHRpZCAxMDAyNDIgdGQgMHhmZmZmZmYwMDgxNDVmMDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVk X3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNo X3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWco KSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0eV9p b2N0bCgpIGF0IHNjdHR5X2lvY3RsKzB4YWViCnR0eV9pb2N0bCgpIGF0IHR0eV9pb2N0bCsweDVk CnR0eWRldl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0bCsweDIxMwpkZXZmc19pb2N0bF9mKCkgYXQg ZGV2ZnNfaW9jdGxfZisweDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJuX2lvY3RsKzB4ZjYKaW9jdGwo KSBhdCBpb2N0bCsweGZkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwo KSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0LCBp b2N0bCksIHJpcCA9IDB4ODAxOTFjOWZjLCByc3AgPSAweDdmZmZmZmFmZmYzOCwgcmJwID0gMHgx MCAtLS0KClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVtb24gcGlkIDE5MTggdGlkIDEw MDI0MSB0ZCAweGZmZmZmZjAwODE0NWYzYTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNo KzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFs cygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNs ZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5X2lvY3RsKCkg YXQgc2N0dHlfaW9jdGwrMHhhZWIKdHR5X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4NWQKdHR5ZGV2 X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19p b2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhmNgppb2N0bCgpIGF0IGlv Y3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhm YXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwg cmlwID0gMHg4MDE5MWM5ZmMsIHJzcCA9IDB4N2ZmZmZmYjEwZjM4LCByYnAgPSAweGYgLS0tCgpU cmFjaW5nIGNvbW1hbmQgY29uc29sZS1raXQtZGFlbW9uIHBpZCAxOTE4IHRpZCAxMDAyNDAgdGQg MHhmZmZmZmYwMDgxNDVmNzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOApt aV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBz bGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2Fp dF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0eV9pb2N0bCgpIGF0IHNjdHR5 X2lvY3RsKzB4YWViCnR0eV9pb2N0bCgpIGF0IHR0eV9pb2N0bCsweDVkCnR0eWRldl9pb2N0bCgp IGF0IHR0eWRldl9pb2N0bCsweDIxMwpkZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNfaW9jdGxfZisw eDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJuX2lvY3RsKzB4ZjYKaW9jdGwoKSBhdCBpb2N0bCsweGZk CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNj YWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0LCBpb2N0bCksIHJpcCA9IDB4 ODAxOTFjOWZjLCByc3AgPSAweDdmZmZmZmIyMWYzOCwgcmJwID0gMHhlIC0tLQoKVHJhY2luZyBj b21tYW5kIGNvbnNvbGUta2l0LWRhZW1vbiBwaWQgMTkxOCB0aWQgMTAwMjM5IHRkIDB4ZmZmZmZm MDA4MTQ1ZmFlMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNo KCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2Nh dGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4 Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKc2N0dHlfaW9jdGwoKSBhdCBzY3R0eV9pb2N0bCsw eGFlYgp0dHlfaW9jdGwoKSBhdCB0dHlfaW9jdGwrMHg1ZAp0dHlkZXZfaW9jdGwoKSBhdCB0dHlk ZXZfaW9jdGwrMHgyMTMKZGV2ZnNfaW9jdGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJu X2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxs KCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUx Ci0tLSBzeXNjYWxsICg1NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMTkxYzlm YywgcnNwID0gMHg3ZmZmZmZiMzJmMzgsIHJicCA9IDB4ZCAtLS0KClRyYWNpbmcgY29tbWFuZCBj b25zb2xlLWtpdC1kYWVtb24gcGlkIDE5MTggdGlkIDEwMDIzOCB0ZCAweGZmZmZmZjAwODE0MDAw MDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1p X3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWdu YWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVw KCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwrMHhhZWIKdHR5 X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3Rs KzB4MjEzCmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgp IGF0IGtlcm5faW9jdGwrMHhmNgppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5 c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lz Y2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDE5MWM5ZmMsIHJzcCA9 IDB4N2ZmZmZmYjQzZjM4LCByYnAgPSAweGMgLS0tCgpUcmFjaW5nIGNvbW1hbmQgY29uc29sZS1r aXQtZGFlbW9uIHBpZCAxOTE4IHRpZCAxMDAyMzcgdGQgMHhmZmZmZmYwMDgxNDAwM2EwCnNjaGVk X3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2gr MHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMx ZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9z bGVlcCsweDI2YgpzY3R0eV9pb2N0bCgpIGF0IHNjdHR5X2lvY3RsKzB4YWViCnR0eV9pb2N0bCgp IGF0IHR0eV9pb2N0bCsweDVkCnR0eWRldl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0bCsweDIxMwpk ZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNfaW9jdGxfZisweDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJu X2lvY3RsKzB4ZjYKaW9jdGwoKSBhdCBpb2N0bCsweGZkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4 MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0 LCBGcmVlQlNEIEVMRjY0LCBpb2N0bCksIHJpcCA9IDB4ODAxOTFjOWZjLCByc3AgPSAweDdmZmZm ZmI1NGYzOCwgcmJwID0gMHhiIC0tLQoKVHJhY2luZyBjb21tYW5kIGNvbnNvbGUta2l0LWRhZW1v biBwaWQgMTkxOCB0aWQgMTAwMjM2IHRkIDB4ZmZmZmZmMDA4MTQwMDc0MApzY2hlZF9zd2l0Y2go KSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNs ZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBx X3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgy NmIKc2N0dHlfaW9jdGwoKSBhdCBzY3R0eV9pb2N0bCsweGFlYgp0dHlfaW9jdGwoKSBhdCB0dHlf aW9jdGwrMHg1ZAp0dHlkZXZfaW9jdGwoKSBhdCB0dHlkZXZfaW9jdGwrMHgyMTMKZGV2ZnNfaW9j dGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJuX2lvY3RsKCkgYXQga2Vybl9pb2N0bCsw eGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFz dF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg1NCwgRnJlZUJT RCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMTkxYzlmYywgcnNwID0gMHg3ZmZmZmZiNjVmMzgs IHJicCA9IDB4YSAtLS0KClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVtb24gcGlkIDE5 MTggdGlkIDEwMDIzNCB0ZCAweGZmZmZmZjAwODEzNWUwMDAKc2NoZWRfc3dpdGNoKCkgYXQgc2No ZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0 Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3Np ZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5 X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwrMHhhZWIKdHR5X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4 NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lvY3RsX2YoKSBh dCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhmNgppb2N0 bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2Fs bCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQs IGlvY3RsKSwgcmlwID0gMHg4MDE5MWM5ZmMsIHJzcCA9IDB4N2ZmZmZmYjg3ZjM4LCByYnAgPSAw eDggLS0tCgpUcmFjaW5nIGNvbW1hbmQgY29uc29sZS1raXQtZGFlbW9uIHBpZCAxOTE4IHRpZCAx MDAyMzMgdGQgMHhmZmZmZmYwMDgxMzVlM2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRj aCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25h bHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBz bGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0eV9pb2N0bCgp IGF0IHNjdHR5X2lvY3RsKzB4YWViCnR0eV9pb2N0bCgpIGF0IHR0eV9pb2N0bCsweDVkCnR0eWRl dl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0bCsweDIxMwpkZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNf aW9jdGxfZisweDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJuX2lvY3RsKzB4ZjYKaW9jdGwoKSBhdCBp b2N0bCsweGZkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBY ZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0LCBpb2N0bCks IHJpcCA9IDB4ODAxOTFjOWZjLCByc3AgPSAweDdmZmZmZmI5OGYzOCwgcmJwID0gMHg3IC0tLQoK VHJhY2luZyBjb21tYW5kIGNvbnNvbGUta2l0LWRhZW1vbiBwaWQgMTkxOCB0aWQgMTAwMjMyIHRk IDB4ZmZmZmZmMDA4MTM1ZTc0MApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgK bWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQg c2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dh aXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKc2N0dHlfaW9jdGwoKSBhdCBzY3R0 eV9pb2N0bCsweGFlYgp0dHlfaW9jdGwoKSBhdCB0dHlfaW9jdGwrMHg1ZAp0dHlkZXZfaW9jdGwo KSBhdCB0dHlkZXZfaW9jdGwrMHgyMTMKZGV2ZnNfaW9jdGxfZigpIGF0IGRldmZzX2lvY3RsX2Yr MHg3NwprZXJuX2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhm ZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lz Y2FsbCsweGUxCi0tLSBzeXNjYWxsICg1NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwpLCByaXAgPSAw eDgwMTkxYzlmYywgcnNwID0gMHg3ZmZmZmZiYTlmMzgsIHJicCA9IDB4NiAtLS0KClRyYWNpbmcg Y29tbWFuZCBjb25zb2xlLWtpdC1kYWVtb24gcGlkIDE5MTggdGlkIDEwMDIzMSB0ZCAweGZmZmZm ZjAwODEzNWVhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRj aCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9j YXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysw eGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwr MHhhZWIKdHR5X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5 ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vy bl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhmNgppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2Fs bCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhl MQotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDE5MWM5 ZmMsIHJzcCA9IDB4N2ZmZmZmYmJhZjM4LCByYnAgPSAweDUgLS0tCgpUcmFjaW5nIGNvbW1hbmQg Y29uc29sZS1raXQtZGFlbW9uIHBpZCAxOTE4IHRpZCAxMDAyMzAgdGQgMHhmZmZmZmYwMDgxMzFm MDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBt aV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2ln bmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVl cCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0eV9pb2N0bCgpIGF0IHNjdHR5X2lvY3RsKzB4YWViCnR0 eV9pb2N0bCgpIGF0IHR0eV9pb2N0bCsweDVkCnR0eWRldl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0 bCsweDIxMwpkZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNfaW9jdGxfZisweDc3Cmtlcm5faW9jdGwo KSBhdCBrZXJuX2lvY3RsKzB4ZjYKaW9jdGwoKSBhdCBpb2N0bCsweGZkCnN5c2NhbGwoKSBhdCBz eXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5 c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0LCBpb2N0bCksIHJpcCA9IDB4ODAxOTFjOWZjLCByc3Ag PSAweDdmZmZmZmJjYmYzOCwgcmJwID0gMHg0IC0tLQoKVHJhY2luZyBjb21tYW5kIGNvbnNvbGUt a2l0LWRhZW1vbiBwaWQgMTkxOCB0aWQgMTAwMjI5IHRkIDB4ZmZmZmZmMDA4MTMxZjNhMApzY2hl ZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNo KzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgz MWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBf c2xlZXArMHgyNmIKc2N0dHlfaW9jdGwoKSBhdCBzY3R0eV9pb2N0bCsweGFlYgp0dHlfaW9jdGwo KSBhdCB0dHlfaW9jdGwrMHg1ZAp0dHlkZXZfaW9jdGwoKSBhdCB0dHlkZXZfaW9jdGwrMHgyMTMK ZGV2ZnNfaW9jdGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJuX2lvY3RsKCkgYXQga2Vy bl9pb2N0bCsweGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsw eDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg1 NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMTkxYzlmYywgcnNwID0gMHg3ZmZm ZmZiZGNmMzgsIHJicCA9IDB4MyAtLS0KClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVt b24gcGlkIDE5MTggdGlkIDEwMDIyNyB0ZCAweGZmZmZmZjAwODEzMWZhZTAKc2NoZWRfc3dpdGNo KCkgYXQgc2NoZWRfc3dpdGNtc2didWYudHh0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMDYwMAAAAAAwAAAAAAAAADAAAAAAAAAANDI0NzIAAAAAAAAAMTEzMzAwNjUyMTUAICA3NTU2 ACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyAAAAcm9v dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3aGVlbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAENvcHlyaWdodCAoYykgMTk5Mi0yMDEwIFRoZSBGcmVlQlNEIFByb2pl Y3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5 MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2Fs aWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJh ZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgOC4wLVNUQUJMRSAjMCBy MjAyOTY5TTogTW9uIEphbiAyNSAxMDowMTowNiBDU1QgMjAxMAogICAgcm9vdEBiZ29vY2g3NTUu c2UuZWR1Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0RFTEw3NTUgYW1kNjQKVGltZWNvdW50ZXIgImk4 MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBJbnRlbChSKSBDb3JlKFRN KTIgUXVhZCBDUFUgICAgUTY2MDAgIEAgMi40MEdIeiAoMjM5NC4wMC1NSHogSzgtY2xhc3MgQ1BV KQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmZiICBTdGVwcGluZyA9IDExCiAg RmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQ SUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxG WFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4ZTNiZDxTU0UzLERURVM2 NCxNT04sRFNfQ1BMLFZNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNPgogIEFNRCBGZWF0 dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4K ICBUU0M6IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVtb3J5ICA9IDg1ODk5MzQ1OTIgKDgxOTIg TUIpCmF2YWlsIG1lbW9yeSA9IDgxMTgxODE4ODggKDc3NDIgTUIpCkFDUEkgQVBJQyBUYWJsZTog PERFTEwgICBCOUsgICAgPgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVj dGVkOiA0IENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDQgY29yZShzKQogY3B1MCAo QlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJ QyBJRDogIDIKIGNwdTMgKEFQKTogQVBJQyBJRDogIDMKaW9hcGljMDogQ2hhbmdpbmcgQVBJQyBJ RCB0byA4CmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKbGFw aWMwOiBGb3JjaW5nIExJTlQxIHRvIGVkZ2UgdHJpZ2dlcgprYmQxIGF0IGtiZG11eDAKYWNwaTA6 IDxERUxMIEI5SyAgICA+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBv d2VyIEJ1dHRvbiAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5 NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0 NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMAphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNp b24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1l Y291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTAwCmFjcGlfYnV0 dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRn ZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMS4wIG9uIHBj aTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxl IGRpc3BsYXk+IHBvcnQgMHhkYzAwLTB4ZGNmZiBtZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4 ZmU5ZjAwMDAtMHhmZTlmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCnBjaTA6IDxz aW1wbGUgY29tbXM+IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKYXRhcGNpMDog PEludGVsIEFUQSBjb250cm9sbGVyPiBwb3J0IDB4ZmU4MC0weGZlODcsMHhmZTkwLTB4ZmU5Myww eGZlYTAtMHhmZWE3LDB4ZmViMC0weGZlYjMsMHhmZWYwLTB4ZmVmZiBpcnEgMTggYXQgZGV2aWNl IDMuMiBvbiBwY2kwCmF0YXBjaTA6IFtJVEhSRUFEXQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24g YXRhcGNpMAphdGEyOiBbSVRIUkVBRF0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAK YXRhMzogW0lUSFJFQURdCnBjaTA6IDxzaW1wbGUgY29tbXMsIFVBUlQ+IGF0IGRldmljZSAzLjMg KG5vIGRyaXZlciBhdHRhY2hlZCkKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25u ZWN0aW9uIDYuOS4xND4gcG9ydCAweGVjYzAtMHhlY2RmIG1lbSAweGZlYmUwMDAwLTB4ZmViZmZm ZmYsMHhmZWJkYjAwMC0weGZlYmRiZmZmIGlycSAyMSBhdCBkZXZpY2UgMjUuMCBvbiBwY2kwCmVt MDogVXNpbmcgTVNJIGludGVycnVwdAplbTA6IFtGSUxURVJdCmVtMDogRXRoZXJuZXQgYWRkcmVz czogMDA6MWU6NGY6ZDU6ODQ6YjcKdWhjaTA6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250 cm9sbGVyPiBwb3J0IDB4ZmYyMC0weGZmM2YgaXJxIDE2IGF0IGRldmljZSAyNi4wIG9uIHBjaTAK dWhjaTA6IFtJVEhSRUFEXQp1aGNpMDogTGVnU3VwID0gMHgyZjAwCnVzYnVzMDogPEludGVsIDgy ODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVoY2kxOiA8SW50ZWwgODI4MDFJ IChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGZmMDAtMHhmZjFmIGlycSAxNyBhdCBkZXZp Y2UgMjYuMSBvbiBwY2kwCnVoY2kxOiBbSVRIUkVBRF0KdWhjaTE6IExlZ1N1cCA9IDB4MmYwMAp1 c2J1czE6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQplaGNp MDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmZWJkOWMw MC0weGZlYmQ5ZmZmIGlycSAyMiBhdCBkZXZpY2UgMjYuNyBvbiBwY2kwCmVoY2kwOiBbSVRIUkVB RF0KdXNidXMyOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMjogPEludGVsIDgyODAxSSAoSUNIOSkg VVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMApoZGFjMDogPEludGVsIDgyODAxSSBIaWdoIERl ZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4ZmViZGMwMDAtMHhmZWJkZmZmZiBpcnEg MTYgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApoZGFjMDogSERBIERyaXZlciBSZXZpc2lvbjogMjAx MDAxMTJfMDE0MApoZGFjMDogW0lUSFJFQURdCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g aXJxIDE2IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjIKdWhjaTI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZmY4 MC0weGZmOWYgaXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdWhjaTI6IFtJVEhSRUFEXQp1 c2J1czM6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMgp1aGNp MzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhmZjYwLTB4ZmY3 ZiBpcnEgMTcgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNpMzogW0lUSFJFQURdCnVzYnVzNDog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kzCnVoY2k0OiA8SW50 ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGZmNDAtMHhmZjVmIGlycSAx OCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2k0OiBbSVRIUkVBRF0KdXNidXM1OiA8SW50ZWwg ODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTQKZWhjaTE6IDxJbnRlbCA4Mjgw MUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZmY5ODA4MDAtMHhmZjk4MGJmZiBp cnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNpMTogW0lUSFJFQURdCnVzYnVzNjogRUhD SSB2ZXJzaW9uIDEuMAp1c2J1czY6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJv bGxlcj4gb24gZWhjaTEKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAu MCBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCmF0YXBjaTE6IDxTaUkgMzEx NCBTQVRBMTUwIGNvbnRyb2xsZXI+IHBvcnQgMHhjOGUwLTB4YzhlNywweGM4ZDgtMHhjOGRiLDB4 YzhlOC0weGM4ZWYsMHhjOGRjLTB4YzhkZiwweGM4ZjAtMHhjOGZmIG1lbSAweGZlNmZmYzAwLTB4 ZmU2ZmZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMwphdGFwY2kxOiBbSVRIUkVBRF0K YXRhNDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTEKYXRhNDogW0lUSFJFQURdCmF0YTU6IDxB VEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCmF0YTU6IFtJVEhSRUFEXQphdGE2OiA8QVRBIGNoYW5u ZWwgMj4gb24gYXRhcGNpMQphdGE2OiBbSVRIUkVBRF0KYXRhNzogPEFUQSBjaGFubmVsIDM+IG9u IGF0YXBjaTEKYXRhNzogW0lUSFJFQURdCnJsMDogPFJlYWxUZWsgODEzOSAxMC8xMDBCYXNlVFg+ IHBvcnQgMHhjYzAwLTB4Y2NmZiBtZW0gMHhmZTZmZmIwMC0weGZlNmZmYmZmIGlycSAxOCBhdCBk ZXZpY2UgMi4wIG9uIHBjaTMKbWlpYnVzMDogPE1JSSBidXM+IG9uIHJsMApybHBoeTA6IDxSZWFs VGVrIGludGVybmFsIG1lZGlhIGludGVyZmFjZT4gUEhZIDAgb24gbWlpYnVzMApybHBoeTA6ICAx MGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvCnJsMDog RXRoZXJuZXQgYWRkcmVzczogMDA6YzA6YTg6ODE6NWI6YzUKcmwwOiBbSVRIUkVBRF0KaXNhYjA6 IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4g b24gaXNhYjAKYWhjaTA6IDxJbnRlbCBJQ0g5IEFIQ0kgU0FUQSBjb250cm9sbGVyPiBwb3J0IDB4 ZmUwMC0weGZlMDcsMHhmZTEwLTB4ZmUxMywweGZlMjAtMHhmZTI3LDB4ZmUzMC0weGZlMzMsMHhm ZWMwLTB4ZmVkZiBtZW0gMHhmZjk3MDAwMC0weGZmOTcwN2ZmIGlycSAxOCBhdCBkZXZpY2UgMzEu MiBvbiBwY2kwCmFoY2kwOiBbSVRIUkVBRF0KYWhjaTA6IEFIQ0kgdjEuMjAgd2l0aCA2IDNHYnBz IHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgc3VwcG9ydGVkCmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+ IGF0IGNoYW5uZWwgMCBvbiBhaGNpMAphaGNpY2gwOiBbSVRIUkVBRF0KYWhjaWNoMTogPEFIQ0kg Y2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCmFoY2ljaDE6IFtJVEhSRUFEXQphaGNpY2gy OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDIgb24gYWhjaTAKYWhjaWNoMjogW0lUSFJFQURd CmFoY2ljaDM6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMyBvbiBhaGNpMAphaGNpY2gzOiBb SVRIUkVBRF0KYWhjaWNoNDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA1IG9uIGFoY2kwCmFo Y2ljaDQ6IFtJVEhSRUFEXQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4z IChubyBkcml2ZXIgYXR0YWNoZWQpCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4 NzAtMHg3ZiBpcnEgOCBvbiBhY3BpMApmZGMwOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXIgKEZE RSk+IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTAKZmRjMDogW0ZJ TFRFUl0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZlIDAKdWFydDA6IDwx NjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24g YWNwaTAKdWFydDA6IFtGSUxURVJdCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0MDogPEVu aGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUg RnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFj cGkwCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEK cDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKY3B1MjogPEFD UEkgQ1BVPiBvbiBhY3BpMAplc3QyOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250 cm9sPiBvbiBjcHUyCnA0dGNjMjogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBj cHUyCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0MzogPEVuaGFuY2VkIFNwZWVkU3RlcCBG cmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MwpwNHRjYzM6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwg Q29udHJvbD4gb24gY3B1Mwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAw LTB4Y2VmZmYsMHhjZjAwMC0weGQwZmZmLDB4ZDEwMDAtMHhkMzdmZiwweGQzODAwLTB4ZDNmZmYg b24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6 IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElT QSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAK YXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQg b24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0 a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdClpGUyBmaWxlc3lz dGVtIHZlcnNpb24gMwpaRlMgc3RvcmFnZSBwb29sIHZlcnNpb24gMTQKVGltZWNvdW50ZXJzIHRp Y2sgZXZlcnkgMS4wMDAgbXNlYwp2Ym94ZHJ2OiBmQXN5bmM9MCBvZmZNaW49MHgxNzEgb2ZmTWF4 PTB4MjM3CmlwZncyICgraXB2NikgaW5pdGlhbGl6ZWQsIGRpdmVydCBlbmFibGVkLCBuYXQgZW5h YmxlZCwgcnVsZS1iYXNlZCBmb3J3YXJkaW5nIGRpc2FibGVkLCBkZWZhdWx0IHRvIGRlbnksIGxv Z2dpbmcgZGlzYWJsZWQKV2FpdGluZyA1IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNlcyB0byBzZXR0 bGUKaGRhYzA6IEhEQSBDb2RlYyAjMDogQW5hbG9nIERldmljZXMgQUQxOTg0CnBjbTA6IDxIREEg QW5hbG9nIERldmljZXMgQUQxOTg0IFBDTSAjMCBBbmFsb2c+IGF0IGNhZCAwIG5pZCAxIG9uIGhk YWMwCnBjbTE6IDxIREEgQW5hbG9nIERldmljZXMgQUQxOTg0IFBDTSAjMSBBbmFsb2c+IGF0IGNh ZCAwIG5pZCAxIG9uIGhkYWMwCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNi dXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czI6IDQ4ME1icHMgSGlnaCBTcGVl ZCBVU0IgdjIuMAp1c2J1czM6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNDogMTJN YnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEu MAp1c2J1czY6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuMC4xOiA8SW50ZWw+IGF0 IHVzYnVzMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6 IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXMxCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyCnVodWIyOiA8SW50ZWwgRUhDSSBy b290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2Vu My4xOiA8SW50ZWw+IGF0IHVzYnVzMwp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKdWdlbjQuMTogPEludGVsPiBh dCB1c2J1czQKdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVnZW41LjE6IDxJbnRlbD4gYXQgdXNidXM1CnVodWI1 OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+ IG9uIHVzYnVzNQp1Z2VuNi4xOiA8SW50ZWw+IGF0IHVzYnVzNgp1aHViNjogPEludGVsIEVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czYKdWh1 YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVodWI1OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1 aHViMjogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDYgcG9y dHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW42LjI6IDx2ZW5kb3IgMHgwNWUz PiBhdCB1c2J1czYKdWh1Yjc6IDx2ZW5kb3IgMHgwNWUzIFVTQjIuMCBIdWIsIGNsYXNzIDkvMCwg cmV2IDIuMDAvOS4wMSwgYWRkciAyPiBvbiB1c2J1czYKdWh1Yjc6IDQgcG9ydHMgd2l0aCA0IHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW42LjM6IDxHZW5lcmljPiBhdCB1c2J1czYKdW1hc3Mw OiA8R2VuZXJpYyBFeHRlcm5hbCwgY2xhc3MgMC8wLCByZXYgMi4wMC8yLjEyLCBhZGRyIDM+IG9u IHVzYnVzNgp1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDAwMDAKdWdl bjAuMjogPERlbGw+IGF0IHVzYnVzMAp1a2JkMDogPEVQMSBJbnRlcnJ1cHQ+IG9uIHVzYnVzMApr YmQyIGF0IHVrYmQwCmFkYTAgYXQgYWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAK YWRhMDogPFdEQyBXRDUwMDFBQUxTLTAwTDNCMiAwMS4wM0IwMT4gQVRBLTggU0FUQSAyLnggZGV2 aWNlCmFkYTA6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gc2l6 ZSA4MTkyYnl0ZXMpCmFkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEwOiA0NzY5NDBN QiAoOTc2NzczMTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTEgYXQg YWhjaWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKYWRhMTogPFdEQyBXRDUwMDFBQUxT LTAwTDNCMiAwMS4wM0IwMT4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFkYTE6IDMwMC4wMDBNQi9z IHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gc2l6ZSA4MTkyYnl0ZXMpCmFkYTE6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExOiA0NzY5NDBNQiAoOTc2NzczMTY4IDUxMiBieXRl IHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmxhcGljMTogRm9yY2luZyBMSU5UMSB0byBlZGdl IHRyaWdnZXIKY2QxIGF0IGFoY2ljaDMgYnVzIDAgc2NidXMzIHRhcmdldCAwIGx1biAwCmNkMTog PFBCRFMgRFZEKy1SVyBESC0xNlcxUyAyRDE0PiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZp Y2UgCmNkMTogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwgVURNQTUsIFBJTyBzaXpl IDgxOTJieXRlcykKY2QxOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogVU5J VCBBVFRFTlRJT04sIFBvd2VyIG9uLCByZXNldCwgb3IgYnVzIGRldmljZSByZXNldCBvY2N1cnJl ZApjZDAgYXQgYWhjaWNoMiBidXMgMCBzY2J1czIgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8SEwtRFQt U1QgRFZELVJPTSBHRFJIMjBOIDBEMDQ+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAK Y2QwOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNSwgUElPIHNpemUgODE5 MmJ5dGVzKQpjZDA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBVTklUIEFU VEVOVElPTiwgUG93ZXIgb24sIHJlc2V0LCBvciBidXMgZGV2aWNlIHJlc2V0IG9jY3VycmVkClNN UDogQVAgQ1BVICMxIExhdW5jaGVkIQpsYXBpYzM6IEZvcmNpbmcgTElOVDEgdG8gZWRnZSB0cmln Z2VyClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpsYXBpYzI6IEZvcmNpbmcgTElOVDEgdG8gZWRn ZSB0cmlnZ2VyClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQp1bWFzczA6NTowOi0xOiBBdHRhY2hl ZCB0byBzY2J1czUKZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAgc2NidXM1IHRhcmdldCAwIGx1biAw CmRhMDogPEdlbmVyaWMgRXh0ZXJuYWwgMi4xMj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTQg ZGV2aWNlIApkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogNDc2OTQwTUIgKDk3Njc3MzE2 OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDYwODAxQykKdWdlbjAuMzogPHZlbmRvciAw eDA0NjE+IGF0IHVzYnVzMAp1bXMwOiA8dmVuZG9yIDB4MDQ2MSBVU0IgT3B0aWNhbCBNb3VzZSwg Y2xhc3MgMC8wLCByZXYgMi4wMC8yLjAwLCBhZGRyIDM+IG9uIHVzYnVzMAp1bXMwOiAzIGJ1dHRv bnMgYW5kIFtYWVpdIGNvb3JkaW5hdGVzIElEPTAKR0VPTV9NSVJST1I6IERldmljZSBtaXJyb3Iv c3dhcCBsYXVuY2hlZCAoMi8yKS4KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB6ZnM6enJvb3QK PDExOD5TZXR0aW5nIGhvc3R1dWlkOiA0NDQ1NGM0Yy01MzAwLTEwNGMtODA1My1jNGMwNGYzNDRh MzEuCjwxMTg+U2V0dGluZyBob3N0aWQ6IDB4YjY3MWZjNDYuCjwxMTg+U3RhcnRpbmcgZGRiLgo8 MTE4PkVudHJvcHkgaGFydmVzdGluZzoKPDExOD4gaW50ZXJydXB0cwo8MTE4PiBldGhlcm5ldAo8 MTE4PiBwb2ludF90b19wb2ludAo8MTE4PiBraWNrc3RhcnQKPDExOD4uCjwxMTg+U3RhcnRpbmcg ZmlsZSBzeXN0ZW0gY2hlY2tzOgo8MTE4Pk1vdW50aW5nIGxvY2FsIGZpbGUgc3lzdGVtczoKPDEx OD4uCnZib3huZXQwOiBFdGhlcm5ldCBhZGRyZXNzOiAwYTowMDoyNzowMDowMDowMAo8MTE4PlNl dHRpbmcgaG9zdG5hbWU6IGJnb29jaDc1NS5zZS5lZHUKPDExOD4uCjwxMTg+dmxhbjEwOiBubyBs aW5rIC4uLgo8MTE4Pi4KPDExOD4uCjwxMTg+IGdvdCBsaW5rCjwxMTg+REhDUFJFUVVFU1Qgb24g dmxhbjEwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3CjwxMTg+CjwxMTg+REhDUFJFUVVFU1Qg b24gdmxhbjEwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3CjwxMTg+CjwxMTg+REhDUERJU0NP VkVSIG9uIHZsYW4xMCB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NyBpbnRlcnZhbCA3CjwxMTg+ CjwxMTg+REhDUERJU0NPVkVSIG9uIHZsYW4xMCB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NyBp bnRlcnZhbCAxMgo8MTE4Pgo8MTE4PkRIQ1BESVNDT1ZFUiBvbiB2bGFuMTAgdG8gMjU1LjI1NS4y NTUuMjU1IHBvcnQgNjcgaW50ZXJ2YWwgMTQKPDExOD4KPDExOD5ESENQT0ZGRVIgZnJvbSAxNzIu MTkuMC4xCjwxMTg+CjwxMTg+REhDUFJFUVVFU1Qgb24gdmxhbjEwIHRvIDI1NS4yNTUuMjU1LjI1 NSBwb3J0IDY3CjwxMTg+CjwxMTg+REhDUEFDSyBmcm9tIDE3Mi4xOS4wLjEKPDExOD4KPDExOD5i b3VuZCB0byAxNzIuMTkuMC4yMzEgLS0gcmVuZXdhbCBpbiAzMDAgc2Vjb25kcy4KPDExOD4KPDEx OD52bGFuMzA6IG5vIGxpbmsgLi4uCjwxMTg+Lgo8MTE4Pi4KPDExOD4gZ290IGxpbmsKPDExOD5E SENQUkVRVUVTVCBvbiB2bGFuMzAgdG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcKPDExOD4KPDEx OD5ESENQUkVRVUVTVCBvbiB2bGFuMzAgdG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcKPDExOD4K PDExOD5ESENQRElTQ09WRVIgb24gdmxhbjMwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGlu dGVydmFsIDgKPDExOD4KPDExOD5ESENQT0ZGRVIgZnJvbSAxNzIuMTguMC4xCjwxMTg+CjwxMTg+ REhDUFJFUVVFU1Qgb24gdmxhbjMwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3CjwxMTg+Cjwx MTg+REhDUEFDSyBmcm9tIDE3Mi4xOC4wLjEKPDExOD4KPDExOD5ib3VuZCB0byAxNzIuMTguMTIz Ljg2IC0tIHJlbmV3YWwgaW4gMzg4ODAwMCBzZWNvbmRzLgo8MTE4Pgo8MTE4PlN0YXJ0aW5nIE5l dHdvcms6IGxvMCBlbTAgdmxhbjEwIHZsYW4yMSB2bGFuMjUgdmxhbjMwLgo8MTE4PmxvMDogZmxh Z3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE2Mzg0 CjwxMTg+CW9wdGlvbnM9MzxSWENTVU0sVFhDU1VNPgo8MTE4PglpbmV0NiBmZTgwOjoxJWxvMCBw cmVmaXhsZW4gNjQgc2NvcGVpZCAweDMgCjwxMTg+CWluZXQ2IDo6MSBwcmVmaXhsZW4gMTI4IAo8 MTE4PglpbmV0IDEyNy4wLjAuMSBuZXRtYXNrIDB4ZmYwMDAwMDAgCjwxMTg+CW5kNiBvcHRpb25z PTM8UEVSRk9STU5VRCxBQ0NFUFRfUlRBRFY+CjwxMTg+ZW0wOiBmbGFncz04ODQzPFVQLEJST0FE Q0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4Pglv cHRpb25zPTE5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdD U1VNLFRTTzQ+CjwxMTg+CWV0aGVyIDAwOjFlOjRmOmQ1Ojg0OmI3CjwxMTg+CWluZXQgMTAuNy4w LjcgbmV0bWFzayAweGZmMDAwMDAwIGJyb2FkY2FzdCAxMC4yNTUuMjU1LjI1NQo8MTE4PgltZWRp YTogRXRoZXJuZXQgYXV0b3NlbGVjdCAoMTAwMGJhc2VUIDxmdWxsLWR1cGxleD4pCjwxMTg+CXN0 YXR1czogYWN0aXZlCjwxMTg+dmxhbjEwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5H LFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4PglvcHRpb25zPTM8UlhD U1VNLFRYQ1NVTT4KPDExOD4JZXRoZXIgMDA6MWU6NGY6ZDU6ODQ6YjcKPDExOD4JaW5ldCAxNzIu MTkuMC4yMzEgbmV0bWFzayAweGZmZmZmZjAwIGJyb2FkY2FzdCAxNzIuMTkuMC4yNTUKPDExOD4J bWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+KQo8MTE4 PglzdGF0dXM6IGFjdGl2ZQo8MTE4Pgl2bGFuOiAxMCBwYXJlbnQgaW50ZXJmYWNlOiBlbTAKPDEx OD52bGFuMjE6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNB U1Q+IG1ldHJpYyAwIG10dSAxNTAwCjwxMTg+CW9wdGlvbnM9MzxSWENTVU0sVFhDU1VNPgo8MTE4 PglldGhlciAwMDoxZTo0ZjpkNTo4NDpiNwo8MTE4PglpbmV0IDE3Mi4xNy4xMjAuNzcgbmV0bWFz ayAweGZmZmZmZjAwIGJyb2FkY2FzdCAxNzIuMTcuMTIwLjI1NQo8MTE4PgltZWRpYTogRXRoZXJu ZXQgYXV0b3NlbGVjdCAoMTAwMGJhc2VUIDxmdWxsLWR1cGxleD4pCjwxMTg+CXN0YXR1czogYWN0 aXZlCjwxMTg+CXZsYW46IDIxIHBhcmVudCBpbnRlcmZhY2U6IGVtMAo8MTE4PnZsYW4yNTogZmxh Z3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAg bXR1IDE1MDAKPDExOD4Jb3B0aW9ucz0zPFJYQ1NVTSxUWENTVU0+CjwxMTg+CWV0aGVyIDAwOjFl OjRmOmQ1Ojg0OmI3CjwxMTg+CWluZXQgMTY0LjU4LjEyMC43NyBuZXRtYXNrIDB4ZmZmZmY4MDAg YnJvYWRjYXN0IDE2NC41OC4xMjcuMjU1CjwxMTg+CW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0 ICgxMDAwYmFzZVQgPGZ1bGwtZHVwbGV4PikKPDExOD4Jc3RhdHVzOiBhY3RpdmUKPDExOD4Jdmxh bjogMjUgcGFyZW50IGludGVyZmFjZTogZW0wCjwxMTg+dmxhbjMwOiBmbGFncz04ODQzPFVQLEJS T0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4 PglvcHRpb25zPTM8UlhDU1VNLFRYQ1NVTT4KPDExOD4JZXRoZXIgMDA6MWU6NGY6ZDU6ODQ6YjcK PDExOD4JaW5ldCAxNzIuMTguMTIzLjg2IG5ldG1hc2sgMHhmZmZmMDAwMCBicm9hZGNhc3QgMTcy LjE4LjI1NS4yNTUKPDExOD4JbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEwMDBiYXNlVCA8 ZnVsbC1kdXBsZXg+KQo8MTE4PglzdGF0dXM6IGFjdGl2ZQo8MTE4Pgl2bGFuOiAzMCBwYXJlbnQg aW50ZXJmYWNlOiBlbTAKPDExOD5yb3V0ZTogCjwxMTg+d3JpdGluZyB0byByb3V0aW5nIHNvY2tl dAo8MTE4PjogCjwxMTg+RmlsZSBleGlzdHMKPDExOD5hZGQgbmV0IGRlZmF1bHQ6IGdhdGV3YXkg MTAuMC4wLjI1NDogcm91dGUgYWxyZWFkeSBpbiB0YWJsZQo8MTE4PlN0YXJ0aW5nIGRldmQuCjwx MTg+U3RhcnRpbmcgdW1zMCBtb3VzZWQKPDExOD4uCjwxMTg+CjwxMTg+MDAxMDAgYWxsb3cgaXAg ZnJvbSBhbnkgdG8gYW55CjwxMTg+RmlyZXdhbGwgcnVsZXMgbG9hZGVkLgo8MTE4PkVMRiBsZGNv bmZpZyBwYXRoOiAvbGliIC91c3IvbGliIC91c3IvbGliL2NvbXBhdCAvdXNyL2xvY2FsL2xpYiAv dXNyL2xvY2FsL2xpYi9xdDQgL3Vzci9sb2NhbC9saWIvdmlydHVhbGJveAo8MTE4PjMyLWJpdCBj b21wYXRpYmlsaXR5IGxkY29uZmlnIHBhdGg6IC91c3IvbGliMzIKPDExOD5DcmVhdGluZyBhbmQv b3IgdHJpbW1pbmcgbG9nIGZpbGVzCjwxMTg+Lgo8MTE4PlN0YXJ0aW5nIHN5c2xvZ2QuCjwxMTg+ Tm8gY29yZSBkdW1wcyBmb3VuZC4KPDExOD5BZGRpdGlvbmFsIEFCSSBzdXBwb3J0Ogo8MTE4PiBs aW51eAo8MTE4Pi4KPDExOD5TdGFydGluZyBycGNiaW5kLgo8MTE4Pk5GUyBhY2Nlc3MgY2FjaGUg dGltZT02MAo8MTE4PlN0YXJ0aW5nIGFtZC4KPDExOD5DbGVhcmluZyAvdG1wIChYIHJlbGF0ZWQp Lgo8MTE4PlN0YXJ0aW5nIG1vdW50ZC4KPDExOD5TdGFydGluZyBuZnNkLgo8MTE4PmFkZCBuZXQg ZGVmYXVsdDogZ2F0ZXdheSAxNzIuMTkuMC4xCjwxMTg+YWRkIG5ldCBkZWZhdWx0OiBnYXRld2F5 IDE3Mi4xNy4xMjAuMQo8MTE4PmFkZCBuZXQgZGVmYXVsdDogZ2F0ZXdheSAxNjQuNTguMTIwLjI1 NAo8MTE4PmFkZCBuZXQgZGVmYXVsdDogZ2F0ZXdheSAxNzIuMTguMC4xCjwxMTg+Y2hhbmdlIG5l dCBkZWZhdWx0OiBnYXRld2F5IDEwLjAuMC4yNTQKPDExOD5SZW1vdmluZyBzdGFsZSBTYW1iYSB0 ZGIgZmlsZXM6IAo8MTE4PiBkb25lCjwxMTg+VXBkYXRpbmcgbW90ZDoKPDExOD4uCjwxMTg+U3Rh cnRpbmcgcG93ZXJkLgo8MTE4PlN0YXJ0aW5nIGRidXMuCjwxMTg+U3RhcnRpbmcgaGFsZC4KPDEx OD5TdGFydGluZyBic2RzdGF0cy4KPDExOD5Qb3N0aW5nIG1vbnRobHkgT1Mgc3RhdGlzdGljcyB0 byBycHQuYnNkc3RhdHMub3JnCjwxMTg+Q29uZmlndXJpbmcgc3lzY29uczoKPDExOD4gYmxhbmt0 aW1lCjwxMTg+Lgo8MTE4PlN0YXJ0aW5nIHNzaGQuCjwxMTg+U3RhcnRpbmcgY3Jvbi4KPDExOD5T dGFydGluZyBiYWNrZ3JvdW5kIGZpbGUgc3lzdGVtIGNoZWNrcyBpbiA2MCBzZWNvbmRzLgo8MTE4 Pgo8MTE4PldlZCBKYW4gMjcgMDk6MTg6NTYgQ1NUIDIwMTAKV0FSTklORyBwaWQgMTE5NjIgKFZC b3hTVkMpOiBpb2N0bCBzaWduLWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmM0YTgxNTAyCldBUk5J TkcgcGlkIDExOTYyIChWQm94U1ZDKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZm ZmZjNGE4MTUwMgpXQVJOSU5HIHBpZCAxMTk2MiAoVkJveFNWQyk6IGlvY3RsIHNpZ24tZXh0ZW5z aW9uIGlvY3RsIGZmZmZmZmZmYzRhODE1MDIKV0FSTklORyBwaWQgMTE5NjIgKFZCb3hTVkMpOiBp b2N0bCBzaWduLWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmM0YTgxNTAyCldBUk5JTkcgcGlkIDEx OTYyIChWQm94U1ZDKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjNGE4MTUw MgpXQVJOSU5HIHBpZCAxMTk2MiAoVkJveFNWQyk6IGlvY3RsIHNpZ24tZXh0ZW5zaW9uIGlvY3Rs IGZmZmZmZmZmYzRhODE1MDIKV0FSTklORyBwaWQgMTE5NjIgKFZCb3hTVkMpOiBpb2N0bCBzaWdu LWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmM0YTgxNTAyCldBUk5JTkcgcGlkIDExOTYyIChWQm94 U1ZDKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjNGE4MTUwMgpXQVJOSU5H IHBpZCAxMTk2MiAoVkJveFNWQyk6IGlvY3RsIHNpZ24tZXh0ZW5zaW9uIGlvY3RsIGZmZmZmZmZm YzRhODE1MDIKPDY+ZW0wOiBwcm9taXNjdW91cyBtb2RlIGVuYWJsZWQKPDY+ZW0wOiBwcm9taXNj dW91cyBtb2RlIGRpc2FibGVkCjw2PnBpZCA4MzQ3NyAodHJ5KSwgdWlkIDA6IGV4aXRlZCBvbiBz aWduYWwgMTAgKGNvcmUgZHVtcGVkKQpXQVJOSU5HIHBpZCA4ODI2NyAoVkJveFNWQyk6IGlvY3Rs IHNpZ24tZXh0ZW5zaW9uIGlvY3RsIGZmZmZmZmZmYzRhODE1MDIKV0FSTklORyBwaWQgODgyNjcg KFZCb3hTVkMpOiBpb2N0bCBzaWduLWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmM0YTgxNTAyCldB Uk5JTkcgcGlkIDg4MjY3IChWQm94U1ZDKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZm ZmZmZmZjNGE4MTUwMgo8Nj5lbTA6IHByb21pc2N1b3VzIG1vZGUgZW5hYmxlZApzcGluIGxvY2sg MHhmZmZmZmZmZjgwODU0ODQwIChzbXAgcmVuZGV6dm91cykgaGVsZCBieSAweGZmZmZmZjAxOWE3 NDFhZTAgKHRpZCAxMDAzMzMpIHRvbyBsb25nCnBhbmljOiBzcGluIGxvY2sgaGVsZCB0b28gbG9u ZwpjcHVpZCA9IDAKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigp IGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCnBhbmljKCkgYXQgcGFuaWMrMHgxODIKX210 eF9sb2NrX3NwaW5fZmFpbGVkKCkgYXQgX210eF9sb2NrX3NwaW5fZmFpbGVkKzB4MzkKX210eF9s b2NrX3NwaW4oKSBhdCBfbXR4X2xvY2tfc3BpbisweGIyCnNtcF90bGJfc2hvb3Rkb3duKCkgYXQg c21wX3RsYl9zaG9vdGRvd24rMHhmYQpwbWFwX2ludmFsaWRhdGVfcmFuZ2UoKSBhdCBwbWFwX2lu dmFsaWRhdGVfcmFuZ2UrMHhhZQp2bV90aHJlYWRfc3RhY2tfZGlzcG9zZSgpIGF0IHZtX3RocmVh ZF9zdGFja19kaXNwb3NlKzB4MmUKdGhyZWFkX2ZyZWUoKSBhdCB0aHJlYWRfZnJlZSsweDNjCnRo cmVhZF9yZWFwKCkgYXQgdGhyZWFkX3JlYXArMHhhMAp0aHJlYWRfYWxsb2MoKSBhdCB0aHJlYWRf YWxsb2MrMHgxOApjcmVhdGVfdGhyZWFkKCkgYXQgY3JlYXRlX3RocmVhZCsweGFkCmtlcm5fdGhy X25ldygpIGF0IGtlcm5fdGhyX25ldysweDdjCnRocl9uZXcoKSBhdCB0aHJfbmV3KzB4NjgKc3lz Y2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwr MHhlMQotLS0gc3lzY2FsbCAoNDU1LCBGcmVlQlNEIEVMRjY0LCB0aHJfbmV3KSwgcmlwID0gMHg4 MDE4N2Q0OGMsIHJzcCA9IDB4N2ZmZmZmZmZlN2U4LCByYnAgPSAweDgwMWMwOGVjMCAtLS0KS0RC OiBlbnRlcjogcGFuaWMKCjB4ZmZmZmZmMDExMDhlNTkzODogdGFnIHpmcywgdHlwZSBWUkVHCiAg ICB1c2Vjb3VudCAxLCB3cml0ZWNvdW50IDEsIHJlZmNvdW50IDEgbW91bnRlZGhlcmUgMAogICAg ZmxhZ3MgKCkKICAgIHZfb2JqZWN0IDB4ZmZmZmZmMDAwOTM1ZWJkMCByZWYgMCBwYWdlcyAwCiAg ICBsb2NrIHR5cGUgemZzOiBFWENMIGJ5IHRocmVhZCAweGZmZmZmZjAxOWE3NDFhZTAgKHBpZCA3 MDA0MykKCjB4ZmZmZmZmMDAwNmI3ODFkODogdGFnIHN5bmNlciwgdHlwZSBWTk9OCiAgICB1c2Vj b3VudCAxLCB3cml0ZWNvdW50IDAsIHJlZmNvdW50IDIgbW91bnRlZGhlcmUgMAogICAgZmxhZ3Mg KCkKICAgIGxvY2sgdHlwZSBzeW5jZXI6IEVYQ0wgYnkgdGhyZWFkIDB4ZmZmZmZmMDAwNjJiMzNh MCAocGlkIDE4KQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwYW5pYy50eHQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDYwMAAAAAAwAAAAAAAAADAAAAAAAAAAMjcAAAAAAAAA AAAAMTEzMzAwNjUyMTUAICA3MTMzACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHVzdGFyAAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3aGVlbAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNwaW4gbG9jayBoZWxkIHRvbyBs b25nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmVyc2lvbi50eHQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADA2MDAAAAAAMAAAAAAAAAAwAAAAAAAAADE2NAAAAAAAAAAA ADExMzMwMDY1MjE1ACAgNzYxMAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAB1c3RhcgAAAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd2hlZWwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGcmVlQlNEIDguMC1TVEFCTEUgIzAg cjIwMjk2OU06IE1vbiBKYW4gMjUgMTA6MDE6MDYgQ1NUIDIwMTAKICAgIHJvb3RAYmdvb2NoNzU1 LnNlLmVkdTovdXNyL29iai91c3Ivc3JjL3N5cy9ERUxMNzU1CgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --000e0cd328beb19215047e28eab4-- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 27 21:48:46 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55E76106568B for ; Wed, 27 Jan 2010 21:48:46 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: from web110513.mail.gq1.yahoo.com (web110513.mail.gq1.yahoo.com [67.195.8.118]) by mx1.freebsd.org (Postfix) with SMTP id 231238FC2E for ; Wed, 27 Jan 2010 21:48:45 +0000 (UTC) Received: (qmail 24574 invoked by uid 60001); 27 Jan 2010 21:48:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264628925; bh=3T+55gMnSAFb5TFx6oE+MGLe7S1mm6aCcOpVVAUkeoU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WdDSIm7ZgeWmhddJJyCnjXblDGAE/z80rolnXpedUIIufWvUrY9xVlY+tOjQADSz3Ag74npOhGbVGwq/2Rc1t+c3zGZSUI7IXzUgKB3kRq7FjYgXMmJc/8MhqucqQtWeZ6onJzNdlc7mDsz3yDmuSVq/0XyyJw/W2dXBEgRZyaA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6IQhIiqbeCXhtjaqwv5b1MnI5RaNQJCmuOb23SKYAFs2jJqRLoSia2lmXo3+ZB2ButOjwghKm2+9rX4N7e3TglaUNFzEsPP3+5VBgbqJDI6UzcDjuCytfOoFnkxQ3fJ0LRuX7CTZsYybYE3cn7/4w34Gg5qGster8MEI+oi4Jo4=; Message-ID: <529238.22926.qm@web110513.mail.gq1.yahoo.com> X-YMail-OSG: HOPfkrwVM1n.O4wvMT0gq79TnN6ddCWomMqEfVUujvXyN5yvVHUNGABvuIxwGHPS2UVjAYsSVMqavSMBMXsRcq4w6UCT2yblzHCwxIWlXV2WhO7SpVaWvZ3TDbeW4J_zeWEPEVkOf1R6KjpshZ7VHDz1eLcES8Zc7UmaDYbV29HohlGCrvpBHqBwnetMPdK9oTZmeqs7M6r3bBwIRpT.AkX22VUgUdxQGatmtn8pxtppxTvKclP8jnps1QDvzbJouDFJhlfsoWtPF7_WcpRTUk3b8omjszfQ80yPnkDYmcIJkU6ButJjZf1t0ez3ygRNi4gkh7nK_XEdhzc.I0FHKwL5sAjpptdiCc9uDHN_BukPdnDd9leZGOFLpBvIRQEF.Oh9S9Kbr4TfE8XFY3gCWgOBf0jED6YNLdM8rgePdmJSJOsgFMLyQ0__CaJKomjLFBZ1c_xpU3ZAM6qd_.sEJzxbx9gRbHWmY6qoD9B_wC9.v.DY79ENZd8gKqac7cRpRsD30yu0zw-- Received: from [71.174.61.120] by web110513.mail.gq1.yahoo.com via HTTP; Wed, 27 Jan 2010 13:48:45 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <419976.64363.qm@web110515.mail.gq1.yahoo.com> <422431.76479.qm@web110504.mail.gq1.yahoo.com> Date: Wed, 27 Jan 2010 13:48:45 -0800 (PST) From: Paul Pathiakis To: Bob Friesenhahn In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS - scrub lead to corruption? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 21:48:46 -0000 Hi all! Well, I've run every exercise tool I can think of and the hardware seems solid as a rock. The machine still crashes when I try to look at anything /usr/bin with a long listing or if I try to go to /usr/src and perform a "make buildworld". The errors all seem to point to ZFS. That is, the panics always occur during some type of ZFS operation. My consistent one (this is after going through each 2GB of the four I have swapping each) is this: zfs_fuid_map_id I can infer what it means but everything in the search engines refers to zfs_fuid.c as to where this issue lay and it was "fixed?". Again, I believe that ZFS is corrupted in some way and I need to roll things back or clean up a section of disk. I re-ran scrub on the pool. The mirror has disk 1 and disk 2. It resilvered disk2 for 563 GB and 99.6% of the time and 0m time remaining. However, after that time, disk 1 started creeping up to 370 MB from 250MB....I was waiting for it to complete when it panic'd. Thank you, Paul ________________________________ From: Bob Friesenhahn To: Paul Pathiakis Cc: freebsd-fs@freebsd.org Sent: Tue, January 26, 2010 1:34:51 PM Subject: Re: ZFS - scrub lead to corruption? On Tue, 26 Jan 2010, Paul Pathiakis wrote: > > Thank you, Bob. It worked fine. I'm up and working on the machine as I'm typing this. The zpool status says everything's fine. (??!!) That's a relief. However, why did the scrub cause it to crash? Zfs scrub is often the most intense thing you will do with your computer. It tends to uncover problems which are not necessarily related to zfs. If you are not using ECC memory, then bad memory is the first thing you should check for. > Please let me know. (Bob, BTW, I just checked into OpenSolaris bootable CD it's nice, you may want to check it out - FreeBSD is still a passion due to it's BSD storied history.) OpenSolaris has not been quite to the state where I feel that I should use it. Perhaps in three months (next OpenSolaris release) the situation will have changed. Meanwhile my FreeBSD system has been solid as a rock since 2003. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 00:23:28 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26343106568D for ; Thu, 28 Jan 2010 00:23:28 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: from web110504.mail.gq1.yahoo.com (web110504.mail.gq1.yahoo.com [67.195.8.252]) by mx1.freebsd.org (Postfix) with SMTP id E90E88FC0C for ; Thu, 28 Jan 2010 00:23:27 +0000 (UTC) Received: (qmail 83393 invoked by uid 60001); 28 Jan 2010 00:23:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264638207; bh=zxYlMX4J8zSsyVYQpSr8NSILBZUS2C0i5DXJHGY6k0c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3RmXZJAuRWOD9X2i3DVo9ZKTmyxnp2E0zqlCjSwJ9q38JWYW2H6a/QSzYRkOVly8LVjtqDBYlaCYa6P+wnWaD50PLviZDcyYbs1tRbxQREPrBcIFSm9qG44Pk+Q48DZxPf/O2nAfrmG7gxa6wOqerzJKSl1hKyX5FCUkacfdzE8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mxhJigj9uecFtPwJMdBb1iqwa9SgdIvwpTwd1KkmIE7mLYfedPCLdHWCtk921IYN371DdTh3SKAjGtd2rp2YAD9lSy2QJjrA4HrkFOZo71A0YTeAV+YN9ZuuqF+Ej3XFe/B55GERfNYiCIp+U8HN880n6r6APtwu2zdS+alRNfU=; Message-ID: <377667.81874.qm@web110504.mail.gq1.yahoo.com> X-YMail-OSG: SnndAnUVM1kKdBbsRXZ26bjbJibTq65yJLYWOl5IVvlxdukRETHWObz0kggHWku7P4kjn6mLBqjxi48CaiXWl5gFpLmiMmypwGk.1dCcjHoJUATAqphP3ypQM7nE5Bg5IabKvlBXNCal.sUMOpee2kKJS8lkOsGZG_3zgM_pLmw.7GLlfTioDwgvrCtQ5ITNfMz8V7wEyekM..s_Yw.HGoBWTxJbBH4065BHuhrGpLhAE3YaT97KANvPy2Lm5Kv5unHvsiIpAOtG4hlULYShKEEM0aa0z_M3sWbDZAiNvK.wG0ZVXfYU4.FrjwUbSrFmNIN.uaE- Received: from [71.174.61.120] by web110504.mail.gq1.yahoo.com via HTTP; Wed, 27 Jan 2010 16:23:27 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <419976.64363.qm@web110515.mail.gq1.yahoo.com> <422431.76479.qm@web110504.mail.gq1.yahoo.com> <529238.22926.qm@web110513.mail.gq1.yahoo.com> Date: Wed, 27 Jan 2010 16:23:27 -0800 (PST) From: Paul Pathiakis To: Paul Pathiakis , Bob Friesenhahn In-Reply-To: <529238.22926.qm@web110513.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS - scrub lead to corruption? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 00:23:28 -0000 Hi, Latest update: The machine is now in a state where is gives the ZFS error described below. I boot to single-user, make sure that scrubbing is turned off and it throws the error within 2 minutes of being up.... I'm SOL unless someone (please!!!) can respond and tell me how to roll this back. I'm going to build another drive with FreeBSD-p2 on it and see if I can import the pool and what that gets me. I might be able to at least get a crash dump and post it. Paul ________________________________ From: Paul Pathiakis To: Bob Friesenhahn Cc: freebsd-fs@freebsd.org Sent: Wed, January 27, 2010 4:48:45 PM Subject: Re: ZFS - scrub lead to corruption? Hi all! Well, I've run every exercise tool I can think of and the hardware seems solid as a rock. The machine still crashes when I try to look at anything /usr/bin with a long listing or if I try to go to /usr/src and perform a "make buildworld". The errors all seem to point to ZFS. That is, the panics always occur during some type of ZFS operation. My consistent one (this is after going through each 2GB of the four I have swapping each) is this: zfs_fuid_map_id I can infer what it means but everything in the search engines refers to zfs_fuid.c as to where this issue lay and it was "fixed?". Again, I believe that ZFS is corrupted in some way and I need to roll things back or clean up a section of disk. I re-ran scrub on the pool. The mirror has disk 1 and disk 2. It resilvered disk2 for 563 GB and 99.6% of the time and 0m time remaining. However, after that time, disk 1 started creeping up to 370 MB from 250MB....I was waiting for it to complete when it panic'd. Thank you, Paul From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 12:06:25 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EC64106566C; Thu, 28 Jan 2010 12:06:25 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7B58FC12; Thu, 28 Jan 2010 12:06:24 +0000 (UTC) Received: from furia.intranet ([93.104.121.114]) (AUTH: LOGIN lopez.on.the.lists@yellowspace.net) by mail.yellowspace.net with esmtp; Thu, 28 Jan 2010 13:06:22 +0100 id 0037B497.000000004B617DBE.000161A2 From: Lorenzo Perone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 13:06:21 +0100 Message-Id: To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: Pawel Jakub Dawidek Subject: Any news on the HASP Project? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 12:06:25 -0000 Hi, a while ago (October) there was a really sexy announcement=20 on freebsd-announce: HASP[1] :) Any news about it? I'm just very curious=20= (and as for many things by pjd, after licking blood... you end up=20 wanting more) about the implementation details and first tests... big regards, Lorenzo [1] = http://lists.freebsd.org/pipermail/freebsd-announce/2009-October/001279.ht= ml From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 12:13:59 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E5F0106568B for ; Thu, 28 Jan 2010 12:13:59 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id 828348FC17 for ; Thu, 28 Jan 2010 12:13:58 +0000 (UTC) Received: from furia.intranet ([93.104.121.114]) (AUTH: LOGIN lopez.on.the.lists@yellowspace.net) by mail.yellowspace.net with esmtp; Thu, 28 Jan 2010 13:13:57 +0100 id 0037B497.000000004B617F85.00016672 From: Lorenzo Perone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 13:13:56 +0100 Message-Id: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: Any news on the HAST Project? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 12:13:59 -0000 SORRY, I just made really misleading typo in my previous=20 post :(. Here's an errata copy for the sake of list-SEO... Hi, a while ago (October) there was a really sexy announcement=20 on freebsd-announce: HAST[1] :) Any news about it? I'm just very curious=20= (and as for many things by pjd, after licking blood... you end up=20 wanting more) about the implementation details and first tests... big regards, Lorenzo [1] = http://lists.freebsd.org/pipermail/freebsd-announce/2009-October/001279.ht= ml _______________________________________________ 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 Jan 28 13:26:16 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1F3E1065672 for ; Thu, 28 Jan 2010 13:26:16 +0000 (UTC) (envelope-from hywel@hmallett.co.uk) Received: from lisbon.directrouter.com (lisbon.directrouter.com [72.249.30.130]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF578FC14 for ; Thu, 28 Jan 2010 13:26:16 +0000 (UTC) Received: from localhost ([127.0.0.1]) by lisbon.directrouter.com with esmtpa (Exim 4.69) (envelope-from ) id 1NaUNx-0003aB-QP; Thu, 28 Jan 2010 07:26:13 -0600 Received: from 82.111.203.2 ([82.111.203.2]) by www.hmallett.co.uk (Horde MIME library) with HTTP; Thu, 28 Jan 2010 13:26:13 +0000 Message-ID: <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> Date: Thu, 28 Jan 2010 13:26:13 +0000 From: Hywel Mallett To: Lorenzo Perone References: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> In-Reply-To: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - lisbon.directrouter.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hmallett.co.uk X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-fs@freebsd.org Subject: Re: Any news on the HAST Project? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 13:26:16 -0000 Quoting Lorenzo Perone : > a while ago (October) there was a really sexy announcement > on freebsd-announce: HAST[1] :) Any news about it? I emailed pjd in mid-December, and received the response (which I'm sure he won't mind me reproducing): "...the goal at this point is to finish it by February. I'll post the code for testing once it is ready. It will be committed to HEAD after some testing from others, but it will probably take another month." About the same time a status update was posted on the FreeBSD Foundation blog at http://freebsdfoundation.blogspot.com/2009/12/update-on-hast-project.html From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 13:37:32 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1EC7106568F for ; Thu, 28 Jan 2010 13:37:32 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6785D8FC14 for ; Thu, 28 Jan 2010 13:37:31 +0000 (UTC) Received: by fxm27 with SMTP id 27so189538fxm.3 for ; Thu, 28 Jan 2010 05:37:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lQj0yqCj5L3DJ32YKA2+arBT2DimXhAxvJgvI1waW8k=; b=A6u1rh/Jlfa0TE7esel+lutc9GxktbHeNxIS1FcJR08y1Rr/lefXgWkHuPSJMUe0ct hylFzfNizNdNxpSW1JPMVdcVQ/ew8iUyaJmdG+3nCZE09tahd7jegVbqlQ+qy6EeBDaS WD2ALS1jBFBc7SR5sNjvCpgcfxqxorDIJZkoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bhcxzCflAcibca+rAZHqMK1wEGsRKdlmv8jLI2nJ/LVTuvc7dApbFfsFb1d2w0QAVy 6l4k8asK/x8cggKRTsXiN8wqs5w3TLW+vW+zgxeIBvg8dk9m08s7kTwsDAix6SqESHd+ Tm599bgzmUa3d2ZoETt+kg7ZYoEXOJF0eOO6U= MIME-Version: 1.0 Received: by 10.216.186.6 with SMTP id v6mr3402618wem.130.1264685850897; Thu, 28 Jan 2010 05:37:30 -0800 (PST) In-Reply-To: <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> References: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> Date: Thu, 28 Jan 2010 14:37:30 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Hywel Mallett Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Any news on the HAST Project? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 13:37:32 -0000 you can follow pjd work here: http://p4db.freebsd.org/changeList.cgi?CMD=changes&FSPC=//depot/user/pjd/hast/... 2010/1/28 Hywel Mallett : > Quoting Lorenzo Perone : > >> a while ago (October) there was a really sexy announcement >> on freebsd-announce: HAST[1] :) Any news about it? > > I emailed pjd in mid-December, and received the response (which I'm sure he > won't mind me reproducing): > > "...the goal at this point is to finish it by February. I'll post the > code for testing once it is ready. It will be committed to HEAD after > some testing from others, but it will probably take another month." > > About the same time a status update was posted on the FreeBSD Foundation > blog at > http://freebsdfoundation.blogspot.com/2009/12/update-on-hast-project.html > > _______________________________________________ > 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 Jan 28 13:58:59 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C88F6106566B for ; Thu, 28 Jan 2010 13:58:59 +0000 (UTC) (envelope-from urmas.lett@eenet.ee) Received: from muheleja.eenet.ee (muheleja.eenet.ee [193.40.0.132]) by mx1.freebsd.org (Postfix) with ESMTP id 8482E8FC1B for ; Thu, 28 Jan 2010 13:58:59 +0000 (UTC) Received: from muheleja.eenet.ee (localhost [127.0.0.1]) by localhost.eenet.ee (Postfix) with ESMTP id 099A81CC2B for ; Thu, 28 Jan 2010 15:43:31 +0200 (EET) X-Virus-Scanned: amavisd-new at eenet.ee Received: from muheleja.eenet.ee ([127.0.0.1]) by muheleja.eenet.ee (muheleja.eenet.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjNQ1hCYRQWW for ; Thu, 28 Jan 2010 15:43:28 +0200 (EET) Received: from [193.40.0.223] (poriseja.eenet.ee [193.40.0.223]) by muheleja.eenet.ee (Postfix) with ESMTP id DF66C1CC2A for ; Thu, 28 Jan 2010 15:43:28 +0200 (EET) Message-ID: <4B619485.8080106@eenet.ee> Date: Thu, 28 Jan 2010 15:43:33 +0200 From: Urmas Lett Organization: EENet User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Reading from ZFS mirror 2x slower than expected? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 13:58:59 -0000 While reading from simple zfs mirror 'dd if=zfs.test of=/dev/null bs=512k' systat -vm shows individual disks only 50% busy: Disks ad4 ad8 ad10 KB/t 0.00 128 128 tps 0 273 285 MB/s 0.00 34.15 35.64 %busy 0 51 48 reading from one disk 'dd if=/dev/ad8 of=/dev/null bs=512k' is 2x faster: Disks ad4 ad8 ad10 KB/t 0.00 128 0.00 tps 0 769 0 MB/s 0.00 96.09 0.00 %busy 0 97 0 and even writing to the same mirror is 2x faster: Disks ad4 ad8 ad10 KB/t 0.00 128 128 tps 0 654 707 MB/s 0.00 81.76 88.36 %busy 0 100 100 -- Urmas Lett Tel: +(372) 7 302 110 Fax: +(372) 7 302 111 E-Mail: urmas.lett@eenet.ee From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 15:27:19 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DDA9106568F for ; Thu, 28 Jan 2010 15:27:19 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 64B488FC22 for ; Thu, 28 Jan 2010 15:27:17 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5A2A245F99; Thu, 28 Jan 2010 16:27:16 +0100 (CET) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 93B6645E35; Thu, 28 Jan 2010 16:27:11 +0100 (CET) Date: Thu, 28 Jan 2010 16:27:09 +0100 From: Pawel Jakub Dawidek To: Lorenzo Perone Message-ID: <20100128152709.GE2251@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="phCU5ROyZO6kBE05" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: Any news on the HASP Project? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 15:27:19 -0000 --phCU5ROyZO6kBE05 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 28, 2010 at 01:06:21PM +0100, Lorenzo Perone wrote: >=20 > Hi, >=20 > a while ago (October) there was a really sexy announcement=20 > on freebsd-announce: HASP[1] :) Any news about it? I'm just very curious= =20 > (and as for many things by pjd, after licking blood... you end up=20 > wanting more) about the implementation details and first tests... Be patient:) I should br able to post test version in early February. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --phCU5ROyZO6kBE05 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLYazMForvXbEpPzQRAkyBAKDpnDTIQPEg5Jkt/i8X99arx/l5gwCgzWKK aMnYK0+1C/6IfFAqg1lu0qw= =tmoC -----END PGP SIGNATURE----- --phCU5ROyZO6kBE05-- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 18:28:09 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFAB21065672 for ; Thu, 28 Jan 2010 18:28:09 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from smtp114.rog.mail.re2.yahoo.com (smtp114.rog.mail.re2.yahoo.com [68.142.225.230]) by mx1.freebsd.org (Postfix) with SMTP id 4C5B78FC12 for ; Thu, 28 Jan 2010 18:28:08 +0000 (UTC) Received: (qmail 4695 invoked from network); 28 Jan 2010 18:28:08 -0000 Received: from CPE0080c8f208a5-CM001371173cf8.cpe.net.cable.rogers.com (gtodd@99.246.61.82 with login) by smtp114.rog.mail.re2.yahoo.com with SMTP; 28 Jan 2010 10:28:08 -0800 PST X-Yahoo-SMTP: nTCfdR6swBBGLC_L2D5qGu5iTT2NdwV8DpHvzb.tTA-- X-YMail-OSG: dfaz1D8VM1nA.ugAPxWPxryyb0XIgs0xECyaN_.VZCbDBjnWCasmOfxSGvItPiPGFA-- X-Yahoo-Newman-Property: ymail-3 Received: from wawanesa.iciti.ca (wawanesa.iciti.ca [192.168.2.4]) by wawanesa.iciti.ca (Postfix) with ESMTP id 45EEA36; Thu, 28 Jan 2010 13:24:40 -0500 (EST) Message-ID: <4B61D668.3020703@bellanet.org> Date: Thu, 28 Jan 2010 13:24:40 -0500 From: Graham Todd User-Agent: Thunderbird 2.0.0.21 (X11/20090511) MIME-Version: 1.0 To: Paul Pathiakis References: <419976.64363.qm@web110515.mail.gq1.yahoo.com> <422431.76479.qm@web110504.mail.gq1.yahoo.com> <529238.22926.qm@web110513.mail.gq1.yahoo.com> <377667.81874.qm@web110504.mail.gq1.yahoo.com> In-Reply-To: <377667.81874.qm@web110504.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ZFS - scrub lead to corruption? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:28:09 -0000 Paul Pathiakis wrote: ... > > I boot to single-user, make sure that scrubbing is turned off and it > throws the error within 2 minutes of being up.... I'm SOL unless someone > (please!!!) can respond and tell me how to roll this back. I think there was a discussion on -current or this list about using zdb to force a rollback to a previous uberblock - but I'm not sure if this would apply to your situation. Using zdb is a bit more high risk and you might not be able to rollback that far ... i.e it might not solve your corruption issue (the one where /usr/bin/m4 is "there" but "not there"?). Here's a related solaris discussion you may have seen: http://www.opensolaris.org/jive/thread.jspa?threadID=85794 From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 18:30:15 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFE0B1065698 for ; Thu, 28 Jan 2010 18:30:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CED388FC24 for ; Thu, 28 Jan 2010 18:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0SIUFmY011875 for ; Thu, 28 Jan 2010 18:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0SIUFcA011870; Thu, 28 Jan 2010 18:30:15 GMT (envelope-from gnats) Date: Thu, 28 Jan 2010 18:30:15 GMT Message-Id: <201001281830.o0SIUFcA011870@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Pedro F. Giffuni" Cc: Subject: Re: kern/142924: Small cleanup for the inode struct in ext2fs (based on UFS) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Pedro F. Giffuni" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:30:16 -0000 The following reply was made to PR kern/142924; it has been noted by GNATS. From: "Pedro F. Giffuni" To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/142924: Small cleanup for the inode struct in ext2fs (based on UFS) Date: Thu, 28 Jan 2010 10:22:25 -0800 (PST) --0-1299979072-1264702945=:12268 Content-Type: text/plain; charset=us-ascii Include two more simple patches from ufs_lookup.c: CVS 1.54: When compacting directories, ufs_direnter() always trusted DIRSIZ() to supply the number of bytes to be bcopy()'d to move an entry. If d_ino == 0 however, DIRSIZ() is not guaranteed to return a sensible length, so ufs_direnter could end up corrupting a directory during compaction. CVS 1.45: Extend the sanity checks in ufs_lookup to ensure that each directory entry fits within its DIRBLKSIZ block. _______ These were meant to fix issues found with dirhash on UFS but ext2fs still works here with those changes so I think it's good to have them, JIC we end up bringing over dirhash to ext2fs. --0-1299979072-1264702945=:12268 Content-Type: application/octet-stream; name=patch-ext2fs Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=patch-ext2fs ZGlmZiAtcnUgZXh0MmZzLmJzZC9leHQyX2xvb2t1cC5jIGV4dDJmcy9leHQy X2xvb2t1cC5jCi0tLSBleHQyZnMuYnNkL2V4dDJfbG9va3VwLmMJMjAxMC0w MS0xNyAxOTowMjozMC4wMDAwMDAwMDAgKzAwMDAKKysrIGV4dDJmcy9leHQy X2xvb2t1cC5jCTIwMTAtMDEtMjQgMTk6Mjc6NTIuMDAwMDAwMDAwICswMDAw CkBAIC0zNDcsNiArMzQ3LDcgQEAKIAkJc2xvdG5lZWRlZCA9IChzaXplb2Yo c3RydWN0IGRpcmVjdCkgLSBNQVhOQU1MRU4gKwogCQkJY25wLT5jbl9uYW1l bGVuICsgMykgJn4gMzsgKi8KIAl9CisJYm1hc2sgPSBWRlNUT0VYVDIodmRw LT52X21vdW50KS0+dW1fbW91bnRwLT5tbnRfc3RhdC5mX2lvc2l6ZSAtIDE7 CiAKIAkvKgogCSAqIElmIHRoZXJlIGlzIGNhY2hlZCBpbmZvcm1hdGlvbiBv biBhIHByZXZpb3VzIHNlYXJjaCBvZgpAQCAtMzU5LDkgKzM2MCw4IEBACiAJ ICogcHJvZmlsaW5nIHRpbWUgYW5kIGhlbmNlIGhhcyBiZWVuIHJlbW92ZWQg aW4gdGhlIGludGVyZXN0CiAJICogb2Ygc2ltcGxpY2l0eS4KIAkgKi8KLQli bWFzayA9IFZGU1RPRVhUMih2ZHAtPnZfbW91bnQpLT51bV9tb3VudHAtPm1u dF9zdGF0LmZfaW9zaXplIC0gMTsKIAlpZiAobmFtZWlvcCAhPSBMT09LVVAg fHwgaV9kaXJvZmYgPT0gMCB8fAotCSAgICBpX2Rpcm9mZiA+IGRwLT5pX3Np emUpIHsKKwkgICAgaV9kaXJvZmYgPj0gZHAtPmlfc2l6ZSkgewogCQllbnRy eW9mZnNldGluYmxvY2sgPSAwOwogCQlpX29mZnNldCA9IDA7CiAJCW51bWRp cnBhc3NlcyA9IDE7CkBAIC00MDgsOSArNDA4LDkgQEAKIAkJICogZGlyZWN0 b3J5LiBDb21wbGV0ZSBjaGVja3MgY2FuIGJlIHJ1biBieSBzZXR0aW5nCiAJ CSAqICJ2ZnMuZTJmcy5kaXJjaGsiIHRvIGJlIHRydWUuCiAJCSAqLwotCQll cCA9IChzdHJ1Y3QgZXh0MmZzX2RpcmVjdF8yICopCi0JCQkoKGNoYXIgKili cC0+Yl9kYXRhICsgZW50cnlvZmZzZXRpbmJsb2NrKTsKLQkJaWYgKGVwLT5l MmRfcmVjbGVuID09IDAgfHwKKwkJZXAgPSAoc3RydWN0IGV4dDJmc19kaXJl Y3RfMiAqKSgoY2hhciAqKWJwLT5iX2RhdGEgKyBlbnRyeW9mZnNldGluYmxv Y2spOworCQlpZiAoZXAtPmUyZF9yZWNsZW4gPT0gMCB8fCBlcC0+ZTJkX3Jl Y2xlbiA+CisJCSAgICBESVJCTEtTSVogLSAoZW50cnlvZmZzZXRpbmJsb2Nr ICYgKERJUkJMS1NJWiAtIDEpKSB8fAogCQkgICAgKGRpcmNoayAmJiBleHQy X2RpcmJhZGVudHJ5KHZkcCwgZXAsIGVudHJ5b2Zmc2V0aW5ibG9jaykpKSB7 CiAJCQlpbnQgaTsKIAkJCWV4dDJfZGlyYmFkKGRwLCBpX29mZnNldCwgIm1h bmdsZWQgZW50cnkiKTsKQEAgLTU1MCwxMCArNTUwLDEwIEBACiAJICogQ2hl Y2sgdGhhdCBkaXJlY3RvcnkgbGVuZ3RoIHByb3Blcmx5IHJlZmxlY3RzIHBy ZXNlbmNlCiAJICogb2YgdGhpcyBlbnRyeS4KIAkgKi8KLQlpZiAoZW50cnlv ZmZzZXRpbmJsb2NrICsgRVhUMl9ESVJfUkVDX0xFTihlcC0+ZTJkX25hbWxl bikKKwlpZiAoZHAtPmlfb2Zmc2V0ICsgRVhUMl9ESVJfUkVDX0xFTihlcC0+ ZTJkX25hbWxlbikKIAkJPiBkcC0+aV9zaXplKSB7CiAJCWV4dDJfZGlyYmFk KGRwLCBpX29mZnNldCwgImlfc2l6ZSB0b28gc21hbGwiKTsKLQkJZHAtPmlf c2l6ZSA9IGVudHJ5b2Zmc2V0aW5ibG9jaytFWFQyX0RJUl9SRUNfTEVOKGVw LT5lMmRfbmFtbGVuKTsKKwkJZHAtPmlfc2l6ZSA9IGRwLT5pX29mZnNldCtF WFQyX0RJUl9SRUNfTEVOKGVwLT5lMmRfbmFtbGVuKTsKIAkJZHAtPmlfZmxh ZyB8PSBJTl9DSEFOR0UgfCBJTl9VUERBVEU7CiAJfQogCWJyZWxzZShicCk7 CkBAIC04NTUsMTcgKzg1NSwzMCBAQAogCSAqIHNwYWNlLgogCSAqLwogCWVw ID0gKHN0cnVjdCBleHQyZnNfZGlyZWN0XzIgKilkaXJidWY7Ci0JZHNpemUg PSBFWFQyX0RJUl9SRUNfTEVOKGVwLT5lMmRfbmFtbGVuKTsKKwlkc2l6ZSA9 IGVwLT5lMmRfaW5vID8gRVhUMl9ESVJfUkVDX0xFTihlcC0+ZTJkX25hbWxl bikgOiAwOwogCXNwYWNlZnJlZSA9IGVwLT5lMmRfcmVjbGVuIC0gZHNpemU7 CiAJZm9yIChsb2MgPSBlcC0+ZTJkX3JlY2xlbjsgbG9jIDwgZHAtPmlfY291 bnQ7ICkgewogCQluZXAgPSAoc3RydWN0IGV4dDJmc19kaXJlY3RfMiAqKShk aXJidWYgKyBsb2MpOwotCQlpZiAoZXAtPmUyZF9pbm8pIHsKLQkJCS8qIHRy aW0gdGhlIGV4aXN0aW5nIHNsb3QgKi8KLQkJCWVwLT5lMmRfcmVjbGVuID0g ZHNpemU7Ci0JCQllcCA9IChzdHJ1Y3QgZXh0MmZzX2RpcmVjdF8yICopKChj aGFyICopZXAgKyBkc2l6ZSk7Ci0JCX0gZWxzZSB7Ci0JCQkvKiBvdmVyd3Jp dGU7IG5vdGhpbmcgdGhlcmU7IGhlYWRlciBpcyBvdXJzICovCi0JCQlzcGFj ZWZyZWUgKz0gZHNpemU7CisKKwkJLyogdHJpbSB0aGUgZXhpc3Rpbmcgc2xv dCAoTkI6IGRzaXplIG1heSBiZSB6ZXJvKS4gKi8KKwkJZXAtPmUyZF9yZWNs ZW4gPSBkc2l6ZTsKKwkJZXAgPSAoc3RydWN0IGV4dDJmc19kaXJlY3RfMiAq KSgoY2hhciAqKWVwICsgZHNpemUpOworCisJCS8qIFJlYWQgbmVwLT5lMmRf cmVjbGVuIG5vdyBhcyB0aGUgYmNvcHkoKSBtYXkgY2xvYmJlciBpdC4gKi8K KwkJbG9jICs9IG5lcC0+ZTJkX3JlY2xlbjsKKwkJaWYgKG5lcC0+ZTJkX2lu byA9PSAwKSB7CisJCQkvKgorCQkJICogQSBtaWQtYmxvY2sgdW51c2VkIGVu dHJ5LiBTdWNoIGVudHJpZXMgYXJlCisJCQkgKiBuZXZlciBjcmVhdGVkIGJ5 IHRoZSBrZXJuZWwsIGJ1dCBmc2NrCisJCQkgKiBjYW4gY3JlYXRlIHRoZW0g KGFuZCBub3QgZml4IHRoZW0pLgorCQkJICoKKwkJCSAqIEFkZCB1cCB0aGUg ZnJlZSBzcGFjZSwgYW5kIGluaXRpYWxpc2UgdGhlCisJCQkgKiByZWxvY2F0 ZWQgZW50cnkgc2luY2Ugd2UgZG9uJ3QgYmNvcHkgaXQuCisJCQkgKi8KKwkJ CXNwYWNlZnJlZSArPSBuZXAtPmUyZF9yZWNsZW47CisJCQllcC0+ZTJkX2lu byA9IDA7CisJCQlkc2l6ZSA9IDA7CisJCQljb250aW51ZTsKIAkJfQogCQlk c2l6ZSA9IEVYVDJfRElSX1JFQ19MRU4obmVwLT5lMmRfbmFtbGVuKTsKIAkJ c3BhY2VmcmVlICs9IG5lcC0+ZTJkX3JlY2xlbiAtIGRzaXplOwpkaWZmIC1y dSBleHQyZnMuYnNkL2V4dDJfdmZzb3BzLmMgZXh0MmZzL2V4dDJfdmZzb3Bz LmMKLS0tIGV4dDJmcy5ic2QvZXh0Ml92ZnNvcHMuYwkyMDEwLTAxLTE3IDE5 OjAyOjU2LjAwMDAwMDAwMCArMDAwMAorKysgZXh0MmZzL2V4dDJfdmZzb3Bz LmMJMjAxMC0wMS0xOCAxNTo0MzoyMC4wMDAwMDAwMDAgKzAwMDAKQEAgLTk0 NSw5ICs5NDUsOCBAQAogCX0KIAogCS8qCi0JICogRmluaXNoIGlub2RlIGlu aXRpYWxpemF0aW9uIG5vdyB0aGF0IGFsaWFzaW5nIGhhcyBiZWVuIHJlc29s dmVkLgorCSAqIEZpbmlzaCBpbm9kZSBpbml0aWFsaXphdGlvbi4KIAkgKi8K LQlpcC0+aV9kZXZ2cCA9IHVtcC0+dW1fZGV2dnA7CiAKIAkvKgogCSAqIFNl dCB1cCBhIGdlbmVyYXRpb24gbnVtYmVyIGZvciB0aGlzIGlub2RlIGlmIGl0 IGRvZXMgbm90CmRpZmYgLXJ1IGV4dDJmcy5ic2QvaW5vZGUuaCBleHQyZnMv aW5vZGUuaAotLS0gZXh0MmZzLmJzZC9pbm9kZS5oCTIwMTAtMDEtMTcgMTk6 MDM6MjEuMDAwMDAwMDAwICswMDAwCisrKyBleHQyZnMvaW5vZGUuaAkyMDEw LTAxLTE4IDE1OjQzOjIwLjAwMDAwMDAwMCArMDAwMApAQCAtNjIsNyArNjIs NiBAQAogICovCiBzdHJ1Y3QgaW5vZGUgewogCXN0cnVjdAl2bm9kZSAgKmlf dm5vZGU7LyogVm5vZGUgYXNzb2NpYXRlZCB3aXRoIHRoaXMgaW5vZGUuICov Ci0Jc3RydWN0CXZub2RlICAqaV9kZXZ2cDsvKiBWbm9kZSBmb3IgYmxvY2sg SS9PLiAqLwogCXN0cnVjdAlleHQybW91bnQgKmlfdW1wOwogCXVfaW50MzJf dCBpX2ZsYWc7CS8qIGZsYWdzLCBzZWUgYmVsb3cgKi8KIAlpbm9fdAkgIGlf bnVtYmVyOwkvKiBUaGUgaWRlbnRpdHkgb2YgdGhlIGlub2RlLiAqLwpAQCAt MTQzLDYgKzE0Miw5IEBACiAjZGVmaW5lCUlOX1NQQUNFQ09VTlRFRAkweDAw ODAJCS8qIEJsb2NrcyB0byBiZSBmcmVlZCBpbiBmcmVlIGNvdW50LiAqLwog I2RlZmluZSBJTl9MQVpZQUNDRVNTICAgMHgwMTAwCQkvKiBQcm9jZXNzIElO X0FDQ0VTUyBhZnRlciB0aGUKIAkJCQkJICAgIHN1c3BlbnNpb24gZmluaXNo ZWQgKi8KKworI2RlZmluZSBpX2RldnZwIGlfdW1wLT51bV9kZXZ2cAorCiAj aWZkZWYgX0tFUk5FTAogLyoKICAqIFN0cnVjdHVyZSB1c2VkIHRvIHBhc3Mg YXJvdW5kIGxvZ2ljYWwgYmxvY2sgcGF0aHMgZ2VuZXJhdGVkIGJ5Cg== --0-1299979072-1264702945=:12268-- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 18:40:11 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35A7A1065670 for ; Thu, 28 Jan 2010 18:40:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 24CA28FC16 for ; Thu, 28 Jan 2010 18:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0SIeAGA021095 for ; Thu, 28 Jan 2010 18:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0SIeAQX021094; Thu, 28 Jan 2010 18:40:10 GMT (envelope-from gnats) Date: Thu, 28 Jan 2010 18:40:10 GMT Message-Id: <201001281840.o0SIeAQX021094@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Mark Linimon Cc: Subject: Re: kern/142924: Small cleanup for the inode struct in ext2fs (based on UFS) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:40:11 -0000 The following reply was made to PR kern/142924; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/142924: Small cleanup for the inode struct in ext2fs (based on UFS) Date: Thu, 28 Jan 2010 12:37:32 -0600 ----- Forwarded message from "Pedro F. Giffuni" ----- From: "Pedro F. Giffuni" To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/142924: Small cleanup for the inode struct in ext2fs (based on UFS) Include two more simple patches from ufs_lookup.c: CVS 1.54: When compacting directories, ufs_direnter() always trusted DIRSIZ() to supply the number of bytes to be bcopy()'d to move an entry. If d_ino == 0 however, DIRSIZ() is not guaranteed to return a sensible length, so ufs_direnter could end up corrupting a directory during compaction. CVS 1.45: Extend the sanity checks in ufs_lookup to ensure that each directory entry fits within its DIRBLKSIZ block. _______ These were meant to fix issues found with dirhash on UFS but ext2fs still works here with those changes so I think it's good to have them, JIC we end up bringing over dirhash to ext2fs. ----- End forwarded message ----- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 19:54:23 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CE37106566B for ; Thu, 28 Jan 2010 19:54:23 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 179088FC14 for ; Thu, 28 Jan 2010 19:54:22 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o0SJsEWI005710; Thu, 28 Jan 2010 13:54:14 -0600 (CST) Date: Thu, 28 Jan 2010 13:54:14 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Urmas Lett In-Reply-To: <4B619485.8080106@eenet.ee> Message-ID: References: <4B619485.8080106@eenet.ee> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Thu, 28 Jan 2010 13:54:14 -0600 (CST) Cc: freebsd-fs@freebsd.org Subject: Re: Reading from ZFS mirror 2x slower than expected? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 19:54:23 -0000 On Thu, 28 Jan 2010, Urmas Lett wrote: > While reading from simple zfs mirror 'dd if=zfs.test of=/dev/null bs=512k' > systat -vm shows individual disks only 50% busy: How big is the file 'zfs.test'? How was it created? If it was created from /dev/zero then its content is bogus. You need to test with non-zero data. It may be that zfs's prefetch is not working adequately. With perfect prefetch, the read rate should be doubled. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Thu Jan 28 23:27:32 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F353106568D for ; Thu, 28 Jan 2010 23:27:32 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: from web110502.mail.gq1.yahoo.com (web110502.mail.gq1.yahoo.com [67.195.8.250]) by mx1.freebsd.org (Postfix) with SMTP id 1BD8E8FC0A for ; Thu, 28 Jan 2010 23:27:31 +0000 (UTC) Received: (qmail 51696 invoked by uid 60001); 28 Jan 2010 23:27:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264721251; bh=MuvYdv47jX9+nR+lcvfJS4poBkDjdb5XWaWUAcJ7bHI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JlyeeQ2WpzI2GYfhV6Wf3gAC/ydaWliMU0OdbduG8YJwQQI5TxHSvHXzPJhz1uQg2kozaigFAJmoLk3nbRvzXRNAZozFMZ3I4EGLNMN5MP+5mOMHJCVkI0a9Xdp+p2uL8Zrd1UaKaEPo5qnM60RUPWYs42Lv/WlztLF6xFxfjRs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xtBY7iuApAC2atZml4ovGZxr7mYFbbpYDXM21hw3bIni0UIkbP6G7Fs/zLU3RraoZVEhJjmpxwjatsqGTMtfP5uqbSteLyr7c66+snaHYhm5k/HLIPJUBf5amUC6ghTPTcbjCyyD3zXpu2E+d9SedypxXXFUXIX5VMz5toi671c=; Message-ID: <539498.51342.qm@web110502.mail.gq1.yahoo.com> X-YMail-OSG: cApjb_AVM1nvLGfe36TFq91MZr82ZEzfUK3meHOQE1.6cko.mIQTTeFeFpu.eMCzHyoT737Ruv5zSJPYu8TQiaioJlx7NTpe90MoLDtmSuhB_4fgkW1uwbxTTm0yVjy_O3llKVzeTNY_3SGaIlhlU6QJ7QYi3TEa73eIRKRqqQ8wxXireMO_sCaVNby4dwcNl.dDk27aTHalWuDtICyhU8ShWNOvG9qL39lFKxSCv8KfC6Mgurwgn1N8gcBjC9TWO843rw0qJYGHqFXNiXqfUv35r2NqGMysERwep.1qNU5xG5phDJMbvkOpfrAuPveWX7FBxIyYh1utHfP2TZvWttBzI2kJv6gPmrRKL520ZhbGJhqqv5bRhgUE_.3cD2D0.bIZ9IWp_7JGgSs_JbiSrjKxYrOuNeHOd_8ibRde2v9FIPkkhWqDobLsdCSRfapMMg29_2s- Received: from [71.174.61.120] by web110502.mail.gq1.yahoo.com via HTTP; Thu, 28 Jan 2010 15:27:31 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <419976.64363.qm@web110515.mail.gq1.yahoo.com> <422431.76479.qm@web110504.mail.gq1.yahoo.com> <529238.22926.qm@web110513.mail.gq1.yahoo.com> <377667.81874.qm@web110504.mail.gq1.yahoo.com> <4B61D668.3020703@bellanet.org> Date: Thu, 28 Jan 2010 15:27:31 -0800 (PST) From: Paul Pathiakis To: Graham Todd In-Reply-To: <4B61D668.3020703@bellanet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS - scrub lead to corruption? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 23:27:32 -0000 From: Graham Todd To: Paul Pathiakis Cc: freebsd-fs@freebsd.org Sent: Thu, January 28, 2010 1:24:40 PM Subject: Re: ZFS - scrub lead to corruption? Paul Pathiakis wrote: ... > > I boot to single-user, make sure that scrubbing is turned off and it > throws the error within 2 minutes of being up.... I'm SOL unless someone > (please!!!) can respond and tell me how to roll this back. I think there was a discussion on -current or this list about using zdb to force a rollback to a previous uberblock - but I'm not sure if this would apply to your situation. Using zdb is a bit more high risk and you might not be able to rollback that far ... i.e it might not solve your corruption issue (the one where /usr/bin/m4 is "there" but "not there"?). Here's a related solaris discussion you may have seen: http://www.opensolaris.org/jive/thread.jspa?threadID=85794 **************************************************************************** Graham, Thanks for the info. I've realized something that is... disconcerting. (I had found that article but I don't think the FreeBSD zdb is as robust with features.) So, I did a quick install of a base OS. I've backed up everything in /usr that doesn't cause a crash (it's only /usr/bin, /usr/share, and /usr/obj files) onto the new pool. Many various files in directories and sub-sub-sub-sub... dirs in /usr have files in them that if you touch them *CRASH* I'm going to zfs destroy the /usr partition and all the subpartitions and recreate it. I'll restore everything from the new OS /usr. From there, I'll change my pool mountpoints back to the norm and I will see if I can make the world and install it. (I'm also going to upgrade the firmware on the drives as well. I'm going to see if Seagate release a version later than the one I have for the 1500 GB drives) I'll give the list an update after this. Paul From owner-freebsd-fs@FreeBSD.ORG Fri Jan 29 08:00:24 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2518A10656A6 for ; Fri, 29 Jan 2010 08:00:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B71318FC0C for ; Fri, 29 Jan 2010 08:00:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0T80LNV037297 for ; Fri, 29 Jan 2010 08:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0T80LUW037292; Fri, 29 Jan 2010 08:00:21 GMT (envelope-from gnats) Date: Fri, 29 Jan 2010 08:00:21 GMT Message-Id: <201001290800.o0T80LUW037292@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Andrei V. Lavreniyuk" Cc: Subject: Re: kern/142878: [zfs] [vfs] lock order reversal X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Andrei V. Lavreniyuk" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 08:00:24 -0000 The following reply was made to PR kern/142878; it has been noted by GNATS. From: "Andrei V. Lavreniyuk" To: bug-followup@FreeBSD.org, dmitry2006@yandex.ru Cc: Subject: Re: kern/142878: [zfs] [vfs] lock order reversal Date: Fri, 29 Jan 2010 09:56:53 +0200 FreeBSD opensolaris.technica-03.local 8.0-STABLE FreeBSD 8.0-STABLE #0: Fri Jan 29 06:12:47 UTC 2010 root@opensolaris.technica-03.local:/usr/obj/usr/src/sys/SMP64R amd64 lock order reversal: 1st 0xffffff00093727f8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1058 2nd 0xffffff000933f7f8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x80b __lockmgr_args() at __lockmgr_args+0xcdd vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x100 devfs_root() at devfs_root+0x48 vfs_donmount() at vfs_donmount+0xfa1 nmount() at nmount+0x63 syscall() at syscall+0x1e6 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007aa6bc, rsp = 0x7fffffffdd28, rbp = 0x800a06048 --- -- Best regards, Andrei V. Lavreniyuk. From owner-freebsd-fs@FreeBSD.ORG Fri Jan 29 16:26:10 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 637291065670 for ; Fri, 29 Jan 2010 16:26:10 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 2DFC98FC12 for ; Fri, 29 Jan 2010 16:26:09 +0000 (UTC) Received: from reflector.ws.pitbpa0.priv.collaborativefusion.com ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Fri, 29 Jan 2010 11:35:54 -0500 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::671 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-fs@freebsd.org X-SMFBL: ZnJlZWJzZC1mc0BmcmVlYnNkLm9yZw== Message-ID: <4B63088F.9030407@comcast.net> Date: Fri, 29 Jan 2010 11:10:55 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100129 Thunderbird/3.0.1 MIME-Version: 1.0 To: Bob Friesenhahn References: <4B619485.8080106@eenet.ee> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Reading from ZFS mirror 2x slower than expected? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:26:10 -0000 On 01/28/10 14:54, Bob Friesenhahn wrote: > On Thu, 28 Jan 2010, Urmas Lett wrote: > >> While reading from simple zfs mirror 'dd if=zfs.test of=/dev/null >> bs=512k' systat -vm shows individual disks only 50% busy: > > How big is the file 'zfs.test'? How was it created? If it was > created from /dev/zero then its content is bogus. You need to test > with non-zero data. > > It may be that zfs's prefetch is not working adequately. With perfect > prefetch, the read rate should be doubled. > I can also vouch that the mirror performance is less than stellar. Writes are also about 50% slower than single-disk performance, although this may be expected due to checksums / other ZFS overhead. I can try to provide more details when I get time. Steve From owner-freebsd-fs@FreeBSD.ORG Fri Jan 29 18:44:50 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C02C106566C; Fri, 29 Jan 2010 18:44:50 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 03B438FC12; Fri, 29 Jan 2010 18:44:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0TIinui079629; Fri, 29 Jan 2010 18:44:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0TIinTY079625; Fri, 29 Jan 2010 18:44:49 GMT (envelope-from linimon) Date: Fri, 29 Jan 2010 18:44:49 GMT Message-Id: <201001291844.o0TIinTY079625@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143343: [zfs] bug in sunlink flag on directories X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 18:44:50 -0000 Old Synopsis: ZFS: bug in sunlink flag on directories New Synopsis: [zfs] bug in sunlink flag on directories Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 29 18:44:25 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143343 From owner-freebsd-fs@FreeBSD.ORG Fri Jan 29 18:48:58 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65DFD1065672; Fri, 29 Jan 2010 18:48:58 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3D51E8FC0A; Fri, 29 Jan 2010 18:48:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0TImwx5079750; Fri, 29 Jan 2010 18:48:58 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0TImwZE079746; Fri, 29 Jan 2010 18:48:58 GMT (envelope-from linimon) Date: Fri, 29 Jan 2010 18:48:58 GMT Message-Id: <201001291848.o0TImwZE079746@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143345: [ext2fs] extfs minor header cleanups to better match NetBSD/UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 18:48:58 -0000 Old Synopsis: extfs minor header cleanups to better match NetBSD/UFS New Synopsis: [ext2fs] extfs minor header cleanups to better match NetBSD/UFS Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 29 18:48:20 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143345 From owner-freebsd-fs@FreeBSD.ORG Sat Jan 30 20:49:59 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BC121065672 for ; Sat, 30 Jan 2010 20:49:59 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mx1.freebsd.org (Postfix) with ESMTP id 054148FC12 for ; Sat, 30 Jan 2010 20:49:56 +0000 (UTC) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 589311C0011E; Sat, 30 Jan 2010 21:31:51 +0100 (CET) Received: from localhost (dynscan2.mnet-online.de [192.168.6.166]) by mail.m-online.net (Postfix) with ESMTP id 4AA9790024; Sat, 30 Jan 2010 21:31:51 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.6.166]) (amavisd-new, port 10024) with ESMTP id fNZxlp7574SG; Sat, 30 Jan 2010 21:31:45 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-114-117.dynamic.mnet-online.de [93.104.114.117]) by mail.mnet-online.de (Postfix) with ESMTP; Sat, 30 Jan 2010 21:31:45 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 4D5C02C192; Sat, 30 Jan 2010 21:31:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 3B6DA2C191; Sat, 30 Jan 2010 21:31:45 +0100 (CET) Date: Sat, 30 Jan 2010 21:31:45 +0100 (CET) From: Michael Reifenberger To: Pawel Jakub Dawidek Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1971476311-1264883505=:4627" Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 20:49:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1971476311-1264883505=:4627 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Hi, have you got any new information or preliminary patch on this topic? Unfortunately I get the same symptom when trying to create a new pool using newly attached ada devices: As in the past (with allready attached/configured mfid* devices) I did with all new disks: gpart create -s gpt ada0 gpart add -i 1 -b 34 -s 2014 -t freebsd-boot ada0 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 ... gpart add -i 2 -b $off -s $siz -t freebsd-swap ada0 ... gpart add -i 3 -b $off -s $siz -t freebsd-zfs ada0 And then: zpool create z raidz2 ada0p3 ada1p3 ada2p3 ada3p3 ada4p3 ada5p3 This leads to the errors described in the thread. Some debugging output is attached. Thanks in advance for your investigation. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com --0-1971476311-1264883505=:4627 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dbg.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=dbg.txt dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGFkYTAuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBtZmlkNy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlb MV06IGd1aWQgZm9yIG1maWQ3IGlzIDE2OTY1ODYxNjM4OTM5OTI4NjYyDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g bWZpZDYuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZv ciBtZmlkNiBpcyA3NDY4NjcxOTAxODMxMjM1MTEzDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDUuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNSBpcyAx NDM5MDI4MjkyOTc5Njk5ODMwNg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ0Li4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDQgaXMgMTY2OTUxNTE5NDcz OTM1MjI1MTgNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBtZmlkMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlb MV06IGd1aWQgZm9yIG1maWQzIGlzIDE3MTc4MzMzMzEyNDgxNDA2MzEwDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g bWZpZDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZv ciBtZmlkMiBpcyA0MDkyMTYzMDU3ODQ0ODQzOTk5DQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDEuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMSBpcyAx MjgyNjk4MTcxMDQ1MzM1MzE3Nw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwLi4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDAgaXMgOTcyMzEwODYwMDI4 MDQxMDIwMg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkLzY1OGM2MjIxLTBkYzgtMTFkZi05MjVhLTAwMzAx OGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkLzYzNThjZjk0LTBkYzgtMTFkZi05MjVhLTAw MzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzYxYmJjZDYwLTBkYzgtMTFkZi05MjVh LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzYwNjQyNjBiLTBkYzgtMTFkZi05 MjVhLTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzVlODA0ZGQ1LTBkYzgtMTFk Zi05MjVhLTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzIxOTc5MjFlLTBkYzgt MTFkZi05MjVhLTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzY1NzJjMmJhLTBk YzgtMTFkZi05MjVhLTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzY1NGJlNmNm LTBkYzgtMTFkZi05MjVhLTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzYzNDEx NGIyLTBkYzgtMTFkZi05MjVhLTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzYz MWE4ZGNhLTBkYzgtMTFkZi05MjVhLTAwMzAxOGFlMTk0NC4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlk LzYxYTBiYTRmLTBkYzgtMTFkZi05MjVhLTAwMzAxOGFlMTk0NC4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdw dGlkLzYxNzZlNzkzLTBkYzgtMTFkZi05MjVhLTAwMzAxOGFlMTk0NC4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkLzYwNDgzY2E3LTBkYzgtMTFkZi05MjVhLTAwMzAxOGFlMTk0NC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkLzYwMWI4NzZjLTBkYzgtMTFkZi05MjVhLTAwMzAxOGFlMTk0 NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkLzVlNjI0YWMwLTBkYzgtMTFkZi05MjVhLTAwMzAxOGFl MTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkLzVlMmQ2ZGYxLTBkYzgtMTFkZi05MjVhLTAwMzAx OGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkLzIxNzliZGUyLTBkYzgtMTFkZi05MjVhLTAw MzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzIxMzk4MjFjLTBkYzgtMTFkZi05MjVh LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05 ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlb MV06IGd1aWQgZm9yIGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05ZGZhLTAw MWQ5MmYzMDJlNSBpcyAxNDA2MzcyMzE5MzI0NDYwMTU4Mg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I5 NDE5ZmFhLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlk L2I3ZjAxZmE3LTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIGdwdGlkL2I3ZjAx ZmE3LTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBpcyAxMzA1NzE2NzE0 MzYyNjk5OTYxMg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkL2I3ZTc1ZjNiLTVhOWUtMTFkZS05ZGZhLTAw MWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZh LTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06 IGd1aWQgZm9yIGdwdGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZhLTAwMWQ5 MmYzMDJlNSBpcyA3NzE5NjM5NTI4NDQ1MDkzODc1DQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjY2YTM3 MzAtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjUx MjkxZjQtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgZ3B0aWQvYjUxMjkxZjQt NWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1IGlzIDE3NTgzMzM5NjkwOTIx ODAyMjEzDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gZ3B0aWQvYjUwYjFiYjgtNWE5ZS0xMWRlLTlkZmEtMDAxZDky ZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gZ3B0aWQvYjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAx ZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3Vp ZCBmb3IgZ3B0aWQvYjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMw MmU1IGlzIDg2NTk1ODY0NTY3MDMxNjkyMDUNCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iM2JhYjIxMC01 YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iMjhkMDk1 Mi01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBncHRpZC9iMjhkMDk1Mi01YTll LTExZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMgMTY1Mzk2MDczMzIzNzgyMzIw ODMNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBncHRpZC9iMjgxZGY5Mi01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAy ZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBncHRpZC9iMGQ0YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJm MzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZv ciBncHRpZC9iMGQ0YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUg aXMgMTQ5OTM5MTQ2MzI2OTcyNzAxOTYNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iMGM5NTRmYi01YTll LTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC84MWY4MDUwNS01 YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzM5WzFdOiBndWlkIGZvciBncHRpZC84MWY4MDUwNS01YTllLTEx ZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMgNjU4NzE3NjYwODc0NjA0OTQzNA0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkLzgxZWNkMDBhLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4u Lg0KdmRldl9nZW9tX29wZW5fYnlfZ3VpZDo0NDlbMV06IFNlYXJjaCBieSBn dWlkIFsxNzkzODM1OTAwMDg4NjIxNjU3XSBmYWlsZWQuDQp2ZGV2X2dlb21f b3Blbl9ieV9wYXRoOjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAv ZGV2L2FkYTVwMy4NCnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hp bmcgdG8gYWRhNXAzLg0KdmRldl9nZW9tX29wZW46NTIxWzFdOiBQcm92aWRl ciAvZGV2L2FkYTVwMyBub3QgZm91bmQuDQp2ZGV2X2dlb21fb3Blbl9ieV9w YXRoOjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2FkYTBw My4NCnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8gYWRh MHAzLg0KdmRldl9nZW9tX2F0dGFjaDoxNTNbMV06IENyZWF0ZWQgY29uc3Vt ZXIgZm9yIGFkYTBwMy4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBhZGEwcDMuLi4NCnZkZXZfZ2VvbV9kZXRhY2g6 MTczWzFdOiBDbG9zaW5nIGFjY2VzcyB0byBhZGEwcDMuDQp2ZGV2X2dlb21f ZGV0YWNoOjE3N1sxXTogRGVzdHJveWVkIGNvbnN1bWVyIHRvIGFkYTBwMy4N CnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6NDc3WzFdOiBndWlkIG1pc21hdGNo IGZvciBwcm92aWRlciAvZGV2L2FkYTBwMzogMTAwNTE3MzI3NTEwMTE1Mjk0 OTAgIT0gMC4NCnZkZXZfZ2VvbV9vcGVuX2J5X2d1aWQ6NDM1WzFdOiBTZWFy Y2hpbmcgYnkgZ3VpZCBbMTAwNTE3MzI3NTEwMTE1Mjk0OTBdLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1kMC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGFkYTVwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGFkYTVwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTVwMS4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTRw My4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGFkYTRwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTRwMS4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTNwMy4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFk YTNwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGFkYTNwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTJwMy4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTJwMi4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGFkYTJwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGFkYTFwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTFwMi4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTFwMS4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGFkYTBwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGFkYTBwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTBwMS4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3 cDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBt ZmlkN3A0IGlzIDE2OTY1ODYxNjM4OTM5OTI4NjYyDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDdwMy4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ3cDMg aXMgMTQwNjM3MjMxOTMyNDQ2MDE1ODINCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkN3AyLi4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDdw MS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIG1maWQ2cDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFd OiBndWlkIGZvciBtZmlkNnA0IGlzIDc0Njg2NzE5MDE4MzEyMzUxMTMNCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkNnAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBm b3IgbWZpZDZwMyBpcyAxMzA1NzE2NzE0MzYyNjk5OTYxMg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ2cDIu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBtZmlkNnAxLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTog UmVhZGluZyBndWlkIGZyb20gbWZpZDVwNC4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ1cDQgaXMgMTQzOTAyODI5Mjk3 OTY5OTgzMDYNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBtZmlkNXAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMz OVsxXTogZ3VpZCBmb3IgbWZpZDVwMyBpcyA3NzE5NjM5NTI4NDQ1MDkzODc1 DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gbWZpZDVwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIG1maWQ1cDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNHA0Li4uDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDRwNCBpcyAx NjY5NTE1MTk0NzM5MzUyMjUxOA0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ0cDMuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNHAzIGlzIDE3NTgzMzM5 NjkwOTIxODAyMjEzDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gbWZpZDRwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ0cDEuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlk M3A0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3Ig bWZpZDNwNCBpcyAxNzE3ODMzMzMxMjQ4MTQwNjMxMA0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQzcDMuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkM3Az IGlzIDg2NTk1ODY0NTY3MDMxNjkyMDUNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkM3AyLi4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDNw MS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIG1maWQycDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFd OiBndWlkIGZvciBtZmlkMnA0IGlzIDQwOTIxNjMwNTc4NDQ4NDM5OTkNCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkMnAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBm b3IgbWZpZDJwMyBpcyAxNjUzOTYwNzMzMjM3ODIzMjA4Mw0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQycDIu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBtZmlkMnAxLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTog UmVhZGluZyBndWlkIGZyb20gbWZpZDFwNC4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQxcDQgaXMgMTI4MjY5ODE3MTA0 NTMzNTMxNzcNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBtZmlkMXAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMz OVsxXTogZ3VpZCBmb3IgbWZpZDFwMyBpcyAxNDk5MzkxNDYzMjY5NzI3MDE5 Ng0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIG1maWQxcDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBtZmlkMXAxLi4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDBwNC4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQwcDQgaXMg OTcyMzEwODYwMDI4MDQxMDIwMg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwcDMuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMHAzIGlzIDY1ODcxNzY2 MDg3NDYwNDk0MzQNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBtZmlkMHAyLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDBwMS4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTUu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBhZGE0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gYWRhMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTIuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGExLi4uDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g YWRhMC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIG1maWQ3Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsx XTogZ3VpZCBmb3IgbWZpZDcgaXMgMTY5NjU4NjE2Mzg5Mzk5Mjg2NjINCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkNi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9y IG1maWQ2IGlzIDc0Njg2NzE5MDE4MzEyMzUxMTMNCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNS4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ1IGlzIDE0 MzkwMjgyOTI5Nzk2OTk4MzA2DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gbWZpZDQuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNCBpcyAxNjY5NTE1MTk0NzM5 MzUyMjUxOA0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIG1maWQzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsx XTogZ3VpZCBmb3IgbWZpZDMgaXMgMTcxNzgzMzMzMTI0ODE0MDYzMTANCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9y IG1maWQyIGlzIDQwOTIxNjMwNTc4NDQ4NDM5OTkNCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMS4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQxIGlzIDEy ODI2OTgxNzEwNDUzMzUzMTc3DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gbWZpZDAuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMCBpcyA5NzIzMTA4NjAwMjgw NDEwMjAyDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gZ3B0aWQvMzQ3OTM1ZWEtMGRkOS0xMWRmLWE2YTQtMDAzMDE4 YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gZ3B0aWQvM2Y5ZDg5Y2EtMGRkOS0xMWRmLWE2YTQtMDAz MDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gZ3B0aWQvM2Y4YWQ1NmYtMGRkOS0xMWRmLWE2YTQt MDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTog UmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2Y2MmQzMDgtMGRkOS0xMWRmLWE2 YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2JhZTA1ODYtMGRkOS0xMWRm LWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2I5YmI3YjYtMGRkOS0x MWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2I3YTMwZWUtMGRk OS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2ExNDI3YTAt MGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvMzlmZWEy ZDktMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvMzlk NGU3NGYtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQv MzhiMjc5OWQtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0 aWQvMzg5ZTkzYmItMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g Z3B0aWQvMzg3Nzk1YmEtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4u DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gZ3B0aWQvMzc0YTMxZWQtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0 Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gZ3B0aWQvMzczNjVhMDAtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUx OTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gZ3B0aWQvMzcxMDY0YzktMGRkOS0xMWRmLWE2YTQtMDAzMDE4 YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gZ3B0aWQvMzQ1YTI0NTktMGRkOS0xMWRmLWE2YTQtMDAz MDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gZ3B0aWQvMzQxYmY3NDktMGRkOS0xMWRmLWE2YTQt MDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTog UmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjk0YTM5N2QtNWE5ZS0xMWRlLTlk ZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsx XTogZ3VpZCBmb3IgZ3B0aWQvYjk0YTM5N2QtNWE5ZS0xMWRlLTlkZmEtMDAx ZDkyZjMwMmU1IGlzIDE0MDYzNzIzMTkzMjQ0NjAxNTgyDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjk0 MTlmYWEtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQv YjdmMDFmYTctNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgZ3B0aWQvYjdmMDFm YTctNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1IGlzIDEzMDU3MTY3MTQz NjI2OTk5NjEyDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gZ3B0aWQvYjdlNzVmM2ItNWE5ZS0xMWRlLTlkZmEtMDAx ZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gZ3B0aWQvYjY3NTFhZmYtNWE5ZS0xMWRlLTlkZmEt MDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTog Z3VpZCBmb3IgZ3B0aWQvYjY3NTFhZmYtNWE5ZS0xMWRlLTlkZmEtMDAxZDky ZjMwMmU1IGlzIDc3MTk2Mzk1Mjg0NDUwOTM4NzUNCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iNjZhMzcz MC01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iNTEy OTFmNC01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBncHRpZC9iNTEyOTFmNC01 YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMgMTc1ODMzMzk2OTA5MjE4 MDIyMTMNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBncHRpZC9iNTBiMWJiOC01YTllLTExZGUtOWRmYS0wMDFkOTJm MzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBncHRpZC9iM2JmOWI0My01YTllLTExZGUtOWRmYS0wMDFk OTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlk IGZvciBncHRpZC9iM2JmOWI0My01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAy ZTUgaXMgODY1OTU4NjQ1NjcwMzE2OTIwNQ0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2IzYmFiMjEwLTVh OWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2IyOGQwOTUy LTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIGdwdGlkL2IyOGQwOTUyLTVhOWUt MTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBpcyAxNjUzOTYwNzMzMjM3ODIzMjA4 Mw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkL2IyODFkZjkyLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJl NS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkL2IwZDRiYzNjLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYz MDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9y IGdwdGlkL2IwZDRiYzNjLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBp cyAxNDk5MzkxNDYzMjY5NzI3MDE5Ng0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2IwYzk1NGZiLTVhOWUt MTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzgxZjgwNTA1LTVh OWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMzlbMV06IGd1aWQgZm9yIGdwdGlkLzgxZjgwNTA1LTVhOWUtMTFk ZS05ZGZhLTAwMWQ5MmYzMDJlNSBpcyA2NTg3MTc2NjA4NzQ2MDQ5NDM0DQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g Z3B0aWQvODFlY2QwMGEtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4u DQp2ZGV2X2dlb21fb3Blbl9ieV9ndWlkOjQ0OVsxXTogU2VhcmNoIGJ5IGd1 aWQgWzEwMDUxNzMyNzUxMDExNTI5NDkwXSBmYWlsZWQuDQp2ZGV2X2dlb21f b3Blbl9ieV9wYXRoOjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAv ZGV2L2FkYTBwMy4NCnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hp bmcgdG8gYWRhMHAzLg0KdmRldl9nZW9tX29wZW46NTIxWzFdOiBQcm92aWRl ciAvZGV2L2FkYTBwMyBub3QgZm91bmQuDQp2ZGV2X2dlb21fb3Blbl9ieV9w YXRoOjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2FkYTFw My4NCnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8gYWRh MXAzLg0KdmRldl9nZW9tX2F0dGFjaDoxNTNbMV06IENyZWF0ZWQgY29uc3Vt ZXIgZm9yIGFkYTFwMy4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBhZGExcDMuLi4NCnZkZXZfZ2VvbV9kZXRhY2g6 MTczWzFdOiBDbG9zaW5nIGFjY2VzcyB0byBhZGExcDMuDQp2ZGV2X2dlb21f ZGV0YWNoOjE3N1sxXTogRGVzdHJveWVkIGNvbnN1bWVyIHRvIGFkYTFwMy4N CnZkZXZfZ2VvbV9vcGVuX2J5X3BhdGg6NDc3WzFdOiBndWlkIG1pc21hdGNo IGZvciBwcm92aWRlciAvZGV2L2FkYTFwMzogOTQxNzg0NjkzODA2MzU1MjU3 NiAhPSAwLg0KdmRldl9nZW9tX29wZW5fYnlfZ3VpZDo0MzVbMV06IFNlYXJj aGluZyBieSBndWlkIFs5NDE3ODQ2OTM4MDYzNTUyNTc2XS4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZDAuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBhZGE1cDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBhZGE1cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE1cDEuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE0cDMu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBhZGE0cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBhZGE0cDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEzcDMuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEz cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBhZGEzcDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEycDMuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEycDIuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBh ZGEycDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBhZGExcDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGExcDIuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGExcDEuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBhZGEwcDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBhZGEwcDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEwcDEuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkN3A0 Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZp ZDdwNCBpcyAxNjk2NTg2MTYzODkzOTkyODY2Mg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3cDMuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkN3AzIGlz IDE0MDYzNzIzMTkzMjQ0NjAxNTgyDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDdwMi4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3cDEu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBtZmlkNnA0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTog Z3VpZCBmb3IgbWZpZDZwNCBpcyA3NDY4NjcxOTAxODMxMjM1MTEzDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZp ZDZwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9y IG1maWQ2cDMgaXMgMTMwNTcxNjcxNDM2MjY5OTk2MTINCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNnAyLi4u DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gbWZpZDZwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIG1maWQ1cDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNXA0IGlzIDE0MzkwMjgyOTI5Nzk2 OTk4MzA2DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gbWZpZDVwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlb MV06IGd1aWQgZm9yIG1maWQ1cDMgaXMgNzcxOTYzOTUyODQ0NTA5Mzg3NQ0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IG1maWQ1cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBtZmlkNXAxLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDRwNC4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ0cDQgaXMgMTY2 OTUxNTE5NDczOTM1MjI1MTgNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNHAzLi4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDRwMyBpcyAxNzU4MzMzOTY5 MDkyMTgwMjIxMw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIG1maWQ0cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNHAxLi4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDNw NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1m aWQzcDQgaXMgMTcxNzgzMzMzMTI0ODE0MDYzMTANCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkM3AzLi4uDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDNwMyBp cyA4NjU5NTg2NDU2NzAzMTY5MjA1DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDNwMi4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQzcDEu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBtZmlkMnA0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTog Z3VpZCBmb3IgbWZpZDJwNCBpcyA0MDkyMTYzMDU3ODQ0ODQzOTk5DQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZp ZDJwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9y IG1maWQycDMgaXMgMTY1Mzk2MDczMzIzNzgyMzIwODMNCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMnAyLi4u DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gbWZpZDJwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIG1maWQxcDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMXA0IGlzIDEyODI2OTgxNzEwNDUz MzUzMTc3DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gbWZpZDFwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlb MV06IGd1aWQgZm9yIG1maWQxcDMgaXMgMTQ5OTM5MTQ2MzI2OTcyNzAxOTYN CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBtZmlkMXAyLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gbWZpZDFwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwcDQuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMHA0IGlzIDk3 MjMxMDg2MDAyODA0MTAyMDINCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMHAzLi4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDBwMyBpcyA2NTg3MTc2NjA4 NzQ2MDQ5NDM0DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gbWZpZDBwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwcDEuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE1Li4u DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gYWRhNC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGFkYTMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEyLi4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhMS4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFk YTAuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBtZmlkNy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06 IGd1aWQgZm9yIG1maWQ3IGlzIDE2OTY1ODYxNjM4OTM5OTI4NjYyDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZp ZDYuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBt ZmlkNiBpcyA3NDY4NjcxOTAxODMxMjM1MTEzDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDUuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNSBpcyAxNDM5 MDI4MjkyOTc5Njk5ODMwNg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDQgaXMgMTY2OTUxNTE5NDczOTM1 MjI1MTgNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBtZmlkMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06 IGd1aWQgZm9yIG1maWQzIGlzIDE3MTc4MzMzMzEyNDgxNDA2MzEwDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZp ZDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBt ZmlkMiBpcyA0MDkyMTYzMDU3ODQ0ODQzOTk5DQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDEuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMSBpcyAxMjgy Njk4MTcxMDQ1MzM1MzE3Nw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwLi4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDAgaXMgOTcyMzEwODYwMDI4MDQx MDIwMg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkLzM3NGEzMWVkLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFl MTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkLzM0NzkzNWVhLTBkZDktMTFkZi1hNmE0LTAwMzAx OGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkLzNmOWQ4OWNhLTBkZDktMTFkZi1hNmE0LTAw MzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNmOGFkNTZmLTBkZDktMTFkZi1hNmE0 LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNmNjJkMzA4LTBkZDktMTFkZi1h NmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiYWUwNTg2LTBkZDktMTFk Zi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiOWJiN2I2LTBkZDkt MTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiN2EzMGVlLTBk ZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNhMTQyN2Ew LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM5ZmVh MmQ5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM5 ZDRlNzRmLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlk LzM4YjI3OTlkLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdw dGlkLzM4OWU5M2JiLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkLzM4Nzc5NWJhLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkLzM3MzY1YTAwLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0 NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkLzM3MTA2NGM5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFl MTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkLzM0NWEyNDU5LTBkZDktMTFkZi1hNmE0LTAwMzAx OGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkLzM0MWJmNzQ5LTBkZDktMTFkZi1hNmE0LTAw MzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05ZGZh LTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06 IGd1aWQgZm9yIGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05ZGZhLTAwMWQ5 MmYzMDJlNSBpcyAxNDA2MzcyMzE5MzI0NDYwMTU4Mg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I5NDE5 ZmFhLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I3 ZjAxZmE3LTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIGdwdGlkL2I3ZjAxZmE3 LTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBpcyAxMzA1NzE2NzE0MzYy Njk5OTYxMg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkL2I3ZTc1ZjNiLTVhOWUtMTFkZS05ZGZhLTAwMWQ5 MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZhLTAw MWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1 aWQgZm9yIGdwdGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYz MDJlNSBpcyA3NzE5NjM5NTI4NDQ1MDkzODc1DQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjY2YTM3MzAt NWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjUxMjkx ZjQtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgZ3B0aWQvYjUxMjkxZjQtNWE5 ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1IGlzIDE3NTgzMzM5NjkwOTIxODAy MjEzDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gZ3B0aWQvYjUwYjFiYjgtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMw MmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gZ3B0aWQvYjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAxZDky ZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBm b3IgZ3B0aWQvYjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1 IGlzIDg2NTk1ODY0NTY3MDMxNjkyMDUNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iM2JhYjIxMC01YTll LTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iMjhkMDk1Mi01 YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzM5WzFdOiBndWlkIGZvciBncHRpZC9iMjhkMDk1Mi01YTllLTEx ZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMgMTY1Mzk2MDczMzIzNzgyMzIwODMN CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBncHRpZC9iMjgxZGY5Mi01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBncHRpZC9iMGQ0YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAy ZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBn cHRpZC9iMGQ0YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMg MTQ5OTM5MTQ2MzI2OTcyNzAxOTYNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iMGM5NTRmYi01YTllLTEx ZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC84MWY4MDUwNS01YTll LTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzM5WzFdOiBndWlkIGZvciBncHRpZC84MWY4MDUwNS01YTllLTExZGUt OWRmYS0wMDFkOTJmMzAyZTUgaXMgNjU4NzE3NjYwODc0NjA0OTQzNA0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdw dGlkLzgxZWNkMDBhLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0K dmRldl9nZW9tX29wZW5fYnlfZ3VpZDo0NDlbMV06IFNlYXJjaCBieSBndWlk IFs5NDE3ODQ2OTM4MDYzNTUyNTc2XSBmYWlsZWQuDQp2ZGV2X2dlb21fb3Bl bl9ieV9wYXRoOjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2 L2FkYTFwMy4NCnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcg dG8gYWRhMXAzLg0KdmRldl9nZW9tX29wZW46NTIxWzFdOiBQcm92aWRlciAv ZGV2L2FkYTFwMyBub3QgZm91bmQuDQp2ZGV2X2dlb21fb3Blbl9ieV9wYXRo OjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2FkYTJwMy4N CnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8gYWRhMnAz Lg0KdmRldl9nZW9tX2F0dGFjaDoxNTNbMV06IENyZWF0ZWQgY29uc3VtZXIg Zm9yIGFkYTJwMy4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBhZGEycDMuLi4NCnZkZXZfZ2VvbV9kZXRhY2g6MTcz WzFdOiBDbG9zaW5nIGFjY2VzcyB0byBhZGEycDMuDQp2ZGV2X2dlb21fZGV0 YWNoOjE3N1sxXTogRGVzdHJveWVkIGNvbnN1bWVyIHRvIGFkYTJwMy4NCnZk ZXZfZ2VvbV9vcGVuX2J5X3BhdGg6NDc3WzFdOiBndWlkIG1pc21hdGNoIGZv ciBwcm92aWRlciAvZGV2L2FkYTJwMzogOTkzODY5NTgzNjgxMTcwNzA2NSAh PSAwLg0KdmRldl9nZW9tX29wZW5fYnlfZ3VpZDo0MzVbMV06IFNlYXJjaGlu ZyBieSBndWlkIFs5OTM4Njk1ODM2ODExNzA3MDY1XS4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZDAuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBh ZGE1cDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBhZGE1cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE1cDEuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE0cDMuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBhZGE0cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBhZGE0cDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEzcDMuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEzcDIu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBhZGEzcDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBhZGEycDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEycDIuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEy cDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBhZGExcDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBhZGExcDIuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGExcDEuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBh ZGEwcDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBhZGEwcDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEwcDEuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkN3A0Li4u DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDdw NCBpcyAxNjk2NTg2MTYzODkzOTkyODY2Mg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3cDMuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkN3AzIGlzIDE0 MDYzNzIzMTkzMjQ0NjAxNTgyDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gbWZpZDdwMi4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3cDEuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBtZmlkNnA0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3Vp ZCBmb3IgbWZpZDZwNCBpcyA3NDY4NjcxOTAxODMxMjM1MTEzDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDZw My4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1m aWQ2cDMgaXMgMTMwNTcxNjcxNDM2MjY5OTk2MTINCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNnAyLi4uDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g bWZpZDZwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIG1maWQ1cDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzM5WzFdOiBndWlkIGZvciBtZmlkNXA0IGlzIDE0MzkwMjgyOTI5Nzk2OTk4 MzA2DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gbWZpZDVwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06 IGd1aWQgZm9yIG1maWQ1cDMgaXMgNzcxOTYzOTUyODQ0NTA5Mzg3NQ0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1m aWQ1cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBtZmlkNXAxLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDRwNC4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ0cDQgaXMgMTY2OTUx NTE5NDczOTM1MjI1MTgNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBtZmlkNHAzLi4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDRwMyBpcyAxNzU4MzMzOTY5MDky MTgwMjIxMw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIG1maWQ0cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNHAxLi4uDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDNwNC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQz cDQgaXMgMTcxNzgzMzMzMTI0ODE0MDYzMTANCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkM3AzLi4uDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDNwMyBpcyA4 NjU5NTg2NDU2NzAzMTY5MjA1DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gbWZpZDNwMi4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQzcDEuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBtZmlkMnA0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3Vp ZCBmb3IgbWZpZDJwNCBpcyA0MDkyMTYzMDU3ODQ0ODQzOTk5DQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDJw My4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1m aWQycDMgaXMgMTY1Mzk2MDczMzIzNzgyMzIwODMNCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMnAyLi4uDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g bWZpZDJwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIG1maWQxcDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzM5WzFdOiBndWlkIGZvciBtZmlkMXA0IGlzIDEyODI2OTgxNzEwNDUzMzUz MTc3DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gbWZpZDFwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06 IGd1aWQgZm9yIG1maWQxcDMgaXMgMTQ5OTM5MTQ2MzI2OTcyNzAxOTYNCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkMXAyLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gbWZpZDFwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwcDQuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMHA0IGlzIDk3MjMx MDg2MDAyODA0MTAyMDINCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBtZmlkMHAzLi4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDBwMyBpcyA2NTg3MTc2NjA4NzQ2 MDQ5NDM0DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gbWZpZDBwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwcDEuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE1Li4uDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g YWRhNC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGFkYTMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEyLi4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhMS4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTAu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBtZmlkNy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1 aWQgZm9yIG1maWQ3IGlzIDE2OTY1ODYxNjM4OTM5OTI4NjYyDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDYu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlk NiBpcyA3NDY4NjcxOTAxODMxMjM1MTEzDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDUuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNSBpcyAxNDM5MDI4 MjkyOTc5Njk5ODMwNg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIG1maWQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMzOVsxXTogZ3VpZCBmb3IgbWZpZDQgaXMgMTY2OTUxNTE5NDczOTM1MjI1 MTgNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBtZmlkMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1 aWQgZm9yIG1maWQzIGlzIDE3MTc4MzMzMzEyNDgxNDA2MzEwDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDIu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlk MiBpcyA0MDkyMTYzMDU3ODQ0ODQzOTk5DQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDEuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMSBpcyAxMjgyNjk4 MTcxMDQ1MzM1MzE3Nw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIG1maWQwLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMzOVsxXTogZ3VpZCBmb3IgbWZpZDAgaXMgOTcyMzEwODYwMDI4MDQxMDIw Mg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkLzM4YjI3OTlkLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0 NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkLzM3NGEzMWVkLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFl MTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkLzM0NzkzNWVhLTBkZDktMTFkZi1hNmE0LTAwMzAx OGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkLzNmOWQ4OWNhLTBkZDktMTFkZi1hNmE0LTAw MzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNmOGFkNTZmLTBkZDktMTFkZi1hNmE0 LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNmNjJkMzA4LTBkZDktMTFkZi1h NmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiYWUwNTg2LTBkZDktMTFk Zi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiOWJiN2I2LTBkZDkt MTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiN2EzMGVlLTBk ZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNhMTQyN2Ew LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM5ZmVh MmQ5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM5 ZDRlNzRmLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlk LzM4OWU5M2JiLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdw dGlkLzM4Nzc5NWJhLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkLzM3MzY1YTAwLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkLzM3MTA2NGM5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0 NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkLzM0NWEyNDU5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFl MTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkLzM0MWJmNzQ5LTBkZDktMTFkZi1hNmE0LTAwMzAx OGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05ZGZhLTAw MWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1 aWQgZm9yIGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYz MDJlNSBpcyAxNDA2MzcyMzE5MzI0NDYwMTU4Mg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I5NDE5ZmFh LTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I3ZjAx ZmE3LTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIGdwdGlkL2I3ZjAxZmE3LTVh OWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBpcyAxMzA1NzE2NzE0MzYyNjk5 OTYxMg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkL2I3ZTc1ZjNiLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYz MDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZhLTAwMWQ5 MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQg Zm9yIGdwdGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJl NSBpcyA3NzE5NjM5NTI4NDQ1MDkzODc1DQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjY2YTM3MzAtNWE5 ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjUxMjkxZjQt NWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgZ3B0aWQvYjUxMjkxZjQtNWE5ZS0x MWRlLTlkZmEtMDAxZDkyZjMwMmU1IGlzIDE3NTgzMzM5NjkwOTIxODAyMjEz DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gZ3B0aWQvYjUwYjFiYjgtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1 Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gZ3B0aWQvYjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMw MmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3Ig Z3B0aWQvYjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1IGlz IDg2NTk1ODY0NTY3MDMxNjkyMDUNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iM2JhYjIxMC01YTllLTEx ZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iMjhkMDk1Mi01YTll LTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzM5WzFdOiBndWlkIGZvciBncHRpZC9iMjhkMDk1Mi01YTllLTExZGUt OWRmYS0wMDFkOTJmMzAyZTUgaXMgMTY1Mzk2MDczMzIzNzgyMzIwODMNCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBn cHRpZC9iMjgxZGY5Mi01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBncHRpZC9iMGQ0YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBncHRp ZC9iMGQ0YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMgMTQ5 OTM5MTQ2MzI2OTcyNzAxOTYNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iMGM5NTRmYi01YTllLTExZGUt OWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC84MWY4MDUwNS01YTllLTEx ZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzM5WzFdOiBndWlkIGZvciBncHRpZC84MWY4MDUwNS01YTllLTExZGUtOWRm YS0wMDFkOTJmMzAyZTUgaXMgNjU4NzE3NjYwODc0NjA0OTQzNA0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlk LzgxZWNkMDBhLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRl dl9nZW9tX29wZW5fYnlfZ3VpZDo0NDlbMV06IFNlYXJjaCBieSBndWlkIFs5 OTM4Njk1ODM2ODExNzA3MDY1XSBmYWlsZWQuDQp2ZGV2X2dlb21fb3Blbl9i eV9wYXRoOjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2Fk YTJwMy4NCnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8g YWRhMnAzLg0KdmRldl9nZW9tX29wZW46NTIxWzFdOiBQcm92aWRlciAvZGV2 L2FkYTJwMyBub3QgZm91bmQuDQp2ZGV2X2dlb21fb3Blbl9ieV9wYXRoOjQ2 NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2FkYTNwMy4NCnZk ZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8gYWRhM3AzLg0K dmRldl9nZW9tX2F0dGFjaDoxNTNbMV06IENyZWF0ZWQgY29uc3VtZXIgZm9y IGFkYTNwMy4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBhZGEzcDMuLi4NCnZkZXZfZ2VvbV9kZXRhY2g6MTczWzFd OiBDbG9zaW5nIGFjY2VzcyB0byBhZGEzcDMuDQp2ZGV2X2dlb21fZGV0YWNo OjE3N1sxXTogRGVzdHJveWVkIGNvbnN1bWVyIHRvIGFkYTNwMy4NCnZkZXZf Z2VvbV9vcGVuX2J5X3BhdGg6NDc3WzFdOiBndWlkIG1pc21hdGNoIGZvciBw cm92aWRlciAvZGV2L2FkYTNwMzogMTA0Nzg2NTE5Nzg2NDE0NTIwMDMgIT0g MC4NCnZkZXZfZ2VvbV9vcGVuX2J5X2d1aWQ6NDM1WzFdOiBTZWFyY2hpbmcg YnkgZ3VpZCBbMTA0Nzg2NTE5Nzg2NDE0NTIwMDNdLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1kMC4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFk YTVwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGFkYTVwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTVwMS4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTRwMy4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGFkYTRwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGFkYTRwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTNwMy4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTNwMi4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGFkYTNwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGFkYTJwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTJwMi4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTJw MS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGFkYTFwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTFwMi4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTFwMS4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFk YTBwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGFkYTBwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTBwMS4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3cDQuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkN3A0 IGlzIDE2OTY1ODYxNjM4OTM5OTI4NjYyDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDdwMy4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ3cDMgaXMgMTQw NjM3MjMxOTMyNDQ2MDE1ODINCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkN3AyLi4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDdwMS4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IG1maWQ2cDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlk IGZvciBtZmlkNnA0IGlzIDc0Njg2NzE5MDE4MzEyMzUxMTMNCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNnAz Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZp ZDZwMyBpcyAxMzA1NzE2NzE0MzYyNjk5OTYxMg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ2cDIuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkNnAxLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gbWZpZDVwNC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MzlbMV06IGd1aWQgZm9yIG1maWQ1cDQgaXMgMTQzOTAyODI5Mjk3OTY5OTgz MDYNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBtZmlkNXAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTog Z3VpZCBmb3IgbWZpZDVwMyBpcyA3NzE5NjM5NTI4NDQ1MDkzODc1DQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZp ZDVwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIG1maWQ1cDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNHA0Li4uDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDRwNCBpcyAxNjY5NTE1 MTk0NzM5MzUyMjUxOA0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIG1maWQ0cDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNHAzIGlzIDE3NTgzMzM5NjkwOTIx ODAyMjEzDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gbWZpZDRwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ0cDEuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkM3A0Li4u DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDNw NCBpcyAxNzE3ODMzMzMxMjQ4MTQwNjMxMA0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQzcDMuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkM3AzIGlzIDg2 NTk1ODY0NTY3MDMxNjkyMDUNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkM3AyLi4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDNwMS4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IG1maWQycDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlk IGZvciBtZmlkMnA0IGlzIDQwOTIxNjMwNTc4NDQ4NDM5OTkNCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMnAz Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZp ZDJwMyBpcyAxNjUzOTYwNzMzMjM3ODIzMjA4Mw0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQycDIuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkMnAxLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gbWZpZDFwNC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MzlbMV06IGd1aWQgZm9yIG1maWQxcDQgaXMgMTI4MjY5ODE3MTA0NTMzNTMx NzcNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBtZmlkMXAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTog Z3VpZCBmb3IgbWZpZDFwMyBpcyAxNDk5MzkxNDYzMjY5NzI3MDE5Ng0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1m aWQxcDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBtZmlkMXAxLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDBwNC4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQwcDQgaXMgOTcyMzEw ODYwMDI4MDQxMDIwMg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIG1maWQwcDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMHAzIGlzIDY1ODcxNzY2MDg3NDYw NDk0MzQNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBtZmlkMHAyLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gbWZpZDBwMS4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTUuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBh ZGE0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gYWRhMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGExLi4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhMC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIG1maWQ3Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3Vp ZCBmb3IgbWZpZDcgaXMgMTY5NjU4NjE2Mzg5Mzk5Mjg2NjINCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNi4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ2 IGlzIDc0Njg2NzE5MDE4MzEyMzUxMTMNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNS4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ1IGlzIDE0MzkwMjgy OTI5Nzk2OTk4MzA2DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gbWZpZDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzM5WzFdOiBndWlkIGZvciBtZmlkNCBpcyAxNjY5NTE1MTk0NzM5MzUyMjUx OA0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIG1maWQzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3Vp ZCBmb3IgbWZpZDMgaXMgMTcxNzgzMzMzMTI0ODE0MDYzMTANCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMi4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQy IGlzIDQwOTIxNjMwNTc4NDQ4NDM5OTkNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMS4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQxIGlzIDEyODI2OTgx NzEwNDUzMzUzMTc3DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gbWZpZDAuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzM5WzFdOiBndWlkIGZvciBtZmlkMCBpcyA5NzIzMTA4NjAwMjgwNDEwMjAy DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gZ3B0aWQvM2ExNDI3YTAtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0 Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gZ3B0aWQvMzhiMjc5OWQtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUx OTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gZ3B0aWQvMzc0YTMxZWQtMGRkOS0xMWRmLWE2YTQtMDAzMDE4 YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gZ3B0aWQvMzQ3OTM1ZWEtMGRkOS0xMWRmLWE2YTQtMDAz MDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gZ3B0aWQvM2Y5ZDg5Y2EtMGRkOS0xMWRmLWE2YTQt MDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTog UmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2Y4YWQ1NmYtMGRkOS0xMWRmLWE2 YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2Y2MmQzMDgtMGRkOS0xMWRm LWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2JhZTA1ODYtMGRkOS0x MWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2I5YmI3YjYtMGRk OS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvM2I3YTMwZWUt MGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvMzlmZWEy ZDktMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvMzlk NGU3NGYtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQv Mzg5ZTkzYmItMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0 aWQvMzg3Nzk1YmEtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4uDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g Z3B0aWQvMzczNjVhMDAtMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0Li4u DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gZ3B0aWQvMzcxMDY0YzktMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUxOTQ0 Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gZ3B0aWQvMzQ1YTI0NTktMGRkOS0xMWRmLWE2YTQtMDAzMDE4YWUx OTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gZ3B0aWQvMzQxYmY3NDktMGRkOS0xMWRmLWE2YTQtMDAzMDE4 YWUxOTQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGlu ZyBndWlkIGZyb20gZ3B0aWQvYjk0YTM5N2QtNWE5ZS0xMWRlLTlkZmEtMDAx ZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3Vp ZCBmb3IgZ3B0aWQvYjk0YTM5N2QtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMw MmU1IGlzIDE0MDYzNzIzMTkzMjQ0NjAxNTgyDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjk0MTlmYWEt NWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjdmMDFm YTctNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgZ3B0aWQvYjdmMDFmYTctNWE5 ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1IGlzIDEzMDU3MTY3MTQzNjI2OTk5 NjEyDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gZ3B0aWQvYjdlNzVmM2ItNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMw MmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gZ3B0aWQvYjY3NTFhZmYtNWE5ZS0xMWRlLTlkZmEtMDAxZDky ZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBm b3IgZ3B0aWQvYjY3NTFhZmYtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1 IGlzIDc3MTk2Mzk1Mjg0NDUwOTM4NzUNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iNjZhMzczMC01YTll LTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iNTEyOTFmNC01 YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzM5WzFdOiBndWlkIGZvciBncHRpZC9iNTEyOTFmNC01YTllLTEx ZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMgMTc1ODMzMzk2OTA5MjE4MDIyMTMN CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBncHRpZC9iNTBiMWJiOC01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBncHRpZC9iM2JmOWI0My01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAy ZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBn cHRpZC9iM2JmOWI0My01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMg ODY1OTU4NjQ1NjcwMzE2OTIwNQ0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2IzYmFiMjEwLTVhOWUtMTFk ZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2IyOGQwOTUyLTVhOWUt MTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMzlbMV06IGd1aWQgZm9yIGdwdGlkL2IyOGQwOTUyLTVhOWUtMTFkZS05 ZGZhLTAwMWQ5MmYzMDJlNSBpcyAxNjUzOTYwNzMzMjM3ODIzMjA4Mw0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdw dGlkL2IyODFkZjkyLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkL2IwZDRiYzNjLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIGdwdGlk L2IwZDRiYzNjLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBpcyAxNDk5 MzkxNDYzMjY5NzI3MDE5Ng0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2IwYzk1NGZiLTVhOWUtMTFkZS05 ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzgxZjgwNTA1LTVhOWUtMTFk ZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MzlbMV06IGd1aWQgZm9yIGdwdGlkLzgxZjgwNTA1LTVhOWUtMTFkZS05ZGZh LTAwMWQ5MmYzMDJlNSBpcyA2NTg3MTc2NjA4NzQ2MDQ5NDM0DQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQv ODFlY2QwMGEtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2 X2dlb21fb3Blbl9ieV9ndWlkOjQ0OVsxXTogU2VhcmNoIGJ5IGd1aWQgWzEw NDc4NjUxOTc4NjQxNDUyMDAzXSBmYWlsZWQuDQp2ZGV2X2dlb21fb3Blbl9i eV9wYXRoOjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2Fk YTNwMy4NCnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8g YWRhM3AzLg0KdmRldl9nZW9tX29wZW46NTIxWzFdOiBQcm92aWRlciAvZGV2 L2FkYTNwMyBub3QgZm91bmQuDQp2ZGV2X2dlb21fb3Blbl9ieV9wYXRoOjQ2 NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2FkYTRwMy4NCnZk ZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8gYWRhNHAzLg0K dmRldl9nZW9tX2F0dGFjaDoxNTNbMV06IENyZWF0ZWQgY29uc3VtZXIgZm9y IGFkYTRwMy4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBhZGE0cDMuLi4NCnZkZXZfZ2VvbV9kZXRhY2g6MTczWzFd OiBDbG9zaW5nIGFjY2VzcyB0byBhZGE0cDMuDQp2ZGV2X2dlb21fZGV0YWNo OjE3N1sxXTogRGVzdHJveWVkIGNvbnN1bWVyIHRvIGFkYTRwMy4NCnZkZXZf Z2VvbV9vcGVuX2J5X3BhdGg6NDc3WzFdOiBndWlkIG1pc21hdGNoIGZvciBw cm92aWRlciAvZGV2L2FkYTRwMzogMjE1ODIzNjk4NTM0OTUzODcwMSAhPSAw Lg0KdmRldl9nZW9tX29wZW5fYnlfZ3VpZDo0MzVbMV06IFNlYXJjaGluZyBi eSBndWlkIFsyMTU4MjM2OTg1MzQ5NTM4NzAxXS4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZDAuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE1 cDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBhZGE1cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE1cDEuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE0cDMuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBh ZGE0cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBhZGE0cDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEzcDMuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEzcDIuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBhZGEzcDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBhZGEycDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEycDIuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEycDEu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBhZGExcDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBhZGExcDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGExcDEuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEw cDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBhZGEwcDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEwcDEuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkN3A0Li4uDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDdwNCBp cyAxNjk2NTg2MTYzODkzOTkyODY2Mg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3cDMuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkN3AzIGlzIDE0MDYz NzIzMTkzMjQ0NjAxNTgyDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTog UmVhZGluZyBndWlkIGZyb20gbWZpZDdwMi4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3cDEuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkNnA0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBm b3IgbWZpZDZwNCBpcyA3NDY4NjcxOTAxODMxMjM1MTEzDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDZwMy4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ2 cDMgaXMgMTMwNTcxNjcxNDM2MjY5OTk2MTINCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNnAyLi4uDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZp ZDZwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIG1maWQ1cDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5 WzFdOiBndWlkIGZvciBtZmlkNXA0IGlzIDE0MzkwMjgyOTI5Nzk2OTk4MzA2 DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gbWZpZDVwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1 aWQgZm9yIG1maWQ1cDMgaXMgNzcxOTYzOTUyODQ0NTA5Mzg3NQ0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ1 cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBtZmlkNXAxLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gbWZpZDRwNC4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ0cDQgaXMgMTY2OTUxNTE5 NDczOTM1MjI1MTgNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBtZmlkNHAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMzOVsxXTogZ3VpZCBmb3IgbWZpZDRwMyBpcyAxNzU4MzMzOTY5MDkyMTgw MjIxMw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIG1maWQ0cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNHAxLi4uDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDNwNC4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQzcDQg aXMgMTcxNzgzMzMzMTI0ODE0MDYzMTANCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkM3AzLi4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDNwMyBpcyA4NjU5 NTg2NDU2NzAzMTY5MjA1DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTog UmVhZGluZyBndWlkIGZyb20gbWZpZDNwMi4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQzcDEuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkMnA0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBm b3IgbWZpZDJwNCBpcyA0MDkyMTYzMDU3ODQ0ODQzOTk5DQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDJwMy4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQy cDMgaXMgMTY1Mzk2MDczMzIzNzgyMzIwODMNCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMnAyLi4uDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZp ZDJwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIG1maWQxcDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5 WzFdOiBndWlkIGZvciBtZmlkMXA0IGlzIDEyODI2OTgxNzEwNDUzMzUzMTc3 DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gbWZpZDFwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1 aWQgZm9yIG1maWQxcDMgaXMgMTQ5OTM5MTQ2MzI2OTcyNzAxOTYNCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlk MXAyLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBn dWlkIGZyb20gbWZpZDFwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwcDQuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMHA0IGlzIDk3MjMxMDg2 MDAyODA0MTAyMDINCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBtZmlkMHAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMzOVsxXTogZ3VpZCBmb3IgbWZpZDBwMyBpcyA2NTg3MTc2NjA4NzQ2MDQ5 NDM0DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gbWZpZDBwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwcDEuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE1Li4uDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRh NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGFkYTMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBhZGEyLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhMS4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTAuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBtZmlkNy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQg Zm9yIG1maWQ3IGlzIDE2OTY1ODYxNjM4OTM5OTI4NjYyDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDYuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNiBp cyA3NDY4NjcxOTAxODMxMjM1MTEzDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDUuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNSBpcyAxNDM5MDI4Mjky OTc5Njk5ODMwNg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIG1maWQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMz OVsxXTogZ3VpZCBmb3IgbWZpZDQgaXMgMTY2OTUxNTE5NDczOTM1MjI1MTgN CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBtZmlkMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQg Zm9yIG1maWQzIGlzIDE3MTc4MzMzMzEyNDgxNDA2MzEwDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDIuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMiBp cyA0MDkyMTYzMDU3ODQ0ODQzOTk5DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDEuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMSBpcyAxMjgyNjk4MTcx MDQ1MzM1MzE3Nw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIG1maWQwLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMz OVsxXTogZ3VpZCBmb3IgbWZpZDAgaXMgOTcyMzEwODYwMDI4MDQxMDIwMg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkLzNiYWUwNTg2LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkLzNhMTQyN2EwLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0 NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkLzM4YjI3OTlkLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFl MTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkLzM3NGEzMWVkLTBkZDktMTFkZi1hNmE0LTAwMzAx OGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkLzM0NzkzNWVhLTBkZDktMTFkZi1hNmE0LTAw MzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNmOWQ4OWNhLTBkZDktMTFkZi1hNmE0 LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNmOGFkNTZmLTBkZDktMTFkZi1h NmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNmNjJkMzA4LTBkZDktMTFk Zi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiOWJiN2I2LTBkZDkt MTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiN2EzMGVlLTBk ZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM5ZmVhMmQ5 LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM5ZDRl NzRmLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM4 OWU5M2JiLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlk LzM4Nzc5NWJhLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdw dGlkLzM3MzY1YTAwLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkLzM3MTA2NGM5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkLzM0NWEyNDU5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0 NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkLzM0MWJmNzQ5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFl MTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05ZGZhLTAwMWQ5 MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQg Zm9yIGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJl NSBpcyAxNDA2MzcyMzE5MzI0NDYwMTU4Mg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I5NDE5ZmFhLTVh OWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I3ZjAxZmE3 LTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIGdwdGlkL2I3ZjAxZmE3LTVhOWUt MTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBpcyAxMzA1NzE2NzE0MzYyNjk5OTYx Mg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkL2I3ZTc1ZjNiLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJl NS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYz MDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9y IGdwdGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBp cyA3NzE5NjM5NTI4NDQ1MDkzODc1DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjY2YTM3MzAtNWE5ZS0x MWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjUxMjkxZjQtNWE5 ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMzOVsxXTogZ3VpZCBmb3IgZ3B0aWQvYjUxMjkxZjQtNWE5ZS0xMWRl LTlkZmEtMDAxZDkyZjMwMmU1IGlzIDE3NTgzMzM5NjkwOTIxODAyMjEzDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g Z3B0aWQvYjUwYjFiYjgtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4u DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gZ3B0aWQvYjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1 Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgZ3B0 aWQvYjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1IGlzIDg2 NTk1ODY0NTY3MDMxNjkyMDUNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iM2JhYjIxMC01YTllLTExZGUt OWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iMjhkMDk1Mi01YTllLTEx ZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzM5WzFdOiBndWlkIGZvciBncHRpZC9iMjhkMDk1Mi01YTllLTExZGUtOWRm YS0wMDFkOTJmMzAyZTUgaXMgMTY1Mzk2MDczMzIzNzgyMzIwODMNCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRp ZC9iMjgxZGY5Mi01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBn cHRpZC9iMGQ0YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBncHRpZC9i MGQ0YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMgMTQ5OTM5 MTQ2MzI2OTcyNzAxOTYNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iMGM5NTRmYi01YTllLTExZGUtOWRm YS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC84MWY4MDUwNS01YTllLTExZGUt OWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5 WzFdOiBndWlkIGZvciBncHRpZC84MWY4MDUwNS01YTllLTExZGUtOWRmYS0w MDFkOTJmMzAyZTUgaXMgNjU4NzE3NjYwODc0NjA0OTQzNA0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzgx ZWNkMDBhLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9n ZW9tX29wZW5fYnlfZ3VpZDo0NDlbMV06IFNlYXJjaCBieSBndWlkIFsyMTU4 MjM2OTg1MzQ5NTM4NzAxXSBmYWlsZWQuDQp2ZGV2X2dlb21fb3Blbl9ieV9w YXRoOjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2FkYTRw My4NCnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8gYWRh NHAzLg0KdmRldl9nZW9tX29wZW46NTIxWzFdOiBQcm92aWRlciAvZGV2L2Fk YTRwMyBub3QgZm91bmQuDQp2ZGV2X2dlb21fb3Blbl9ieV9wYXRoOjQ2Nlsx XTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2FkYTVwMy4NCnZkZXZf Z2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8gYWRhNXAzLg0KdmRl dl9nZW9tX2F0dGFjaDoxNTNbMV06IENyZWF0ZWQgY29uc3VtZXIgZm9yIGFk YTVwMy4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBhZGE1cDMuLi4NCnZkZXZfZ2VvbV9kZXRhY2g6MTczWzFdOiBD bG9zaW5nIGFjY2VzcyB0byBhZGE1cDMuDQp2ZGV2X2dlb21fZGV0YWNoOjE3 N1sxXTogRGVzdHJveWVkIGNvbnN1bWVyIHRvIGFkYTVwMy4NCnZkZXZfZ2Vv bV9vcGVuX2J5X3BhdGg6NDc3WzFdOiBndWlkIG1pc21hdGNoIGZvciBwcm92 aWRlciAvZGV2L2FkYTVwMzogMTMzMTA5NjA5ODA4Njc5NzE2MSAhPSAwLg0K dmRldl9nZW9tX29wZW5fYnlfZ3VpZDo0MzVbMV06IFNlYXJjaGluZyBieSBn dWlkIFsxMzMxMDk2MDk4MDg2Nzk3MTYxXS4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZDAuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE1cDMu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBhZGE1cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBhZGE1cDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE0cDMuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE0 cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1 aWQgZnJvbSBhZGE0cDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEzcDMuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEzcDIuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBh ZGEzcDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBhZGEycDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEycDIuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEycDEuLi4N CnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJv bSBhZGExcDMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBhZGExcDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGExcDEuLi4NCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGEwcDMu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBhZGEwcDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBhZGEwcDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkN3A0Li4uDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDdwNCBpcyAx Njk2NTg2MTYzODkzOTkyODY2Mg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3cDMuLi4NCnZkZXZfZ2VvbV9y ZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkN3AzIGlzIDE0MDYzNzIz MTkzMjQ0NjAxNTgyDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gbWZpZDdwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ3cDEuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlk NnA0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3Ig bWZpZDZwNCBpcyA3NDY4NjcxOTAxODMxMjM1MTEzDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDZwMy4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ2cDMg aXMgMTMwNTcxNjcxNDM2MjY5OTk2MTINCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkNnAyLi4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDZw MS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIG1maWQ1cDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFd OiBndWlkIGZvciBtZmlkNXA0IGlzIDE0MzkwMjgyOTI5Nzk2OTk4MzA2DQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g bWZpZDVwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQg Zm9yIG1maWQ1cDMgaXMgNzcxOTYzOTUyODQ0NTA5Mzg3NQ0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQ1cDIu Li4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQg ZnJvbSBtZmlkNXAxLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTog UmVhZGluZyBndWlkIGZyb20gbWZpZDRwNC4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQ0cDQgaXMgMTY2OTUxNTE5NDcz OTM1MjI1MTgNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBtZmlkNHAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMz OVsxXTogZ3VpZCBmb3IgbWZpZDRwMyBpcyAxNzU4MzMzOTY5MDkyMTgwMjIx Mw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIG1maWQ0cDIuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBtZmlkNHAxLi4uDQp2ZGV2X2dlb21fcmVhZF9n dWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDNwNC4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQzcDQgaXMg MTcxNzgzMzMzMTI0ODE0MDYzMTANCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAx WzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkM3AzLi4uDQp2ZGV2X2dlb21f cmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgbWZpZDNwMyBpcyA4NjU5NTg2 NDU2NzAzMTY5MjA1DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVh ZGluZyBndWlkIGZyb20gbWZpZDNwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQzcDEuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlk MnA0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3Ig bWZpZDJwNCBpcyA0MDkyMTYzMDU3ODQ0ODQzOTk5DQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDJwMy4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIG1maWQycDMg aXMgMTY1Mzk2MDczMzIzNzgyMzIwODMNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6 MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMnAyLi4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDJw MS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIG1maWQxcDQuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFd OiBndWlkIGZvciBtZmlkMXA0IGlzIDEyODI2OTgxNzEwNDUzMzUzMTc3DQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g bWZpZDFwMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQg Zm9yIG1maWQxcDMgaXMgMTQ5OTM5MTQ2MzI2OTcyNzAxOTYNCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBtZmlkMXAy Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlk IGZyb20gbWZpZDFwMS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIG1maWQwcDQuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMHA0IGlzIDk3MjMxMDg2MDAy ODA0MTAyMDINCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5n IGd1aWQgZnJvbSBtZmlkMHAzLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMz OVsxXTogZ3VpZCBmb3IgbWZpZDBwMyBpcyA2NTg3MTc2NjA4NzQ2MDQ5NDM0 DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZy b20gbWZpZDBwMi4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIG1maWQwcDEuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1 aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBhZGE1Li4uDQp2ZGV2X2dl b21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhNC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGFkYTMuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBhZGEyLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gYWRhMS4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGFkYTAuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkNy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9y IG1maWQ3IGlzIDE2OTY1ODYxNjM4OTM5OTI4NjYyDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDYuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNiBpcyA3 NDY4NjcxOTAxODMxMjM1MTEzDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gbWZpZDUuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkNSBpcyAxNDM5MDI4MjkyOTc5 Njk5ODMwNg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIG1maWQ0Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsx XTogZ3VpZCBmb3IgbWZpZDQgaXMgMTY2OTUxNTE5NDczOTM1MjI1MTgNCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBt ZmlkMy4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9y IG1maWQzIGlzIDE3MTc4MzMzMzEyNDgxNDA2MzEwDQp2ZGV2X2dlb21fcmVh ZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gbWZpZDIuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMiBpcyA0 MDkyMTYzMDU3ODQ0ODQzOTk5DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gbWZpZDEuLi4NCnZkZXZfZ2VvbV9yZWFk X2d1aWQ6MzM5WzFdOiBndWlkIGZvciBtZmlkMSBpcyAxMjgyNjk4MTcxMDQ1 MzM1MzE3Nw0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIG1maWQwLi4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsx XTogZ3VpZCBmb3IgbWZpZDAgaXMgOTcyMzEwODYwMDI4MDQxMDIwMg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdw dGlkLzNmOWQ4OWNhLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkLzNiYWUwNTg2LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkLzNhMTQyN2EwLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0 NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkLzM4YjI3OTlkLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFl MTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcg Z3VpZCBmcm9tIGdwdGlkLzM3NGEzMWVkLTBkZDktMTFkZi1hNmE0LTAwMzAx OGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRp bmcgZ3VpZCBmcm9tIGdwdGlkLzM0NzkzNWVhLTBkZDktMTFkZi1hNmE0LTAw MzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJl YWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNmOGFkNTZmLTBkZDktMTFkZi1hNmE0 LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06 IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNmNjJkMzA4LTBkZDktMTFkZi1h NmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFb MV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiOWJiN2I2LTBkZDktMTFk Zi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzNiN2EzMGVlLTBkZDkt MTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM5ZmVhMmQ5LTBk ZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM5ZDRlNzRm LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM4OWU5 M2JiLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9nZW9t X3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzM4 Nzc5NWJhLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRldl9n ZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlk LzM3MzY1YTAwLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0KdmRl dl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdw dGlkLzM3MTA2NGM5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4uLg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkLzM0NWEyNDU5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NC4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkLzM0MWJmNzQ5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0 NC4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3Vp ZCBmcm9tIGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYz MDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9y IGdwdGlkL2I5NGEzOTdkLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBp cyAxNDA2MzcyMzE5MzI0NDYwMTU4Mg0KdmRldl9nZW9tX3JlYWRfZ3VpZDoz MDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I5NDE5ZmFhLTVhOWUt MTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRfZ3Vp ZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkL2I3ZjAxZmE3LTVh OWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9tX3JlYWRf Z3VpZDozMzlbMV06IGd1aWQgZm9yIGdwdGlkL2I3ZjAxZmE3LTVhOWUtMTFk ZS05ZGZhLTAwMWQ5MmYzMDJlNSBpcyAxMzA1NzE2NzE0MzYyNjk5OTYxMg0K dmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9t IGdwdGlkL2I3ZTc1ZjNiLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4u Lg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBm cm9tIGdwdGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJl NS4uLg0KdmRldl9nZW9tX3JlYWRfZ3VpZDozMzlbMV06IGd1aWQgZm9yIGdw dGlkL2I2NzUxYWZmLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNSBpcyA3 NzE5NjM5NTI4NDQ1MDkzODc1DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsx XTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjY2YTM3MzAtNWE5ZS0xMWRl LTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMw MVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0aWQvYjUxMjkxZjQtNWE5ZS0x MWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2ZGV2X2dlb21fcmVhZF9ndWlk OjMzOVsxXTogZ3VpZCBmb3IgZ3B0aWQvYjUxMjkxZjQtNWE5ZS0xMWRlLTlk ZmEtMDAxZDkyZjMwMmU1IGlzIDE3NTgzMzM5NjkwOTIxODAyMjEzDQp2ZGV2 X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20gZ3B0 aWQvYjUwYjFiYjgtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4uDQp2 ZGV2X2dlb21fcmVhZF9ndWlkOjMwMVsxXTogUmVhZGluZyBndWlkIGZyb20g Z3B0aWQvYjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1Li4u DQp2ZGV2X2dlb21fcmVhZF9ndWlkOjMzOVsxXTogZ3VpZCBmb3IgZ3B0aWQv YjNiZjliNDMtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1IGlzIDg2NTk1 ODY0NTY3MDMxNjkyMDUNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iM2JhYjIxMC01YTllLTExZGUtOWRm YS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFd OiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9iMjhkMDk1Mi01YTllLTExZGUt OWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5 WzFdOiBndWlkIGZvciBncHRpZC9iMjhkMDk1Mi01YTllLTExZGUtOWRmYS0w MDFkOTJmMzAyZTUgaXMgMTY1Mzk2MDczMzIzNzgyMzIwODMNCnZkZXZfZ2Vv bV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRpZC9i MjgxZGY5Mi01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZf Z2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFkaW5nIGd1aWQgZnJvbSBncHRp ZC9iMGQ0YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUuLi4NCnZk ZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFdOiBndWlkIGZvciBncHRpZC9iMGQ0 YmMzYy01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUgaXMgMTQ5OTM5MTQ2 MzI2OTcyNzAxOTYNCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBSZWFk aW5nIGd1aWQgZnJvbSBncHRpZC9iMGM5NTRmYi01YTllLTExZGUtOWRmYS0w MDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzAxWzFdOiBS ZWFkaW5nIGd1aWQgZnJvbSBncHRpZC84MWY4MDUwNS01YTllLTExZGUtOWRm YS0wMDFkOTJmMzAyZTUuLi4NCnZkZXZfZ2VvbV9yZWFkX2d1aWQ6MzM5WzFd OiBndWlkIGZvciBncHRpZC84MWY4MDUwNS01YTllLTExZGUtOWRmYS0wMDFk OTJmMzAyZTUgaXMgNjU4NzE3NjYwODc0NjA0OTQzNA0KdmRldl9nZW9tX3Jl YWRfZ3VpZDozMDFbMV06IFJlYWRpbmcgZ3VpZCBmcm9tIGdwdGlkLzgxZWNk MDBhLTVhOWUtMTFkZS05ZGZhLTAwMWQ5MmYzMDJlNS4uLg0KdmRldl9nZW9t X29wZW5fYnlfZ3VpZDo0NDlbMV06IFNlYXJjaCBieSBndWlkIFsxMzMxMDk2 MDk4MDg2Nzk3MTYxXSBmYWlsZWQuDQp2ZGV2X2dlb21fb3Blbl9ieV9wYXRo OjQ2NlsxXTogRm91bmQgcHJvdmlkZXIgYnkgbmFtZSAvZGV2L2FkYTVwMy4N CnZkZXZfZ2VvbV9hdHRhY2g6MTEyWzFdOiBBdHRhY2hpbmcgdG8gYWRhNXAz Lg0KdmRldl9nZW9tX29wZW46NTIxWzFdOiBQcm92aWRlciAvZGV2L2FkYTVw MyBub3QgZm91bmQuDQo= --0-1971476311-1264883505=:4627 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=glabel.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=glabel.txt R2VvbSBuYW1lOiBtZmlkMHAxDQpQcm92aWRlcnM6DQoxLiBOYW1lOiBncHRp ZC84MWVjZDAwYS01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUNCiAgIE1l ZGlhc2l6ZTogMjQ0NzM2ICgyMzlLKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQog ICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0KICAgb2Zmc2V0OiAw DQogICBzZWNsZW5ndGg6IDQ3OA0KICAgbGVuZ3RoOiAyNDQ3MzYNCiAgIGlu ZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBtZmlkMHAxDQogICBNZWRp YXNpemU6IDI0NDczNiAoMjM5SykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAg TW9kZTogcjB3MGUwDQoNCkdlb20gbmFtZTogbWZpZDBwMw0KUHJvdmlkZXJz Og0KMS4gTmFtZTogZ3B0aWQvODFmODA1MDUtNWE5ZS0xMWRlLTlkZmEtMDAx ZDkyZjMwMmU1DQogICBNZWRpYXNpemU6IDEwNzM3NDE4MjQgKDEuMEcpDQog ICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KICAgc2Vjb2Zm c2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xlbmd0aDogMjA5NzE1Mg0K ICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBpbmRleDogMA0KQ29uc3VtZXJz Og0KMS4gTmFtZTogbWZpZDBwMw0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0 ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTAN Cg0KR2VvbSBuYW1lOiBtZmlkMXAxDQpQcm92aWRlcnM6DQoxLiBOYW1lOiBn cHRpZC9iMGM5NTRmYi01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUNCiAg IE1lZGlhc2l6ZTogMjQ0NzM2ICgyMzlLKQ0KICAgU2VjdG9yc2l6ZTogNTEy DQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0KICAgb2Zmc2V0 OiAwDQogICBzZWNsZW5ndGg6IDQ3OA0KICAgbGVuZ3RoOiAyNDQ3MzYNCiAg IGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBtZmlkMXAxDQogICBN ZWRpYXNpemU6IDI0NDczNiAoMjM5SykNCiAgIFNlY3RvcnNpemU6IDUxMg0K ICAgTW9kZTogcjB3MGUwDQoNCkdlb20gbmFtZTogbWZpZDFwMw0KUHJvdmlk ZXJzOg0KMS4gTmFtZTogZ3B0aWQvYjBkNGJjM2MtNWE5ZS0xMWRlLTlkZmEt MDAxZDkyZjMwMmU1DQogICBNZWRpYXNpemU6IDEwNzM3NDE4MjQgKDEuMEcp DQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KICAgc2Vj b2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xlbmd0aDogMjA5NzE1 Mg0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBpbmRleDogMA0KQ29uc3Vt ZXJzOg0KMS4gTmFtZTogbWZpZDFwMw0KICAgTWVkaWFzaXplOiAxMDczNzQx ODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcw ZTANCg0KR2VvbSBuYW1lOiBtZmlkMnAxDQpQcm92aWRlcnM6DQoxLiBOYW1l OiBncHRpZC9iMjgxZGY5Mi01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAyZTUN CiAgIE1lZGlhc2l6ZTogMjQ0NzM2ICgyMzlLKQ0KICAgU2VjdG9yc2l6ZTog NTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0KICAgb2Zm c2V0OiAwDQogICBzZWNsZW5ndGg6IDQ3OA0KICAgbGVuZ3RoOiAyNDQ3MzYN CiAgIGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBtZmlkMnAxDQog ICBNZWRpYXNpemU6IDI0NDczNiAoMjM5SykNCiAgIFNlY3RvcnNpemU6IDUx Mg0KICAgTW9kZTogcjB3MGUwDQoNCkdlb20gbmFtZTogbWZpZDJwMw0KUHJv dmlkZXJzOg0KMS4gTmFtZTogZ3B0aWQvYjI4ZDA5NTItNWE5ZS0xMWRlLTlk ZmEtMDAxZDkyZjMwMmU1DQogICBNZWRpYXNpemU6IDEwNzM3NDE4MjQgKDEu MEcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KICAg c2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xlbmd0aDogMjA5 NzE1Mg0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBpbmRleDogMA0KQ29u c3VtZXJzOg0KMS4gTmFtZTogbWZpZDJwMw0KICAgTWVkaWFzaXplOiAxMDcz NzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiBy MHcwZTANCg0KR2VvbSBuYW1lOiBtZmlkM3AxDQpQcm92aWRlcnM6DQoxLiBO YW1lOiBncHRpZC9iM2JhYjIxMC01YTllLTExZGUtOWRmYS0wMDFkOTJmMzAy ZTUNCiAgIE1lZGlhc2l6ZTogMjQ0NzM2ICgyMzlLKQ0KICAgU2VjdG9yc2l6 ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0KICAg b2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDQ3OA0KICAgbGVuZ3RoOiAyNDQ3 MzYNCiAgIGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBtZmlkM3Ax DQogICBNZWRpYXNpemU6IDI0NDczNiAoMjM5SykNCiAgIFNlY3RvcnNpemU6 IDUxMg0KICAgTW9kZTogcjB3MGUwDQoNCkdlb20gbmFtZTogbWZpZDNwMw0K UHJvdmlkZXJzOg0KMS4gTmFtZTogZ3B0aWQvYjNiZjliNDMtNWE5ZS0xMWRl LTlkZmEtMDAxZDkyZjMwMmU1DQogICBNZWRpYXNpemU6IDEwNzM3NDE4MjQg KDEuMEcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0K ICAgc2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xlbmd0aDog MjA5NzE1Mg0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBpbmRleDogMA0K Q29uc3VtZXJzOg0KMS4gTmFtZTogbWZpZDNwMw0KICAgTWVkaWFzaXplOiAx MDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2Rl OiByMHcwZTANCg0KR2VvbSBuYW1lOiBtZmlkNHAxDQpQcm92aWRlcnM6DQox LiBOYW1lOiBncHRpZC9iNTBiMWJiOC01YTllLTExZGUtOWRmYS0wMDFkOTJm MzAyZTUNCiAgIE1lZGlhc2l6ZTogMjQ0NzM2ICgyMzlLKQ0KICAgU2VjdG9y c2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0K ICAgb2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDQ3OA0KICAgbGVuZ3RoOiAy NDQ3MzYNCiAgIGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBtZmlk NHAxDQogICBNZWRpYXNpemU6IDI0NDczNiAoMjM5SykNCiAgIFNlY3RvcnNp emU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQoNCkdlb20gbmFtZTogbWZpZDRw Mw0KUHJvdmlkZXJzOg0KMS4gTmFtZTogZ3B0aWQvYjUxMjkxZjQtNWE5ZS0x MWRlLTlkZmEtMDAxZDkyZjMwMmU1DQogICBNZWRpYXNpemU6IDEwNzM3NDE4 MjQgKDEuMEcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBl MA0KICAgc2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xlbmd0 aDogMjA5NzE1Mg0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBpbmRleDog MA0KQ29uc3VtZXJzOg0KMS4gTmFtZTogbWZpZDRwMw0KICAgTWVkaWFzaXpl OiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBN b2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBtZmlkNXAxDQpQcm92aWRlcnM6 DQoxLiBOYW1lOiBncHRpZC9iNjZhMzczMC01YTllLTExZGUtOWRmYS0wMDFk OTJmMzAyZTUNCiAgIE1lZGlhc2l6ZTogMjQ0NzM2ICgyMzlLKQ0KICAgU2Vj dG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDog MA0KICAgb2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDQ3OA0KICAgbGVuZ3Ro OiAyNDQ3MzYNCiAgIGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBt ZmlkNXAxDQogICBNZWRpYXNpemU6IDI0NDczNiAoMjM5SykNCiAgIFNlY3Rv cnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQoNCkdlb20gbmFtZTogbWZp ZDVwMw0KUHJvdmlkZXJzOg0KMS4gTmFtZTogZ3B0aWQvYjY3NTFhZmYtNWE5 ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1DQogICBNZWRpYXNpemU6IDEwNzM3 NDE4MjQgKDEuMEcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIw dzBlMA0KICAgc2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xl bmd0aDogMjA5NzE1Mg0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBpbmRl eDogMA0KQ29uc3VtZXJzOg0KMS4gTmFtZTogbWZpZDVwMw0KICAgTWVkaWFz aXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQog ICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBtZmlkNnAxDQpQcm92aWRl cnM6DQoxLiBOYW1lOiBncHRpZC9iN2U3NWYzYi01YTllLTExZGUtOWRmYS0w MDFkOTJmMzAyZTUNCiAgIE1lZGlhc2l6ZTogMjQ0NzM2ICgyMzlLKQ0KICAg U2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNl dDogMA0KICAgb2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDQ3OA0KICAgbGVu Z3RoOiAyNDQ3MzYNCiAgIGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1l OiBtZmlkNnAxDQogICBNZWRpYXNpemU6IDI0NDczNiAoMjM5SykNCiAgIFNl Y3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQoNCkdlb20gbmFtZTog bWZpZDZwMw0KUHJvdmlkZXJzOg0KMS4gTmFtZTogZ3B0aWQvYjdmMDFmYTct NWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1DQogICBNZWRpYXNpemU6IDEw NzM3NDE4MjQgKDEuMEcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6 IHIwdzBlMA0KICAgc2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNl Y2xlbmd0aDogMjA5NzE1Mg0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBp bmRleDogMA0KQ29uc3VtZXJzOg0KMS4gTmFtZTogbWZpZDZwMw0KICAgTWVk aWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEy DQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBtZmlkN3AxDQpQcm92 aWRlcnM6DQoxLiBOYW1lOiBncHRpZC9iOTQxOWZhYS01YTllLTExZGUtOWRm YS0wMDFkOTJmMzAyZTUNCiAgIE1lZGlhc2l6ZTogMjQ0NzM2ICgyMzlLKQ0K ICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29m ZnNldDogMA0KICAgb2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDQ3OA0KICAg bGVuZ3RoOiAyNDQ3MzYNCiAgIGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBO YW1lOiBtZmlkN3AxDQogICBNZWRpYXNpemU6IDI0NDczNiAoMjM5SykNCiAg IFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQoNCkdlb20gbmFt ZTogbWZpZDdwMw0KUHJvdmlkZXJzOg0KMS4gTmFtZTogZ3B0aWQvYjk0YTM5 N2QtNWE5ZS0xMWRlLTlkZmEtMDAxZDkyZjMwMmU1DQogICBNZWRpYXNpemU6 IDEwNzM3NDE4MjQgKDEuMEcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1v ZGU6IHIwdzBlMA0KICAgc2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAg IHNlY2xlbmd0aDogMjA5NzE1Mg0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQog ICBpbmRleDogMA0KQ29uc3VtZXJzOg0KMS4gTmFtZTogbWZpZDdwMw0KICAg TWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTog NTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBhZGEwcDENClBy b3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzM0MWJmNzQ5LTBkZDktMTFkZi1h NmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFzaXplOiAxMDMxMTY4ICgxLjBN KQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNl Y29mZnNldDogMA0KICAgb2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDIwMTQN CiAgIGxlbmd0aDogMTAzMTE2OA0KICAgaW5kZXg6IDANCkNvbnN1bWVyczoN CjEuIE5hbWU6IGFkYTBwMQ0KICAgTWVkaWFzaXplOiAxMDMxMTY4ICgxLjBN KQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0KR2Vv bSBuYW1lOiBhZGEwcDINClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzM0 NWEyNDU5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFz aXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQog ICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0KICAgb2Zmc2V0OiAw DQogICBzZWNsZW5ndGg6IDIwOTcxNTINCiAgIGxlbmd0aDogMTA3Mzc0MTgy NA0KICAgaW5kZXg6IDANCkNvbnN1bWVyczoNCjEuIE5hbWU6IGFkYTBwMg0K ICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6 ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBhZGExcDEN ClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzM3MTA2NGM5LTBkZDktMTFk Zi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFzaXplOiAxMDMxMTY4ICgx LjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAg IHNlY29mZnNldDogMA0KICAgb2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDIw MTQNCiAgIGxlbmd0aDogMTAzMTE2OA0KICAgaW5kZXg6IDANCkNvbnN1bWVy czoNCjEuIE5hbWU6IGFkYTFwMQ0KICAgTWVkaWFzaXplOiAxMDMxMTY4ICgx LjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0K R2VvbSBuYW1lOiBhZGExcDINClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlk LzM3MzY1YTAwLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVk aWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEy DQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0KICAgb2Zmc2V0 OiAwDQogICBzZWNsZW5ndGg6IDIwOTcxNTINCiAgIGxlbmd0aDogMTA3Mzc0 MTgyNA0KICAgaW5kZXg6IDANCkNvbnN1bWVyczoNCjEuIE5hbWU6IGFkYTFw Mg0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9y c2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBhZGEy cDENClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzM4Nzc5NWJhLTBkZDkt MTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFzaXplOiAxMDMxMTY4 ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTAN CiAgIHNlY29mZnNldDogMA0KICAgb2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6 IDIwMTQNCiAgIGxlbmd0aDogMTAzMTE2OA0KICAgaW5kZXg6IDANCkNvbnN1 bWVyczoNCjEuIE5hbWU6IGFkYTJwMQ0KICAgTWVkaWFzaXplOiAxMDMxMTY4 ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTAN Cg0KR2VvbSBuYW1lOiBhZGEycDINClByb3ZpZGVyczoNCjEuIE5hbWU6IGdw dGlkLzM4OWU5M2JiLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAg TWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTog NTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0KICAgb2Zm c2V0OiAwDQogICBzZWNsZW5ndGg6IDIwOTcxNTINCiAgIGxlbmd0aDogMTA3 Mzc0MTgyNA0KICAgaW5kZXg6IDANCkNvbnN1bWVyczoNCjEuIE5hbWU6IGFk YTJwMg0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2Vj dG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBh ZGEzcDENClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzM5ZDRlNzRmLTBk ZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFzaXplOiAxMDMx MTY4ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcw ZTANCiAgIHNlY29mZnNldDogMA0KICAgb2Zmc2V0OiAwDQogICBzZWNsZW5n dGg6IDIwMTQNCiAgIGxlbmd0aDogMTAzMTE2OA0KICAgaW5kZXg6IDANCkNv bnN1bWVyczoNCjEuIE5hbWU6IGFkYTNwMQ0KICAgTWVkaWFzaXplOiAxMDMx MTY4ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcw ZTANCg0KR2VvbSBuYW1lOiBhZGEzcDINClByb3ZpZGVyczoNCjEuIE5hbWU6 IGdwdGlkLzM5ZmVhMmQ5LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0K ICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6 ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0KICAg b2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDIwOTcxNTINCiAgIGxlbmd0aDog MTA3Mzc0MTgyNA0KICAgaW5kZXg6IDANCkNvbnN1bWVyczoNCjEuIE5hbWU6 IGFkYTNwMg0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAg U2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1l OiBhZGE0cDENClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzNiN2EzMGVl LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFzaXplOiAx MDMxMTY4ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiBy MHcwZTANCiAgIHNlY29mZnNldDogMA0KICAgb2Zmc2V0OiAwDQogICBzZWNs ZW5ndGg6IDIwMTQNCiAgIGxlbmd0aDogMTAzMTE2OA0KICAgaW5kZXg6IDAN CkNvbnN1bWVyczoNCjEuIE5hbWU6IGFkYTRwMQ0KICAgTWVkaWFzaXplOiAx MDMxMTY4ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiBy MHcwZTANCg0KR2VvbSBuYW1lOiBhZGE0cDINClByb3ZpZGVyczoNCjEuIE5h bWU6IGdwdGlkLzNiOWJiN2I2LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0 NA0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9y c2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDogMA0K ICAgb2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDIwOTcxNTINCiAgIGxlbmd0 aDogMTA3Mzc0MTgyNA0KICAgaW5kZXg6IDANCkNvbnN1bWVyczoNCjEuIE5h bWU6IGFkYTRwMg0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0K ICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBu YW1lOiBhZGE1cDENClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzNmNjJk MzA4LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFzaXpl OiAxMDMxMTY4ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2Rl OiByMHcwZTANCiAgIHNlY29mZnNldDogMA0KICAgb2Zmc2V0OiAwDQogICBz ZWNsZW5ndGg6IDIwMTQNCiAgIGxlbmd0aDogMTAzMTE2OA0KICAgaW5kZXg6 IDANCkNvbnN1bWVyczoNCjEuIE5hbWU6IGFkYTVwMQ0KICAgTWVkaWFzaXpl OiAxMDMxMTY4ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2Rl OiByMHcwZTANCg0KR2VvbSBuYW1lOiBhZGE1cDINClByb3ZpZGVyczoNCjEu IE5hbWU6IGdwdGlkLzNmOGFkNTZmLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFl MTk0NA0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2Vj dG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHNlY29mZnNldDog MA0KICAgb2Zmc2V0OiAwDQogICBzZWNsZW5ndGg6IDIwOTcxNTINCiAgIGxl bmd0aDogMTA3Mzc0MTgyNA0KICAgaW5kZXg6IDANCkNvbnN1bWVyczoNCjEu IE5hbWU6IGFkYTVwMg0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBH KQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0KR2Vv bSBuYW1lOiBhZGEwcDMNClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzM0 NzkzNWVhLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFz aXplOiA5OTkxMzAwNzg3MjAgKDkzMUcpDQogICBTZWN0b3JzaXplOiA1MTIN CiAgIE1vZGU6IHIwdzBlMA0KICAgc2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6 IDANCiAgIHNlY2xlbmd0aDogMTk1MTQyNTkzNQ0KICAgbGVuZ3RoOiA5OTkx MzAwNzg3MjANCiAgIGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBh ZGEwcDMNCiAgIE1lZGlhc2l6ZTogOTk5MTMwMDc4NzIwICg5MzFHKQ0KICAg U2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1l OiBhZGExcDMNClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzM3NGEzMWVk LTBkZDktMTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFzaXplOiA5 OTkxMzAwNzg3MjAgKDkzMUcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1v ZGU6IHIwdzBlMA0KICAgc2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAg IHNlY2xlbmd0aDogMTk1MTQyNTkzNQ0KICAgbGVuZ3RoOiA5OTkxMzAwNzg3 MjANCiAgIGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBhZGExcDMN CiAgIE1lZGlhc2l6ZTogOTk5MTMwMDc4NzIwICg5MzFHKQ0KICAgU2VjdG9y c2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBhZGEy cDMNClByb3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzM4YjI3OTlkLTBkZDkt MTFkZi1hNmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFzaXplOiA5OTkxMzAw Nzg3MjAgKDkzMUcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIw dzBlMA0KICAgc2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xl bmd0aDogMTk1MTQyNTkzNQ0KICAgbGVuZ3RoOiA5OTkxMzAwNzg3MjANCiAg IGluZGV4OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBhZGEycDMNCiAgIE1l ZGlhc2l6ZTogOTk5MTMwMDc4NzIwICg5MzFHKQ0KICAgU2VjdG9yc2l6ZTog NTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBhZGEzcDMNClBy b3ZpZGVyczoNCjEuIE5hbWU6IGdwdGlkLzNhMTQyN2EwLTBkZDktMTFkZi1h NmE0LTAwMzAxOGFlMTk0NA0KICAgTWVkaWFzaXplOiA5OTkxMzAwNzg3MjAg KDkzMUcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0K ICAgc2Vjb2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xlbmd0aDog MTk1MTQyNTkzNQ0KICAgbGVuZ3RoOiA5OTkxMzAwNzg3MjANCiAgIGluZGV4 OiAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBhZGEzcDMNCiAgIE1lZGlhc2l6 ZTogOTk5MTMwMDc4NzIwICg5MzFHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQog ICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBhZGE0cDMNClByb3ZpZGVy czoNCjEuIE5hbWU6IGdwdGlkLzNiYWUwNTg2LTBkZDktMTFkZi1hNmE0LTAw MzAxOGFlMTk0NA0KICAgTWVkaWFzaXplOiA5OTkxMzAwNzg3MjAgKDkzMUcp DQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KICAgc2Vj b2Zmc2V0OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xlbmd0aDogMTk1MTQy NTkzNQ0KICAgbGVuZ3RoOiA5OTkxMzAwNzg3MjANCiAgIGluZGV4OiAwDQpD b25zdW1lcnM6DQoxLiBOYW1lOiBhZGE0cDMNCiAgIE1lZGlhc2l6ZTogOTk5 MTMwMDc4NzIwICg5MzFHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2Rl OiByMHcwZTANCg0KR2VvbSBuYW1lOiBhZGE1cDMNClByb3ZpZGVyczoNCjEu IE5hbWU6IGdwdGlkLzNmOWQ4OWNhLTBkZDktMTFkZi1hNmE0LTAwMzAxOGFl MTk0NA0KICAgTWVkaWFzaXplOiA5OTkxMzAwNzg3MjAgKDkzMUcpDQogICBT ZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KICAgc2Vjb2Zmc2V0 OiAwDQogICBvZmZzZXQ6IDANCiAgIHNlY2xlbmd0aDogMTk1MTQyNTkzNQ0K ICAgbGVuZ3RoOiA5OTkxMzAwNzg3MjANCiAgIGluZGV4OiAwDQpDb25zdW1l cnM6DQoxLiBOYW1lOiBhZGE1cDMNCiAgIE1lZGlhc2l6ZTogOTk5MTMwMDc4 NzIwICg5MzFHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcw ZTANCg0K --0-1971476311-1264883505=:4627 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gpart.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=gpart.txt R2VvbSBuYW1lOiBtZmlkMA0KZndoZWFkczogMjU1DQpmd3NlY3RvcnM6IDYz DQpsYXN0OiAxOTUyNDQ4NDc4DQpmaXJzdDogMzQNCmVudHJpZXM6IDEyOA0K c2NoZW1lOiBHUFQNClByb3ZpZGVyczoNCjEuIE5hbWU6IG1maWQwcDENCiAg IE1lZGlhc2l6ZTogMjQ0NzM2ICgyMzlLKQ0KICAgU2VjdG9yc2l6ZTogNTEy DQogICBNb2RlOiByMHcwZTANCiAgIHJhd3R5cGU6IDgzYmQ2YjlkLTdmNDEt MTFkYy1iZTBiLTAwMTU2MGI4NGYwZg0KICAgbGFiZWw6IChudWxsKQ0KICAg bGVuZ3RoOiAyNDQ3MzYNCiAgIG9mZnNldDogMTc0MDgNCiAgIHR5cGU6IGZy ZWVic2QtYm9vdA0KICAgaW5kZXg6IDENCiAgIGVuZDogNTExDQogICBzdGFy dDogMzQNCjIuIE5hbWU6IG1maWQwcDINCiAgIE1lZGlhc2l6ZTogMTA3Mzc0 MTgyNCAoMS4wRykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjF3 MWUwDQogICByYXd0eXBlOiA1MTZlN2NiNS02ZWNmLTExZDYtOGZmOC0wMDAy MmQwOTcxMmINCiAgIGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDogMTA3Mzc0 MTgyNA0KICAgb2Zmc2V0OiAyNjIxNDQNCiAgIHR5cGU6IGZyZWVic2Qtc3dh cA0KICAgaW5kZXg6IDINCiAgIGVuZDogMjA5NzY2Mw0KICAgc3RhcnQ6IDUx Mg0KMy4gTmFtZTogbWZpZDBwMw0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0 ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTAN CiAgIHJhd3R5cGU6IDUxNmU3Y2JhLTZlY2YtMTFkNi04ZmY4LTAwMDIyZDA5 NzEyYg0KICAgbGFiZWw6IChudWxsKQ0KICAgbGVuZ3RoOiAxMDczNzQxODI0 DQogICBvZmZzZXQ6IDEwNzQwMDM5NjgNCiAgIHR5cGU6IGZyZWVic2QtemZz DQogICBpbmRleDogMw0KICAgZW5kOiA0MTk0ODE1DQogICBzdGFydDogMjA5 NzY2NA0KNC4gTmFtZTogbWZpZDBwNA0KICAgTWVkaWFzaXplOiA5OTc1MDU4 NzU0NTYgKDkyOUcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIx dzFlMQ0KICAgcmF3dHlwZTogNTE2ZTdjYmEtNmVjZi0xMWQ2LThmZjgtMDAw MjJkMDk3MTJiDQogICBsYWJlbDogKG51bGwpDQogICBsZW5ndGg6IDk5NzUw NTg3NTQ1Ng0KICAgb2Zmc2V0OiAyMTQ3NzQ1NzkyDQogICB0eXBlOiBmcmVl YnNkLXpmcw0KICAgaW5kZXg6IDQNCiAgIGVuZDogMTk1MjQ0ODQ3OA0KICAg c3RhcnQ6IDQxOTQ4MTYNCkNvbnN1bWVyczoNCjEuIE5hbWU6IG1maWQwDQog ICBNZWRpYXNpemU6IDk5OTY1MzYzODE0NCAoOTMxRykNCiAgIFNlY3RvcnNp emU6IDUxMg0KICAgTW9kZTogcjJ3MmUzDQoNCkdlb20gbmFtZTogbWZpZDEN CmZ3aGVhZHM6IDI1NQ0KZndzZWN0b3JzOiA2Mw0KbGFzdDogMTk1MjQ0ODQ3 OA0KZmlyc3Q6IDM0DQplbnRyaWVzOiAxMjgNCnNjaGVtZTogR1BUDQpQcm92 aWRlcnM6DQoxLiBOYW1lOiBtZmlkMXAxDQogICBNZWRpYXNpemU6IDI0NDcz NiAoMjM5SykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUw DQogICByYXd0eXBlOiA4M2JkNmI5ZC03ZjQxLTExZGMtYmUwYi0wMDE1NjBi ODRmMGYNCiAgIGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDogMjQ0NzM2DQog ICBvZmZzZXQ6IDE3NDA4DQogICB0eXBlOiBmcmVlYnNkLWJvb3QNCiAgIGlu ZGV4OiAxDQogICBlbmQ6IDUxMQ0KICAgc3RhcnQ6IDM0DQoyLiBOYW1lOiBt ZmlkMXAyDQogICBNZWRpYXNpemU6IDEwNzM3NDE4MjQgKDEuMEcpDQogICBT ZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIxdzFlMA0KICAgcmF3dHlwZTog NTE2ZTdjYjUtNmVjZi0xMWQ2LThmZjgtMDAwMjJkMDk3MTJiDQogICBsYWJl bDogKG51bGwpDQogICBsZW5ndGg6IDEwNzM3NDE4MjQNCiAgIG9mZnNldDog MjYyMTQ0DQogICB0eXBlOiBmcmVlYnNkLXN3YXANCiAgIGluZGV4OiAyDQog ICBlbmQ6IDIwOTc2NjMNCiAgIHN0YXJ0OiA1MTINCjMuIE5hbWU6IG1maWQx cDMNCiAgIE1lZGlhc2l6ZTogMTA3Mzc0MTgyNCAoMS4wRykNCiAgIFNlY3Rv cnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQogICByYXd0eXBlOiA1MTZl N2NiYS02ZWNmLTExZDYtOGZmOC0wMDAyMmQwOTcxMmINCiAgIGxhYmVsOiAo bnVsbCkNCiAgIGxlbmd0aDogMTA3Mzc0MTgyNA0KICAgb2Zmc2V0OiAxMDc0 MDAzOTY4DQogICB0eXBlOiBmcmVlYnNkLXpmcw0KICAgaW5kZXg6IDMNCiAg IGVuZDogNDE5NDgxNQ0KICAgc3RhcnQ6IDIwOTc2NjQNCjQuIE5hbWU6IG1m aWQxcDQNCiAgIE1lZGlhc2l6ZTogOTk3NTA1ODc1NDU2ICg5MjlHKQ0KICAg U2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMXcxZTENCiAgIHJhd3R5cGU6 IDUxNmU3Y2JhLTZlY2YtMTFkNi04ZmY4LTAwMDIyZDA5NzEyYg0KICAgbGFi ZWw6IChudWxsKQ0KICAgbGVuZ3RoOiA5OTc1MDU4NzU0NTYNCiAgIG9mZnNl dDogMjE0Nzc0NTc5Mg0KICAgdHlwZTogZnJlZWJzZC16ZnMNCiAgIGluZGV4 OiA0DQogICBlbmQ6IDE5NTI0NDg0NzgNCiAgIHN0YXJ0OiA0MTk0ODE2DQpD b25zdW1lcnM6DQoxLiBOYW1lOiBtZmlkMQ0KICAgTWVkaWFzaXplOiA5OTk2 NTM2MzgxNDQgKDkzMUcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6 IHIydzJlMw0KDQpHZW9tIG5hbWU6IG1maWQyDQpmd2hlYWRzOiAyNTUNCmZ3 c2VjdG9yczogNjMNCmxhc3Q6IDE5NTI0NDg0NzgNCmZpcnN0OiAzNA0KZW50 cmllczogMTI4DQpzY2hlbWU6IEdQVA0KUHJvdmlkZXJzOg0KMS4gTmFtZTog bWZpZDJwMQ0KICAgTWVkaWFzaXplOiAyNDQ3MzYgKDIzOUspDQogICBTZWN0 b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KICAgcmF3dHlwZTogODNi ZDZiOWQtN2Y0MS0xMWRjLWJlMGItMDAxNTYwYjg0ZjBmDQogICBsYWJlbDog KG51bGwpDQogICBsZW5ndGg6IDI0NDczNg0KICAgb2Zmc2V0OiAxNzQwOA0K ICAgdHlwZTogZnJlZWJzZC1ib290DQogICBpbmRleDogMQ0KICAgZW5kOiA1 MTENCiAgIHN0YXJ0OiAzNA0KMi4gTmFtZTogbWZpZDJwMg0KICAgTWVkaWFz aXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQog ICBNb2RlOiByMXcxZTANCiAgIHJhd3R5cGU6IDUxNmU3Y2I1LTZlY2YtMTFk Ni04ZmY4LTAwMDIyZDA5NzEyYg0KICAgbGFiZWw6IChudWxsKQ0KICAgbGVu Z3RoOiAxMDczNzQxODI0DQogICBvZmZzZXQ6IDI2MjE0NA0KICAgdHlwZTog ZnJlZWJzZC1zd2FwDQogICBpbmRleDogMg0KICAgZW5kOiAyMDk3NjYzDQog ICBzdGFydDogNTEyDQozLiBOYW1lOiBtZmlkMnAzDQogICBNZWRpYXNpemU6 IDEwNzM3NDE4MjQgKDEuMEcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1v ZGU6IHIwdzBlMA0KICAgcmF3dHlwZTogNTE2ZTdjYmEtNmVjZi0xMWQ2LThm ZjgtMDAwMjJkMDk3MTJiDQogICBsYWJlbDogKG51bGwpDQogICBsZW5ndGg6 IDEwNzM3NDE4MjQNCiAgIG9mZnNldDogMTA3NDAwMzk2OA0KICAgdHlwZTog ZnJlZWJzZC16ZnMNCiAgIGluZGV4OiAzDQogICBlbmQ6IDQxOTQ4MTUNCiAg IHN0YXJ0OiAyMDk3NjY0DQo0LiBOYW1lOiBtZmlkMnA0DQogICBNZWRpYXNp emU6IDk5NzUwNTg3NTQ1NiAoOTI5RykNCiAgIFNlY3RvcnNpemU6IDUxMg0K ICAgTW9kZTogcjF3MWUxDQogICByYXd0eXBlOiA1MTZlN2NiYS02ZWNmLTEx ZDYtOGZmOC0wMDAyMmQwOTcxMmINCiAgIGxhYmVsOiAobnVsbCkNCiAgIGxl bmd0aDogOTk3NTA1ODc1NDU2DQogICBvZmZzZXQ6IDIxNDc3NDU3OTINCiAg IHR5cGU6IGZyZWVic2QtemZzDQogICBpbmRleDogNA0KICAgZW5kOiAxOTUy NDQ4NDc4DQogICBzdGFydDogNDE5NDgxNg0KQ29uc3VtZXJzOg0KMS4gTmFt ZTogbWZpZDINCiAgIE1lZGlhc2l6ZTogOTk5NjUzNjM4MTQ0ICg5MzFHKQ0K ICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMncyZTMNCg0KR2VvbSBu YW1lOiBtZmlkMw0KZndoZWFkczogMjU1DQpmd3NlY3RvcnM6IDYzDQpsYXN0 OiAxOTUyNDQ4NDc4DQpmaXJzdDogMzQNCmVudHJpZXM6IDEyOA0Kc2NoZW1l OiBHUFQNClByb3ZpZGVyczoNCjEuIE5hbWU6IG1maWQzcDENCiAgIE1lZGlh c2l6ZTogMjQ0NzM2ICgyMzlLKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBN b2RlOiByMHcwZTANCiAgIHJhd3R5cGU6IDgzYmQ2YjlkLTdmNDEtMTFkYy1i ZTBiLTAwMTU2MGI4NGYwZg0KICAgbGFiZWw6IChudWxsKQ0KICAgbGVuZ3Ro OiAyNDQ3MzYNCiAgIG9mZnNldDogMTc0MDgNCiAgIHR5cGU6IGZyZWVic2Qt Ym9vdA0KICAgaW5kZXg6IDENCiAgIGVuZDogNTExDQogICBzdGFydDogMzQN CjIuIE5hbWU6IG1maWQzcDINCiAgIE1lZGlhc2l6ZTogMTA3Mzc0MTgyNCAo MS4wRykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjF3MWUwDQog ICByYXd0eXBlOiA1MTZlN2NiNS02ZWNmLTExZDYtOGZmOC0wMDAyMmQwOTcx MmINCiAgIGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDogMTA3Mzc0MTgyNA0K ICAgb2Zmc2V0OiAyNjIxNDQNCiAgIHR5cGU6IGZyZWVic2Qtc3dhcA0KICAg aW5kZXg6IDINCiAgIGVuZDogMjA5NzY2Mw0KICAgc3RhcnQ6IDUxMg0KMy4g TmFtZTogbWZpZDNwMw0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBH KQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHJh d3R5cGU6IDUxNmU3Y2JhLTZlY2YtMTFkNi04ZmY4LTAwMDIyZDA5NzEyYg0K ICAgbGFiZWw6IChudWxsKQ0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBv ZmZzZXQ6IDEwNzQwMDM5NjgNCiAgIHR5cGU6IGZyZWVic2QtemZzDQogICBp bmRleDogMw0KICAgZW5kOiA0MTk0ODE1DQogICBzdGFydDogMjA5NzY2NA0K NC4gTmFtZTogbWZpZDNwNA0KICAgTWVkaWFzaXplOiA5OTc1MDU4NzU0NTYg KDkyOUcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIxdzFlMQ0K ICAgcmF3dHlwZTogNTE2ZTdjYmEtNmVjZi0xMWQ2LThmZjgtMDAwMjJkMDk3 MTJiDQogICBsYWJlbDogKG51bGwpDQogICBsZW5ndGg6IDk5NzUwNTg3NTQ1 Ng0KICAgb2Zmc2V0OiAyMTQ3NzQ1NzkyDQogICB0eXBlOiBmcmVlYnNkLXpm cw0KICAgaW5kZXg6IDQNCiAgIGVuZDogMTk1MjQ0ODQ3OA0KICAgc3RhcnQ6 IDQxOTQ4MTYNCkNvbnN1bWVyczoNCjEuIE5hbWU6IG1maWQzDQogICBNZWRp YXNpemU6IDk5OTY1MzYzODE0NCAoOTMxRykNCiAgIFNlY3RvcnNpemU6IDUx Mg0KICAgTW9kZTogcjJ3MmUzDQoNCkdlb20gbmFtZTogbWZpZDQNCmZ3aGVh ZHM6IDI1NQ0KZndzZWN0b3JzOiA2Mw0KbGFzdDogMTk1MjQ0ODQ3OA0KZmly c3Q6IDM0DQplbnRyaWVzOiAxMjgNCnNjaGVtZTogR1BUDQpQcm92aWRlcnM6 DQoxLiBOYW1lOiBtZmlkNHAxDQogICBNZWRpYXNpemU6IDI0NDczNiAoMjM5 SykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQogICBy YXd0eXBlOiA4M2JkNmI5ZC03ZjQxLTExZGMtYmUwYi0wMDE1NjBiODRmMGYN CiAgIGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDogMjQ0NzM2DQogICBvZmZz ZXQ6IDE3NDA4DQogICB0eXBlOiBmcmVlYnNkLWJvb3QNCiAgIGluZGV4OiAx DQogICBlbmQ6IDUxMQ0KICAgc3RhcnQ6IDM0DQoyLiBOYW1lOiBtZmlkNHAy DQogICBNZWRpYXNpemU6IDEwNzM3NDE4MjQgKDEuMEcpDQogICBTZWN0b3Jz aXplOiA1MTINCiAgIE1vZGU6IHIxdzFlMA0KICAgcmF3dHlwZTogNTE2ZTdj YjUtNmVjZi0xMWQ2LThmZjgtMDAwMjJkMDk3MTJiDQogICBsYWJlbDogKG51 bGwpDQogICBsZW5ndGg6IDEwNzM3NDE4MjQNCiAgIG9mZnNldDogMjYyMTQ0 DQogICB0eXBlOiBmcmVlYnNkLXN3YXANCiAgIGluZGV4OiAyDQogICBlbmQ6 IDIwOTc2NjMNCiAgIHN0YXJ0OiA1MTINCjMuIE5hbWU6IG1maWQ0cDMNCiAg IE1lZGlhc2l6ZTogMTA3Mzc0MTgyNCAoMS4wRykNCiAgIFNlY3RvcnNpemU6 IDUxMg0KICAgTW9kZTogcjB3MGUwDQogICByYXd0eXBlOiA1MTZlN2NiYS02 ZWNmLTExZDYtOGZmOC0wMDAyMmQwOTcxMmINCiAgIGxhYmVsOiAobnVsbCkN CiAgIGxlbmd0aDogMTA3Mzc0MTgyNA0KICAgb2Zmc2V0OiAxMDc0MDAzOTY4 DQogICB0eXBlOiBmcmVlYnNkLXpmcw0KICAgaW5kZXg6IDMNCiAgIGVuZDog NDE5NDgxNQ0KICAgc3RhcnQ6IDIwOTc2NjQNCjQuIE5hbWU6IG1maWQ0cDQN CiAgIE1lZGlhc2l6ZTogOTk3NTA1ODc1NDU2ICg5MjlHKQ0KICAgU2VjdG9y c2l6ZTogNTEyDQogICBNb2RlOiByMXcxZTENCiAgIHJhd3R5cGU6IDUxNmU3 Y2JhLTZlY2YtMTFkNi04ZmY4LTAwMDIyZDA5NzEyYg0KICAgbGFiZWw6IChu dWxsKQ0KICAgbGVuZ3RoOiA5OTc1MDU4NzU0NTYNCiAgIG9mZnNldDogMjE0 Nzc0NTc5Mg0KICAgdHlwZTogZnJlZWJzZC16ZnMNCiAgIGluZGV4OiA0DQog ICBlbmQ6IDE5NTI0NDg0NzgNCiAgIHN0YXJ0OiA0MTk0ODE2DQpDb25zdW1l cnM6DQoxLiBOYW1lOiBtZmlkNA0KICAgTWVkaWFzaXplOiA5OTk2NTM2Mzgx NDQgKDkzMUcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIydzJl Mw0KDQpHZW9tIG5hbWU6IG1maWQ1DQpmd2hlYWRzOiAyNTUNCmZ3c2VjdG9y czogNjMNCmxhc3Q6IDE5NTI0NDg0NzgNCmZpcnN0OiAzNA0KZW50cmllczog MTI4DQpzY2hlbWU6IEdQVA0KUHJvdmlkZXJzOg0KMS4gTmFtZTogbWZpZDVw MQ0KICAgTWVkaWFzaXplOiAyNDQ3MzYgKDIzOUspDQogICBTZWN0b3JzaXpl OiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KICAgcmF3dHlwZTogODNiZDZiOWQt N2Y0MS0xMWRjLWJlMGItMDAxNTYwYjg0ZjBmDQogICBsYWJlbDogKG51bGwp DQogICBsZW5ndGg6IDI0NDczNg0KICAgb2Zmc2V0OiAxNzQwOA0KICAgdHlw ZTogZnJlZWJzZC1ib290DQogICBpbmRleDogMQ0KICAgZW5kOiA1MTENCiAg IHN0YXJ0OiAzNA0KMi4gTmFtZTogbWZpZDVwMg0KICAgTWVkaWFzaXplOiAx MDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2Rl OiByMXcxZTANCiAgIHJhd3R5cGU6IDUxNmU3Y2I1LTZlY2YtMTFkNi04ZmY4 LTAwMDIyZDA5NzEyYg0KICAgbGFiZWw6IChudWxsKQ0KICAgbGVuZ3RoOiAx MDczNzQxODI0DQogICBvZmZzZXQ6IDI2MjE0NA0KICAgdHlwZTogZnJlZWJz ZC1zd2FwDQogICBpbmRleDogMg0KICAgZW5kOiAyMDk3NjYzDQogICBzdGFy dDogNTEyDQozLiBOYW1lOiBtZmlkNXAzDQogICBNZWRpYXNpemU6IDEwNzM3 NDE4MjQgKDEuMEcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIw dzBlMA0KICAgcmF3dHlwZTogNTE2ZTdjYmEtNmVjZi0xMWQ2LThmZjgtMDAw MjJkMDk3MTJiDQogICBsYWJlbDogKG51bGwpDQogICBsZW5ndGg6IDEwNzM3 NDE4MjQNCiAgIG9mZnNldDogMTA3NDAwMzk2OA0KICAgdHlwZTogZnJlZWJz ZC16ZnMNCiAgIGluZGV4OiAzDQogICBlbmQ6IDQxOTQ4MTUNCiAgIHN0YXJ0 OiAyMDk3NjY0DQo0LiBOYW1lOiBtZmlkNXA0DQogICBNZWRpYXNpemU6IDk5 NzUwNTg3NTQ1NiAoOTI5RykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9k ZTogcjF3MWUxDQogICByYXd0eXBlOiA1MTZlN2NiYS02ZWNmLTExZDYtOGZm OC0wMDAyMmQwOTcxMmINCiAgIGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDog OTk3NTA1ODc1NDU2DQogICBvZmZzZXQ6IDIxNDc3NDU3OTINCiAgIHR5cGU6 IGZyZWVic2QtemZzDQogICBpbmRleDogNA0KICAgZW5kOiAxOTUyNDQ4NDc4 DQogICBzdGFydDogNDE5NDgxNg0KQ29uc3VtZXJzOg0KMS4gTmFtZTogbWZp ZDUNCiAgIE1lZGlhc2l6ZTogOTk5NjUzNjM4MTQ0ICg5MzFHKQ0KICAgU2Vj dG9yc2l6ZTogNTEyDQogICBNb2RlOiByMncyZTMNCg0KR2VvbSBuYW1lOiBt ZmlkNg0KZndoZWFkczogMjU1DQpmd3NlY3RvcnM6IDYzDQpsYXN0OiAxOTUy NDQ4NDc4DQpmaXJzdDogMzQNCmVudHJpZXM6IDEyOA0Kc2NoZW1lOiBHUFQN ClByb3ZpZGVyczoNCjEuIE5hbWU6IG1maWQ2cDENCiAgIE1lZGlhc2l6ZTog MjQ0NzM2ICgyMzlLKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiBy MHcwZTANCiAgIHJhd3R5cGU6IDgzYmQ2YjlkLTdmNDEtMTFkYy1iZTBiLTAw MTU2MGI4NGYwZg0KICAgbGFiZWw6IChudWxsKQ0KICAgbGVuZ3RoOiAyNDQ3 MzYNCiAgIG9mZnNldDogMTc0MDgNCiAgIHR5cGU6IGZyZWVic2QtYm9vdA0K ICAgaW5kZXg6IDENCiAgIGVuZDogNTExDQogICBzdGFydDogMzQNCjIuIE5h bWU6IG1maWQ2cDINCiAgIE1lZGlhc2l6ZTogMTA3Mzc0MTgyNCAoMS4wRykN CiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjF3MWUwDQogICByYXd0 eXBlOiA1MTZlN2NiNS02ZWNmLTExZDYtOGZmOC0wMDAyMmQwOTcxMmINCiAg IGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDogMTA3Mzc0MTgyNA0KICAgb2Zm c2V0OiAyNjIxNDQNCiAgIHR5cGU6IGZyZWVic2Qtc3dhcA0KICAgaW5kZXg6 IDINCiAgIGVuZDogMjA5NzY2Mw0KICAgc3RhcnQ6IDUxMg0KMy4gTmFtZTog bWZpZDZwMw0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAg U2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHJhd3R5cGU6 IDUxNmU3Y2JhLTZlY2YtMTFkNi04ZmY4LTAwMDIyZDA5NzEyYg0KICAgbGFi ZWw6IChudWxsKQ0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBvZmZzZXQ6 IDEwNzQwMDM5NjgNCiAgIHR5cGU6IGZyZWVic2QtemZzDQogICBpbmRleDog Mw0KICAgZW5kOiA0MTk0ODE1DQogICBzdGFydDogMjA5NzY2NA0KNC4gTmFt ZTogbWZpZDZwNA0KICAgTWVkaWFzaXplOiA5OTc1MDU4NzU0NTYgKDkyOUcp DQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIxdzFlMQ0KICAgcmF3 dHlwZTogNTE2ZTdjYmEtNmVjZi0xMWQ2LThmZjgtMDAwMjJkMDk3MTJiDQog ICBsYWJlbDogKG51bGwpDQogICBsZW5ndGg6IDk5NzUwNTg3NTQ1Ng0KICAg b2Zmc2V0OiAyMTQ3NzQ1NzkyDQogICB0eXBlOiBmcmVlYnNkLXpmcw0KICAg aW5kZXg6IDQNCiAgIGVuZDogMTk1MjQ0ODQ3OA0KICAgc3RhcnQ6IDQxOTQ4 MTYNCkNvbnN1bWVyczoNCjEuIE5hbWU6IG1maWQ2DQogICBNZWRpYXNpemU6 IDk5OTY1MzYzODE0NCAoOTMxRykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAg TW9kZTogcjJ3MmUzDQoNCkdlb20gbmFtZTogbWZpZDcNCmZ3aGVhZHM6IDI1 NQ0KZndzZWN0b3JzOiA2Mw0KbGFzdDogMTk1MjQ0ODQ3OA0KZmlyc3Q6IDM0 DQplbnRyaWVzOiAxMjgNCnNjaGVtZTogR1BUDQpQcm92aWRlcnM6DQoxLiBO YW1lOiBtZmlkN3AxDQogICBNZWRpYXNpemU6IDI0NDczNiAoMjM5SykNCiAg IFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQogICByYXd0eXBl OiA4M2JkNmI5ZC03ZjQxLTExZGMtYmUwYi0wMDE1NjBiODRmMGYNCiAgIGxh YmVsOiAobnVsbCkNCiAgIGxlbmd0aDogMjQ0NzM2DQogICBvZmZzZXQ6IDE3 NDA4DQogICB0eXBlOiBmcmVlYnNkLWJvb3QNCiAgIGluZGV4OiAxDQogICBl bmQ6IDUxMQ0KICAgc3RhcnQ6IDM0DQoyLiBOYW1lOiBtZmlkN3AyDQogICBN ZWRpYXNpemU6IDEwNzM3NDE4MjQgKDEuMEcpDQogICBTZWN0b3JzaXplOiA1 MTINCiAgIE1vZGU6IHIxdzFlMA0KICAgcmF3dHlwZTogNTE2ZTdjYjUtNmVj Zi0xMWQ2LThmZjgtMDAwMjJkMDk3MTJiDQogICBsYWJlbDogKG51bGwpDQog ICBsZW5ndGg6IDEwNzM3NDE4MjQNCiAgIG9mZnNldDogMjYyMTQ0DQogICB0 eXBlOiBmcmVlYnNkLXN3YXANCiAgIGluZGV4OiAyDQogICBlbmQ6IDIwOTc2 NjMNCiAgIHN0YXJ0OiA1MTINCjMuIE5hbWU6IG1maWQ3cDMNCiAgIE1lZGlh c2l6ZTogMTA3Mzc0MTgyNCAoMS4wRykNCiAgIFNlY3RvcnNpemU6IDUxMg0K ICAgTW9kZTogcjB3MGUwDQogICByYXd0eXBlOiA1MTZlN2NiYS02ZWNmLTEx ZDYtOGZmOC0wMDAyMmQwOTcxMmINCiAgIGxhYmVsOiAobnVsbCkNCiAgIGxl bmd0aDogMTA3Mzc0MTgyNA0KICAgb2Zmc2V0OiAxMDc0MDAzOTY4DQogICB0 eXBlOiBmcmVlYnNkLXpmcw0KICAgaW5kZXg6IDMNCiAgIGVuZDogNDE5NDgx NQ0KICAgc3RhcnQ6IDIwOTc2NjQNCjQuIE5hbWU6IG1maWQ3cDQNCiAgIE1l ZGlhc2l6ZTogOTk3NTA1ODc1NDU2ICg5MjlHKQ0KICAgU2VjdG9yc2l6ZTog NTEyDQogICBNb2RlOiByMXcxZTENCiAgIHJhd3R5cGU6IDUxNmU3Y2JhLTZl Y2YtMTFkNi04ZmY4LTAwMDIyZDA5NzEyYg0KICAgbGFiZWw6IChudWxsKQ0K ICAgbGVuZ3RoOiA5OTc1MDU4NzU0NTYNCiAgIG9mZnNldDogMjE0Nzc0NTc5 Mg0KICAgdHlwZTogZnJlZWJzZC16ZnMNCiAgIGluZGV4OiA0DQogICBlbmQ6 IDE5NTI0NDg0NzgNCiAgIHN0YXJ0OiA0MTk0ODE2DQpDb25zdW1lcnM6DQox LiBOYW1lOiBtZmlkNw0KICAgTWVkaWFzaXplOiA5OTk2NTM2MzgxNDQgKDkz MUcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIydzJlMw0KDQpH ZW9tIG5hbWU6IGFkYTANCmZ3aGVhZHM6IDE2DQpmd3NlY3RvcnM6IDYzDQps YXN0OiAxOTUzNTI1MTM0DQpmaXJzdDogMzQNCmVudHJpZXM6IDEyOA0Kc2No ZW1lOiBHUFQNClByb3ZpZGVyczoNCjEuIE5hbWU6IGFkYTBwMQ0KICAgTWVk aWFzaXplOiAxMDMxMTY4ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQog ICBNb2RlOiByMHcwZTANCiAgIHJhd3R5cGU6IDgzYmQ2YjlkLTdmNDEtMTFk Yy1iZTBiLTAwMTU2MGI4NGYwZg0KICAgbGFiZWw6IChudWxsKQ0KICAgbGVu Z3RoOiAxMDMxMTY4DQogICBvZmZzZXQ6IDE3NDA4DQogICB0eXBlOiBmcmVl YnNkLWJvb3QNCiAgIGluZGV4OiAxDQogICBlbmQ6IDIwNDcNCiAgIHN0YXJ0 OiAzNA0KMi4gTmFtZTogYWRhMHAyDQogICBNZWRpYXNpemU6IDEwNzM3NDE4 MjQgKDEuMEcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBl MA0KICAgcmF3dHlwZTogNTE2ZTdjYjUtNmVjZi0xMWQ2LThmZjgtMDAwMjJk MDk3MTJiDQogICBsYWJlbDogKG51bGwpDQogICBsZW5ndGg6IDEwNzM3NDE4 MjQNCiAgIG9mZnNldDogMTA0ODU3Ng0KICAgdHlwZTogZnJlZWJzZC1zd2Fw DQogICBpbmRleDogMg0KICAgZW5kOiAyMDk5MTk5DQogICBzdGFydDogMjA0 OA0KMy4gTmFtZTogYWRhMHAzDQogICBNZWRpYXNpemU6IDk5OTEzMDA3ODcy MCAoOTMxRykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUw DQogICByYXd0eXBlOiA1MTZlN2NiYS02ZWNmLTExZDYtOGZmOC0wMDAyMmQw OTcxMmINCiAgIGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDogOTk5MTMwMDc4 NzIwDQogICBvZmZzZXQ6IDEwNzQ3OTA0MDANCiAgIHR5cGU6IGZyZWVic2Qt emZzDQogICBpbmRleDogMw0KICAgZW5kOiAxOTUzNTI1MTM0DQogICBzdGFy dDogMjA5OTIwMA0KQ29uc3VtZXJzOg0KMS4gTmFtZTogYWRhMA0KICAgTWVk aWFzaXplOiAxMDAwMjA0ODg2MDE2ICg5MzJHKQ0KICAgU2VjdG9yc2l6ZTog NTEyDQogICBNb2RlOiByMHcwZTANCg0KR2VvbSBuYW1lOiBhZGExDQpmd2hl YWRzOiAxNg0KZndzZWN0b3JzOiA2Mw0KbGFzdDogMTk1MzUyNTEzNA0KZmly c3Q6IDM0DQplbnRyaWVzOiAxMjgNCnNjaGVtZTogR1BUDQpQcm92aWRlcnM6 DQoxLiBOYW1lOiBhZGExcDENCiAgIE1lZGlhc2l6ZTogMTAzMTE2OCAoMS4w TSkNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQogICBy YXd0eXBlOiA4M2JkNmI5ZC03ZjQxLTExZGMtYmUwYi0wMDE1NjBiODRmMGYN CiAgIGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDogMTAzMTE2OA0KICAgb2Zm c2V0OiAxNzQwOA0KICAgdHlwZTogZnJlZWJzZC1ib290DQogICBpbmRleDog MQ0KICAgZW5kOiAyMDQ3DQogICBzdGFydDogMzQNCjIuIE5hbWU6IGFkYTFw Mg0KICAgTWVkaWFzaXplOiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9y c2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHJhd3R5cGU6IDUxNmU3 Y2I1LTZlY2YtMTFkNi04ZmY4LTAwMDIyZDA5NzEyYg0KICAgbGFiZWw6IChu dWxsKQ0KICAgbGVuZ3RoOiAxMDczNzQxODI0DQogICBvZmZzZXQ6IDEwNDg1 NzYNCiAgIHR5cGU6IGZyZWVic2Qtc3dhcA0KICAgaW5kZXg6IDINCiAgIGVu ZDogMjA5OTE5OQ0KICAgc3RhcnQ6IDIwNDgNCjMuIE5hbWU6IGFkYTFwMw0K ICAgTWVkaWFzaXplOiA5OTkxMzAwNzg3MjAgKDkzMUcpDQogICBTZWN0b3Jz aXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KICAgcmF3dHlwZTogNTE2ZTdj YmEtNmVjZi0xMWQ2LThmZjgtMDAwMjJkMDk3MTJiDQogICBsYWJlbDogKG51 bGwpDQogICBsZW5ndGg6IDk5OTEzMDA3ODcyMA0KICAgb2Zmc2V0OiAxMDc0 NzkwNDAwDQogICB0eXBlOiBmcmVlYnNkLXpmcw0KICAgaW5kZXg6IDMNCiAg IGVuZDogMTk1MzUyNTEzNA0KICAgc3RhcnQ6IDIwOTkyMDANCkNvbnN1bWVy czoNCjEuIE5hbWU6IGFkYTENCiAgIE1lZGlhc2l6ZTogMTAwMDIwNDg4NjAx NiAoOTMyRykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUw DQoNCkdlb20gbmFtZTogYWRhMg0KZndoZWFkczogMTYNCmZ3c2VjdG9yczog NjMNCmxhc3Q6IDE5NTM1MjUxMzQNCmZpcnN0OiAzNA0KZW50cmllczogMTI4 DQpzY2hlbWU6IEdQVA0KUHJvdmlkZXJzOg0KMS4gTmFtZTogYWRhMnAxDQog ICBNZWRpYXNpemU6IDEwMzExNjggKDEuME0pDQogICBTZWN0b3JzaXplOiA1 MTINCiAgIE1vZGU6IHIwdzBlMA0KICAgcmF3dHlwZTogODNiZDZiOWQtN2Y0 MS0xMWRjLWJlMGItMDAxNTYwYjg0ZjBmDQogICBsYWJlbDogKG51bGwpDQog ICBsZW5ndGg6IDEwMzExNjgNCiAgIG9mZnNldDogMTc0MDgNCiAgIHR5cGU6 IGZyZWVic2QtYm9vdA0KICAgaW5kZXg6IDENCiAgIGVuZDogMjA0Nw0KICAg c3RhcnQ6IDM0DQoyLiBOYW1lOiBhZGEycDINCiAgIE1lZGlhc2l6ZTogMTA3 Mzc0MTgyNCAoMS4wRykNCiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTog cjB3MGUwDQogICByYXd0eXBlOiA1MTZlN2NiNS02ZWNmLTExZDYtOGZmOC0w MDAyMmQwOTcxMmINCiAgIGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDogMTA3 Mzc0MTgyNA0KICAgb2Zmc2V0OiAxMDQ4NTc2DQogICB0eXBlOiBmcmVlYnNk LXN3YXANCiAgIGluZGV4OiAyDQogICBlbmQ6IDIwOTkxOTkNCiAgIHN0YXJ0 OiAyMDQ4DQozLiBOYW1lOiBhZGEycDMNCiAgIE1lZGlhc2l6ZTogOTk5MTMw MDc4NzIwICg5MzFHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiBy MHcwZTANCiAgIHJhd3R5cGU6IDUxNmU3Y2JhLTZlY2YtMTFkNi04ZmY4LTAw MDIyZDA5NzEyYg0KICAgbGFiZWw6IChudWxsKQ0KICAgbGVuZ3RoOiA5OTkx MzAwNzg3MjANCiAgIG9mZnNldDogMTA3NDc5MDQwMA0KICAgdHlwZTogZnJl ZWJzZC16ZnMNCiAgIGluZGV4OiAzDQogICBlbmQ6IDE5NTM1MjUxMzQNCiAg IHN0YXJ0OiAyMDk5MjAwDQpDb25zdW1lcnM6DQoxLiBOYW1lOiBhZGEyDQog ICBNZWRpYXNpemU6IDEwMDAyMDQ4ODYwMTYgKDkzMkcpDQogICBTZWN0b3Jz aXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KDQpHZW9tIG5hbWU6IGFkYTMN CmZ3aGVhZHM6IDE2DQpmd3NlY3RvcnM6IDYzDQpsYXN0OiAxOTUzNTI1MTM0 DQpmaXJzdDogMzQNCmVudHJpZXM6IDEyOA0Kc2NoZW1lOiBHUFQNClByb3Zp ZGVyczoNCjEuIE5hbWU6IGFkYTNwMQ0KICAgTWVkaWFzaXplOiAxMDMxMTY4 ICgxLjBNKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTAN CiAgIHJhd3R5cGU6IDgzYmQ2YjlkLTdmNDEtMTFkYy1iZTBiLTAwMTU2MGI4 NGYwZg0KICAgbGFiZWw6IChudWxsKQ0KICAgbGVuZ3RoOiAxMDMxMTY4DQog ICBvZmZzZXQ6IDE3NDA4DQogICB0eXBlOiBmcmVlYnNkLWJvb3QNCiAgIGlu ZGV4OiAxDQogICBlbmQ6IDIwNDcNCiAgIHN0YXJ0OiAzNA0KMi4gTmFtZTog YWRhM3AyDQogICBNZWRpYXNpemU6IDEwNzM3NDE4MjQgKDEuMEcpDQogICBT ZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIwdzBlMA0KICAgcmF3dHlwZTog NTE2ZTdjYjUtNmVjZi0xMWQ2LThmZjgtMDAwMjJkMDk3MTJiDQogICBsYWJl bDogKG51bGwpDQogICBsZW5ndGg6IDEwNzM3NDE4MjQNCiAgIG9mZnNldDog MTA0ODU3Ng0KICAgdHlwZTogZnJlZWJzZC1zd2FwDQogICBpbmRleDogMg0K ICAgZW5kOiAyMDk5MTk5DQogICBzdGFydDogMjA0OA0KMy4gTmFtZTogYWRh M3AzDQogICBNZWRpYXNpemU6IDk5OTEzMDA3ODcyMCAoOTMxRykNCiAgIFNl Y3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQogICByYXd0eXBlOiA1 MTZlN2NiYS02ZWNmLTExZDYtOGZmOC0wMDAyMmQwOTcxMmINCiAgIGxhYmVs OiAobnVsbCkNCiAgIGxlbmd0aDogOTk5MTMwMDc4NzIwDQogICBvZmZzZXQ6 IDEwNzQ3OTA0MDANCiAgIHR5cGU6IGZyZWVic2QtemZzDQogICBpbmRleDog Mw0KICAgZW5kOiAxOTUzNTI1MTM0DQogICBzdGFydDogMjA5OTIwMA0KQ29u c3VtZXJzOg0KMS4gTmFtZTogYWRhMw0KICAgTWVkaWFzaXplOiAxMDAwMjA0 ODg2MDE2ICg5MzJHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiBy MHcwZTANCg0KR2VvbSBuYW1lOiBhZGE0DQpmd2hlYWRzOiAxNg0KZndzZWN0 b3JzOiA2Mw0KbGFzdDogMTk1MzUyNTEzNA0KZmlyc3Q6IDM0DQplbnRyaWVz OiAxMjgNCnNjaGVtZTogR1BUDQpQcm92aWRlcnM6DQoxLiBOYW1lOiBhZGE0 cDENCiAgIE1lZGlhc2l6ZTogMTAzMTE2OCAoMS4wTSkNCiAgIFNlY3RvcnNp emU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQogICByYXd0eXBlOiA4M2JkNmI5 ZC03ZjQxLTExZGMtYmUwYi0wMDE1NjBiODRmMGYNCiAgIGxhYmVsOiAobnVs bCkNCiAgIGxlbmd0aDogMTAzMTE2OA0KICAgb2Zmc2V0OiAxNzQwOA0KICAg dHlwZTogZnJlZWJzZC1ib290DQogICBpbmRleDogMQ0KICAgZW5kOiAyMDQ3 DQogICBzdGFydDogMzQNCjIuIE5hbWU6IGFkYTRwMg0KICAgTWVkaWFzaXpl OiAxMDczNzQxODI0ICgxLjBHKQ0KICAgU2VjdG9yc2l6ZTogNTEyDQogICBN b2RlOiByMHcwZTANCiAgIHJhd3R5cGU6IDUxNmU3Y2I1LTZlY2YtMTFkNi04 ZmY4LTAwMDIyZDA5NzEyYg0KICAgbGFiZWw6IChudWxsKQ0KICAgbGVuZ3Ro OiAxMDczNzQxODI0DQogICBvZmZzZXQ6IDEwNDg1NzYNCiAgIHR5cGU6IGZy ZWVic2Qtc3dhcA0KICAgaW5kZXg6IDINCiAgIGVuZDogMjA5OTE5OQ0KICAg c3RhcnQ6IDIwNDgNCjMuIE5hbWU6IGFkYTRwMw0KICAgTWVkaWFzaXplOiA5 OTkxMzAwNzg3MjAgKDkzMUcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1v ZGU6IHIwdzBlMA0KICAgcmF3dHlwZTogNTE2ZTdjYmEtNmVjZi0xMWQ2LThm ZjgtMDAwMjJkMDk3MTJiDQogICBsYWJlbDogKG51bGwpDQogICBsZW5ndGg6 IDk5OTEzMDA3ODcyMA0KICAgb2Zmc2V0OiAxMDc0NzkwNDAwDQogICB0eXBl OiBmcmVlYnNkLXpmcw0KICAgaW5kZXg6IDMNCiAgIGVuZDogMTk1MzUyNTEz NA0KICAgc3RhcnQ6IDIwOTkyMDANCkNvbnN1bWVyczoNCjEuIE5hbWU6IGFk YTQNCiAgIE1lZGlhc2l6ZTogMTAwMDIwNDg4NjAxNiAoOTMyRykNCiAgIFNl Y3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQoNCkdlb20gbmFtZTog YWRhNQ0KZndoZWFkczogMTYNCmZ3c2VjdG9yczogNjMNCmxhc3Q6IDE5NTM1 MjUxMzQNCmZpcnN0OiAzNA0KZW50cmllczogMTI4DQpzY2hlbWU6IEdQVA0K UHJvdmlkZXJzOg0KMS4gTmFtZTogYWRhNXAxDQogICBNZWRpYXNpemU6IDEw MzExNjggKDEuME0pDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1vZGU6IHIw dzBlMA0KICAgcmF3dHlwZTogODNiZDZiOWQtN2Y0MS0xMWRjLWJlMGItMDAx NTYwYjg0ZjBmDQogICBsYWJlbDogKG51bGwpDQogICBsZW5ndGg6IDEwMzEx NjgNCiAgIG9mZnNldDogMTc0MDgNCiAgIHR5cGU6IGZyZWVic2QtYm9vdA0K ICAgaW5kZXg6IDENCiAgIGVuZDogMjA0Nw0KICAgc3RhcnQ6IDM0DQoyLiBO YW1lOiBhZGE1cDINCiAgIE1lZGlhc2l6ZTogMTA3Mzc0MTgyNCAoMS4wRykN CiAgIFNlY3RvcnNpemU6IDUxMg0KICAgTW9kZTogcjB3MGUwDQogICByYXd0 eXBlOiA1MTZlN2NiNS02ZWNmLTExZDYtOGZmOC0wMDAyMmQwOTcxMmINCiAg IGxhYmVsOiAobnVsbCkNCiAgIGxlbmd0aDogMTA3Mzc0MTgyNA0KICAgb2Zm c2V0OiAxMDQ4NTc2DQogICB0eXBlOiBmcmVlYnNkLXN3YXANCiAgIGluZGV4 OiAyDQogICBlbmQ6IDIwOTkxOTkNCiAgIHN0YXJ0OiAyMDQ4DQozLiBOYW1l OiBhZGE1cDMNCiAgIE1lZGlhc2l6ZTogOTk5MTMwMDc4NzIwICg5MzFHKQ0K ICAgU2VjdG9yc2l6ZTogNTEyDQogICBNb2RlOiByMHcwZTANCiAgIHJhd3R5 cGU6IDUxNmU3Y2JhLTZlY2YtMTFkNi04ZmY4LTAwMDIyZDA5NzEyYg0KICAg bGFiZWw6IChudWxsKQ0KICAgbGVuZ3RoOiA5OTkxMzAwNzg3MjANCiAgIG9m ZnNldDogMTA3NDc5MDQwMA0KICAgdHlwZTogZnJlZWJzZC16ZnMNCiAgIGlu ZGV4OiAzDQogICBlbmQ6IDE5NTM1MjUxMzQNCiAgIHN0YXJ0OiAyMDk5MjAw DQpDb25zdW1lcnM6DQoxLiBOYW1lOiBhZGE1DQogICBNZWRpYXNpemU6IDEw MDAyMDQ4ODYwMTYgKDkzMkcpDQogICBTZWN0b3JzaXplOiA1MTINCiAgIE1v ZGU6IHIwdzBlMA0KDQo= --0-1971476311-1264883505=:4627-- From owner-freebsd-fs@FreeBSD.ORG Sat Jan 30 22:02:32 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABF8A106566C for ; Sat, 30 Jan 2010 22:02:32 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id F0CD08FC12 for ; Sat, 30 Jan 2010 22:02:31 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3DA0B45C9F; Sat, 30 Jan 2010 23:02:30 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 18AA345C89; Sat, 30 Jan 2010 23:02:25 +0100 (CET) Date: Sat, 30 Jan 2010 23:02:21 +0100 From: Pawel Jakub Dawidek To: Michael Reifenberger Message-ID: <20100130220221.GC1660@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 22:02:32 -0000 --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 30, 2010 at 09:31:45PM +0100, Michael Reifenberger wrote: > Hi, > have you got any new information or preliminary patch on this topic? > Unfortunately I get the same symptom when trying to create a new pool usi= ng > newly attached ada devices: [...] I got no response how the patch works. Maybe you could try it? http://people.freebsd.org/~pjd/patches/vdev_geom.c.2.patch --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLZKxrForvXbEpPzQRAv88AJ0dNf2iPo59gd66InGkwZD8937NtACgraco unVPLOsQg2ceP2hmTu1h+dE= =2Kqa -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef-- From owner-freebsd-fs@FreeBSD.ORG Sat Jan 30 22:30:36 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AB9F1065694; Sat, 30 Jan 2010 22:30:36 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mx1.freebsd.org (Postfix) with ESMTP id 50C248FC18; Sat, 30 Jan 2010 22:30:35 +0000 (UTC) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id D67A11C00175; Sat, 30 Jan 2010 23:30:34 +0100 (CET) Received: from localhost (dynscan2.mnet-online.de [192.168.6.166]) by mail.m-online.net (Postfix) with ESMTP id C7C55901D3; Sat, 30 Jan 2010 23:30:34 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.6.166]) (amavisd-new, port 10024) with ESMTP id UHaplubEZ5DK; Sat, 30 Jan 2010 23:30:33 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-114-117.dynamic.mnet-online.de [93.104.114.117]) by mail.mnet-online.de (Postfix) with ESMTP; Sat, 30 Jan 2010 23:30:33 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 628C62C043; Sat, 30 Jan 2010 23:30:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 5BAF42C042; Sat, 30 Jan 2010 23:30:33 +0100 (CET) Date: Sat, 30 Jan 2010 23:30:33 +0100 (CET) From: Michael Reifenberger To: Pawel Jakub Dawidek In-Reply-To: <20100130220221.GC1660@garage.freebsd.pl> Message-ID: References: <20100130220221.GC1660@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 22:30:36 -0000 On Sat, 30 Jan 2010, Pawel Jakub Dawidek wrote: ... >> Unfortunately I get the same symptom when trying to create a new pool using >> newly attached ada devices: > [...] > > I got no response how the patch works. Maybe you could try it? > > http://people.freebsd.org/~pjd/patches/vdev_geom.c.2.patch > The patch works for me (after removing the ';' in line 414): ... pool: z state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM z ONLINE 0 0 0 raidz2 ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 ada1p3 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 ada4p3 ONLINE 0 0 0 ada5p3 ONLINE 0 0 0 errors: No known data errors ... If you feel comftable with the patch, should I commit the fix to HEAD? Thanks for fixing! Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com