From owner-freebsd-fs@FreeBSD.ORG Sun May 26 20:54:22 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64E8DDD; Sun, 26 May 2013 20:54:22 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFF7D9D; Sun, 26 May 2013 20:54:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4QKsMPt043848; Sun, 26 May 2013 20:54:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4QKsMr9043847; Sun, 26 May 2013 20:54:22 GMT (envelope-from linimon) Date: Sun, 26 May 2013 20:54:22 GMT Message-Id: <201305262054.r4QKsMr9043847@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: bin/178996: [zfs] [patch] error in message with zfs mount -> there is no "mount -F zfs" in FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 20:54:22 -0000 Old Synopsis: error in message with zfs mount -> there is no "mount -F zfs" in FreeBSD New Synopsis: [zfs] [patch] error in message with zfs mount -> there is no "mount -F zfs" in FreeBSD Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 26 20:53:43 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178996 From owner-freebsd-fs@FreeBSD.ORG Mon May 27 01:22:08 2013 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6E948AD for ; Mon, 27 May 2013 01:22:08 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) by mx1.freebsd.org (Postfix) with ESMTP id 9100389B for ; Mon, 27 May 2013 01:22:08 +0000 (UTC) Received: from meatwad.mouf.net (cpe-098-122-135-254.nc.res.rr.com [98.122.135.254]) (authenticated bits=0) by mouf.net (8.14.5/8.14.5) with ESMTP id r4R1LtBG078364 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 27 May 2013 01:22:00 GMT (envelope-from swills@FreeBSD.org) Message-ID: <51A2B533.8030504@FreeBSD.org> Date: Mon, 27 May 2013 01:21:55 +0000 From: Steve Wills User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: fs@FreeBSD.org Subject: Re: dev entries for cloned zvol don't show up until after reboot References: <8ea8b9c8074fd122f78c5eaa3b289805.squirrel@mouf.net> In-Reply-To: <8ea8b9c8074fd122f78c5eaa3b289805.squirrel@mouf.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Mon, 27 May 2013 01:22:00 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=none autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mouf.net X-Virus-Scanned: clamav-milter 0.97.7 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 01:22:08 -0000 On 05/24/13 17:56, Steve Wills wrote: > Hi, > > I've noticed that if I make zvol, create a snapshot of it, then clone > that, the /dev/zvol/* entries for it don't show up until after I reboot. > This is on r250925. Is this a known bug? To add a bit more detail to this, the steps are: zfs create -V 1G pool/somevol ls /dev/zvol/pool # witness somevol entries zfs create pool/somevol@somesnap ls /dev/zvol/pool # witness no new entries zfs clone pool/somvol@somesnap pool/anothervol ls /dev/zvol/pool # again witness no new entries reboot ls /dev/zvol/pool # witness missing entries appearing I'll go ahead and submit a PR too in case that helps. Steve From owner-freebsd-fs@FreeBSD.ORG Mon May 27 05:10:20 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 96C9CC1E for ; Mon, 27 May 2013 05:10:20 +0000 (UTC) (envelope-from ngrundmann@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1.freebsd.org (Postfix) with ESMTP id 4412A182 for ; Mon, 27 May 2013 05:10:19 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Md1Gm-1UxoLp0RBi-00IAPc for ; Mon, 27 May 2013 07:10:19 +0200 Received: (qmail invoked by alias); 27 May 2013 05:10:18 -0000 Received: from i59F56C7C.versanet.de (EHLO [192.168.1.10]) [89.245.108.124] by mail.gmx.net (mp033) with SMTP; 27 May 2013 07:10:18 +0200 X-Authenticated: #5821560 X-Provags-ID: V01U2FsdGVkX19mWOo7YbVmoC7u/h3bHqKfbBMiU3I0a+qIanYJYo TQQ8j27fay3IjZ Message-ID: <51A2EABA.9080306@gmx.de> Date: Mon, 27 May 2013 07:10:18 +0200 From: Norbert User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130201 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: FreeBSD problem with rsync, sshfs and MooseFS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 05:10:20 -0000 Hello, I am checking to use MooseFS a "backbone" distributed filesystem on servers and clients. Most things are working fine - setup was very easy. But one problem I discovered was using rsync - and it came up with rdiff-backup as well! Long lasting copies with tar or scp worked fine... The mounting of the filesystem is done over fusefs-ssh... So what was the first panic after installing fuse4bsd and the "standard" kmod module: current process = 1234 (rsync) ... #0 0xffffffff808680fe at kdb_backtrace+0x5e #1 0xffffffff80832cb7 at panic+0x187 #2 0xffffffff80b18400 at trap_fatal+0x290 #3 0xffffffff80b18749 at trap_pfault+0x1f9 #4 0xffffffff80b18c0f at trap+0x3df #5 0xffffffff80b0313f at calltrap+0x8 #6 0xffffffff80b17cf0 at amd64_syscall+0x450 #7 0xffffffff80b03427 at Zfast_syscall+0xf7 see also: http://www.freebsd.org/cgi/query-pr.cgi?pr=167362 and: http://forums.pcbsd.org/showthread.php?p=104651 Then I got the information to use an experimental kmod verion 0.4.4 (see http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2), which I compiled and installed. Now it was much better - but instead of immediately dying the panic was after running rdiff-backup for 10 minutes... that is much better - but not ok... :-( I got the panic message: May 23 14:12:47 HOST kernel: Fatal trap 12: page fault while in kernel mode May 23 14:12:47 HOST kernel: cpuid = 0; apic id = 00 May 23 14:12:47 HOST kernel: fault virtual address = 0x64 May 23 14:12:47 HOST kernel: fault code = supervisor read data, page not present May 23 14:12:47 HOST kernel: instruction pointer = 0x20:0xffffffff818541a4 May 23 14:12:47 HOST kernel: stack pointer = 0x28:0xffffff822d3467b0 May 23 14:12:47 HOST kernel: frame pointer = 0x28:0xffffff822d346870 May 23 14:12:47 HOST kernel: code segment = base 0x0, limit 0xfffff, type 0x1b May 23 14:12:47 HOST kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May 23 14:12:47 HOST kernel: processor eflags = interrupt enabled, resume, IOPL = 0 May 23 14:12:47 HOST kernel: current process = 3624 (python2.7) May 23 14:12:47 HOST kernel: trap number = 12 May 23 14:12:47 HOST kernel: panic: page fault May 23 14:12:47 HOST kernel: cpuid = 0 May 23 14:12:47 HOST kernel: KDB: stack backtrace: May 23 14:12:47 HOST kernel: #0 0xffffffff809208a6 at kdb_backtrace+0x66 May 23 14:12:47 HOST kernel: #1 0xffffffff808ea8be at panic+0x1ce May 23 14:12:47 HOST kernel: #2 0xffffffff80bd8240 at trap_fatal+0x290 May 23 14:12:47 HOST kernel: #3 0xffffffff80bd857d at trap_pfault+0x1ed May 23 14:12:47 HOST kernel: #4 0xffffffff80bd8b9e at trap+0x3ce May 23 14:12:47 HOST kernel: #5 0xffffffff80bc315f at calltrap+0x8 May 23 14:12:47 HOST kernel: #6 0xffffffff80c687f1 at VOP_CREATE_APV+0x31 May 23 14:12:47 HOST kernel: #7 0xffffffff809604e0 at uipc_bind+0x380 May 23 14:12:47 HOST kernel: #8 0xffffffff8095a95e at kern_bind+0xde May 23 14:12:47 HOST kernel: #9 0xffffffff8095a9d1 at sys_bind+0x41 May 23 14:12:47 HOST kernel: #10 0xffffffff80bd7ae6 at amd64_syscall+0x546 May 23 14:12:47 HOST kernel: #11 0xffffffff80bc3447 at Xfast_syscall+0xf7 May 23 14:12:47 HOST kernel: Uptime: 3h8m41s May 23 14:12:47 HOST kernel: Automatic reboot in 15 seconds - press a key on the console to abort May 23 14:12:47 HOST kernel: Rebooting... Oh, I forgot: I am using FreeBSD 9.1 on AMD64... My question: has anyone an idea how to proceed, some help or a workaround? That would be very nice :-) I don't have time to do testing on a debugging kernel and analyse core dumps - sorry Thanks, Norbert From owner-freebsd-fs@FreeBSD.ORG Mon May 27 11:06:45 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D7DDD317 for ; Mon, 27 May 2013 11:06:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C82316BB for ; Mon, 27 May 2013 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4RB6jW5016002 for ; Mon, 27 May 2013 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4RB6jch016000 for freebsd-fs@FreeBSD.org; Mon, 27 May 2013 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 May 2013 11:06:45 GMT Message-Id: <201305271106.r4RB6jch016000@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 11:06:45 -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 bin/178996 fs [zfs] [patch] error in message with zfs mount -> there o kern/178854 fs [ufs] FreeBSD kernel crash in UFS o kern/178713 fs [nfs] [patch] Correct WebNFS support in NFS server and o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/178103 fs [kernel] [nfs] [patch] Correct support of index files o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic f kern/177335 fs [nfs] [panic] Sleeping on "vmopar" with the following o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/174060 fs [ext2fs] Ext2FS system crashes (buffer overflow?) o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 319 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon May 27 17:00:03 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 36019B7 for ; Mon, 27 May 2013 17:00:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA8DE8C for ; Mon, 27 May 2013 17:00:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4RH02aq087381 for ; Mon, 27 May 2013 17:00:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4RH02AM087380; Mon, 27 May 2013 17:00:02 GMT (envelope-from gnats) Date: Mon, 27 May 2013 17:00:02 GMT Message-Id: <201305271700.r4RH02AM087380@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Jilles Tjoelker Subject: Re: kern/165392: Multiple mkdir/rmdir fails with errno 31 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jilles Tjoelker List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:00:03 -0000 The following reply was made to PR kern/165392; it has been noted by GNATS. From: Jilles Tjoelker To: Jaakko Heinonen Cc: bug-followup@FreeBSD.org, vvv@colocall.net, mckusick@FreeBSD.org Subject: Re: kern/165392: Multiple mkdir/rmdir fails with errno 31 Date: Mon, 27 May 2013 18:53:28 +0200 On Mon, May 20, 2013 at 10:21:34PM +0300, Jaakko Heinonen wrote: > On 2012-02-25, Jilles Tjoelker wrote: > > > [mkdir fails with [EMLINK], but link count < LINK_MAX] > > I can reproduce this problem with UFS with soft updates (with or without > > journaling). > > A reproduction without C programs is: > > cd empty_dir > > mkdir `jot 32766 1` # the last one will fail (correctly) > > rmdir 1 > > mkdir a # will erroneously fail > > The problem appears to be because the previous rmdir has not yet been > > fully completed. It is still holding onto the link count until the > > directory is written, which may take up to two minutes. > > The same problem can occur with other calls that increase the link count > > such as link() and rename(). > > A workaround is to call fsync() on the directory that contained the > > deleted entries. It will then release its hold on the link count and > > allow mkdir or other calls. If fsync() is only called when [EMLINK] is > > returned, the performance impact should not be very bad, although it > > still causes more I/O than necessary. > I tried to implement this with the following patch: > http://people.freebsd.org/~jh/patches/ufs-check_linkcnt.diff > However, VOP_FSYNC(9) with the MNT_WAIT flag seems not to update the > i_nlink count for a reason unknown to me. I can verify that also by > taking your reproduction recipe above and adding "fsync ." between > "rmdir 1" and "mkdir a". fsync certainly helps but not as effectively as you'd want. Some combination of sleeps, fsyncs and mkdir attempts appears to be needed. A shell loop like rmdir 8; fsync .; \ until mkdir h 2>/dev/null; do printf .; fsync .; sleep 1; done takes two seconds. However, in rmdir 13; mkdir m; fsync .; \ until mkdir m 2>/dev/null; do printf .; sleep 1; done the fsync is of no benefit. It is just as slow as omitting it (about half a minute). I must have taken long enough to type/recall the commands when I tried this earlier. In my earlier experiments I gave the commands separately. > Does this mean that fsync(2) is broken for directories on softdep > enabled UFS? I don't think fsync(2) has to sync the exact link count to disk, since fsck will take care of that. However, it has to sync the timestamps, permissions and directory entries. > I have cc'd Kirk in hope he could shed some light on this. I'm also interested in whether it is safe to call VOP_FSYNC at that point, especially in the case of a rename where a lock on the source directory vnode may be held at the same time. -- Jilles Tjoelker From owner-freebsd-fs@FreeBSD.ORG Mon May 27 23:30:18 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77E2C182; Mon, 27 May 2013 23:30:18 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 50B7C2FD; Mon, 27 May 2013 23:30:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4RNUIBJ066155; Mon, 27 May 2013 23:30:18 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4RNUIQ8066154; Mon, 27 May 2013 23:30:18 GMT (envelope-from linimon) Date: Mon, 27 May 2013 23:30:18 GMT Message-Id: <201305272330.r4RNUIQ8066154@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/178999: [zfs] dev entries for cloned zvol don't show up until after reboot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 23:30:18 -0000 Old Synopsis: dev entries for cloned zvol don't show up until after reboot New Synopsis: [zfs] dev entries for cloned zvol don't show up until after reboot Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 27 23:30:01 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178999 From owner-freebsd-fs@FreeBSD.ORG Wed May 29 00:40:01 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B0DB83D for ; Wed, 29 May 2013 00:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 43D10871 for ; Wed, 29 May 2013 00:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4T0e1O4079617 for ; Wed, 29 May 2013 00:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4T0e0du079616; Wed, 29 May 2013 00:40:00 GMT (envelope-from gnats) Date: Wed, 29 May 2013 00:40:00 GMT Message-Id: <201305290040.r4T0e0du079616@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/177335: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 00:40:01 -0000 The following reply was made to PR kern/177335; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/177335: commit references a PR Date: Wed, 29 May 2013 00:32:57 +0000 (UTC) Author: rmacklem Date: Wed May 29 00:32:49 2013 New Revision: 251089 URL: http://svnweb.freebsd.org/changeset/base/251089 Log: Add a patch analygous to r248567, r248581, r251079 to the old NFS client to avoid the panic reported in the PR by doing the vnode_pager_setsize() call after unlocking the mutex. PR: 177335 MFC after: 2 weeks Modified: head/sys/nfsclient/nfs_subs.c Modified: head/sys/nfsclient/nfs_subs.c ============================================================================== --- head/sys/nfsclient/nfs_subs.c Wed May 29 00:19:58 2013 (r251088) +++ head/sys/nfsclient/nfs_subs.c Wed May 29 00:32:49 2013 (r251089) @@ -463,6 +463,8 @@ nfs_loadattrcache(struct vnode **vpp, st struct timespec mtime, mtime_save; int v3 = NFS_ISV3(vp); int error = 0; + u_quad_t nsize; + int setnsize; md = *mdp; t1 = (mtod(md, caddr_t) + md->m_len) - *dposp; @@ -565,6 +567,8 @@ nfs_loadattrcache(struct vnode **vpp, st vap->va_filerev = 0; } np->n_attrstamp = time_second; + setnsize = 0; + nsize = 0; if (vap->va_size != np->n_size) { if (vap->va_type == VREG) { if (dontshrink && vap->va_size < np->n_size) { @@ -591,7 +595,8 @@ nfs_loadattrcache(struct vnode **vpp, st np->n_size = vap->va_size; np->n_flag |= NSIZECHANGED; } - vnode_pager_setsize(vp, np->n_size); + setnsize = 1; + nsize = vap->va_size; } else { np->n_size = vap->va_size; } @@ -628,6 +633,8 @@ nfs_loadattrcache(struct vnode **vpp, st KDTRACE_NFS_ATTRCACHE_LOAD_DONE(vp, &np->n_vattr, 0); #endif mtx_unlock(&np->n_mtx); + if (setnsize) + vnode_pager_setsize(vp, nsize); out: #ifdef KDTRACE_HOOKS if (error) _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed May 29 11:49:58 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2CAC6CB for ; Wed, 29 May 2013 11:49:58 +0000 (UTC) (envelope-from prvs=1861a99eb2=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6E162270 for ; Wed, 29 May 2013 11:49:58 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004062750.msg for ; Wed, 29 May 2013 12:49:55 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 29 May 2013 12:49:55 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1861a99eb2=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Message-ID: <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> From: "Steven Hartland" To: "Ajit Jain" References: <60316751643743738AB83DABC6A5934B@multiplay.co.uk> <20130429105143.GA1492@icarus.home.lan> <3AD1AB31003D49B2BF2EA7DD411B38A2@multiplay.co.uk> <9681E07546D348168052D4FC5365B4CD@multiplay.co.uk> <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk> <93D0677B373A452BAF58C8EA6823783D@multiplay.co.uk> <35ABA7AAEB7F4D86A1ED54C4C47FEB49@multiplay.co.uk> Subject: Re: seeing data corruption with zfs trim functionality Date: Wed, 29 May 2013 12:49:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 11:49:58 -0000 Sorry to pester, but any update on this Ajit? I ask as its currently blocking the MFC of TRIM to stable/8 & 9 and I've been unable to reproduce this issue even with your testing code on working FW versions. Regards Steve ----- Original Message ----- From: "Ajit Jain" > Sure Steven, > I'll apply the patches and update ASAP. > > thanks > ajit > > > On Thu, May 23, 2013 at 3:03 PM, Steven Hartland wrote: > >> I've attacked the two patch sets I'm looking to MFC to stable-9, one >> adds BIO_DELETE CAM changes and the other is ZFS TRIM support. >> >> They should both apply cleanly to stable-9, if you could test with >> those on your machine and let me know. >> >> Regards >> Steve >> >> ----- Original Message ----- From: "Ajit Jain" >> >> >> Hi Steven, >>> >>> FW version on the setup is P15. >>> I will upgrade the FW to P16, but I think my >>> best bet will be to update code base to 9 stable as unlike you, >>> I was seeing corruption for all three delete methods. >>> >>> thanks >>> ajit >>> >>> On Sat, May 18, 2013 at 4:15 AM, Steven Hartland >> >**wrote: >>> >>> ----- Original Message ----- From: "Steven Hartland" < >>>> killing@multiplay.co.uk> >>>> >>>> >>>> After initially seeing not issues, our overnight monitoring started >>>>> moaning >>>>> big time on the test box. So we checked and there was zpool corruption >>>>> as >>>>> well >>>>> as a missing boot loader and a corrupt GPT, so I believe we have >>>>> reproduced >>>>> your issue. >>>>> >>>>> After recovering the machine I created 3 pools on 3 different disks each >>>>> running a different delete_method. >>>>> >>>>> We then re-ran the tests which resulted in the pool running with >>>>> delete_method >>>>> WS16 being so broken it had suspended IO. A reboot resulted in it once >>>>> again >>>>> reporting no partition table via gpart. >>>>> >>>>> A third test run again produced a corrupt pool for WS16. >>>>> >>>>> I've conducted a preliminary review of the CAM WS16 code path along with >>>>> SBC-3 >>>>> spec which didn't identify any obvious issues. >>>>> >>>>> Given we're both using LSI 2008 based controllers it could be FW issue >>>>> specific >>>>> to WS16 but that's just speculation atm, so I'll continue to >>>>> investigate. >>>>> >>>>> If you could re-test you end without using WS16 to see if you can >>>>> reproduce the >>>>> problem with either UNMAP or ATA_TRIM that would be a very useful data >>>>> point. >>>>> >>>>> >>>> After much playing I narrow down a test case of one delete which was >>>> causing >>>> disc corruption for us (deleted the partition table instead of data in >>>> the middle of the disk). >>>> >>>> The conclusion is LSI 2008 HBA with FW below P13 will eat the data on >>>> your >>>> SATA >>>> disks if you use WS16 due to the following bug:- >>>> SCGCQ00230159 (DFCT) - Write same command to a SATA drive that doesn't >>>> support >>>> SCT write same may write wrong region. >>>> >>>> After updating here to P16, which we would generally be running, but test >>>> box >>>> was new and hadnt updated yet the corruption issue is no longer >>>> reproducable. >>>> >>>> So Ajit please check your FW version, I'm hoping to here your on >>>> something >>>> below P13, P12 possibly? >>>> >>>> If so then this is your issue, to fix simply update to P16 and the >>>> problem >>>> should be gone. >>>> >>>> >>>> Regards >>>> Steve >>>> >>>> >>>> ==============================****================== >>>> >>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>> the person or entity to whom it is addressed. In the event of >>>> misdirection, >>>> the recipient is prohibited from using, copying, printing or otherwise >>>> disseminating it or any information contained in it. >>>> In the event of misdirection, illegible or incomplete transmission please >>>> telephone +44 845 868 1337 >>>> or return the E.mail to postmaster@multiplay.co.uk. >>>> >>>> >>>> >>> >> ==============================**================== >> This e.mail is private and confidential between Multiplay (UK) Ltd. and >> the person or entity to whom it is addressed. In the event of misdirection, >> the recipient is prohibited from using, copying, printing or otherwise >> disseminating it or any information contained in it. >> In the event of misdirection, illegible or incomplete transmission please >> telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >> > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Wed May 29 12:43:35 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B89C4E09 for ; Wed, 29 May 2013 12:43:35 +0000 (UTC) (envelope-from ajit.jain@cloudbyte.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5D7950 for ; Wed, 29 May 2013 12:43:35 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id ta17so3375407obb.22 for ; Wed, 29 May 2013 05:43:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=k8Ch87HkS55+8yXKx3e25Vth36QY05iYUFzjK5hhB+4=; b=D9IOAB6OJoFZP2G8QPxsnaLI9IKD5aTTyCNfMBeBNlv/JFMEtkd+VC6yC6tZ9Qs8Yu D1n+2kx3dBoJ5yohdhZuE9qZegpAB1ljeU+Tjawhrb6iWGmzUoB7Nj/5zcCZbAUMLkjf EEW+JVaeYq24GuCYfyM8piELDBfEeLeHOCsVjggXL7Tfio3tPYpsc2MrnNwMD+Z1Y9IM sDWLXsrJ74DGYdjsjyc4y6NkhkVdbF0Pyjt44gLZCywpT6QQHn+TDPWASRAdQmdyWSU1 mHFKXpTZi5THdDbZtgO+Z62JBxjER0/N5UCenbPjI99QLtBZm09q2+/APkVJ/AftMVf7 r4pg== X-Received: by 10.60.116.202 with SMTP id jy10mr1421342oeb.82.1369831414895; Wed, 29 May 2013 05:43:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.151.134 with HTTP; Wed, 29 May 2013 05:43:14 -0700 (PDT) In-Reply-To: <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> References: <60316751643743738AB83DABC6A5934B@multiplay.co.uk> <20130429105143.GA1492@icarus.home.lan> <3AD1AB31003D49B2BF2EA7DD411B38A2@multiplay.co.uk> <9681E07546D348168052D4FC5365B4CD@multiplay.co.uk> <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk> <93D0677B373A452BAF58C8EA6823783D@multiplay.co.uk> <35ABA7AAEB7F4D86A1ED54C4C47FEB49@multiplay.co.uk> <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> From: Ajit Jain Date: Wed, 29 May 2013 18:13:14 +0530 Message-ID: Subject: Re: seeing data corruption with zfs trim functionality To: Steven Hartland X-Gm-Message-State: ALoCoQms++Hgn6MQACKAS08L9MUTav0KZ2XTZugRm0V9R1r5c1oX2AFJuLsDUaKqCg6Amuu5+oxV Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 12:43:35 -0000 Hi Steven, Sorry for the long delay, but might delay even further. I think the reason for the corruption was, my code was not updated specially cam directory. I request please do not stop just because of the issue I reported. I'll update my src tree and rerun the experiments I was running if I see some issue then probably we fix the bug rather then stopping for MFC. thanks, ajit On Wed, May 29, 2013 at 5:19 PM, Steven Hartland wrote: > Sorry to pester, but any update on this Ajit? > > I ask as its currently blocking the MFC of TRIM to stable/8 & 9 and I've > been > unable to reproduce this issue even with your testing code on working FW > versions. > > > Regards > Steve > > ----- Original Message ----- From: "Ajit Jain" > > > Sure Steven, >> I'll apply the patches and update ASAP. >> >> thanks >> ajit >> >> >> On Thu, May 23, 2013 at 3:03 PM, Steven Hartland > >**wrote: >> >> I've attacked the two patch sets I'm looking to MFC to stable-9, one >>> adds BIO_DELETE CAM changes and the other is ZFS TRIM support. >>> >>> They should both apply cleanly to stable-9, if you could test with >>> those on your machine and let me know. >>> >>> Regards >>> Steve >>> >>> ----- Original Message ----- From: "Ajit Jain" >>> >>> >>> Hi Steven, >>> >>>> >>>> FW version on the setup is P15. >>>> I will upgrade the FW to P16, but I think my >>>> best bet will be to update code base to 9 stable as unlike you, >>>> I was seeing corruption for all three delete methods. >>>> >>>> thanks >>>> ajit >>>> >>>> On Sat, May 18, 2013 at 4:15 AM, Steven Hartland < >>>> killing@multiplay.co.uk >>>> >**wrote: >>>> >>>> >>>> ----- Original Message ----- From: "Steven Hartland" < >>>> >>>>> killing@multiplay.co.uk> >>>>> >>>>> >>>>> After initially seeing not issues, our overnight monitoring started >>>>> >>>>>> moaning >>>>>> big time on the test box. So we checked and there was zpool corruption >>>>>> as >>>>>> well >>>>>> as a missing boot loader and a corrupt GPT, so I believe we have >>>>>> reproduced >>>>>> your issue. >>>>>> >>>>>> After recovering the machine I created 3 pools on 3 different disks >>>>>> each >>>>>> running a different delete_method. >>>>>> >>>>>> We then re-ran the tests which resulted in the pool running with >>>>>> delete_method >>>>>> WS16 being so broken it had suspended IO. A reboot resulted in it once >>>>>> again >>>>>> reporting no partition table via gpart. >>>>>> >>>>>> A third test run again produced a corrupt pool for WS16. >>>>>> >>>>>> I've conducted a preliminary review of the CAM WS16 code path along >>>>>> with >>>>>> SBC-3 >>>>>> spec which didn't identify any obvious issues. >>>>>> >>>>>> Given we're both using LSI 2008 based controllers it could be FW issue >>>>>> specific >>>>>> to WS16 but that's just speculation atm, so I'll continue to >>>>>> investigate. >>>>>> >>>>>> If you could re-test you end without using WS16 to see if you can >>>>>> reproduce the >>>>>> problem with either UNMAP or ATA_TRIM that would be a very useful data >>>>>> point. >>>>>> >>>>>> >>>>>> After much playing I narrow down a test case of one delete which was >>>>> causing >>>>> disc corruption for us (deleted the partition table instead of data in >>>>> the middle of the disk). >>>>> >>>>> The conclusion is LSI 2008 HBA with FW below P13 will eat the data on >>>>> your >>>>> SATA >>>>> disks if you use WS16 due to the following bug:- >>>>> SCGCQ00230159 (DFCT) - Write same command to a SATA drive that doesn't >>>>> support >>>>> SCT write same may write wrong region. >>>>> >>>>> After updating here to P16, which we would generally be running, but >>>>> test >>>>> box >>>>> was new and hadnt updated yet the corruption issue is no longer >>>>> reproducable. >>>>> >>>>> So Ajit please check your FW version, I'm hoping to here your on >>>>> something >>>>> below P13, P12 possibly? >>>>> >>>>> If so then this is your issue, to fix simply update to P16 and the >>>>> problem >>>>> should be gone. >>>>> >>>>> >>>>> Regards >>>>> Steve >>>>> >>>>> >>>>> ==============================******================== >>>>> >>>>> >>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>>> the person or entity to whom it is addressed. In the event of >>>>> misdirection, >>>>> the recipient is prohibited from using, copying, printing or otherwise >>>>> disseminating it or any information contained in it. >>>>> In the event of misdirection, illegible or incomplete transmission >>>>> please >>>>> telephone +44 845 868 1337 >>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>> >>>>> >>>>> >>>>> >>>> ==============================****================== >>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>> the person or entity to whom it is addressed. In the event of >>> misdirection, >>> the recipient is prohibited from using, copying, printing or otherwise >>> disseminating it or any information contained in it. >>> In the event of misdirection, illegible or incomplete transmission please >>> telephone +44 845 868 1337 >>> or return the E.mail to postmaster@multiplay.co.uk. >>> >>> >> > ==============================**================== > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of misdirection, > the recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > From owner-freebsd-fs@FreeBSD.ORG Wed May 29 13:10:10 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 68F06CEA for ; Wed, 29 May 2013 13:10:10 +0000 (UTC) (envelope-from prvs=1861a99eb2=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id ED1B7CC6 for ; Wed, 29 May 2013 13:10:09 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004063730.msg for ; Wed, 29 May 2013 14:10:07 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 29 May 2013 14:10:07 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1861a99eb2=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Message-ID: <6E4EBFE196274519B847A47A062950EE@multiplay.co.uk> From: "Steven Hartland" To: "Ajit Jain" References: <3AD1AB31003D49B2BF2EA7DD411B38A2@multiplay.co.uk> <9681E07546D348168052D4FC5365B4CD@multiplay.co.uk> <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk> <93D0677B373A452BAF58C8EA6823783D@multiplay.co.uk> <35ABA7AAEB7F4D86A1ED54C4C47FEB49@multiplay.co.uk> <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> Subject: Re: seeing data corruption with zfs trim functionality Date: Wed, 29 May 2013 14:09:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:10:10 -0000 Unfortunately FS corruption is a serious matters so even though I'm 99.99% convinced there isn't a problem I'd still prefer to confirm this was indeed an issue with your code base and not an issue with the current code prior to MFC'ing. Would a pre-patched stable/9 source / build help. If so I can look at making that available for you. Regards Steve ----- Original Message ----- From: "Ajit Jain" > Hi Steven, > > Sorry for the long delay, but might delay even further. > I think the reason for the corruption was, my code > was not updated specially cam directory. > > I request please do not stop just because of the issue I reported. > I'll update my src tree and rerun the experiments I was running > if I see some issue then probably we fix the bug rather then stopping > for MFC. > > thanks, > ajit > > > > On Wed, May 29, 2013 at 5:19 PM, Steven Hartland wrote: > >> Sorry to pester, but any update on this Ajit? >> >> I ask as its currently blocking the MFC of TRIM to stable/8 & 9 and I've >> been >> unable to reproduce this issue even with your testing code on working FW >> versions. >> >> >> Regards >> Steve >> >> ----- Original Message ----- From: "Ajit Jain" >> >> >> Sure Steven, >>> I'll apply the patches and update ASAP. >>> >>> thanks >>> ajit >>> >>> >>> On Thu, May 23, 2013 at 3:03 PM, Steven Hartland >> >**wrote: >>> >>> I've attacked the two patch sets I'm looking to MFC to stable-9, one >>>> adds BIO_DELETE CAM changes and the other is ZFS TRIM support. >>>> >>>> They should both apply cleanly to stable-9, if you could test with >>>> those on your machine and let me know. >>>> >>>> Regards >>>> Steve >>>> >>>> ----- Original Message ----- From: "Ajit Jain" >>>> >>>> >>>> Hi Steven, >>>> >>>>> >>>>> FW version on the setup is P15. >>>>> I will upgrade the FW to P16, but I think my >>>>> best bet will be to update code base to 9 stable as unlike you, >>>>> I was seeing corruption for all three delete methods. >>>>> >>>>> thanks >>>>> ajit >>>>> >>>>> On Sat, May 18, 2013 at 4:15 AM, Steven Hartland < >>>>> killing@multiplay.co.uk >>>>> >**wrote: >>>>> >>>>> >>>>> ----- Original Message ----- From: "Steven Hartland" < >>>>> >>>>>> killing@multiplay.co.uk> >>>>>> >>>>>> >>>>>> After initially seeing not issues, our overnight monitoring started >>>>>> >>>>>>> moaning >>>>>>> big time on the test box. So we checked and there was zpool corruption >>>>>>> as >>>>>>> well >>>>>>> as a missing boot loader and a corrupt GPT, so I believe we have >>>>>>> reproduced >>>>>>> your issue. >>>>>>> >>>>>>> After recovering the machine I created 3 pools on 3 different disks >>>>>>> each >>>>>>> running a different delete_method. >>>>>>> >>>>>>> We then re-ran the tests which resulted in the pool running with >>>>>>> delete_method >>>>>>> WS16 being so broken it had suspended IO. A reboot resulted in it once >>>>>>> again >>>>>>> reporting no partition table via gpart. >>>>>>> >>>>>>> A third test run again produced a corrupt pool for WS16. >>>>>>> >>>>>>> I've conducted a preliminary review of the CAM WS16 code path along >>>>>>> with >>>>>>> SBC-3 >>>>>>> spec which didn't identify any obvious issues. >>>>>>> >>>>>>> Given we're both using LSI 2008 based controllers it could be FW issue >>>>>>> specific >>>>>>> to WS16 but that's just speculation atm, so I'll continue to >>>>>>> investigate. >>>>>>> >>>>>>> If you could re-test you end without using WS16 to see if you can >>>>>>> reproduce the >>>>>>> problem with either UNMAP or ATA_TRIM that would be a very useful data >>>>>>> point. >>>>>>> >>>>>>> >>>>>>> After much playing I narrow down a test case of one delete which was >>>>>> causing >>>>>> disc corruption for us (deleted the partition table instead of data in >>>>>> the middle of the disk). >>>>>> >>>>>> The conclusion is LSI 2008 HBA with FW below P13 will eat the data on >>>>>> your >>>>>> SATA >>>>>> disks if you use WS16 due to the following bug:- >>>>>> SCGCQ00230159 (DFCT) - Write same command to a SATA drive that doesn't >>>>>> support >>>>>> SCT write same may write wrong region. >>>>>> >>>>>> After updating here to P16, which we would generally be running, but >>>>>> test >>>>>> box >>>>>> was new and hadnt updated yet the corruption issue is no longer >>>>>> reproducable. >>>>>> >>>>>> So Ajit please check your FW version, I'm hoping to here your on >>>>>> something >>>>>> below P13, P12 possibly? >>>>>> >>>>>> If so then this is your issue, to fix simply update to P16 and the >>>>>> problem >>>>>> should be gone. >>>>>> >>>>>> >>>>>> Regards >>>>>> Steve >>>>>> >>>>>> >>>>>> ==============================******================== >>>>>> >>>>>> >>>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>>>> the person or entity to whom it is addressed. In the event of >>>>>> misdirection, >>>>>> the recipient is prohibited from using, copying, printing or otherwise >>>>>> disseminating it or any information contained in it. >>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>> please >>>>>> telephone +44 845 868 1337 >>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ==============================****================== >>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>> the person or entity to whom it is addressed. In the event of >>>> misdirection, >>>> the recipient is prohibited from using, copying, printing or otherwise >>>> disseminating it or any information contained in it. >>>> In the event of misdirection, illegible or incomplete transmission please >>>> telephone +44 845 868 1337 >>>> or return the E.mail to postmaster@multiplay.co.uk. >>>> >>>> >>> >> ==============================**================== >> This e.mail is private and confidential between Multiplay (UK) Ltd. and >> the person or entity to whom it is addressed. In the event of misdirection, >> the recipient is prohibited from using, copying, printing or otherwise >> disseminating it or any information contained in it. >> In the event of misdirection, illegible or incomplete transmission please >> telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >> >> > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Wed May 29 13:49:32 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E8FAED4 for ; Wed, 29 May 2013 13:49:32 +0000 (UTC) (envelope-from happe@nbi.dk) Received: from mail2.nbi.dk (up.nbi.dk [130.225.212.6]) by mx1.freebsd.org (Postfix) with ESMTP id 3C101F72 for ; Wed, 29 May 2013 13:49:31 +0000 (UTC) Received: from [172.24.6.39] (happe.priv.nbi.dk [172.24.6.39]) by mail2.nbi.dk (Postfix) with ESMTP id A8C173C016 for ; Wed, 29 May 2013 15:18:37 +0200 (CEST) Message-ID: <51A6002C.2040803@nbi.dk> Date: Wed, 29 May 2013 15:18:36 +0200 From: Hans Henrik Happe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130317 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: ZFS 4k aligned space overhead Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:49:32 -0000 Hi, I've a system with 3TB WD NAS disks for ZFS. I created a 4k aligned 10 disk RAIDZ2. I noticed the overhead was ~1.4TB for the file system (3*8*10^12/2^40 - ). Then I tried with different number of disks: 6: 0.2602885812520981 7: 1.1858475767076015 8: 1.149622268974781 9: 0.7288754601031542 10: 1.3953630803152919 11: 2.061850775964558 12: 2.915792594663799 13: 1.5491229379549623 14: 2.056995471008122 15: 2.5648680040612817 16: 3.0727405650541186 17: 3.5806130981072783 18: 0.7912140190601349 the other good configs (6 and 18) is okay, but it seem strange that 10 has higher spaceoverhead than 18. I then tried with RAIDZ: 5: 0.19996666628867388 9: 0.39560710452497005 17: 0.8849408514797688 This seems correct. Then RAIDZ2 again but with ashift=9: 6: 0.2602881230413914 10: 0.4523236369714141 18: 0.7912133224308491 This also seems correct. The 6 and 18 results are basically the same for ashift 9 and 12. Is there an explanation to this? I'm running FreeBSD 9.1-RELEASE-p3. Cheers, Hans Henrik Happe From owner-freebsd-fs@FreeBSD.ORG Wed May 29 15:19:30 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C6B4D97 for ; Wed, 29 May 2013 15:19:30 +0000 (UTC) (envelope-from ajit.jain@cloudbyte.com) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 01DCCED3 for ; Wed, 29 May 2013 15:19:29 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wo10so567109obc.17 for ; Wed, 29 May 2013 08:19:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=qeW96SPbNXUuFMfqeTNIESv3Za6afSy8jyAr2YJ2qrU=; b=YFoLwsKqb0KhjX62U6PTUDsfIqIz2CwCiFDTCIMu8jGJA83pjOfqH68BIbW+nHY3vE WiBrZ079c/Ixr6yHfZwbErCJPRxXhp08ioGGK46hbxwTlQ4y0daoLdlRJ/PP+coGgaNm ZaSokTdoMrGYHa3Ts3XaBa0fBC0Z4Fju8GvWfcb5PSufvzaqV0f45B8lhx926do86q6k ErGdjXzZEOw7QAMtGtxQ1nl3U9vijYa4vNJlg9KGcmx75kqLaqjUtFaihAah9CS7l8/Z 7Zme/hRgDBQhvuU51QgePiDE7KB9iZBmOs4o7ZUUYdwN0/3TqRHtMa782iuRIJ+0L+Wa h4vw== X-Received: by 10.182.98.135 with SMTP id ei7mr1823900obb.102.1369840769539; Wed, 29 May 2013 08:19:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.151.134 with HTTP; Wed, 29 May 2013 08:19:08 -0700 (PDT) In-Reply-To: <6E4EBFE196274519B847A47A062950EE@multiplay.co.uk> References: <3AD1AB31003D49B2BF2EA7DD411B38A2@multiplay.co.uk> <9681E07546D348168052D4FC5365B4CD@multiplay.co.uk> <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk> <93D0677B373A452BAF58C8EA6823783D@multiplay.co.uk> <35ABA7AAEB7F4D86A1ED54C4C47FEB49@multiplay.co.uk> <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> <6E4EBFE196274519B847A47A062950EE@multiplay.co.uk> From: Ajit Jain Date: Wed, 29 May 2013 20:49:08 +0530 Message-ID: Subject: Re: seeing data corruption with zfs trim functionality To: Steven Hartland X-Gm-Message-State: ALoCoQnuBhDUBuhNNH1dtRWJW1xjqC0i5P/sOZEiJZDTvSWyjj+LG51IYGnYAIeBQPlhTfNWDnb2 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 15:19:30 -0000 Hi Steven, That would be really great. I'll install build provided by you and can quickly update the result. I am kind of feeling that I am asking too much of fever from you. thanks for the help and bearing me, ajit On Wed, May 29, 2013 at 6:39 PM, Steven Hartland wrote: > Unfortunately FS corruption is a serious matters so even though I'm 99.99% > convinced there isn't a problem I'd still prefer to confirm this was indeed > an issue with your code base and not an issue with the current code prior > to MFC'ing. > > Would a pre-patched stable/9 source / build help. If so I can look at > making > that available for you. > > > Regards > Steve > > ----- Original Message ----- From: "Ajit Jain" > > > Hi Steven, >> >> Sorry for the long delay, but might delay even further. >> I think the reason for the corruption was, my code >> was not updated specially cam directory. >> >> I request please do not stop just because of the issue I reported. >> I'll update my src tree and rerun the experiments I was running >> if I see some issue then probably we fix the bug rather then stopping >> for MFC. >> >> thanks, >> ajit >> >> >> >> On Wed, May 29, 2013 at 5:19 PM, Steven Hartland > >**wrote: >> >> Sorry to pester, but any update on this Ajit? >>> >>> I ask as its currently blocking the MFC of TRIM to stable/8 & 9 and I've >>> been >>> unable to reproduce this issue even with your testing code on working FW >>> versions. >>> >>> >>> Regards >>> Steve >>> >>> ----- Original Message ----- From: "Ajit Jain" >>> >>> >>> Sure Steven, >>> >>>> I'll apply the patches and update ASAP. >>>> >>>> thanks >>>> ajit >>>> >>>> >>>> On Thu, May 23, 2013 at 3:03 PM, Steven Hartland < >>>> killing@multiplay.co.uk >>>> >**wrote: >>>> >>>> >>>> I've attacked the two patch sets I'm looking to MFC to stable-9, one >>>> >>>>> adds BIO_DELETE CAM changes and the other is ZFS TRIM support. >>>>> >>>>> They should both apply cleanly to stable-9, if you could test with >>>>> those on your machine and let me know. >>>>> >>>>> Regards >>>>> Steve >>>>> >>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>> ajit.jain@cloudbyte.com> >>>>> >>>>> >>>>> Hi Steven, >>>>> >>>>> >>>>>> FW version on the setup is P15. >>>>>> I will upgrade the FW to P16, but I think my >>>>>> best bet will be to update code base to 9 stable as unlike you, >>>>>> I was seeing corruption for all three delete methods. >>>>>> >>>>>> thanks >>>>>> ajit >>>>>> >>>>>> On Sat, May 18, 2013 at 4:15 AM, Steven Hartland < >>>>>> killing@multiplay.co.uk >>>>>> >**wrote: >>>>>> >>>>>> >>>>>> ----- Original Message ----- From: "Steven Hartland" < >>>>>> >>>>>> killing@multiplay.co.uk> >>>>>>> >>>>>>> >>>>>>> After initially seeing not issues, our overnight monitoring started >>>>>>> >>>>>>> moaning >>>>>>>> big time on the test box. So we checked and there was zpool >>>>>>>> corruption >>>>>>>> as >>>>>>>> well >>>>>>>> as a missing boot loader and a corrupt GPT, so I believe we have >>>>>>>> reproduced >>>>>>>> your issue. >>>>>>>> >>>>>>>> After recovering the machine I created 3 pools on 3 different disks >>>>>>>> each >>>>>>>> running a different delete_method. >>>>>>>> >>>>>>>> We then re-ran the tests which resulted in the pool running with >>>>>>>> delete_method >>>>>>>> WS16 being so broken it had suspended IO. A reboot resulted in it >>>>>>>> once >>>>>>>> again >>>>>>>> reporting no partition table via gpart. >>>>>>>> >>>>>>>> A third test run again produced a corrupt pool for WS16. >>>>>>>> >>>>>>>> I've conducted a preliminary review of the CAM WS16 code path along >>>>>>>> with >>>>>>>> SBC-3 >>>>>>>> spec which didn't identify any obvious issues. >>>>>>>> >>>>>>>> Given we're both using LSI 2008 based controllers it could be FW >>>>>>>> issue >>>>>>>> specific >>>>>>>> to WS16 but that's just speculation atm, so I'll continue to >>>>>>>> investigate. >>>>>>>> >>>>>>>> If you could re-test you end without using WS16 to see if you can >>>>>>>> reproduce the >>>>>>>> problem with either UNMAP or ATA_TRIM that would be a very useful >>>>>>>> data >>>>>>>> point. >>>>>>>> >>>>>>>> >>>>>>>> After much playing I narrow down a test case of one delete which >>>>>>>> was >>>>>>>> >>>>>>> causing >>>>>>> disc corruption for us (deleted the partition table instead of data >>>>>>> in >>>>>>> the middle of the disk). >>>>>>> >>>>>>> The conclusion is LSI 2008 HBA with FW below P13 will eat the data on >>>>>>> your >>>>>>> SATA >>>>>>> disks if you use WS16 due to the following bug:- >>>>>>> SCGCQ00230159 (DFCT) - Write same command to a SATA drive that >>>>>>> doesn't >>>>>>> support >>>>>>> SCT write same may write wrong region. >>>>>>> >>>>>>> After updating here to P16, which we would generally be running, but >>>>>>> test >>>>>>> box >>>>>>> was new and hadnt updated yet the corruption issue is no longer >>>>>>> reproducable. >>>>>>> >>>>>>> So Ajit please check your FW version, I'm hoping to here your on >>>>>>> something >>>>>>> below P13, P12 possibly? >>>>>>> >>>>>>> If so then this is your issue, to fix simply update to P16 and the >>>>>>> problem >>>>>>> should be gone. >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> ==============================********================== >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. >>>>>>> and >>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>> misdirection, >>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>> otherwise >>>>>>> disseminating it or any information contained in it. >>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>> please >>>>>>> telephone +44 845 868 1337 >>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ==============================******================== >>>>>> >>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>>> the person or entity to whom it is addressed. In the event of >>>>> misdirection, >>>>> the recipient is prohibited from using, copying, printing or otherwise >>>>> disseminating it or any information contained in it. >>>>> In the event of misdirection, illegible or incomplete transmission >>>>> please >>>>> telephone +44 845 868 1337 >>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>> >>>>> >>>>> >>>> ==============================****================== >>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>> the person or entity to whom it is addressed. In the event of >>> misdirection, >>> the recipient is prohibited from using, copying, printing or otherwise >>> disseminating it or any information contained in it. >>> In the event of misdirection, illegible or incomplete transmission please >>> telephone +44 845 868 1337 >>> or return the E.mail to postmaster@multiplay.co.uk. >>> >>> >>> >> > ==============================**================== > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of misdirection, > the recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > From owner-freebsd-fs@FreeBSD.ORG Wed May 29 15:19:44 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B386E22 for ; Wed, 29 May 2013 15:19:44 +0000 (UTC) (envelope-from nowakpl@platinum.linux.pl) Received: from platinum.linux.pl (platinum.edu.pl [81.161.192.4]) by mx1.freebsd.org (Postfix) with ESMTP id 516F6EE4 for ; Wed, 29 May 2013 15:19:43 +0000 (UTC) Received: by platinum.linux.pl (Postfix, from userid 87) id 90C3947E1A; Wed, 29 May 2013 17:19:35 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on platinum.linux.pl X-Spam-Level: X-Spam-Status: No, score=-1.3 required=3.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.3.2 Received: from [10.255.0.2] (c38-073.client.duna.pl [83.151.38.73]) by platinum.linux.pl (Postfix) with ESMTPA id 3129547E15 for ; Wed, 29 May 2013 17:19:35 +0200 (CEST) Message-ID: <51A61C7F.5060007@platinum.linux.pl> Date: Wed, 29 May 2013 17:19:27 +0200 From: Adam Nowacki User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS 4k aligned space overhead References: <51A6002C.2040803@nbi.dk> In-Reply-To: <51A6002C.2040803@nbi.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 15:19:44 -0000 Free space calculation is done with the assumption of 128k block size. Each block is completely independent so sector aligned and no parity shared between blocks. This creates overhead unless the number of disks minus raidz level is a power of two. Above that is allocation overhead where each block (together with parity) is padded to occupy the multiple of raidz level plus 1 (sectors). Zero overhead from both happens at raidz1 with 2, 3, 5, 9 and 17 disks and raidz2 with 3, 6 or 18 disks. On 2013-05-29 15:18, Hans Henrik Happe wrote: > Hi, > > I've a system with 3TB WD NAS disks for ZFS. I created a 4k aligned 10 > disk RAIDZ2. I noticed the overhead was ~1.4TB for the file system > (3*8*10^12/2^40 - ). Then I tried with different number of > disks: > > 6: 0.2602885812520981 > 7: 1.1858475767076015 > 8: 1.149622268974781 > 9: 0.7288754601031542 > 10: 1.3953630803152919 > 11: 2.061850775964558 > 12: 2.915792594663799 > 13: 1.5491229379549623 > 14: 2.056995471008122 > 15: 2.5648680040612817 > 16: 3.0727405650541186 > 17: 3.5806130981072783 > 18: 0.7912140190601349 > > the other good configs (6 and 18) is okay, but it seem strange that 10 > has higher spaceoverhead than 18. High overhead with 10 disks is because of allocation overhead. 128k / 4k = 32 sectors, 32 sectors / 8 data disks = 4 sectors per disk, 4 sectors per disk * (8 data disks + 2 parity disks) = 40 sectors. 40 is not a multiple of 3 so 2 sector padding is added. (5% overhead) > > I then tried with RAIDZ: > > 5: 0.19996666628867388 > 9: 0.39560710452497005 > 17: 0.8849408514797688 > > This seems correct. Then RAIDZ2 again but with ashift=9: > > 6: 0.2602881230413914 > 10: 0.4523236369714141 > 18: 0.7912133224308491 > > This also seems correct. The 6 and 18 results are basically the same for > ashift 9 and 12. > > Is there an explanation to this? > > I'm running FreeBSD 9.1-RELEASE-p3. > > Cheers, > Hans Henrik Happe > _______________________________________________ > 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 Wed May 29 17:00:01 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 60EA838E for ; Wed, 29 May 2013 17:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 530F19C9 for ; Wed, 29 May 2013 17:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4TH01OX081931 for ; Wed, 29 May 2013 17:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4TH01uG081930; Wed, 29 May 2013 17:00:01 GMT (envelope-from gnats) Date: Wed, 29 May 2013 17:00:01 GMT Message-Id: <201305291700.r4TH01uG081930@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Jaakko Heinonen Subject: Re: kern/165392: Multiple mkdir/rmdir fails with errno 31 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jaakko Heinonen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:00:01 -0000 The following reply was made to PR kern/165392; it has been noted by GNATS. From: Jaakko Heinonen To: Jilles Tjoelker Cc: bug-followup@FreeBSD.org, vvv@colocall.net, mckusick@FreeBSD.org Subject: Re: kern/165392: Multiple mkdir/rmdir fails with errno 31 Date: Wed, 29 May 2013 19:53:11 +0300 On 2013-05-27, Jilles Tjoelker wrote: > > However, VOP_FSYNC(9) with the MNT_WAIT flag seems not to update the > > i_nlink count for a reason unknown to me. I can verify that also by > > taking your reproduction recipe above and adding "fsync ." between > > "rmdir 1" and "mkdir a". > > fsync certainly helps but not as effectively as you'd want. Some > combination of sleeps, fsyncs and mkdir attempts appears to be needed. I have revised the patch and the following version _appears_ to work. http://people.freebsd.org/~jh/patches/ufs-check_linkcnt.2.diff It's still experimental and doesn't handle link(2) or rename(2) at all. In my testing debug.softdep.linkcnt_retries is increased by one with your original reproduction recipe. > I'm also interested in whether it is safe to call VOP_FSYNC at that > point, especially in the case of a rename where a lock on the source > directory vnode may be held at the same time. I think your concern is valid because softdep_fsync() needs to lock parent directories. Possibly you can work around the problem by unlocking the vnodes, doing fsync and then restarting rename. Unfortunately this makes rename even more complex. -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Thu May 30 00:50:00 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C46F5B9E for ; Thu, 30 May 2013 00:50:00 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6073F3 for ; Thu, 30 May 2013 00:50:00 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type; q=dns; s=sweb; b= B+79YKv1Z6RbHDI5/mG3GpkHQQMtHfdDV9Q50Z6fi795Z+XRDysLxAx8Rj0napoL xgxyX8wZMwUahouqW0vgQvxkoXbpLwvk1QPnrTf/gXO09qigO50rgmc/ayUdOmpn TNXQ5aeWqJ4y+4B+lP/SJiuZL4kPYTrVcSSoEbxiROI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type; s=sweb; bh=Rlvr cELeE7DsN54cGggVHdv8Dvs2iCc2SbFFthiu+3o=; b=JoL8H8Fd7Wj6xMQs1hnq Pa3OV+cF0OEuY3rRfaSlAo6ZNfLl9a5hJDZFB/WTvPgpAoVaAjXAMKXZkHdugg1w 0rYR0wMILvik5cs41t39p8F6sOWx+QJ7+znPvoj1BQJ0BK2+8nbUx/XtvIPKAHdO HucZIEW3mMcwBR8fKfRo5fk= Received: (qmail 2510 invoked from network); 29 May 2013 19:43:17 -0500 Received: from unknown (HELO ?10.10.1.133?) (bryan@shatow.net@10.10.1.133) by sweb.xzibition.com with ESMTPA; 29 May 2013 19:43:17 -0500 Message-ID: <51A6A096.8030103@shatow.net> Date: Wed, 29 May 2013 19:43:02 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Subject: NFS+ZFS+nullfs on Server random Permission Denied errors on client (nfsv4) X-Enigmail-Version: 1.5.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2DQXKLBUQPLUNTMLXDRII" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 00:50:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2DQXKLBUQPLUNTMLXDRII Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Server: 9.1-RELEASE mount: > tank/distfiles/freebsd on /tank/distfiles/freebsd (zfs, NFS exported, l= ocal, noatime, noexec, nfsv4acls) /etc/zfs/exports: > /tank/distfiles/freebsd -maproot=3Droot -network 10.10.0.0/16 Clients: 8.3-RELEASE fstab: > tank:/tank/distfiles/freebsd /mnt/distfiles = nfs rw,bg,noatime,intr,rsize=3D65536,wsize=3D65536,re= adahead=3D8,nfsv4 0 0 HEAD r250991: > tank:/tank/distfiles/freebsd /mnt/distfiles nfs = rw,bg,noatime,intr,rsize=3D65536,wsize=3D65536,readahead=3D8,nfsv4 = 0 0 9.1-STABLE r247421: > tank:/tank/distfiles/freebsd /mnt/distfiles nfs = rw,bg,noatime,intr,rsize=3D65536,wsize=3D65536,readahead=3D8,nfsv4 = 0 0 Problem: For months I constantly get random Permission Denied errors on the client side. Just trying the read again can fix the problem. The client will usually show this in dmesg as the same time: > nfsv4 client/server protocol prob err=3D10020 Example errors: > root@c1100_1:/usr/local/poudriere/data/logs/bulk/91amd64-default/2013-0= 5-29_19:17:45/logs/errors # grep "Permission denied" * > dconf-0.12.1_1.log:cannot open gnome3/dconf-0.12.1.tar.xz: Permission d= enied > p5-Pod-Tests-1.19_1.log:pax: Unable to open /mnt/distfiles//Pod-Tests-1= =2E19.tar.gz to read > sofia-sip-1.12.11.log:pax: Unable to open /mnt/distfiles//sofia-sip-1.1= 2.11.tar.gz to read > tex-ptex-3.3_1.log:fetch: texlive-20120701-texmf.tar.xz: Permission den= ied > tkman-2.2_2.log:pax: Unable to open /mnt/distfiles//tkman-2.2.tar.gz to= read I have realized that this problem manifests when I nullfs mount the /tank/distfiles/freebsd directory on the server and start doing reads from it, while also reading from the clients. It became so bad that I had to move my mail off of NFS and back onto the mail server itself since I had questions of where mail had disappeared to= ! Has anyone else experienced this? Is is fixed in STABLE already? Bryan Drewery ------enig2DQXKLBUQPLUNTMLXDRII Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpqCbAAoJEG54KsA8mwz5ZF0P/2HBsQt+HkUJW2KyiRgLOJzg R7pkhy1hkQLFQANYS8PiFHlmjqSbCmDnk3hn2tujjltqYlZ+wIJ0R7XUH7JpLf5w DPozU2rLYvE6HwjgMYlXoG+pbeB/n5dm+35IxsbUjukPyQHU3g6qeQLYs9rMYeR0 aJh0sp+gbEvcycesIrYj4mp7W76K8znaKRXtL+HpLa9nN0w53Yb2OwqlYXJlsXU5 wnBwlaDw7EjMI3selse05za/18Sn7vMv2D1rQPKHehc0auSZehJ51GgT0TcD4Fct 58/r7B3fy5Zwb4nzjXrX0alRWNVKtd8G/NL3Vrn1QyvrlmUeWlIfUgVB9j/QmtBj 1PBBQpRckPg3mSQhzb9YC0Kf8RmjV3peHdMQq8eozESqyZ8EhJuXLDBhfz+rXu4E HZMwc8IzCUVPbcCH927V/9Y6X8HL+MXDVPUtb8lUhIetgj1bm1V1H10ZqDxw+zBv ngd2TBqe/WvUXyTMEH19t/jNn5xv2h5FNRZw0gHUqG0ML9F194Qwt+HmSRssdIbQ 2LM+dVoOri/9Sgil1mXA/fUfLRok4H8I9dKBYGKb0m/95S6BXCw8Z/FdgcLN+0kS UOkVLHfLuEEQOvIUe4K/g4tjuRqA+LqyPqtqtrasibNjhflq7hJxj3snWLhizsoK R3U2voi3JJJRxH/XXDx7 =f1By -----END PGP SIGNATURE----- ------enig2DQXKLBUQPLUNTMLXDRII-- From owner-freebsd-fs@FreeBSD.ORG Thu May 30 01:19:07 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2D9DE9E4 for ; Thu, 30 May 2013 01:19:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id ECD329D0 for ; Thu, 30 May 2013 01:19:06 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAMinplGDaFvO/2dsb2JhbABahnS+RIEadIIjAQEEASNWBRYYAgINGQJZBogaBqgGkhCBJow7fjQHgkOBFAOXO5FAgysggTU2 X-IronPort-AV: E=Sophos;i="4.87,767,1363147200"; d="scan'208";a="30524839" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 29 May 2013 21:18:59 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 918D5B4046; Wed, 29 May 2013 21:18:59 -0400 (EDT) Date: Wed, 29 May 2013 21:18:59 -0400 (EDT) From: Rick Macklem To: Bryan Drewery Message-ID: <316743389.56838.1369876739579.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <51A6A096.8030103@shatow.net> Subject: Re: NFS+ZFS+nullfs on Server random Permission Denied errors on client (nfsv4) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 01:19:07 -0000 Bryan Drewery wrote: > Server: > 9.1-RELEASE > mount: > > tank/distfiles/freebsd on /tank/distfiles/freebsd (zfs, NFS > > exported, local, noatime, noexec, nfsv4acls) > /etc/zfs/exports: > > /tank/distfiles/freebsd -maproot=root -network 10.10.0.0/16 > > Clients: > > 8.3-RELEASE > fstab: > > tank:/tank/distfiles/freebsd /mnt/distfiles nfs > > rw,bg,noatime,intr,rsize=65536,wsize=65536,readahead=8,nfsv4 0 0 > > HEAD r250991: > > tank:/tank/distfiles/freebsd /mnt/distfiles nfs > > rw,bg,noatime,intr,rsize=65536,wsize=65536,readahead=8,nfsv4 0 0 > > 9.1-STABLE r247421: > > tank:/tank/distfiles/freebsd /mnt/distfiles nfs > > rw,bg,noatime,intr,rsize=65536,wsize=65536,readahead=8,nfsv4 0 0 > > Problem: > > For months I constantly get random Permission Denied errors on the > client side. Just trying the read again can fix the problem. The > client > will usually show this in dmesg as the same time: > > nfsv4 client/server protocol prob err=10020 > This error means "no file handle" and I believe it will happen when the client tries to access the root of the exported tree. (The root specified by the "V4: ..." line in /etc/exports.) > Example errors: > > root@c1100_1:/usr/local/poudriere/data/logs/bulk/91amd64-default/2013-05-29_19:17:45/logs/errors > > # grep "Permission denied" * > > dconf-0.12.1_1.log:cannot open gnome3/dconf-0.12.1.tar.xz: > > Permission denied > > p5-Pod-Tests-1.19_1.log:pax: Unable to open > > /mnt/distfiles//Pod-Tests-1.19.tar.gz to read > > sofia-sip-1.12.11.log:pax: Unable to open > > /mnt/distfiles//sofia-sip-1.12.11.tar.gz to read > > tex-ptex-3.3_1.log:fetch: texlive-20120701-texmf.tar.xz: Permission > > denied > > tkman-2.2_2.log:pax: Unable to open /mnt/distfiles//tkman-2.2.tar.gz > > to read > > > I have realized that this problem manifests when I nullfs mount the > /tank/distfiles/freebsd directory on the server and start doing reads > from it, while also reading from the clients. > > It became so bad that I had to move my mail off of NFS and back onto > the > mail server itself since I had questions of where mail had disappeared > to! > > Has anyone else experienced this? Is is fixed in STABLE already? > > > Bryan Drewery There have been assorted commits to nullfs recently, but I have no idea if they will have fixed this. If you want the NFS server to work reliably, I'd recommend you not use nullfs. You should be able to access the ZFS volumes locally in the server safely, just don't put any nullfs mount in the mix. rick From owner-freebsd-fs@FreeBSD.ORG Thu May 30 11:00:16 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 60BC6863 for ; Thu, 30 May 2013 11:00:16 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id D9BD3391 for ; Thu, 30 May 2013 11:00:15 +0000 (UTC) Received: from girgBook.local (citron2.pingpong.net [195.178.173.68]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by melon.pingpong.net (Postfix) with ESMTPSA id F36F02C71C; Thu, 30 May 2013 13:00:13 +0200 (CEST) Message-ID: <51A73141.8070908@FreeBSD.org> Date: Thu, 30 May 2013 13:00:17 +0200 From: Palle Girgensohn User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Kirk McKusick Subject: Re: leaking lots of unreferenced inodes (pg_xlog files?), maybe after moving tables and indexes to tablespace on different volume References: <201303160401.r2G41Um7026132@chez.mckusick.com> <51850E69.5080508@FreeBSD.org> In-Reply-To: <51850E69.5080508@FreeBSD.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org, Dan Thomas , Jeff Roberson , Julian Akehurst X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 11:00:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I forward this message from postgresql hackers. Apparently I am not alone. Dan Thomas is experiencing the same problem: - -------- Ursprungligt meddelande -------- Ämne: Re: [HACKERS] leaking lots of unreferenced inodes (pg_xlog files?), maybe after moving tables and indexes to tablespace on different volume Datum: Wed, 13 Mar 2013 15:09:07 +0000 Från: Dan Thomas Till: Magnus Hagander Kopia: PostgreSQL Hackers We're seeing similar behaviour on several of our FreeBSD servers too. It doesn't look like open files, or filesystem snapshots. Rebooting does reset it, but restarting PG makes no difference. We've got an assortment of different versions of both FreeBSD and PostgreSQL, some of which are demonstrating this behaviour, some aren't. Here's a quick breakdown of versions and what we've got running: FreeBSD PostgreSQL Leaking? 8.0 8.4.4 no 8.2 9.0.4 no 8.3 9.1.4 yes 8.3 9.2.3 yes 9.1 9.2.3 yes All of these machines are under similar load patterns and (apart from the version differences), are set up essentially the same and are doing the same job. They all have hot standbys yet this problem doesn't exist on any of the standby servers. We haven't done anything with tablespaces, the database has its own dedicated partition (although pg_log/pg_xlog are both symlinked out to /usr). However (just to throw a spanner in the works) we do have another server running fbsd8.3/pg9.1.4 which ISN'T showing this behaviour - although its load patterns are quite different. I'm not sure if this is going to help, but here's a graph of this disk space disparity over the last few days (Y axis is in gigabytes). The flat-ish part in the middle is the weekend where we have little traffic, so we can at least say it's not constant: http://i.imgur.com/jlbgzNI.png Up until now we've been upgrading things in the hope that the problem will go away, but since we've got one server up to fbsd9.1/pg9.2.3 and still seeing the problem we're a little stumped. Any ideas about how we can go about debugging this would be appreciated. Thanks, Dan On 13 March 2013 07:39, Magnus Hagander wrote: > > On Mar 13, 2013 3:04 AM, "Tom Lane" wrote: >> >> Palle Girgensohn writes: >>> ... I got lots of space freed up, but it seems that after that >>> the disk usage grows linearly (it seems >>> to leave many inodes unreferenced). >> >> Hm. We've seen issues in the past with PG processes failing to >> close no-longer-useful files promptly, but ... >> >>> Strange thing is I cannot find any open files. >> >> ... that suggests there's something else going on. >> >>> The unreferenced inodes are almost exclusively around 16 MB in >>> size, so i.e. they would most probably all be pg_xlog files. >> >> Have you got any sort of WAL archiving active, and if so maybe >> that's holding onto WAL files? Not that it's clear how come lsof >> wouldn't tattle on an archiving process either. >> >>> Stopping postgresql briefly did not help, I tried that. >> >> That seems to point the finger at some non-postgres cause. I >> confess I can't guess what. >> > > Yeah, unreferenced inodes with no open files, and only discoverable > with fsck sounds like a filsystem bug to me. Particularly since it > showed up just > after a operating system upgrade, and doesn't go away with a > postgres restart... > > /Magnus - -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJRpzFBAAoJEIhV+7FrxBJDNyoH/R88rxJbkzhcmuUOKrRE5EJb XJ17PiJZELKp9A3lWklT6tDPRmWqTGNkslMKToT2Rlic7ErzpozVmob4hJaMuzbl Ak2+PDFhS/B3FbyJ4l+33vfVHKkWy7q4mv/nKNO6fjpsdBdWlY38zqVLTU0CDlLl lyv+KEXNbAaGKjcI5bvKjAmjV3jy5Kg3UlOPmyZHAT1Ce9OsxBETlEeSmjD9v9eg wy/o686r2qBuGSvW1hLhrnmNn3TLyKdTPs3Yo91ebhgeX7ecfjEvT1iHszSdKMls nLjX8eYt3JGaYQjxUguwox2qGuOqcc4s4D24ktNFKnvqcbjCRjljTnSiFz7+yRU= =9Gc1 -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Thu May 30 11:05:19 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 25A549B4 for ; Thu, 30 May 2013 11:05:19 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3380D3EB for ; Thu, 30 May 2013 11:05:17 +0000 (UTC) Received: from girgBook.local (citron2.pingpong.net [195.178.173.68]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by melon.pingpong.net (Postfix) with ESMTPSA id A51082C6C4; Thu, 30 May 2013 12:56:50 +0200 (CEST) Message-ID: <51A73076.8020609@FreeBSD.org> Date: Thu, 30 May 2013 12:56:54 +0200 From: Palle Girgensohn User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Kirk McKusick Subject: Re: leaking lots of unreferenced inodes (pg_xlog files?) References: <201305062250.r46MoWkx091499@chez.mckusick.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/mixed; boundary="------------010605080509040900010402" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@FreeBSD.org, Dan Thomas , Jeff Roberson , Julian Akehurst X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 11:05:19 -0000 This is a multi-part message in MIME format. --------------010605080509040900010402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello again! I have now remounted the postgresql filesystem on a test server that experiences the same problem. The production server is not remounted yet, we're planning that in a weeks time approximately, but I though I could gain som time by running the suggested procedure on the test box. The base problem was this: # df -h /pgsql ; du -hxs /pgsql Filesystem Size Used Avail Capacity Mounted on /dev/da2s1d 128G 101G 17G 86% /pgsql 82G /pgsql df says 101 GB used, but du only finds 82 GB, and fstat cannot find any open files that are unreferenced in the file system. Stopping postgresql does not help. It seems the OS is leaking inode references. FreeBSD 9.1, postgresql 9.2.3 from port. I ran the suggested commans (in attached diskspacecheck) before stopping postgresql (before.log), after stopping postgresql but before unmount /pgsql (before2.log), and then i unmounted /pgsql (had to run umount -f /pgsql, and it took about 20 seconds). I did not enter single-user mode, since I really did not have to this time (On the production server, the disk is /usr, so that will require more shutting down...) I've attach the logs here. Hope it helps! The commands run in diskspaccheck are #! /bin/sh df -ih /pgsql vmstat -z vmstat -m sysctl debug fstat -f /pgsql as suggested by Kirk. Jeff Roberson skrev: > On Mon, 6 May 2013, Kirk McKusick wrote: > >>> Date: Sat, 04 May 2013 15:34:33 +0200 From: Palle Girgensohn >>> To: Kirk McKusick >>> Subject: Re: leaking lots of unreferenced inodes (pg_xlog >>> files?), maybe after moving tables and indexes to tablespace on >>> different volume Cc: freebsd-fs@freebsd.org, Jeff Roberson >>> >>> >>> Hi, >>> >>> Just a quick ping on this issue, it is still happening and we are >>> slowly filling up the disk again. Is seems like we will have to >>> plan a remount within a month given the current graphs. I will be >>> back with info once we have remounted it, running you suggested >>> scripts before and after. >>> >>> Is there anything else I can do to get more debug information? >>> >>> Regards, Palle >> >> In addition to the things that I mentioned previously please also >> run `vmstat -z' before and after the unmount/mount. >> >> Jeff, do you have any other things that you think he should run? >> >> Kirk >> > > Remounting fixes it? Does it require a fsck? I don't have enough > context to comment here. The vmstat will tell us if it's a leak in > a memory reference but that should blow up memory before is saturates > a volume unless the volume is very small. How big is the volume? > How much memory do you have? The inodes show up as used in df -i? > How many more than find sees? What is kern.maxvnodes and > vfs.numvnodes? > > Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJRpzB2AAoJEIhV+7FrxBJDVIYIAK8a2zAx6pUlDn1CDj1AlSb3 jvNRh/YgTUJBj0JSkh93uRqi8A6sy1gGz6PHqOhUE4uN+nNXCIqkYvPkLJ7C8zRW O6LCJ9nSMud6woGpeBRz8V3bu2RbHZMOATZ2f1dyzFPOyB8nU02zsoK3yOojUsWk PpCGIpSZafKfP1A98wKNxFBoo59+HxePqbAEQeP4Cl5+/Hudnj6hwBdB0DsZkhkU 4vSVEzQ360iiQDFTurxIv+CARvtrnhYC+iFxPsQftevEbhlRH5z9YsUZkR5YVms/ h+Y551yqB4NrsRqcw0qQOf9lNb10PK74z7sCrizsIKFonYkXGQSv16AXWXnG95I= =LvOT -----END PGP SIGNATURE----- --------------010605080509040900010402 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="before.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="before.log" U2NyaXB0IHN0YXJ0ZWQgb24gV2VkIE1heSAyOSAxODo1NDoxMyAyMDEzCi4vZGlza3NwYWNl Y2hlY2suc2gNCkZpbGVzeXN0ZW0gICAgIFNpemUgICAgVXNlZCAgIEF2YWlsIENhcGFjaXR5 IGl1c2VkIGlmcmVlICVpdXNlZCAgTW91bnRlZCBvbg0KL2Rldi9kYTJzMWQgICAgMTI4RyAg ICAxMDFHICAgICAxN0cgICAgODYlICAgICAyN2sgICAxN00gICAgMCUgICAvcGdzcWwNCklU RU0gICAgICAgICAgICAgICAgICAgU0laRSAgTElNSVQgICAgIFVTRUQgICAgIEZSRUUgICAg ICBSRVEgRkFJTCBTTEVFUA0KDQpVTUEgS2VnczogICAgICAgICAgICAgICAyMDgsICAgICAg MCwgICAgICA4NiwgICAgICAxNiwgICAgICA4NiwgICAwLCAgIDANClVNQSBab25lczogICAg ICAgICAgICAgMTQwOCwgICAgICAwLCAgICAgIDg2LCAgICAgICAwLCAgICAgIDg2LCAgIDAs ICAgMA0KVU1BIFNsYWJzOiAgICAgICAgICAgICAgNTY4LCAgICAgIDAsICAgIDcwMjMsICAg ICAzMjAsICA2MDkyNjQsICAgMCwgICAwDQpVTUEgUkNudFNsYWJzOiAgICAgICAgICA1Njgs ICAgICAgMCwgICAgNDMzNSwgICAgIDg1MiwgIDM4NzI1NywgICAwLCAgIDANClVNQSBIYXNo OiAgICAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAz LCAgIDAsICAgMA0KMTYgQnVja2V0OiAgICAgICAgICAgICAgMTUyLCAgICAgIDAsICAgICAg MjUsICAgICAgNzUsICAgICAyMDksICAgMCwgICAwDQozMiBCdWNrZXQ6ICAgICAgICAgICAg ICAyODAsICAgICAgMCwgICAgICA0NywgICAgIDE0OSwgICAgIDMzOSwgICA2LCAgIDANCjY0 IEJ1Y2tldDogICAgICAgICAgICAgIDUzNiwgICAgICAwLCAgICAgIDc4LCAgICAgIDc2LCAg ICAgNzUyLCAgOTAsICAgMA0KMTI4IEJ1Y2tldDogICAgICAgICAgICAxMDQ4LCAgICAgIDAs ICAgICA3NzMsICAgICAyNDQsIDE1MTE4OTUsMTQ5NTM1NjYsICAgMA0KVk0gT0JKRUNUOiAg ICAgICAgICAgICAgMjMyLCAgICAgIDAsICAgODAyODksICAxMDU3NDMsMTM3NjE5OTM0LCAg IDAsICAgMA0KTUFQOiAgICAgICAgICAgICAgICAgICAgMjMyLCAgICAgIDAsICAgICAgIDcs ICAgICAgMjUsICAgICAgIDcsICAgMCwgICAwDQpLTUFQIEVOVFJZOiAgICAgICAgICAgICAx MjAsIDExMjg3MTAsICAgICAgNzksICAgNTExMzMsMTcyNTkwMzMyMiwgICAwLCAgIDANCk1B UCBFTlRSWTogICAgICAgICAgICAgIDEyMCwgICAgICAwLCAgICAyMDY3LCAgICA1OTAwLDI5 MzAxODczMSwgICAwLCAgIDANCmZha2VwZzogICAgICAgICAgICAgICAgIDEyMCwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KbXRfem9uZTogICAgICAg ICAgICAgICA0MTEyLCAgICAgIDAsICAgICAzMjYsICAgICAgIDEsICAgICAzMjYsICAgMCwg ICAwDQoxNjogICAgICAgICAgICAgICAgICAgICAgMTYsICAgICAgMCwgICAgMjgxNywgICAg MTU1MSwxNDc0NzQ0NSwgICAwLCAgIDANCjMyOiAgICAgICAgICAgICAgICAgICAgICAzMiwg ICAgICAwLCAgICAyOTU2LCAgICAxMzg3LDQ4ODYxMDc3LCAgIDAsICAgMA0KNjQ6ICAgICAg ICAgICAgICAgICAgICAgIDY0LCAgICAgIDAsICAgIDUzOTgsICAgIDMyODIsODA2MTA2Mzcs ICAgMCwgICAwDQoxMjg6ICAgICAgICAgICAgICAgICAgICAxMjgsICAgICAgMCwgICAgOTg5 OSwgICAgNDg2Miw2Njc3NDg0NzYsICAgMCwgICAwDQoyNTY6ICAgICAgICAgICAgICAgICAg ICAyNTYsICAgICAgMCwgICAgMTAwMCwgICAgNTIyNSwyODE0ODYxOTEzLCAgIDAsICAgMA0K NTEyOiAgICAgICAgICAgICAgICAgICAgNTEyLCAgICAgIDAsICAgIDI3ODgsICAgIDIwMDAs MTc1NjU0NTksICAgMCwgICAwDQoxMDI0OiAgICAgICAgICAgICAgICAgIDEwMjQsICAgICAg MCwgICAgICA3MSwgICAgMTIwOSwgMjEzNDM4NiwgICAwLCAgIDANCjIwNDg6ICAgICAgICAg ICAgICAgICAgMjA0OCwgICAgICAwLCAgICA1NjU3LCAgICAxMjA3LCA0MDA5MTA3LCAgIDAs ICAgMA0KNDA5NjogICAgICAgICAgICAgICAgICA0MDk2LCAgICAgIDAsICAgICA0NTEsICAg IDEwMjEsIDUxNzU2ODgsICAgMCwgICAwDQpGaWxlczogICAgICAgICAgICAgICAgICAgODAs ICAgICAgMCwgICAgIDkyNywgICAxMDI3OCwxOTMwNTk3NDAsICAgMCwgICAwDQpUVVJOU1RJ TEU6ICAgICAgICAgICAgICAxMzYsICAgICAgMCwgICAgMTkzOSwgICAgIDEyMSwgICAgMTk0 OCwgICAwLCAgIDANCnVtdHggcGk6ICAgICAgICAgICAgICAgICA5NiwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KTUFDIGxhYmVsczogICAgICAgICAg ICAgIDQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpQ Uk9DOiAgICAgICAgICAgICAgICAgIDExODQsICAgICAgMCwgICAgICA2OCwgICAgMTQxNywg NDQwNjk0NSwgICAwLCAgIDANClRIUkVBRDogICAgICAgICAgICAgICAgMTEyOCwgICAgICAw LCAgICAxNTQ5LCAgICAgMzg5LCAgICAxOTUxLCAgIDAsICAgMA0KU0xFRVBRVUVVRTogICAg ICAgICAgICAgIDgwLCAgICAgIDAsICAgIDE5MzksICAgICAyNjUsICAgIDE5NDgsICAgMCwg ICAwDQpWTVNQQUNFOiAgICAgICAgICAgICAgICAzOTIsICAgICAgMCwgICAgICA0OSwgICAg MTU0MSwgNDQwNjkyOCwgICAwLCAgIDANCmNwdXNldDogICAgICAgICAgICAgICAgICA3Miwg ICAgICAwLCAgICAgIDg1LCAgICAgIDY1LCAgICAgIDg1LCAgIDAsICAgMA0KYXVkaXRfcmVj b3JkOiAgICAgICAgICAgOTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwDQptYnVmX3BhY2tldDogICAgICAgICAgICAyNTYsICAgICAgMCwgICAgNDA4 MCwgICAgMTI5Niw2ODg1MDM4NTIsICAgMCwgICAwDQptYnVmOiAgICAgICAgICAgICAgICAg ICAyNTYsICAgICAgMCwgICAgMTAyMSwgICAgMTk3MywxOTQyMDI2NTM2LCAgIDAsICAgMA0K bWJ1Zl9jbHVzdGVyOiAgICAgICAgICAyMDQ4LCAgMjU2MDAsICAgIDUzNzYsICAgIDE4OTQs IDE2OTMxODQsICAgMCwgICAwDQptYnVmX2p1bWJvX3BhZ2U6ICAgICAgIDQwOTYsICAxMjgw MCwgICAgICAgMCwgICAgIDcwMCw4MzMxNjU0NiwgICAwLCAgIDANCm1idWZfanVtYm9fOWs6 ICAgICAgICAgOTIxNiwgICA2NDAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMA0KbWJ1Zl9qdW1ib18xNms6ICAgICAgIDE2Mzg0LCAgIDMyMDAsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwDQptYnVmX2V4dF9yZWZjbnQ6ICAgICAgICAgIDQs ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCmdfYmlvOiAg ICAgICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgICAgICAwLCAgICA2MDY0LDI4NzcwODc1 MDAsICAgMCwgICAwDQp0dHlpbnE6ICAgICAgICAgICAgICAgICAxNjAsICAgICAgMCwgICAg IDE1MCwgICAgIDM3OCwgICAgMjQ5MCwgICAwLCAgIDANCnR0eW91dHE6ICAgICAgICAgICAg ICAgIDI1NiwgICAgICAwLCAgICAgIDgwLCAgICAgMzI1LCAgICAxMzI4LCAgIDAsICAgMA0K YXRhX3JlcXVlc3Q6ICAgICAgICAgICAgMzI4LCAgICAgIDAsICAgICAgIDAsICAgICAgODQs ICAgICAgMzIsICAgMCwgICAwDQphdGFfY29tcG9zaXRlOiAgICAgICAgICAzMzYsICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANClZOT0RFOiAgICAgICAg ICAgICAgICAgIDQ4MCwgICAgICAwLCAgMjI0NzU0LCAgIDM0NTI2LDE1Mzc3NjUyMiwgICAw LCAgIDANClZOT0RFUE9MTDogICAgICAgICAgICAgIDExMiwgICAgICAwLCAgICAgICAwLCAg ICAgMTMyLCAgICAgICA2LCAgIDAsICAgMA0KTkFNRUk6ICAgICAgICAgICAgICAgICAxMDI0 LCAgICAgIDAsICAgICAgIDAsICAgIDEyMTIsNDE4ODg2NDM5LCAgIDAsICAgMA0KUyBWRlMg Q2FjaGU6ICAgICAgICAgICAgMTA4LCAgICAgIDAsICAyMzIyMDgsICAgNDM4NzAsMTU4MDQ5 NDQ3LCAgIDAsICAgMA0KU1RTIFZGUyBDYWNoZTogICAgICAgICAgMTQ4LCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpMIFZGUyBDYWNoZTogICAgICAg ICAgICAzMjgsICAgICAgMCwgICAgIDY4MSwgICAgNDk1OSwgNzM3NjcyOSwgICAwLCAgIDAN CkxUUyBWRlMgQ2FjaGU6ICAgICAgICAgIDM2OCwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMA0KTkNMTk9ERTogICAgICAgICAgICAgICAgNTY4LCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpESVJIQVNIOiAgICAg ICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgMTk3MSwgICAgIDYxMywgMjk4MTg3MywgICAw LCAgIDANCk1vdW50cG9pbnRzOiAgICAgICAgICAgIDc5MiwgICAgICAwLCAgICAgICA4LCAg ICAgIDIyLCAgICAgICA4LCAgIDAsICAgMA0KcGlwZTogICAgICAgICAgICAgICAgICAgNzI4 LCAgICAgIDAsICAgICAgMjMsICAgIDEyMDcsIDM4NDg5MjcsICAgMCwgICAwDQprc2lnaW5m bzogICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAgMTQ3NCwgICAgMTQzMCwgOTc3MDQ3 MywgICAwLCAgIDANCml0aW1lcjogICAgICAgICAgICAgICAgIDM0NCwgICAgICAwLCAgICAg ICAxLCAgICAgIDIxLCAgICAgICAxLCAgIDAsICAgMA0KS05PVEU6ICAgICAgICAgICAgICAg ICAgMTI4LCAgICAgIDAsICAgICAgIDAsICAgIDE3MTEsIDEwOTgwMjEsICAgMCwgICAwDQpz b2NrZXQ6ICAgICAgICAgICAgICAgICA2ODAsIDEwMDAwMiwgICAgICA1MiwgICAgMTQwNiwg OTM2NzgzMywgICAwLCAgIDANCmlwcTogICAgICAgICAgICAgICAgICAgICA1NiwgICAgODE5 LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KdWRwX2lucGNiOiAgICAg ICAgICAgICAgMzkyLCAxMDAwMDAsICAgICAgMTMsICAgIDE0MTcsIDczMjgxODksICAgMCwg ICAwDQp1ZHBjYjogICAgICAgICAgICAgICAgICAgMTYsIDEwMDEyOCwgICAgICAxMywgICAg MTgzNSwgNzMyODE4OSwgICAwLCAgIDANCnRjcF9pbnBjYjogICAgICAgICAgICAgIDM5Miwg MTAwMDAwLCAgICAgIDIzLCAgICAxNzM3LCAgNjUyMDYwLCAgIDAsICAgMA0KdGNwY2I6ICAg ICAgICAgICAgICAgICAgOTc2LCAxMDAwMDAsICAgICAgMjMsICAgIDE3NDksICA2NTIwNjAs ICAgMCwgICAwDQp0Y3B0dzogICAgICAgICAgICAgICAgICAgNzIsICAyMDAwMCwgICAgICAg MCwgICAgIDU1MCwgICAgMzI1MSwgICAwLCAgIDANCnN5bmNhY2hlOiAgICAgICAgICAgICAg IDE1MiwgIDE1Mzc1LCAgICAgICAwLCAgICAgNjI1LCAgNTA1NDM5LCAgIDAsICAgMA0KaG9z dGNhY2hlOiAgICAgICAgICAgICAgMTM2LCAgMTUzNzIsICAgICAgIDMsICAgICA0NDUsICAg IDE4MTksICAgMCwgICAwDQp0Y3ByZWFzczogICAgICAgICAgICAgICAgNDAsICAgMTY4MCwg ICAgICAgMCwgICAgMTU5NiwgICAyMTY5MCwgICAwLCAgIDANCnNhY2tob2xlOiAgICAgICAg ICAgICAgICAzMiwgICAgICAwLCAgICAgICAwLCAgICAgOTA5LCAgICAgODc1LCAgIDAsICAg MA0Kc2N0cF9lcDogICAgICAgICAgICAgICAxMzc2LCAxMDAwMDAsICAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgMCwgICAwDQpzY3RwX2Fzb2M6ICAgICAgICAgICAgIDIyODgsICA0 MDAwMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfbGFkZHI6 ICAgICAgICAgICAgICA0OCwgIDgwMDY0LCAgICAgICAwLCAgICAgMjg4LCAgICAgICA2LCAg IDAsICAgMA0Kc2N0cF9yYWRkcjogICAgICAgICAgICAgNzA0LCAgODAwMDAsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpzY3RwX2NodW5rOiAgICAgICAgICAgICAx MzYsIDQwMDAwOCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBf cmVhZHE6ICAgICAgICAgICAgIDEwNCwgNDAwMDMyLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMA0Kc2N0cF9zdHJlYW1fbXNnX291dDogICAgMTEyLCA0MDAwMjYsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpzY3RwX2FzY29uZjogICAgICAg ICAgICAgNDAsIDQwMDAwOCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAN CnNjdHBfYXNjb25mX2FjazogICAgICAgICA0OCwgNDAwMDMyLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMA0KcmlwY2I6ICAgICAgICAgICAgICAgICAgMzkyLCAxMDAw MDAsICAgICAgIDAsICAgICAxMDAsICAgICAxMjIsICAgMCwgICAwDQp1bnBjYjogICAgICAg ICAgICAgICAgICAyNDAsIDEwMDAwMCwgICAgICAxNSwgICAgMTMxMywgMTM4NzQ1NiwgICAw LCAgIDANCnJ0ZW50cnk6ICAgICAgICAgICAgICAgIDIwMCwgICAgICAwLCAgICAgIDIzLCAg ICAgIDkxLCAgICAgIDIzLCAgIDAsICAgMA0Kc2VsZmQ6ICAgICAgICAgICAgICAgICAgIDU2 LCAgICAgIDAsICAgIDIwMzUsICAgIDEzMDQsMzAwMTgwNDcwLCAgIDAsICAgMA0KU1dBUE1F VEE6ICAgICAgICAgICAgICAgMjg4LCAxMTY1MTksICAgICAgNDcsICAgICA1NTEsIDEwNTM1 NjIsICAgMCwgICAwDQpGRlMgaW5vZGU6ICAgICAgICAgICAgICAxNjgsICAgICAgMCwgIDIy NDcxNiwgICA0MTI4NiwxNTM3NzQyODksICAgMCwgICAwDQpGRlMxIGRpbm9kZTogICAgICAg ICAgICAxMjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAN CkZGUzIgZGlub2RlOiAgICAgICAgICAgIDI1NiwgICAgICAwLCAgMjI0NzE2LCAgIDM5OTg5 LDE1Mzc3NDI4MywgICAwLCAgIDANCg0KICAgICAgICAgVHlwZSBJblVzZSBNZW1Vc2UgSGln aFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQ0KQ0FNIGRldiBxdWV1ZSAgICAgNCAgICAgMUsgICAg ICAgLSAgICAgICAgNCAgMTI4DQogIG1kX3NpaV9kYXRhICAgICAwICAgICAwSyAgICAgICAt ICAgICAgIDM4ICA1MTINCiAgICAgIENBTSBYUFQgICA1NzEgIDEwNDVLICAgICAgIC0gICAg ICA5NDMgIDE2LDMyLDY0LDEyOCwyNTYsMTAyNCwyMDQ4DQogICAgICAgaXNhZGV2ICAgICA4 ICAgICAxSyAgICAgICAtICAgICAgICA4ICAxMjgNCiAgICAgICAgIFVBUlQgICAgIDYgICAg IDRLICAgICAgIC0gICAgICAgIDYgIDE2LDUxMiwxMDI0DQogICAgIGFjcGlpbnRyICAgICAx ICAgICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgICAgICAgY2RldiAgICAgNyAgICAg MksgICAgICAgLSAgICAgICAgNyAgMjU2DQogICAgICAgYWNwaWNhICAxNDUxICAgMTM5SyAg ICAgICAtICA2MzA4NTAyICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0DQogICAgICAgIHNp Z2lvICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgICBmaWxlZGVzYyAg IDEyMCAgIDE0MksgICAgICAgLSAgNDkwMzk5MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAy NCwyMDQ4LDQwOTYNCiAgICAgICAgIGtlbnYgICAgNzggICAgMTFLICAgICAgIC0gICAgICAg ODkgIDE2LDMyLDY0LDEyOA0KICAgICAgIGtxdWV1ZSAgICAgMCAgICAgMEsgICAgICAgLSAg MTA1Njk4NyAgMjU2LDUxMiwyMDQ4DQogICAgcHJvYy1hcmdzICAgIDQ5ICAgICAzSyAgICAg ICAtICA2OTY3MzU1ICAxNiwzMiw2NCwxMjgsMjU2DQogICAgICAgIGhob29rICAgICAyICAg ICAxSyAgICAgICAtICAgICAgICAyICAxMjgNCiAgICAgYWNwaXRhc2sgICAgIDEgICAgIDJL ICAgICAgIC0gICAgICAgIDEgIDIwNDgNCiAgICAgIGl0aHJlYWQgICAgOTkgICAgMTZLICAg ICAgIC0gICAgICAgOTkgIDMyLDEyOCwyNTYNCiAgICBDQU0gcXVldWUgICAgMTkgICAgIDdL ICAgICAgIC0gICAgICA0MDcgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgNCiAgICAgICBL VFJBQ0UgICAxMDAgICAgMTNLICAgICAgIC0gICAgICAxMDAgIDEyOA0KICAgICAgIGxpbmtl ciAgIDE1OCAgICAxMUsgICAgICAgLSAgICAgIDE2MCAgMTYsMzIsNjQsNTEyDQogICAgICAg IGxvY2tmICAgIDIwICAgICAzSyAgICAgICAtICAgIDIzOTc2ICA2NCwxMjgNCiAgIGxvZ2lu Y2xhc3MgICAgIDIgICAgIDFLICAgICAgIC0gICAgNTkwNjEgIDY0DQogICAgICAgaXA2bmRw ICAgIDEyICAgICAxSyAgICAgICAtICAgICAgIDE0ICA2NCwxMjgNCiAgICAgICAgIHRlbXAg ICAgNTEgICAgIDJLICAgICAgIC0gIDgyMTc2NTAgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEw MjQsMjA0OCw0MDk2DQogICAgICAgZGV2YnVmICA4NjQ4IDQxODg5SyAgICAgICAtICAgIDEw MTQzICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAgICAgIG1vZHVs ZSAgIDQ3NyAgICA2MEsgICAgICAgLSAgICAgIDQ3NyAgMTI4DQogICAgY2lzc19kYXRhICAg IDE1ICAgIDE0SyAgICAgICAtICAgICA1OTIxICAxNiwxMjgsMjU2LDUxMiwxMDI0LDIwNDgs NDA5Ng0KICAgICBtdHhfcG9vbCAgICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgDQog ICAgICAgVVNCZGV2ICAgIDM0ICAgICA4SyAgICAgICAtICAgICAgIDQ0ICA2NCwxMjgsNTEy LDQwOTYNCiAgICAgICAgICBVU0IgICAgNTIgICAgMzFLICAgICAgIC0gICAgICAgNjYgIDE2 LDMyLDY0LDEyOCwyNTYsMjA0OCw0MDk2DQogICAgIHBtY2hvb2tzICAgICAxICAgICAxSyAg ICAgICAtICAgICAgICAxICAxMjgNCiAgICAgIHN1YnByb2MgIDE1NTYgIDEwMjBLICAgICAg IC0gIDQ0MDg0MzQgIDUxMiw0MDk2DQogICAgICAgICBwcm9jICAgICAyICAgIDE2SyAgICAg ICAtICAgICAgICAyICANCiAgICAgIHNlc3Npb24gICAgNDMgICAgIDZLICAgICAgIC0gIDM1 NTA2NzQgIDEyOA0KICAgICAgICAgcGdycCAgICA0NyAgICAgNksgICAgICAgLSAgMzU1NTA4 NyAgMTI4DQogICAgICAgICBjcmVkICAgIDYwICAgIDEwSyAgICAgICAtIDMyODc2MTYwICA2 NCwyNTYNCiAgICAgIHVpZGluZm8gICAgIDYgICAgIDNLICAgICAgIC0gICAxODY4NTkgIDEy OCwyMDQ4DQogICAgICAgcGxpbWl0ICAgIDE3ICAgICA1SyAgICAgICAtICAgNzcwNjk2ICAy NTYNCiAgICAgIGF0YV9wY2kgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0DQog ICAgICBzY3NpX2NkICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDEwICAxNg0KICAgIHN5 c2N0bHRtcCAgICAgMCAgICAgMEsgICAgICAgLSAgICAxNDIyMCAgMTYsMzIsNjQsMTI4LDQw OTYNCiAgICBzeXNjdGxvaWQgIDQ5NzggICAyNTFLICAgICAgIC0gICAgIDUzNjAgIDE2LDMy LDY0LDEyOA0KICAgICAgIHN5c2N0bCAgICAgMCAgICAgMEsgICAgICAgLSAgNzk1NTc4OSAg MTYsMzIsNjQNCiAgICAgIHRpZGhhc2ggICAgIDEgICAgMTZLICAgICAgIC0gICAgICAgIDEg IA0KICAgICAgY2FsbG91dCAgICAgNyAxNDMzNksgICAgICAgLSAgICAgICAgNyAgDQogICAg ICAgICB1bXR4ICAzODc2ICAgNDg1SyAgICAgICAtICAgICAzODk0ICAxMjgNCiAgICAgcDEw MDMuMWIgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDE2DQogICAgICAgICBTV0FQ ICAgICAyICAgNTQ5SyAgICAgICAtICAgICAgICAyICA2NA0KICAgICAgIGJ1cy1zYyAgIDEx MyAgIDc4MUsgICAgICAgLSAgICAgNTIzNCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwy MDQ4LDQwOTYNCiAgICAgICAgICBidXMgIDEyODIgICAxMDlLICAgICAgIC0gICAgIDg2MjYg IDE2LDMyLDY0LDEyOCwyNTYsMTAyNA0KICAgICAgZGV2c3RhdCAgICAxMiAgICAyNUsgICAg ICAgLSAgICAgICAxMiAgMzIsNDA5Ng0KIGV2ZW50aGFuZGxlciAgICA3NyAgICAgNksgICAg ICAgLSAgICAgICA3NyAgNjQsMTI4DQogICAgICBhY3Bpc2VtICAgIDE5ICAgICAzSyAgICAg ICAtICAgICAgIDE5ICAxMjgNCiAgICAgICAgIGtvYmogICAzMzAgIDEzMjBLICAgICAgIC0g ICAgICA2MjYgIDQwOTYNCiAgICAgIENBTSBTSU0gICAgIDUgICAgIDJLICAgICAgIC0gICAg ICAgIDUgIDI1Ng0KICAgICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAg MSAgMzINCiAgIENBTSBwZXJpcGggICAgMTAgICAgIDNLICAgICAgIC0gICAgICAgNTQgIDE2 LDMyLDY0LDEyOCwyNTYNCiAgICAgICAgIHJtYW4gICAyNDggICAgMjZLICAgICAgIC0gICAg ICA2MTMgIDE2LDMyLDEyOA0KICAgICAgICAgc2J1ZiAgICAgMSAgICAgMUsgICAgICAgLSAg ICAgMjA2MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgIGVu dHJvcHkgIDEwMjQgICAgNjRLICAgICAgIC0gICAgIDEwMjQgIDY0DQogICAgICAgY3RsbWVt ICA1MDYyIDEwMTEzSyAgICAgICAtICAgICA1MDYyICAxMjgsMjA0OA0KICAgICAgICBzdGFj ayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAgMjU2DQogICAgdGFza3F1ZXVlICAg IDE1ICAgICAySyAgICAgICAtICAgICAgIDE1ICAxNiwzMiwxMjgNCiAgICAgICBVbml0bm8g ICAgMTQgICAgIDFLICAgICAgIC0gICA1OTY3MTYgIDMyLDY0DQogICAgICAgICAgaW92ICAg ICAwICAgICAwSyAgICAgICAtICAxNTYwNzMyICAxNiwzMiw2NCwxMjgsMjU2LDUxMg0KICAg ICAgIHNlbGVjdCAgMTQ1NSAgIDE4MksgICAgICAgLSAgICAgMTQ1NSAgMTI4DQogICAgIGlv Y3Rsb3BzICAgICAwICAgICAwSyAgICAgICAtICA4NDk3MDU4ICAxNiwzMiw2NCwxMjgsMjU2 LDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAgICAgICAgIG1zZyAgICAgNCAgICAzMEsgICAgICAg LSAgICAgICAgNCAgMjA0OCw0MDk2DQogICAgICAgICAgc2VtICAgICA0ICAgMTk2SyAgICAg ICAtICAgICAgICA0ICANCiAgICAgICAgICBzaG0gICAgMjEgICAgNjBLICAgICAgIC0gIDMz NDkyNzggIDIwNDgNCiAgICAgICAgICB0dHkgICAgMjQgICAgMjRLICAgICAgIC0gICAgICAx NDggIDEwMjQsMjA0OA0KICAgICAgICAgIHB0cyAgICAgMyAgICAgMUsgICAgICAgLSAgICAg IDEyNSAgMjU2DQogICAgIG1idWZfdGFnICAgICAwICAgICAwSyAgICAgICAtIDQzMzQ0NjUy ICAzMiwxMjgNCiAgICAgICAgc2htZmQgICAgIDEgICAgIDhLICAgICAgIC0gICAgICAgIDEg IA0KICAgICAgICAgIHBjYiAgICAyMyAgIDE1N0sgICAgICAgLSAgIDYyOTA4OCAgMTYsMzIs MTI4LDEwMjQsMjA0OCw0MDk2DQogICAgICAgc29uYW1lICAgICA1ICAgICAxSyAgICAgICAt IDUyMjI5NjIyICAxNiwzMiwxMjgNCiAgICAgICAgICBhY2wgICAgIDAgICAgIDBLICAgICAg IC0gICAxNDQxMDEgIDQwOTYNCiAgICAgICBiaW9idWYgICAgIDEgICAgIDJLICAgICAgIC0g ICAgMTQ2ODMgIDIwNDgNCiAgICAgdmZzY2FjaGUgICAgIDEgIDgxOTJLICAgICAgIC0gICAg ICAgIDEgIA0KICAgY2xfc2F2ZWJ1ZiAgICAgMCAgICAgMEsgICAgICAgLSAxMDE3MDgzODIg IDY0LDEyOA0KICAgICB2ZnNfaGFzaCAgICAgMSAgNDA5NksgICAgICAgLSAgICAgICAgMSAg DQogICAgICAgREVWRlMxICAgMTE2ICAgIDU4SyAgICAgICAtICAgICAgMjYxICA1MTINCiAg ICAgICB2bm9kZXMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDQgIDY0LDI1Ng0KICAg ICAgIERFVkZTMyAgIDEzMiAgICAzM0sgICAgICAgLSAgICAgIDI4MSAgMjU2DQogICAgICAg IG1vdW50ICAgMTA2ICAgICA1SyAgICAgICAtICAgICAgMTc2ICAxNiwzMiw2NCwxMjgsMjU2 DQogIHZub2RlbWFya2VyICAgICAwICAgICAwSyAgICAgICAtICA1MDYyMzExICA1MTINCiAg ICAgICAgICBCUEYgICAgIDkgICAgIDJLICAgICAgIC0gICAgICAgIDkgIDEyOA0KICBldGhl cl9tdWx0aSAgICA1NiAgICAgM0sgICAgICAgLSAgICAgICA2NiAgMTYsMzIsNjQNCiAgICAg ICBpZmFkZHIgICAgODcgICAgMjJLICAgICAgIC0gICAgICAgODcgIDMyLDY0LDEyOCwyNTYs NTEyLDQwOTYNCiAgICAgICAgaWZuZXQgICAgMTAgICAgMTlLICAgICAgIC0gICAgICAgMTAg IDEyOCwyMDQ4DQogICAgICAgIGNsb25lICAgICA2ICAgIDI0SyAgICAgICAtICAgICAgICA2 ICA0MDk2DQogICAgICAgYXJwY29tICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAx Ng0KICAgICAgbGx0YWJsZSAgICAzMSAgICAxM0sgICAgICAgLSAgICA1ODQ4MiAgMjU2LDUx Mg0KICAgICAgICBERVZGUyAgICAxNyAgICAgMUsgICAgICAgLSAgICAgICAyMCAgMTYsMTI4 DQogICAgICAgREVWRlNQICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAyICA2NA0KICAg ICByb3V0ZXRibCAgICA0NCAgICAgNksgICAgICAgLSAgMTQ2NDIwMiAgMzIsNjQsMTI4LDI1 Niw1MTINCiAgICAgICAgIGlnbXAgICAgIDkgICAgIDNLICAgICAgIC0gICAgICAgIDkgIDI1 Ng0KICAgICBpbl9tdWx0aSAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMjU2DQog ICAgc2N0cF9pdGVyICAgICAwICAgICAwSyAgICAgICAtICAgICAgICA0ICAyNTYNCiAgICAg c2N0cF9pZm4gICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDEyOA0KICAgICBzY3Rw X2lmYSAgICAgNyAgICAgMUsgICAgICAgLSAgICAgICAgNyAgMTI4DQogICAgIHNjdHBfdnJm ICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgIHNjdHBfYV9pdCAgICAg MCAgICAgMEsgICAgICAgLSAgICAgICAgNCAgMTYNCiAgICBob3N0Y2FjaGUgICAgIDEgICAg MjhLICAgICAgIC0gICAgICAgIDEgIA0KICAgICBzeW5jYWNoZSAgICAgMSAgICA5NksgICAg ICAgLSAgICAgICAgMSAgDQogICAgaW42X211bHRpICAgIDI4ICAgICA0SyAgICAgICAtICAg ICAgIDI4ICAzMiwyNTYNCiAgICAgICAgICBtbGQgICAgIDkgICAgIDJLICAgICAgIC0gICAg ICAgIDkgIDEyOA0KICAgICAgICAgIHJwYyAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAg MiAgMjU2DQphdWRpdF9ldmNsYXNzICAgMTc5ICAgICA2SyAgICAgICAtICAgICAgMjE4ICAz Mg0KICAgICBzYXZlZGlubyAgICAgMCAgICAgMEsgICAgICAgLSAgMzA4MzIyMyAgMjU2DQog ICAgIGZyZWV3b3JrICAgICAxICAgICAxSyAgICAgICAtIDgwNTQ4Njg1ICAxNiwxMjgNCiAg ICBuZXdkaXJibGsgICAgIDAgICAgIDBLICAgICAgIC0gICAgMTgzMzcgIDY0DQogICAgICAg ZGlycmVtICAgICAxICAgICAxSyAgICAgICAtIDEzMDgyOTk2ICAxMjgNCiAgICAgICAgbWtk aXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgMjk0MzYgIDEyOA0KICAgICAgIGRpcmFkZCAg ICAgMSAgICAgMUsgICAgICAgLSAxMzA5MTIyOSAgMTI4DQogICAgIGZyZWVmaWxlICAgICAx ICAgICAxSyAgICAgICAtICA2NzEzOTI3ICA2NA0KICAgICBmcmVlYmxrcyAgICAgMCAgICAg MEsgICAgICAgLSAgNjYxMTI5NCAgMTI4DQogICAgIGZyZWVmcmFnICAgICAwICAgICAwSyAg ICAgICAtIDQyNzU4MjI0NCAgMTI4DQogICAgIGluZGlyZGVwICAgICAxICAgICAxSyAgICAg ICAtICA2MjUxOTA2ICAxMjgNCiAgICAgICBuZXdibGsgICA0MDcgICA2MTRLICAgICAgIC0g Mjc4MTg2MjE0MSAgMjU2DQogICAgYm1zYWZlbWFwICAgIDEwICAgIDExSyAgICAgICAtICA4 OTM4MzUyICAyNTYNCiAgICAgaW5vZGVkZXAgICAgIDUgIDQwOThLICAgICAgIC0gIDc4MzIw NTkgIDUxMg0KICAgICAgcGFnZWRlcCAgICAgMiAgIDUxM0sgICAgICAgLSAgIDEzOTExOCAg MjU2DQogIHVmc19kaXJoYXNoICAxNDYyICAgMzcySyAgICAgICAtICAgNDAxNjQ0ICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwxMDI0DQogICAgdWZzX21vdW50ICAgIDE4ICAgIDY5SyAgICAg ICAtICAgICAgIDE4ICA1MTIsMjA0OCw0MDk2DQogICAgdm1fcGdkYXRhICAgICAyICAgMTI5 SyAgICAgICAtICAgICAgICAyICAxMjgNCiAgICAgIFVNQUhhc2ggICAgIDMgICAgMjJLICAg ICAgIC0gICAgICAgMTMgIDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAgICAgbWVtZGVzYyAgICAg MSAgICAgNEsgICAgICAgLSAgICAgICAgMSAgNDA5Ng0KICAgICBhdGtiZGRldiAgICAgMiAg ICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQNCiAgICBwZnNfbm9kZXMgICAgMjEgICAgIDZL ICAgICAgIC0gICAgICAgMjEgIDI1Ng0KICBwZnNfdm5jYWNoZSAgICAgMSAgICAgMUsgICAg ICAgLSAgICAgIDI2MCAgNjQNCiAgICAgICBjdGxibGsgICAyMDAgIDE2MDBLICAgICAgIC0g ICAgICAyMDAgIA0KICAgICAgICAgR0VPTSAgIDEyNyAgICA0MEsgICAgICAgLSAgICAgMTMx MiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4DQogICAgICByYW1kaXNrICAgICAx ICA0MDk2SyAgICAgICAtICAgICAgICAxICANCiAgICAgIGFjcGlkZXYgICAgMzAgICAgIDJL ICAgICAgIC0gICAgICAgMzAgIDY0DQogICAgICBjdGxwb29sICAgNTMyICAgMTQySyAgICAg ICAtICAgICAgNTMyICAzMiw1MTINCiAgICAgICBrYmRtdXggICAgIDcgICAgMThLICAgICAg IC0gICAgICAgIDggIDE2LDUxMiwxMDI0LDIwNDgNCiAgICAgICBhcG1kZXYgICAgIDEgICAg IDFLICAgICAgIC0gICAgICAgIDEgIDEyOA0KICAgbWFkdF90YWJsZSAgICAgMCAgICAgMEsg ICAgICAgLSAgICAgICAgMSAgNDA5Ng0KICAgICAgIGZlZWRlciAgICAgNyAgICAgMUsgICAg ICAgLSAgICAgICAgNyAgMzINCiAgICAgIHNjc2lfZGEgICAgIDAgICAgIDBLICAgICAgIC0g ICAgICAyNjYgIDE2DQogICAgIHBjaV9saW5rICAgIDE2ICAgICAySyAgICAgICAtICAgICAg IDE2ICAxNiwxMjgNCiAgICByYWlkX2RhdGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAy MzQgIDMyLDEyOCwyNTYNCiAgICAgIGlvX2FwaWMgICAgIDEgICAgIDJLICAgICAgIC0gICAg ICAgIDEgIDIwNDgNCiAgICAgICAgICBNQ0EgICAgIDggICAgIDFLICAgICAgIC0gICAgICAg IDggIDEyOA0KICAgICAgICAgIG1zaSAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAg MTI4DQogICAgIG5leHVzZGV2ICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAxNg0K bWRfbnZpZGlhX2RhdGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMzggIDUxMg0KZGVi dWcuYWNwaS5zdXNwZW5kX2JvdW5jZTogMA0KZGVidWcuYWNwaS5yZXNldF9jbG9jazogMQ0K ZGVidWcuYWNwaS5pbnRlcnByZXRlcl9zbGFjazogMQ0KZGVidWcuYWNwaS5lbmFibGVfZGVi dWdfb2JqZWN0czogMA0KZGVidWcuYWNwaS5hY3BpX2NhX3ZlcnNpb246IDIwMTEwNTI3DQpk ZWJ1Zy5hY3BpLmNwdV91bm9yZGVyZWQ6IDANCmRlYnVnLmFjcGkuZWMudGltZW91dDogNzUw DQpkZWJ1Zy5hY3BpLmVjLnBvbGxlZDogMA0KZGVidWcuYWNwaS5lYy5idXJzdDogMA0KZGVi dWcuYWNwaS5iYXR0LmJhdHRfc2xlZXBfbXM6IDANCmRlYnVnLmFjcGkucmVzdW1lX2JlZXA6 IDANCmRlYnVnLmZpcmV3aXJlX2RlYnVnOiAwDQpkZWJ1Zy5md21lbV9kZWJ1ZzogMA0KZGVi dWcuaWZfZndlX2RlYnVnOiAwDQpkZWJ1Zy5pZl9md2lwX2RlYnVnOiAwDQpkZWJ1Zy5pcHc6 IDANCmRlYnVnLml3aTogMA0KZGVidWcubWRkZWJ1ZzogMA0KZGVidWcud3BpOiAwDQpkZWJ1 Zy5lbGY2NF9sZWdhY3lfY29yZWR1bXA6IDANCmRlYnVnLmJvb3R2ZXJib3NlOiAwDQpkZWJ1 Zy5ib290aG93dG86IDANCmRlYnVnLmNwdWZyZXEudmVyYm9zZTogMA0KZGVidWcuY3B1ZnJl cS5sb3dlc3Q6IDANCmRlYnVnLmZhaWxfcG9pbnQuc3lzY3RsX3J1bm5pbmc6IG9mZg0KZGVi dWcuZmFpbF9wb2ludC5idWZfcHJlc3N1cmU6IG9mZg0KZGVidWcuZmFpbF9wb2ludC5ubG1f ZGVueV9ncmFudDogb2ZmDQpkZWJ1Zy5hZGFwdGl2ZV9tYWNoaW5lX2FyY2g6IDENCmRlYnVn LnNpemVvZi5jZGV2X3ByaXY6IDM3Ng0KZGVidWcuc2l6ZW9mLmNkZXY6IDI4OA0KZGVidWcu c2l6ZW9mLmdfYmlvcTogNTYNCmRlYnVnLnNpemVvZi5nX2NvbnN1bWVyOiA5Ng0KZGVidWcu c2l6ZW9mLmdfcHJvdmlkZXI6IDEzNg0KZGVidWcuc2l6ZW9mLmdfZ2VvbTogMTYwDQpkZWJ1 Zy5zaXplb2YuZ19jbGFzczogMTYwDQpkZWJ1Zy5zaXplb2Yua2luZm9fcHJvYzogMTA4OA0K ZGVidWcuc2l6ZW9mLmJ1ZjogNjA4DQpkZWJ1Zy5zaXplb2YuYmlvOiAyMzINCmRlYnVnLnNp emVvZi5wcm9jOiAxMTg0DQpkZWJ1Zy5zaXplb2Yudm5vZGU6IDQ4MA0KZGVidWcuc2l6ZW9m LmRldnN0YXQ6IDI4OA0KZGVidWcuc2l6ZW9mLm5hbWVjYWNoZTogNzINCmRlYnVnLm9zZDog MA0KZGVidWcudHJhY2Vfb25fcGFuaWM6IDENCmRlYnVnLmRlYnVnZ2VyX29uX3BhbmljOiAx DQpkZWJ1Zy5uY29yZXM6IDUNCmRlYnVnLnRvX2F2Z19tcGNhbGxzOiA3NDUNCmRlYnVnLnRv X2F2Z19sb2NrY2FsbHM6IDI0NQ0KZGVidWcudG9fYXZnX2djYWxsczogNDk2DQpkZWJ1Zy50 b19hdmdfZGVwdGg6IDE5MjgNCmRlYnVnLnVtdHgudW10eF9waV9hbGxvY2F0ZWQ6IDANCmRl YnVnLmNsb2NrdGltZTogMA0KZGVidWcua2RiLmFsdF9icmVha190b19kZWJ1Z2dlcjogMA0K ZGVidWcua2RiLmJyZWFrX3RvX2RlYnVnZ2VyOiAwDQpkZWJ1Zy5rZGIudHJhcF9jb2RlOiAw DQpkZWJ1Zy5rZGIudHJhcDogMA0KZGVidWcua2RiLnBhbmljOiAwDQpkZWJ1Zy5rZGIuZW50 ZXI6IDANCmRlYnVnLmtkYi5jdXJyZW50OiANCmRlYnVnLnJtYW5fZGVidWc6IDANCmRlYnVn Lmlvc2l6ZV9tYXhfY2xhbXA6IDENCmRlYnVnLmRpc2FibGVmdWxscGF0aDogMA0KZGVidWcu ZGlzYWJsZWN3ZDogMA0KZGVidWcudmZzY2FjaGU6IDENCmRlYnVnLm51bWNhY2hlaHY6IDI1 MjM0DQpkZWJ1Zy5udW1jYWNoZTogMjMyODg5DQpkZWJ1Zy5udW1uZWc6IDEyMTQ2DQpkZWJ1 Zy5uY2hhc2g6IDEwNDg1NzUNCmRlYnVnLnZubHJ1X25vd2hlcmU6IDANCmRlYnVnLnJ1c2hf cmVxdWVzdHM6IDM3MDI4MQ0KZGVidWcuaWZfdHVuX2RlYnVnOiAwDQpkZWJ1Zy5ubG1fZGVi dWc6IDANCmRlYnVnLmZzY2tjbWRzOiAwDQpkZWJ1Zy5jb2xsZWN0c25hcHN0YXRzOiAwDQpk ZWJ1Zy5zbmFwZGVidWc6IDANCmRlYnVnLmRvcGVyc2lzdGVuY2U6IDANCmRlYnVnLnNvZnRk ZXAuY2xlYW51cF9mYWlsdXJlczogMzY5NjM0DQpkZWJ1Zy5zb2Z0ZGVwLmNsZWFudXBfcmV0 cmllczogODI2DQpkZWJ1Zy5zb2Z0ZGVwLmNsZWFudXBfaGlnaF9kZWxheTogMTQNCmRlYnVn LnNvZnRkZXAuY2xlYW51cF9pbm9yZXF1ZXN0czogMA0KZGVidWcuc29mdGRlcC5jbGVhbnVw X2Jsa3JlcXVlc3RzOiAzNjk2OTANCmRlYnVnLnNvZnRkZXAuandhaXRfbmV3YmxrOiAwDQpk ZWJ1Zy5zb2Z0ZGVwLmp3YWl0X2lub2RlOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmp3YWl0X2ZyZWVi bGtzOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmp3YWl0X2ZpbGVwYWdlOiAwDQpkZWJ1Zy5zb2Z0ZGVw LmpvdXJuYWxfd2FpdDogMA0KZGVidWcuc29mdGRlcC5qb3VybmFsX21pbjogMA0KZGVidWcu c29mdGRlcC5qb3VybmFsX2xvdzogMA0KZGVidWcuc29mdGRlcC5qbmV3YmxrX3JvbGxiYWNr OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmphZGRyZWZfcm9sbGJhY2s6IDANCmRlYnVnLnNvZnRkZXAu ZGlyX2VudHJ5OiAxOTU2NTkNCmRlYnVnLnNvZnRkZXAuZGlyZWN0X2Jsa19wdHJzOiAzMzkw MjENCmRlYnVnLnNvZnRkZXAuaW5vZGVfYml0bWFwOiAyNTAzNzMwDQpkZWJ1Zy5zb2Z0ZGVw LmluZGlyX2Jsa19wdHJzOiAyNjg4MQ0KZGVidWcuc29mdGRlcC5zeW5jX2xpbWl0X2hpdDog NTkxDQpkZWJ1Zy5zb2Z0ZGVwLmlub19saW1pdF9oaXQ6IDANCmRlYnVnLnNvZnRkZXAuYmxr X2xpbWl0X2hpdDogMzY5MjIwDQpkZWJ1Zy5zb2Z0ZGVwLmlub19saW1pdF9wdXNoOiAwDQpk ZWJ1Zy5zb2Z0ZGVwLmJsa19saW1pdF9wdXNoOiAzNjk2OTANCmRlYnVnLnNvZnRkZXAud29y a2xpc3RfcHVzaDogMjE1Ng0KZGVidWcuc29mdGRlcC5tYXhpbmRpcmRlcHM6IDUwDQpkZWJ1 Zy5zb2Z0ZGVwLnRpY2tkZWxheTogMg0KZGVidWcuc29mdGRlcC5tYXhfc29mdGRlcHM6IDIz NTIzMDgNCmRlYnVnLnNvZnRkZXAud3JpdGUuamZzeW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndy aXRlLmp0cnVuYzogMA0KZGVidWcuc29mdGRlcC53cml0ZS5zYmRlcDogMA0KZGVidWcuc29m dGRlcC53cml0ZS5qc2VnZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpzZWc6IDANCmRl YnVnLnNvZnRkZXAud3JpdGUuamZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpm cmVlYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpuZXdibGs6IDANCmRlYnVnLnNvZnRk ZXAud3JpdGUuam12cmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpyZW1yZWY6IDANCmRl YnVnLnNvZnRkZXAud3JpdGUuamFkZHJlZjogMA0KZGVidWcuc29mdGRlcC53cml0ZS5mcmVl ZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmZyZWV3b3JrOiAwDQpkZWJ1Zy5zb2Z0ZGVw LndyaXRlLm5ld2RpcmJsazogMA0KZGVidWcuc29mdGRlcC53cml0ZS5kaXJyZW06IDANCmRl YnVnLnNvZnRkZXAud3JpdGUubWtkaXI6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZGlyYWRk OiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmZyZWVmaWxlOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndy aXRlLmZyZWVibGtzOiA2Njg5NTgNCmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZWZyYWc6IDAN CmRlYnVnLnNvZnRkZXAud3JpdGUuYWxsb2NpbmRpcjogMjI0ODAxMTMxNg0KZGVidWcuc29m dGRlcC53cml0ZS5pbmRpcmRlcDogMTE1NDM5DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmFsbG9j ZGlyZWN0OiA3NDI1NDAxMw0KZGVidWcuc29mdGRlcC53cml0ZS5uZXdibGs6IDANCmRlYnVn LnNvZnRkZXAud3JpdGUuYm1zYWZlbWFwOiAyMzkzOTA2DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRl Lmlub2RlZGVwOiA2ODAxMTA5DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLnBhZ2VkZXA6IDMyMDMx Mw0KZGVidWcuc29mdGRlcC5jdXJyZW50Lmpmc3luYzogMA0KZGVidWcuc29mdGRlcC5jdXJy ZW50Lmp0cnVuYzogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LnNiZGVwOiAwDQpkZWJ1Zy5z b2Z0ZGVwLmN1cnJlbnQuanNlZ2RlcDogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpzZWc6 IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qZnJlZWZyYWc6IDANCmRlYnVnLnNvZnRkZXAu Y3VycmVudC5qZnJlZWJsazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpuZXdibGs6IDAN CmRlYnVnLnNvZnRkZXAuY3VycmVudC5qbXZyZWY6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVu dC5qcmVtcmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuamFkZHJlZjogMA0KZGVidWcu c29mdGRlcC5jdXJyZW50LmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5mcmVl d29yazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50Lm5ld2RpcmJsazogMA0KZGVidWcuc29m dGRlcC5jdXJyZW50LmRpcnJlbTogMQ0KZGVidWcuc29mdGRlcC5jdXJyZW50Lm1rZGlyOiAw DQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZGlyYWRkOiAxDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJl bnQuZnJlZWZpbGU6IDENCmRlYnVnLnNvZnRkZXAuY3VycmVudC5mcmVlYmxrczogMA0KZGVi dWcuc29mdGRlcC5jdXJyZW50LmZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQu YWxsb2NpbmRpcjogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmluZGlyZGVwOiAxDQpkZWJ1 Zy5zb2Z0ZGVwLmN1cnJlbnQuYWxsb2NkaXJlY3Q6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVu dC5uZXdibGs6IDQwNg0KZGVidWcuc29mdGRlcC5jdXJyZW50LmJtc2FmZW1hcDogOQ0KZGVi dWcuc29mdGRlcC5jdXJyZW50Lmlub2RlZGVwOiA0DQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQu cGFnZWRlcDogMQ0KZGVidWcuc29mdGRlcC50b3RhbC5qZnN5bmM6IDANCmRlYnVnLnNvZnRk ZXAudG90YWwuanRydW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLnNiZGVwOiAwDQpkZWJ1 Zy5zb2Z0ZGVwLnRvdGFsLmpzZWdkZXA6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuanNlZzog MA0KZGVidWcuc29mdGRlcC50b3RhbC5qZnJlZWZyYWc6IDANCmRlYnVnLnNvZnRkZXAudG90 YWwuamZyZWVibGs6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuam5ld2JsazogMA0KZGVidWcu c29mdGRlcC50b3RhbC5qbXZyZWY6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuanJlbXJlZjog MA0KZGVidWcuc29mdGRlcC50b3RhbC5qYWRkcmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFs LmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuZnJlZXdvcms6IDgwNTQ4Njg0DQpk ZWJ1Zy5zb2Z0ZGVwLnRvdGFsLm5ld2RpcmJsazogMTgzMzcNCmRlYnVnLnNvZnRkZXAudG90 YWwuZGlycmVtOiAxMzA4Mjk5Ng0KZGVidWcuc29mdGRlcC50b3RhbC5ta2RpcjogMjk0MzYN CmRlYnVnLnNvZnRkZXAudG90YWwuZGlyYWRkOiAxMzA5MTIyOQ0KZGVidWcuc29mdGRlcC50 b3RhbC5mcmVlZmlsZTogNjcxMzkyNw0KZGVidWcuc29mdGRlcC50b3RhbC5mcmVlYmxrczog NjYxMTI5NA0KZGVidWcuc29mdGRlcC50b3RhbC5mcmVlZnJhZzogNDI3NTgyMjQ0DQpkZWJ1 Zy5zb2Z0ZGVwLnRvdGFsLmFsbG9jaW5kaXI6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuaW5k aXJkZXA6IDYyMjUwMjUNCmRlYnVnLnNvZnRkZXAudG90YWwuYWxsb2NkaXJlY3Q6IDANCmRl YnVnLnNvZnRkZXAudG90YWwubmV3YmxrOiAyNzgxODYyMTQwDQpkZWJ1Zy5zb2Z0ZGVwLnRv dGFsLmJtc2FmZW1hcDogODkzODM1MQ0KZGVidWcuc29mdGRlcC50b3RhbC5pbm9kZWRlcDog NzgzMjA1OA0KZGVidWcuc29mdGRlcC50b3RhbC5wYWdlZGVwOiAxMzkxMTcNCmRlYnVnLmRv YmtncmR3cml0ZTogMQ0KZGVidWcuYmlnY2dzOiAwDQpkZWJ1Zy5kaXJjaGVjazogMA0KZGVi dWcucHNtLnBrdGVycnRocmVzaDogMg0KZGVidWcucHNtLnVzZWNzOiA1MDAwMDANCmRlYnVn LnBzbS5zZWNzOiAwDQpkZWJ1Zy5wc20uZXJydXNlY3M6IDANCmRlYnVnLnBzbS5lcnJzZWNz OiAyDQpkZWJ1Zy5wc20uaHo6IDIwDQpkZWJ1Zy5wc20ubG9nbGV2ZWw6IDANCmRlYnVnLnZl c2Euc2hhZG93X3JvbTogMA0KZGVidWcuZmRjLnNldHRsZTogMA0KZGVidWcuZmRjLnNwZWMy OiAxNg0KZGVidWcuZmRjLnNwZWMxOiAxNzUNCmRlYnVnLmZkYy5yZXRyaWVzOiAxMA0KZGVi dWcuZmRjLmRlYnVnZmxhZ3M6IDANCmRlYnVnLmZkYy5maWZvOiA4DQpkZWJ1Zy5lbGYzMl9s ZWdhY3lfY29yZWR1bXA6IDANCmRlYnVnLng4NmJpb3MuaW50OiAwDQpkZWJ1Zy54ODZiaW9z LmNhbGw6IDANCmRlYnVnLmh3cHN0YXRlX3ZlcmJvc2U6IDANCmRlYnVnLm1pbmlkdW1wOiAx DQpVU0VSICAgICBDTUQgICAgICAgICAgUElEICAgRkQgTU9VTlQgICAgICBJTlVNIE1PREUg ICAgICAgICBTWnxEViBSL1cNCnBnc3FsICAgIHBvc3RncmVzICAgMTI4ODUgICB3ZCAvcGdz cWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVz ICAgMTI4ODUgICAgNiAvcGdzcWwgICAxNTc4MDMzMSAtcnctLS0tLS0tICAgIDgxOTIgcncN CnBnc3FsICAgIHBvc3RncmVzICAgMTI4ODUgICAxMiAvcGdzcWwgICAxNTc3OTg2NiAtcnct LS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTI4NjkgICB3ZCAvcGdz cWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVz ICAgMTI4NjkgICAgNiAvcGdzcWwgICAxMjY3MTAyNCAtcnctLS0tLS0tICAgIDgxOTIgcncN CnBnc3FsICAgIHBvc3RncmVzICAgMTI3ODggICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4 LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAgMTI3ODggICAgNiAvcGdz cWwgICAxMTA0NjAxNCAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVz ICAgMTI3ODggICA0MCAvcGdzcWwgICAxMTA1MzE1NyAtcnctLS0tLS0tICAgMTYzODQgcncN CnBnc3FsICAgIHBvc3RncmVzICAgMTI3NDcgICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4 LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAgMTI3NDcgICAgNiAvcGdz cWwgICAxMjY3MTAyNCAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVz ICAgMTI3MzAgICB3ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHIN CnBnc3FsICAgIHBvc3RncmVzICAgMTI3MzAgICAgNiAvcGdzcWwgICAxMTA0NjAxNCAtcnct LS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTI3MzAgICA0MCAvcGdz cWwgICAxMTA1MzE1NyAtcnctLS0tLS0tICAgMTYzODQgcncNCnBnc3FsICAgIHBvc3RncmVz ICAgMTI3MzAgICA1NCAvcGdzcWwgICAxMTA1MzMwNCAtcnctLS0tLS0tICAxNjc3NzIxNiBy dw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMjcyOSAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRy d3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwgICAgcG9zdGdyZXMgICAxMjcyOSAgICA2IC9w Z3NxbCAgIDExMDQ2MDE0IC1ydy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICAxMjYzMSAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAg cg0KcGdzcWwgICAgcG9zdGdyZXMgICAxMjYzMSAgICA2IC9wZ3NxbCAgIDE1NzgwMzMxIC1y dy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMjYzMSAgIDEyIC9w Z3NxbCAgIDE1Nzc5ODY2IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICAxMjYxNCAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAg cg0KcGdzcWwgICAgcG9zdGdyZXMgICAxMjYxNCAgICA2IC9wZ3NxbCAgIDEyNjcxMDI0IC1y dy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMjUyOCAgIHdkIC9w Z3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KcGdzcWwgICAgcG9zdGdy ZXMgICAxMjUyOCAgICA2IC9wZ3NxbCAgIDExMDQ2MDE0IC1ydy0tLS0tLS0gICAgODE5MiBy dw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMjUyOCAgIDQwIC9wZ3NxbCAgIDExMDUzMTU3IC1y dy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMjUyOCAgIDU0IC9w Z3NxbCAgIDExMDUzMzA0IC1ydy0tLS0tLS0gIDE2Nzc3MjE2IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDEyNDY3ICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEy ICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEyNDY3ICAgIDYgL3Bnc3FsICAgMTEwNDYwMTQg LXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDEyNDY3ICAgNDAg L3Bnc3FsICAgMTEwNTMxNTcgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDEyNDY3ICAgNTcgL3Bnc3FsICAgMTEwNTMzMDQgLXJ3LS0tLS0tLSAgMTY3Nzcy MTYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTIxMzQgICB3ZCAvcGdzcWwgICAxMTA0NTg4 OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBvc3RncmVzICAgMTIxMzQgICAg NiAvcGdzcWwgICAxNTc4MDMzMSAtcnctLS0tLS0tICAgIDgxOTIgcncNCnBnc3FsICAgIHBv c3RncmVzICAgMTIxMzQgICAxMiAvcGdzcWwgICAxNTc3OTg2NiAtcnctLS0tLS0tICAgMTYz ODQgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTIxMzQgIDEzMiAvcGdzcWwgICAxNTc3OTg4 NiAtcnctLS0tLS0tICAgODE5MjAgcncNCnBnc3FsICAgIHBvc3RncmVzICAgMTIxMzQgIDEz MyAvcGdzcWwgICAxNTc3OTg4MCAtcnctLS0tLS0tICAyNTcxMzg2ODggcncNCnBnc3FsICAg IHBvc3RncmVzICAgMTIxMzQgIDEzNSAvcGdzcWwgICAxNTc3OTg4OSAtcnctLS0tLS0tICA3 NTY3NzY5NiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAxMjEzNCAgMTM2IC9wZ3NxbCAgIDEx MDUzMzA0IC1ydy0tLS0tLS0gIDE2Nzc3MjE2IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDU0 MDg2ICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3Nx bCAgICBwb3N0Z3JlcyAgIDU0MDg2ICAgIDYgL3Bnc3FsICAgMTEwNDYwMTQgLXJ3LS0tLS0t LSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDU0MDg2ICAgMTMgL3Bnc3FsICAg MTEwNDYwOTYgLXJ3LS0tLS0tLSAgMTE3OTY0OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA1 NDA4NiAgIDE0IC9wZ3NxbCAgIDExMDUzMzc0IC1ydy0tLS0tLS0gIDE2Nzc3MjE2IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDU0MDg2ICAgMTUgL3Bnc3FsICAgMTEwNDYwMTEgLXJ3LS0t LS0tLSAgNzk0NjI0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDU0MDg2ICAgMTYgL3Bnc3Fs ICAgMTEwNDYwMzkgLXJ3LS0tLS0tLSAgMTMxMDcyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAg IDU0MDg2ICAgMTcgL3Bnc3FsICAgMTEwNDYwNjMgLXJ3LS0tLS0tLSAgMzM1ODcyIHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDU0MDg2ICAgMTggL3Bnc3FsICAgMTEwNDYwMjEgLXJ3LS0t LS0tLSAgIDI0NTc2IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDU0MDg2ICAgMTkgL3Bnc3Fs ICAgMTEwNDYwOTIgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAg IDU0MDg2ICAgMjAgL3Bnc3FsICAgMTEwNDYwOTMgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgIDU0MDg2ICAgMjEgL3Bnc3FsICAgMTEwNDYxMTAgLXJ3LS0t LS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDU0MDg2ICAgMjIgL3Bnc3Fs ICAgMTEwNDYxNTYgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAg IDU0MDg2ICAgMjMgL3Bnc3FsICAgMTEwNDYyNDggLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgICA4MDU2ICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0t LS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgICA4MDU2ICAgIDYgL3Bnc3Fs ICAgMTU3ODAzMzEgLXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAg ICA4MDU2ICAgMTAgL3Bnc3FsICAgMTU3ODAyOTUgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpw Z3NxbCAgICBwb3N0Z3JlcyAgICA4MDU2ICAgMTMgL3Bnc3FsICAgMTU3ODAzNjUgLXJ3LS0t LS0tLSAgMTcxMjEyOCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAgODA1NiAgIDE1IC9wZ3Nx bCAgIDE1NzgwNDE1IC1ydy0tLS0tLS0gIDE0MjU0MDggcncNCnBnc3FsICAgIHBvc3RncmVz ICAgIDgwNTYgICAxNyAtICAgICAgICAxMTA1MzMwNSAtcnctLS0tLS0tICAxNjc3NzIxNiBy dw0KcGdzcWwgICAgcG9zdGdyZXMgICAgODA1NiAgIDE5IC9wZ3NxbCAgIDE1NzgwMzU2IC1y dy0tLS0tLS0gIDE1NTY0OCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAgODA1NiAgIDIwIC9w Z3NxbCAgIDE1NzgwMzgyIC1ydy0tLS0tLS0gIDM2ODY0MCBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICAgODA1NiAgIDI0IC9wZ3NxbCAgIDExMDQ2MTEwIC1ydy0tLS0tLS0gICAgODE5MiBy dw0KcGdzcWwgICAgcG9zdGdyZXMgICAgODA1NiAgIDI1IC9wZ3NxbCAgIDExMDQ2MTU2IC1y dy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICAgODA1NiAgIDI2IC9w Z3NxbCAgIDExMDQ2MjQ4IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICA0NTQxMiAgIHdkIC9wZ3NxbCAgIDExMDQ1ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAg cg0KcGdzcWwgICAgcG9zdGdyZXMgICA0NTQxMiAgIDEyIC9wZ3NxbCAgIDE1NzgwMzMxIC1y dy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA0NTQxMiAgIDEzIC9w Z3NxbCAgIDE1NzgwMzI5IC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICA0NTQxMiAgIDE0IC9wZ3NxbCAgIDE1NzgwMzQ5IC1ydy0tLS0tLS0gICAyNDU3NiBy dw0KcGdzcWwgICAgcG9zdGdyZXMgICA0NTQxMiAgIDE1IC9wZ3NxbCAgIDE1NzgwMzk3IC1y dy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA0NTQxMiAgIDE2IC9w Z3NxbCAgIDE1NzgwMjkzIC1ydy0tLS0tLS0gICAzMjc2OCBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICA0NTQxMiAgIDIzIC9wZ3NxbCAgIDE1NzgwMjk1IC1ydy0tLS0tLS0gICAxNjM4NCBy dw0KcGdzcWwgICAgcG9zdGdyZXMgICA0NTQxMiAgIDI0IC9wZ3NxbCAgIDE1NzgwMzQ4IC1y dy0tLS0tLS0gICAgODE5MiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA0NTQxMiAgIDI1IC9w Z3NxbCAgIDE1NzgwNDAxIC1ydy0tLS0tLS0gICAxNjM4NCBydw0KcGdzcWwgICAgcG9zdGdy ZXMgICA0NTQxMiAgIDMxIC9wZ3NxbCAgIDE1NzgwMzgwIC1ydy0tLS0tLS0gICA4MTkyMCBy dw0KcGdzcWwgICAgcG9zdGdyZXMgICA0NTQxMiAgIDM3IC0gICAgICAgIDExMDQ3NDA1IC1y dy0tLS0tLS0gIDE2Nzc3MjE2IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgMzkg L3Bnc3FsICAgMTU3ODA0MDUgLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDQ1NDEyICAgNDAgL3Bnc3FsICAgMTU3ODAzNTEgLXJ3LS0tLS0tLSAgMTMxMDcy IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgNDEgL3Bnc3FsICAgMTU3ODA0MDMg LXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgNDIg L3Bnc3FsICAgMTU3ODAyOTYgLXJ3LS0tLS0tLSAgNDU4NzUyIHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDQ1NDEyICAgNDMgL3Bnc3FsICAgMTU3ODAzOTYgLXJ3LS0tLS0tLSAgIDQwOTYw IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgNDQgL3Bnc3FsICAgMTU3ODAzMzcg LXJ3LS0tLS0tLSAgMTE0Njg4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgNDUg L3Bnc3FsICAgMTU3ODAzMDcgLXJ3LS0tLS0tLSAgIDMyNzY4IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDQ1NDEyICAgNDYgL3Bnc3FsICAgMTEwNDYxMTAgLXJ3LS0tLS0tLSAgICA4MTky IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgNDcgL3Bnc3FsICAgMTEwNDYxNTYg LXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgNDgg L3Bnc3FsICAgMTEwNDYyNDggLXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDQ1NDEyICAgNDkgL3Bnc3FsICAgMTU3ODAzOTkgLXJ3LS0tLS0tLSAgIDMyNzY4 IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgNTAgL3Bnc3FsICAgMTU3ODAzNTAg LXJ3LS0tLS0tLSAgIDMyNzY4IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgNTMg L3Bnc3FsICAgMTU3ODAyOTIgLXJ3LS0tLS0tLSAgIDMyNzY4IHJ3DQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDQ1NDEyICAgNTQgL3Bnc3FsICAgMTU3ODAzNzEgLXJ3LS0tLS0tLSAgIDE2Mzg0 IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDEyICAgNTUgL3Bnc3FsICAgMTU3ODAzMzkg LXJ3LS0tLS0tLSAgIDE2Mzg0IHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDAxICAgd2Qg L3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDQ1NDAwICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEy ICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1NDAwICAgIDggL3Bnc3FsICAgMTEwNDY2MTQg LXJ3LS0tLS0tLSAgICA4MTkyIHJ3DQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1Mzk5ICAgd2Qg L3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEyICByDQpwZ3NxbCAgICBwb3N0 Z3JlcyAgIDQ1Mzk4ICAgd2QgL3Bnc3FsICAgMTEwNDU4ODggZHJ3eC0tLS0tLSAgICAgNTEy ICByDQpwZ3NxbCAgICBwb3N0Z3JlcyAgIDQ1Mzk4ICAgIDggLSAgICAgICAgMTEwNTMyOTMg LXJ3LS0tLS0tLSAgMTY3NzcyMTYgcncNCnBnc3FsICAgIHBvc3RncmVzICAgNDUzOTcgICB3 ZCAvcGdzcWwgICAxMTA0NTg4OCBkcnd4LS0tLS0tICAgICA1MTIgIHINCnBnc3FsICAgIHBv c3RncmVzICAgNDUzOTcgICAgNiAvcGdzcWwgICAxMTA1MzMwNCAtcnctLS0tLS0tICAxNjc3 NzIxNiBydw0KcGdzcWwgICAgcG9zdGdyZXMgICA0NTM5NSAgIHdkIC9wZ3NxbCAgIDExMDQ1 ODg4IGRyd3gtLS0tLS0gICAgIDUxMiAgcg0KClNjcmlwdCBkb25lIG9uIFdlZCBNYXkgMjkg MTg6NTQ6MTMgMjAxMwo= --------------010605080509040900010402 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="before2.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="before2.log" U2NyaXB0IHN0YXJ0ZWQgb24gV2VkIE1heSAyOSAxODo1NzowMSAyMDEzCi4vZGlza3NwYWNl Y2hlY2suc2gNCkZpbGVzeXN0ZW0gICAgIFNpemUgICAgVXNlZCAgIEF2YWlsIENhcGFjaXR5 IGl1c2VkIGlmcmVlICVpdXNlZCAgTW91bnRlZCBvbg0KL2Rldi9kYTJzMWQgICAgMTI4RyAg ICAxMDFHICAgICAxN0cgICAgODYlICAgICAyN2sgICAxN00gICAgMCUgICAvcGdzcWwNCklU RU0gICAgICAgICAgICAgICAgICAgU0laRSAgTElNSVQgICAgIFVTRUQgICAgIEZSRUUgICAg ICBSRVEgRkFJTCBTTEVFUA0KDQpVTUEgS2VnczogICAgICAgICAgICAgICAyMDgsICAgICAg MCwgICAgICA4NiwgICAgICAxNiwgICAgICA4NiwgICAwLCAgIDANClVNQSBab25lczogICAg ICAgICAgICAgMTQwOCwgICAgICAwLCAgICAgIDg2LCAgICAgICAwLCAgICAgIDg2LCAgIDAs ICAgMA0KVU1BIFNsYWJzOiAgICAgICAgICAgICAgNTY4LCAgICAgIDAsICAgIDcwMTksICAg ICAzMjQsICA2MDkyNjQsICAgMCwgICAwDQpVTUEgUkNudFNsYWJzOiAgICAgICAgICA1Njgs ICAgICAgMCwgICAgNDMzNSwgICAgIDg1MiwgIDM4NzI1NywgICAwLCAgIDANClVNQSBIYXNo OiAgICAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAz LCAgIDAsICAgMA0KMTYgQnVja2V0OiAgICAgICAgICAgICAgMTUyLCAgICAgIDAsICAgICAg MjUsICAgICAgNzUsICAgICAyMDksICAgMCwgICAwDQozMiBCdWNrZXQ6ICAgICAgICAgICAg ICAyODAsICAgICAgMCwgICAgICA0NywgICAgIDE0OSwgICAgIDMzOSwgICA2LCAgIDANCjY0 IEJ1Y2tldDogICAgICAgICAgICAgIDUzNiwgICAgICAwLCAgICAgIDc4LCAgICAgIDc2LCAg ICAgNzUyLCAgOTAsICAgMA0KMTI4IEJ1Y2tldDogICAgICAgICAgICAxMDQ4LCAgICAgIDAs ICAgICA3OTQsICAgICAyMjMsIDE1MTE5MTYsMTQ5NTM1NjYsICAgMA0KVk0gT0JKRUNUOiAg ICAgICAgICAgICAgMjMyLCAgICAgIDAsICAgNzk3NDEsICAxMDYyOTEsMTM3NjIxMjcxLCAg IDAsICAgMA0KTUFQOiAgICAgICAgICAgICAgICAgICAgMjMyLCAgICAgIDAsICAgICAgIDcs ICAgICAgMjUsICAgICAgIDcsICAgMCwgICAwDQpLTUFQIEVOVFJZOiAgICAgICAgICAgICAx MjAsIDExMjg3MTAsICAgICAgNzgsICAgNTExMzQsMTcyNTkwMzMzMSwgICAwLCAgIDANCk1B UCBFTlRSWTogICAgICAgICAgICAgIDEyMCwgICAgICAwLCAgICAgNTgyLCAgICA3Mzg1LDI5 MzAyMTQxNywgICAwLCAgIDANCmZha2VwZzogICAgICAgICAgICAgICAgIDEyMCwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KbXRfem9uZTogICAgICAg ICAgICAgICA0MTEyLCAgICAgIDAsICAgICAzMjYsICAgICAgIDEsICAgICAzMjYsICAgMCwg ICAwDQoxNjogICAgICAgICAgICAgICAgICAgICAgMTYsICAgICAgMCwgICAgMjgxMywgICAg MTU1NSwxNDc0Nzk5MCwgICAwLCAgIDANCjMyOiAgICAgICAgICAgICAgICAgICAgICAzMiwg ICAgICAwLCAgICAyOTQ0LCAgICAxMzk5LDQ4ODYxMzk2LCAgIDAsICAgMA0KNjQ6ICAgICAg ICAgICAgICAgICAgICAgIDY0LCAgICAgIDAsICAgIDUzNjksICAgIDMzMTEsODA2MTE3Nzks ICAgMCwgICAwDQoxMjg6ICAgICAgICAgICAgICAgICAgICAxMjgsICAgICAgMCwgICAgOTg0 NCwgICAgNDkxNyw2Njc3NDk4MzMsICAgMCwgICAwDQoyNTY6ICAgICAgICAgICAgICAgICAg ICAyNTYsICAgICAgMCwgICAgIDU2OCwgICAgNTY1NywyODE0ODY3NzczLCAgIDAsICAgMA0K NTEyOiAgICAgICAgICAgICAgICAgICAgNTEyLCAgICAgIDAsICAgIDI3NTgsICAgIDIwMzAs MTc1NjU2MzEsICAgMCwgICAwDQoxMDI0OiAgICAgICAgICAgICAgICAgIDEwMjQsICAgICAg MCwgICAgICA1MywgICAgMTIyNywgMjEzNjY3NCwgICAwLCAgIDANCjIwNDg6ICAgICAgICAg ICAgICAgICAgMjA0OCwgICAgICAwLCAgICA1NjI4LCAgICAxMjM2LCA0MDA5MjUwLCAgIDAs ICAgMA0KNDA5NjogICAgICAgICAgICAgICAgICA0MDk2LCAgICAgIDAsICAgICA0MTgsICAg IDEwNTQsIDUxNzU3NTEsICAgMCwgICAwDQpGaWxlczogICAgICAgICAgICAgICAgICAgODAs ICAgICAgMCwgICAgICA4MiwgICAxMTEyMywxOTMwNjA4MzYsICAgMCwgICAwDQpUVVJOU1RJ TEU6ICAgICAgICAgICAgICAxMzYsICAgICAgMCwgICAgMTkzOSwgICAgIDEyMSwgICAgMTk0 OCwgICAwLCAgIDANCnVtdHggcGk6ICAgICAgICAgICAgICAgICA5NiwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KTUFDIGxhYmVsczogICAgICAgICAg ICAgIDQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpQ Uk9DOiAgICAgICAgICAgICAgICAgIDExODQsICAgICAgMCwgICAgICA0MywgICAgMTQ0Miwg NDQwNjk5NSwgICAwLCAgIDANClRIUkVBRDogICAgICAgICAgICAgICAgMTEyOCwgICAgICAw LCAgICAxNTQ5LCAgICAgMzg5LCAgICAxOTUxLCAgIDAsICAgMA0KU0xFRVBRVUVVRTogICAg ICAgICAgICAgIDgwLCAgICAgIDAsICAgIDE5MzksICAgICAyNjUsICAgIDE5NDgsICAgMCwg ICAwDQpWTVNQQUNFOiAgICAgICAgICAgICAgICAzOTIsICAgICAgMCwgICAgICAyNCwgICAg MTU2NiwgNDQwNjk3OCwgICAwLCAgIDANCmNwdXNldDogICAgICAgICAgICAgICAgICA3Miwg ICAgICAwLCAgICAgIDg1LCAgICAgIDY1LCAgICAgIDg1LCAgIDAsICAgMA0KYXVkaXRfcmVj b3JkOiAgICAgICAgICAgOTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwDQptYnVmX3BhY2tldDogICAgICAgICAgICAyNTYsICAgICAgMCwgICAgNDA4 MCwgICAgMTI5Niw2ODg1MDM5NTgsICAgMCwgICAwDQptYnVmOiAgICAgICAgICAgICAgICAg ICAyNTYsICAgICAgMCwgICAgMTAyMSwgICAgMTk3MywxOTQyMDI4MjY1LCAgIDAsICAgMA0K bWJ1Zl9jbHVzdGVyOiAgICAgICAgICAyMDQ4LCAgMjU2MDAsICAgIDUzNzYsICAgIDE4OTQs IDE2OTMxODQsICAgMCwgICAwDQptYnVmX2p1bWJvX3BhZ2U6ICAgICAgIDQwOTYsICAxMjgw MCwgICAgICAgMCwgICAgIDcwMCw4MzMxNjU0NiwgICAwLCAgIDANCm1idWZfanVtYm9fOWs6 ICAgICAgICAgOTIxNiwgICA2NDAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMA0KbWJ1Zl9qdW1ib18xNms6ICAgICAgIDE2Mzg0LCAgIDMyMDAsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwDQptYnVmX2V4dF9yZWZjbnQ6ICAgICAgICAgIDQs ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCmdfYmlvOiAg ICAgICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgICAgICAwLCAgICA2MDY0LDI4NzcwOTEz MDMsICAgMCwgICAwDQp0dHlpbnE6ICAgICAgICAgICAgICAgICAxNjAsICAgICAgMCwgICAg IDEzNSwgICAgIDM5MywgICAgMjUwNSwgICAwLCAgIDANCnR0eW91dHE6ICAgICAgICAgICAg ICAgIDI1NiwgICAgICAwLCAgICAgIDcyLCAgICAgMzMzLCAgICAxMzM2LCAgIDAsICAgMA0K YXRhX3JlcXVlc3Q6ICAgICAgICAgICAgMzI4LCAgICAgIDAsICAgICAgIDAsICAgICAgODQs ICAgICAgMzIsICAgMCwgICAwDQphdGFfY29tcG9zaXRlOiAgICAgICAgICAzMzYsICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANClZOT0RFOiAgICAgICAg ICAgICAgICAgIDQ4MCwgICAgICAwLCAgMjI0NDcwLCAgIDM0ODEwLDE1Mzc3NjU1NywgICAw LCAgIDANClZOT0RFUE9MTDogICAgICAgICAgICAgIDExMiwgICAgICAwLCAgICAgICAwLCAg ICAgMTMyLCAgICAgICA2LCAgIDAsICAgMA0KTkFNRUk6ICAgICAgICAgICAgICAgICAxMDI0 LCAgICAgIDAsICAgICAgIDAsICAgIDEyMTIsNDE4OTEyNjcwLCAgIDAsICAgMA0KUyBWRlMg Q2FjaGU6ICAgICAgICAgICAgMTA4LCAgICAgIDAsICAyMzE5NjUsICAgNDQxMTMsMTU4MDQ5 NTMwLCAgIDAsICAgMA0KU1RTIFZGUyBDYWNoZTogICAgICAgICAgMTQ4LCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpMIFZGUyBDYWNoZTogICAgICAg ICAgICAzMjgsICAgICAgMCwgICAgIDY4MSwgICAgNDk1OSwgNzM3NjcyOSwgICAwLCAgIDAN CkxUUyBWRlMgQ2FjaGU6ICAgICAgICAgIDM2OCwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMA0KTkNMTk9ERTogICAgICAgICAgICAgICAgNTY4LCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpESVJIQVNIOiAgICAg ICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgMTk3OCwgICAgIDYwNiwgMjk4MTg4MCwgICAw LCAgIDANCk1vdW50cG9pbnRzOiAgICAgICAgICAgIDc5MiwgICAgICAwLCAgICAgICA4LCAg ICAgIDIyLCAgICAgICA4LCAgIDAsICAgMA0KcGlwZTogICAgICAgICAgICAgICAgICAgNzI4 LCAgICAgIDAsICAgICAgIDIsICAgIDEyMjgsIDM4NDg5NDMsICAgMCwgICAwDQprc2lnaW5m bzogICAgICAgICAgICAgICAxMTIsICAgICAgMCwgICAgMTQ3NCwgICAgMTQzMCwgOTc3MDUz NSwgICAwLCAgIDANCml0aW1lcjogICAgICAgICAgICAgICAgIDM0NCwgICAgICAwLCAgICAg ICAxLCAgICAgIDIxLCAgICAgICAxLCAgIDAsICAgMA0KS05PVEU6ICAgICAgICAgICAgICAg ICAgMTI4LCAgICAgIDAsICAgICAgIDAsICAgIDE3MTEsIDEwOTgwMjEsICAgMCwgICAwDQpz b2NrZXQ6ICAgICAgICAgICAgICAgICA2ODAsIDEwMDAwMiwgICAgICAyNiwgICAgMTQzMiwg OTM2Nzk0MSwgICAwLCAgIDANCmlwcTogICAgICAgICAgICAgICAgICAgICA1NiwgICAgODE5 LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KdWRwX2lucGNiOiAgICAg ICAgICAgICAgMzkyLCAxMDAwMDAsICAgICAgMTIsICAgIDE0MTgsIDczMjgyOTMsICAgMCwg ICAwDQp1ZHBjYjogICAgICAgICAgICAgICAgICAgMTYsIDEwMDEyOCwgICAgICAxMiwgICAg MTgzNiwgNzMyODI5MywgICAwLCAgIDANCnRjcF9pbnBjYjogICAgICAgICAgICAgIDM5Miwg MTAwMDAwLCAgICAgICA1LCAgICAxNzU1LCAgNjUyMDYwLCAgIDAsICAgMA0KdGNwY2I6ICAg ICAgICAgICAgICAgICAgOTc2LCAxMDAwMDAsICAgICAgIDUsICAgIDE3NjcsICA2NTIwNjAs ICAgMCwgICAwDQp0Y3B0dzogICAgICAgICAgICAgICAgICAgNzIsICAyMDAwMCwgICAgICAg MCwgICAgIDU1MCwgICAgMzI1NCwgICAwLCAgIDANCnN5bmNhY2hlOiAgICAgICAgICAgICAg IDE1MiwgIDE1Mzc1LCAgICAgICAwLCAgICAgNjI1LCAgNTA1NDM5LCAgIDAsICAgMA0KaG9z dGNhY2hlOiAgICAgICAgICAgICAgMTM2LCAgMTUzNzIsICAgICAgIDQsICAgICA0NDQsICAg IDE4MjAsICAgMCwgICAwDQp0Y3ByZWFzczogICAgICAgICAgICAgICAgNDAsICAgMTY4MCwg ICAgICAgMCwgICAgMTU5NiwgICAyMTY5MCwgICAwLCAgIDANCnNhY2tob2xlOiAgICAgICAg ICAgICAgICAzMiwgICAgICAwLCAgICAgICAwLCAgICAgOTA5LCAgICAgODc1LCAgIDAsICAg MA0Kc2N0cF9lcDogICAgICAgICAgICAgICAxMzc2LCAxMDAwMDAsICAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgMCwgICAwDQpzY3RwX2Fzb2M6ICAgICAgICAgICAgIDIyODgsICA0 MDAwMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfbGFkZHI6 ICAgICAgICAgICAgICA0OCwgIDgwMDY0LCAgICAgICAwLCAgICAgMjg4LCAgICAgICA2LCAg IDAsICAgMA0Kc2N0cF9yYWRkcjogICAgICAgICAgICAgNzA0LCAgODAwMDAsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpzY3RwX2NodW5rOiAgICAgICAgICAgICAx MzYsIDQwMDAwOCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBf cmVhZHE6ICAgICAgICAgICAgIDEwNCwgNDAwMDMyLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMA0Kc2N0cF9zdHJlYW1fbXNnX291dDogICAgMTEyLCA0MDAwMjYsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpzY3RwX2FzY29uZjogICAgICAg ICAgICAgNDAsIDQwMDAwOCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAN CnNjdHBfYXNjb25mX2FjazogICAgICAgICA0OCwgNDAwMDMyLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMA0KcmlwY2I6ICAgICAgICAgICAgICAgICAgMzkyLCAxMDAw MDAsICAgICAgIDAsICAgICAxMDAsICAgICAxMjIsICAgMCwgICAwDQp1bnBjYjogICAgICAg ICAgICAgICAgICAyNDAsIDEwMDAwMCwgICAgICAgOCwgICAgMTMyMCwgMTM4NzQ2MCwgICAw LCAgIDANCnJ0ZW50cnk6ICAgICAgICAgICAgICAgIDIwMCwgICAgICAwLCAgICAgIDIzLCAg ICAgIDkxLCAgICAgIDIzLCAgIDAsICAgMA0Kc2VsZmQ6ICAgICAgICAgICAgICAgICAgIDU2 LCAgICAgIDAsICAgIDIwMTUsICAgIDEzMjQsMzAwMTg4MjAwLCAgIDAsICAgMA0KU1dBUE1F VEE6ICAgICAgICAgICAgICAgMjg4LCAxMTY1MTksICAgICAgMzMsICAgICA1NjUsIDEwNTM1 NzQsICAgMCwgICAwDQpGRlMgaW5vZGU6ICAgICAgICAgICAgICAxNjgsICAgICAgMCwgIDIy NDQzNCwgICA0MTU2OCwxNTM3NzQzMjIsICAgMCwgICAwDQpGRlMxIGRpbm9kZTogICAgICAg ICAgICAxMjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAN CkZGUzIgZGlub2RlOiAgICAgICAgICAgIDI1NiwgICAgICAwLCAgMjI0NDM0LCAgIDQwMjcx LDE1Mzc3NDMxNiwgICAwLCAgIDANCg0KICAgICAgICAgVHlwZSBJblVzZSBNZW1Vc2UgSGln aFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQ0KQ0FNIGRldiBxdWV1ZSAgICAgNCAgICAgMUsgICAg ICAgLSAgICAgICAgNCAgMTI4DQogIG1kX3NpaV9kYXRhICAgICAwICAgICAwSyAgICAgICAt ICAgICAgIDM4ICA1MTINCiAgICAgIENBTSBYUFQgICA1NzEgIDEwNDVLICAgICAgIC0gICAg ICA5NDMgIDE2LDMyLDY0LDEyOCwyNTYsMTAyNCwyMDQ4DQogICAgICAgaXNhZGV2ICAgICA4 ICAgICAxSyAgICAgICAtICAgICAgICA4ICAxMjgNCiAgICAgICAgIFVBUlQgICAgIDYgICAg IDRLICAgICAgIC0gICAgICAgIDYgIDE2LDUxMiwxMDI0DQogICAgIGFjcGlpbnRyICAgICAx ICAgICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgICAgICAgY2RldiAgICAgNyAgICAg MksgICAgICAgLSAgICAgICAgNyAgMjU2DQogICAgICAgYWNwaWNhICAxNDUxICAgMTM5SyAg ICAgICAtICA2MzA4NjA0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0DQogICAgICAgIHNp Z2lvICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgICBmaWxlZGVzYyAg ICA0NiAgICAyNEsgICAgICAgLSAgNDkwNDA1OCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAy NCwyMDQ4LDQwOTYNCiAgICAgICAgIGtlbnYgICAgNzggICAgMTFLICAgICAgIC0gICAgICAg ODkgIDE2LDMyLDY0LDEyOA0KICAgICAgIGtxdWV1ZSAgICAgMCAgICAgMEsgICAgICAgLSAg MTA1Njk4NyAgMjU2LDUxMiwyMDQ4DQogICAgcHJvYy1hcmdzICAgIDI0ICAgICAySyAgICAg ICAtICA2OTY3NDQyICAxNiwzMiw2NCwxMjgsMjU2DQogICAgICAgIGhob29rICAgICAyICAg ICAxSyAgICAgICAtICAgICAgICAyICAxMjgNCiAgICAgYWNwaXRhc2sgICAgIDEgICAgIDJL ICAgICAgIC0gICAgICAgIDEgIDIwNDgNCiAgICAgIGl0aHJlYWQgICAgOTkgICAgMTZLICAg ICAgIC0gICAgICAgOTkgIDMyLDEyOCwyNTYNCiAgICBDQU0gcXVldWUgICAgMTkgICAgIDdL ICAgICAgIC0gICAgICA0MDcgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDIwNDgNCiAgICAgICBL VFJBQ0UgICAxMDAgICAgMTNLICAgICAgIC0gICAgICAxMDAgIDEyOA0KICAgICAgIGxpbmtl ciAgIDE1OCAgICAxMUsgICAgICAgLSAgICAgIDE2MCAgMTYsMzIsNjQsNTEyDQogICAgICAg IGxvY2tmICAgIDIwICAgICAzSyAgICAgICAtICAgIDI0MDA4ICA2NCwxMjgNCiAgIGxvZ2lu Y2xhc3MgICAgIDIgICAgIDFLICAgICAgIC0gICAgNTkwNjUgIDY0DQogICAgICAgaXA2bmRw ICAgIDEyICAgICAxSyAgICAgICAtICAgICAgIDE0ICA2NCwxMjgNCiAgICAgICAgIHRlbXAg ICAgNTEgICAgIDJLICAgICAgIC0gIDgyMjAxNTggIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEw MjQsMjA0OCw0MDk2DQogICAgICAgZGV2YnVmICA4NjQ4IDQxODg5SyAgICAgICAtICAgIDEw MTQzICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAgICAgIG1vZHVs ZSAgIDQ3NyAgICA2MEsgICAgICAgLSAgICAgIDQ3NyAgMTI4DQogICAgY2lzc19kYXRhICAg IDE1ICAgIDE0SyAgICAgICAtICAgICA1OTIxICAxNiwxMjgsMjU2LDUxMiwxMDI0LDIwNDgs NDA5Ng0KICAgICBtdHhfcG9vbCAgICAgMiAgICAxNksgICAgICAgLSAgICAgICAgMiAgDQog ICAgICAgVVNCZGV2ICAgIDM0ICAgICA4SyAgICAgICAtICAgICAgIDQ0ICA2NCwxMjgsNTEy LDQwOTYNCiAgICAgICAgICBVU0IgICAgNTIgICAgMzFLICAgICAgIC0gICAgICAgNjYgIDE2 LDMyLDY0LDEyOCwyNTYsMjA0OCw0MDk2DQogICAgIHBtY2hvb2tzICAgICAxICAgICAxSyAg ICAgICAtICAgICAgICAxICAxMjgNCiAgICAgIHN1YnByb2MgIDE1MzEgICA5MjBLICAgICAg IC0gIDQ0MDg0ODQgIDUxMiw0MDk2DQogICAgICAgICBwcm9jICAgICAyICAgIDE2SyAgICAg ICAtICAgICAgICAyICANCiAgICAgIHNlc3Npb24gICAgMjEgICAgIDNLICAgICAgIC0gIDM1 NTA2ODMgIDEyOA0KICAgICAgICAgcGdycCAgICAyMyAgICAgM0sgICAgICAgLSAgMzU1NTEy NyAgMTI4DQogICAgICAgICBjcmVkICAgIDQyICAgICA3SyAgICAgICAtIDMyODc3MTYyICA2 NCwyNTYNCiAgICAgIHVpZGluZm8gICAgIDQgICAgIDNLICAgICAgIC0gICAxODY4NjEgIDEy OCwyMDQ4DQogICAgICAgcGxpbWl0ICAgIDE0ICAgICA0SyAgICAgICAtICAgNzcwNzYzICAy NTYNCiAgICAgIGF0YV9wY2kgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0DQog ICAgICBzY3NpX2NkICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDEwICAxNg0KICAgIHN5 c2N0bHRtcCAgICAgMCAgICAgMEsgICAgICAgLSAgICAxNDI0MSAgMTYsMzIsNjQsMTI4LDQw OTYNCiAgICBzeXNjdGxvaWQgIDQ5NzggICAyNTFLICAgICAgIC0gICAgIDUzNjAgIDE2LDMy LDY0LDEyOA0KICAgICAgIHN5c2N0bCAgICAgMCAgICAgMEsgICAgICAgLSAgNzk1NjAxMiAg MTYsMzIsNjQNCiAgICAgIHRpZGhhc2ggICAgIDEgICAgMTZLICAgICAgIC0gICAgICAgIDEg IA0KICAgICAgY2FsbG91dCAgICAgNyAxNDMzNksgICAgICAgLSAgICAgICAgNyAgDQogICAg ICAgICB1bXR4ICAzODc2ICAgNDg1SyAgICAgICAtICAgICAzODk0ICAxMjgNCiAgICAgcDEw MDMuMWIgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDE2DQogICAgICAgICBTV0FQ ICAgICAyICAgNTQ5SyAgICAgICAtICAgICAgICAyICA2NA0KICAgICAgIGJ1cy1zYyAgIDEx MyAgIDc4MUsgICAgICAgLSAgICAgNTIzNCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwy MDQ4LDQwOTYNCiAgICAgICAgICBidXMgIDEyODIgICAxMDlLICAgICAgIC0gICAgIDg2MzQg IDE2LDMyLDY0LDEyOCwyNTYsMTAyNA0KICAgICAgZGV2c3RhdCAgICAxMiAgICAyNUsgICAg ICAgLSAgICAgICAxMiAgMzIsNDA5Ng0KIGV2ZW50aGFuZGxlciAgICA3NyAgICAgNksgICAg ICAgLSAgICAgICA3NyAgNjQsMTI4DQogICAgICBhY3Bpc2VtICAgIDE5ICAgICAzSyAgICAg ICAtICAgICAgIDE5ICAxMjgNCiAgICAgICAgIGtvYmogICAzMzAgIDEzMjBLICAgICAgIC0g ICAgICA2MjYgIDQwOTYNCiAgICAgIENBTSBTSU0gICAgIDUgICAgIDJLICAgICAgIC0gICAg ICAgIDUgIDI1Ng0KICAgICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAg MSAgMzINCiAgIENBTSBwZXJpcGggICAgMTAgICAgIDNLICAgICAgIC0gICAgICAgNTQgIDE2 LDMyLDY0LDEyOCwyNTYNCiAgICAgICAgIHJtYW4gICAyNDggICAgMjZLICAgICAgIC0gICAg ICA2MTMgIDE2LDMyLDEyOA0KICAgICAgICAgc2J1ZiAgICAgMSAgICAgMUsgICAgICAgLSAg ICAgMjA3MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgIGVu dHJvcHkgIDEwMjQgICAgNjRLICAgICAgIC0gICAgIDEwMjQgIDY0DQogICAgICAgY3RsbWVt ICA1MDYyIDEwMTEzSyAgICAgICAtICAgICA1MDYyICAxMjgsMjA0OA0KICAgICAgICBzdGFj ayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAgMjU2DQogICAgdGFza3F1ZXVlICAg IDE1ICAgICAySyAgICAgICAtICAgICAgIDE1ICAxNiwzMiwxMjgNCiAgICAgICBVbml0bm8g ICAgMTQgICAgIDFLICAgICAgIC0gICA1OTY3NDQgIDMyLDY0DQogICAgICAgICAgaW92ICAg ICAwICAgICAwSyAgICAgICAtICAxNTYwNzk0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMg0KICAg ICAgIHNlbGVjdCAgMTQ1NSAgIDE4MksgICAgICAgLSAgICAgMTQ1NSAgMTI4DQogICAgIGlv Y3Rsb3BzICAgICAwICAgICAwSyAgICAgICAtICA4NDk3NjE4ICAxNiwzMiw2NCwxMjgsMjU2 LDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAgICAgICAgIG1zZyAgICAgNCAgICAzMEsgICAgICAg LSAgICAgICAgNCAgMjA0OCw0MDk2DQogICAgICAgICAgc2VtICAgICA0ICAgMTk2SyAgICAg ICAtICAgICAgICA0ICANCiAgICAgICAgICBzaG0gICAgIDEgICAgMjBLICAgICAgIC0gIDMz NDkyODMgIDIwNDgNCiAgICAgICAgICB0dHkgICAgMjIgICAgMjJLICAgICAgIC0gICAgICAx NDkgIDEwMjQsMjA0OA0KICAgICAgICAgIHB0cyAgICAgMSAgICAgMUsgICAgICAgLSAgICAg IDEyNiAgMjU2DQogICAgIG1idWZfdGFnICAgICAwICAgICAwSyAgICAgICAtIDQzMzQ0Njk5 ICAzMiwxMjgNCiAgICAgICAgc2htZmQgICAgIDEgICAgIDhLICAgICAgIC0gICAgICAgIDEg IA0KICAgICAgICAgIHBjYiAgICAyMCAgIDE1N0sgICAgICAgLSAgIDYyOTA4OSAgMTYsMzIs MTI4LDEwMjQsMjA0OCw0MDk2DQogICAgICAgc29uYW1lICAgICAzICAgICAxSyAgICAgICAt IDUyMjMwMDQ5ICAxNiwzMiwxMjgNCiAgICAgICAgICBhY2wgICAgIDAgICAgIDBLICAgICAg IC0gICAxNDQxMDEgIDQwOTYNCiAgICAgICBiaW9idWYgICAgIDAgICAgIDBLICAgICAgIC0g ICAgMTQ2ODMgIDIwNDgNCiAgICAgdmZzY2FjaGUgICAgIDEgIDgxOTJLICAgICAgIC0gICAg ICAgIDEgIA0KICAgY2xfc2F2ZWJ1ZiAgICAgMCAgICAgMEsgICAgICAgLSAxMDE3MDg1NTgg IDY0LDEyOA0KICAgICB2ZnNfaGFzaCAgICAgMSAgNDA5NksgICAgICAgLSAgICAgICAgMSAg DQogICAgICAgREVWRlMxICAgMTE0ICAgIDU3SyAgICAgICAtICAgICAgMjYyICA1MTINCiAg ICAgICB2bm9kZXMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDQgIDY0LDI1Ng0KICAg ICAgIERFVkZTMyAgIDEzMCAgICAzM0sgICAgICAgLSAgICAgIDI4NSAgMjU2DQogICAgICAg IG1vdW50ICAgMTA2ICAgICA1SyAgICAgICAtICAgICAgMTc2ICAxNiwzMiw2NCwxMjgsMjU2 DQogIHZub2RlbWFya2VyICAgICAwICAgICAwSyAgICAgICAtICA1MDYyMzgyICA1MTINCiAg ICAgICAgICBCUEYgICAgIDkgICAgIDJLICAgICAgIC0gICAgICAgIDkgIDEyOA0KICBldGhl cl9tdWx0aSAgICA1NiAgICAgM0sgICAgICAgLSAgICAgICA2NiAgMTYsMzIsNjQNCiAgICAg ICBpZmFkZHIgICAgODcgICAgMjJLICAgICAgIC0gICAgICAgODcgIDMyLDY0LDEyOCwyNTYs NTEyLDQwOTYNCiAgICAgICAgaWZuZXQgICAgMTAgICAgMTlLICAgICAgIC0gICAgICAgMTAg IDEyOCwyMDQ4DQogICAgICAgIGNsb25lICAgICA2ICAgIDI0SyAgICAgICAtICAgICAgICA2 ICA0MDk2DQogICAgICAgYXJwY29tICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAx Ng0KICAgICAgbGx0YWJsZSAgICAzMSAgICAxM0sgICAgICAgLSAgICA1ODQ4MiAgMjU2LDUx Mg0KICAgICAgICBERVZGUyAgICAxNyAgICAgMUsgICAgICAgLSAgICAgICAyMCAgMTYsMTI4 DQogICAgICAgREVWRlNQICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAyICA2NA0KICAg ICByb3V0ZXRibCAgICA0NCAgICAgNksgICAgICAgLSAgMTQ2NDIyNiAgMzIsNjQsMTI4LDI1 Niw1MTINCiAgICAgICAgIGlnbXAgICAgIDkgICAgIDNLICAgICAgIC0gICAgICAgIDkgIDI1 Ng0KICAgICBpbl9tdWx0aSAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMjU2DQog ICAgc2N0cF9pdGVyICAgICAwICAgICAwSyAgICAgICAtICAgICAgICA0ICAyNTYNCiAgICAg c2N0cF9pZm4gICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDEyOA0KICAgICBzY3Rw X2lmYSAgICAgNyAgICAgMUsgICAgICAgLSAgICAgICAgNyAgMTI4DQogICAgIHNjdHBfdnJm ICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgIHNjdHBfYV9pdCAgICAg MCAgICAgMEsgICAgICAgLSAgICAgICAgNCAgMTYNCiAgICBob3N0Y2FjaGUgICAgIDEgICAg MjhLICAgICAgIC0gICAgICAgIDEgIA0KICAgICBzeW5jYWNoZSAgICAgMSAgICA5NksgICAg ICAgLSAgICAgICAgMSAgDQogICAgaW42X211bHRpICAgIDI4ICAgICA0SyAgICAgICAtICAg ICAgIDI4ICAzMiwyNTYNCiAgICAgICAgICBtbGQgICAgIDkgICAgIDJLICAgICAgIC0gICAg ICAgIDkgIDEyOA0KICAgICAgICAgIHJwYyAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAg MiAgMjU2DQphdWRpdF9ldmNsYXNzICAgMTc5ICAgICA2SyAgICAgICAtICAgICAgMjE4ICAz Mg0KICAgICBzYXZlZGlubyAgICAgMCAgICAgMEsgICAgICAgLSAgMzA4MzIyNyAgMjU2DQog ICAgIGZyZWV3b3JrICAgICAxICAgICAxSyAgICAgICAtIDgwNTQ4ODc0ICAxNiwxMjgNCiAg ICBuZXdkaXJibGsgICAgIDAgICAgIDBLICAgICAgIC0gICAgMTgzMzcgIDY0DQogICAgICAg ZGlycmVtICAgICAwICAgICAwSyAgICAgICAtIDEzMDgzMDM1ICAxMjgNCiAgICAgICAgbWtk aXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgMjk0MzYgIDEyOA0KICAgICAgIGRpcmFkZCAg ICAgMCAgICAgMEsgICAgICAgLSAxMzA5MTI2MyAgMTI4DQogICAgIGZyZWVmaWxlICAgICAw ICAgICAwSyAgICAgICAtICA2NzEzOTUyICA2NA0KICAgICBmcmVlYmxrcyAgICAgMCAgICAg MEsgICAgICAgLSAgNjYxMTMxNSAgMTI4DQogICAgIGZyZWVmcmFnICAgICAwICAgICAwSyAg ICAgICAtIDQyNzU4MjkyMiAgMTI4DQogICAgIGluZGlyZGVwICAgICAwICAgICAwSyAgICAg ICAtICA2MjUxOTE3ICAxMjgNCiAgICAgICBuZXdibGsgICAgIDEgICA1MTJLICAgICAgIC0g Mjc4MTg2NzI4OSAgMjU2DQogICAgYm1zYWZlbWFwICAgICAxICAgICA4SyAgICAgICAtICA4 OTM4MzkzICAyNTYNCiAgICAgaW5vZGVkZXAgICAgIDEgIDQwOTZLICAgICAgIC0gIDc4MzIx MDQgIDUxMg0KICAgICAgcGFnZWRlcCAgICAgMSAgIDUxMksgICAgICAgLSAgIDEzOTEyNiAg MjU2DQogIHVmc19kaXJoYXNoICAxNDY3ICAgMzczSyAgICAgICAtICAgNDAxNjQ5ICAxNiwz Miw2NCwxMjgsMjU2LDUxMiwxMDI0DQogICAgdWZzX21vdW50ICAgIDE4ICAgIDY5SyAgICAg ICAtICAgICAgIDE4ICA1MTIsMjA0OCw0MDk2DQogICAgdm1fcGdkYXRhICAgICAyICAgMTI5 SyAgICAgICAtICAgICAgICAyICAxMjgNCiAgICAgIFVNQUhhc2ggICAgIDMgICAgMjJLICAg ICAgIC0gICAgICAgMTMgIDUxMiwxMDI0LDIwNDgsNDA5Ng0KICAgICAgbWVtZGVzYyAgICAg MSAgICAgNEsgICAgICAgLSAgICAgICAgMSAgNDA5Ng0KICAgICBhdGtiZGRldiAgICAgMiAg ICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQNCiAgICBwZnNfbm9kZXMgICAgMjEgICAgIDZL ICAgICAgIC0gICAgICAgMjEgIDI1Ng0KICBwZnNfdm5jYWNoZSAgICAgMSAgICAgMUsgICAg ICAgLSAgICAgIDI2MCAgNjQNCiAgICAgICBjdGxibGsgICAyMDAgIDE2MDBLICAgICAgIC0g ICAgICAyMDAgIA0KICAgICAgICAgR0VPTSAgIDEyNyAgICA0MEsgICAgICAgLSAgICAgMTMx MiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4DQogICAgICByYW1kaXNrICAgICAx ICA0MDk2SyAgICAgICAtICAgICAgICAxICANCiAgICAgIGFjcGlkZXYgICAgMzAgICAgIDJL ICAgICAgIC0gICAgICAgMzAgIDY0DQogICAgICBjdGxwb29sICAgNTMyICAgMTQySyAgICAg ICAtICAgICAgNTMyICAzMiw1MTINCiAgICAgICBrYmRtdXggICAgIDcgICAgMThLICAgICAg IC0gICAgICAgIDggIDE2LDUxMiwxMDI0LDIwNDgNCiAgICAgICBhcG1kZXYgICAgIDEgICAg IDFLICAgICAgIC0gICAgICAgIDEgIDEyOA0KICAgbWFkdF90YWJsZSAgICAgMCAgICAgMEsg ICAgICAgLSAgICAgICAgMSAgNDA5Ng0KICAgICAgIGZlZWRlciAgICAgNyAgICAgMUsgICAg ICAgLSAgICAgICAgNyAgMzINCiAgICAgIHNjc2lfZGEgICAgIDAgICAgIDBLICAgICAgIC0g ICAgICAyNjYgIDE2DQogICAgIHBjaV9saW5rICAgIDE2ICAgICAySyAgICAgICAtICAgICAg IDE2ICAxNiwxMjgNCiAgICByYWlkX2RhdGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAy MzQgIDMyLDEyOCwyNTYNCiAgICAgIGlvX2FwaWMgICAgIDEgICAgIDJLICAgICAgIC0gICAg ICAgIDEgIDIwNDgNCiAgICAgICAgICBNQ0EgICAgIDggICAgIDFLICAgICAgIC0gICAgICAg IDggIDEyOA0KICAgICAgICAgIG1zaSAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAg MTI4DQogICAgIG5leHVzZGV2ICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAxNg0K bWRfbnZpZGlhX2RhdGEgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgMzggIDUxMg0KZGVi dWcuYWNwaS5zdXNwZW5kX2JvdW5jZTogMA0KZGVidWcuYWNwaS5yZXNldF9jbG9jazogMQ0K ZGVidWcuYWNwaS5pbnRlcnByZXRlcl9zbGFjazogMQ0KZGVidWcuYWNwaS5lbmFibGVfZGVi dWdfb2JqZWN0czogMA0KZGVidWcuYWNwaS5hY3BpX2NhX3ZlcnNpb246IDIwMTEwNTI3DQpk ZWJ1Zy5hY3BpLmNwdV91bm9yZGVyZWQ6IDANCmRlYnVnLmFjcGkuZWMudGltZW91dDogNzUw DQpkZWJ1Zy5hY3BpLmVjLnBvbGxlZDogMA0KZGVidWcuYWNwaS5lYy5idXJzdDogMA0KZGVi dWcuYWNwaS5iYXR0LmJhdHRfc2xlZXBfbXM6IDANCmRlYnVnLmFjcGkucmVzdW1lX2JlZXA6 IDANCmRlYnVnLmZpcmV3aXJlX2RlYnVnOiAwDQpkZWJ1Zy5md21lbV9kZWJ1ZzogMA0KZGVi dWcuaWZfZndlX2RlYnVnOiAwDQpkZWJ1Zy5pZl9md2lwX2RlYnVnOiAwDQpkZWJ1Zy5pcHc6 IDANCmRlYnVnLml3aTogMA0KZGVidWcubWRkZWJ1ZzogMA0KZGVidWcud3BpOiAwDQpkZWJ1 Zy5lbGY2NF9sZWdhY3lfY29yZWR1bXA6IDANCmRlYnVnLmJvb3R2ZXJib3NlOiAwDQpkZWJ1 Zy5ib290aG93dG86IDANCmRlYnVnLmNwdWZyZXEudmVyYm9zZTogMA0KZGVidWcuY3B1ZnJl cS5sb3dlc3Q6IDANCmRlYnVnLmZhaWxfcG9pbnQuc3lzY3RsX3J1bm5pbmc6IG9mZg0KZGVi dWcuZmFpbF9wb2ludC5idWZfcHJlc3N1cmU6IG9mZg0KZGVidWcuZmFpbF9wb2ludC5ubG1f ZGVueV9ncmFudDogb2ZmDQpkZWJ1Zy5hZGFwdGl2ZV9tYWNoaW5lX2FyY2g6IDENCmRlYnVn LnNpemVvZi5jZGV2X3ByaXY6IDM3Ng0KZGVidWcuc2l6ZW9mLmNkZXY6IDI4OA0KZGVidWcu c2l6ZW9mLmdfYmlvcTogNTYNCmRlYnVnLnNpemVvZi5nX2NvbnN1bWVyOiA5Ng0KZGVidWcu c2l6ZW9mLmdfcHJvdmlkZXI6IDEzNg0KZGVidWcuc2l6ZW9mLmdfZ2VvbTogMTYwDQpkZWJ1 Zy5zaXplb2YuZ19jbGFzczogMTYwDQpkZWJ1Zy5zaXplb2Yua2luZm9fcHJvYzogMTA4OA0K ZGVidWcuc2l6ZW9mLmJ1ZjogNjA4DQpkZWJ1Zy5zaXplb2YuYmlvOiAyMzINCmRlYnVnLnNp emVvZi5wcm9jOiAxMTg0DQpkZWJ1Zy5zaXplb2Yudm5vZGU6IDQ4MA0KZGVidWcuc2l6ZW9m LmRldnN0YXQ6IDI4OA0KZGVidWcuc2l6ZW9mLm5hbWVjYWNoZTogNzINCmRlYnVnLm9zZDog MA0KZGVidWcudHJhY2Vfb25fcGFuaWM6IDENCmRlYnVnLmRlYnVnZ2VyX29uX3BhbmljOiAx DQpkZWJ1Zy5uY29yZXM6IDUNCmRlYnVnLnRvX2F2Z19tcGNhbGxzOiA3NTUNCmRlYnVnLnRv X2F2Z19sb2NrY2FsbHM6IDMwMw0KZGVidWcudG9fYXZnX2djYWxsczogNTE0DQpkZWJ1Zy50 b19hdmdfZGVwdGg6IDIwMzMNCmRlYnVnLnVtdHgudW10eF9waV9hbGxvY2F0ZWQ6IDANCmRl YnVnLmNsb2NrdGltZTogMA0KZGVidWcua2RiLmFsdF9icmVha190b19kZWJ1Z2dlcjogMA0K ZGVidWcua2RiLmJyZWFrX3RvX2RlYnVnZ2VyOiAwDQpkZWJ1Zy5rZGIudHJhcF9jb2RlOiAw DQpkZWJ1Zy5rZGIudHJhcDogMA0KZGVidWcua2RiLnBhbmljOiAwDQpkZWJ1Zy5rZGIuZW50 ZXI6IDANCmRlYnVnLmtkYi5jdXJyZW50OiANCmRlYnVnLnJtYW5fZGVidWc6IDANCmRlYnVn Lmlvc2l6ZV9tYXhfY2xhbXA6IDENCmRlYnVnLmRpc2FibGVmdWxscGF0aDogMA0KZGVidWcu ZGlzYWJsZWN3ZDogMA0KZGVidWcudmZzY2FjaGU6IDENCmRlYnVnLm51bWNhY2hlaHY6IDI1 MTg5DQpkZWJ1Zy5udW1jYWNoZTogMjMyNjQ2DQpkZWJ1Zy5udW1uZWc6IDEyMTg4DQpkZWJ1 Zy5uY2hhc2g6IDEwNDg1NzUNCmRlYnVnLnZubHJ1X25vd2hlcmU6IDANCmRlYnVnLnJ1c2hf cmVxdWVzdHM6IDM3MDI4MQ0KZGVidWcuaWZfdHVuX2RlYnVnOiAwDQpkZWJ1Zy5ubG1fZGVi dWc6IDANCmRlYnVnLmZzY2tjbWRzOiAwDQpkZWJ1Zy5jb2xsZWN0c25hcHN0YXRzOiAwDQpk ZWJ1Zy5zbmFwZGVidWc6IDANCmRlYnVnLmRvcGVyc2lzdGVuY2U6IDANCmRlYnVnLnNvZnRk ZXAuY2xlYW51cF9mYWlsdXJlczogMzY5NjM0DQpkZWJ1Zy5zb2Z0ZGVwLmNsZWFudXBfcmV0 cmllczogODI2DQpkZWJ1Zy5zb2Z0ZGVwLmNsZWFudXBfaGlnaF9kZWxheTogMTQNCmRlYnVn LnNvZnRkZXAuY2xlYW51cF9pbm9yZXF1ZXN0czogMA0KZGVidWcuc29mdGRlcC5jbGVhbnVw X2Jsa3JlcXVlc3RzOiAzNjk2OTANCmRlYnVnLnNvZnRkZXAuandhaXRfbmV3YmxrOiAwDQpk ZWJ1Zy5zb2Z0ZGVwLmp3YWl0X2lub2RlOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmp3YWl0X2ZyZWVi bGtzOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmp3YWl0X2ZpbGVwYWdlOiAwDQpkZWJ1Zy5zb2Z0ZGVw LmpvdXJuYWxfd2FpdDogMA0KZGVidWcuc29mdGRlcC5qb3VybmFsX21pbjogMA0KZGVidWcu c29mdGRlcC5qb3VybmFsX2xvdzogMA0KZGVidWcuc29mdGRlcC5qbmV3YmxrX3JvbGxiYWNr OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmphZGRyZWZfcm9sbGJhY2s6IDANCmRlYnVnLnNvZnRkZXAu ZGlyX2VudHJ5OiAxOTU2NjANCmRlYnVnLnNvZnRkZXAuZGlyZWN0X2Jsa19wdHJzOiAzMzkw MjMNCmRlYnVnLnNvZnRkZXAuaW5vZGVfYml0bWFwOiAyNTAzNzM0DQpkZWJ1Zy5zb2Z0ZGVw LmluZGlyX2Jsa19wdHJzOiAyNjg4MQ0KZGVidWcuc29mdGRlcC5zeW5jX2xpbWl0X2hpdDog NTkxDQpkZWJ1Zy5zb2Z0ZGVwLmlub19saW1pdF9oaXQ6IDANCmRlYnVnLnNvZnRkZXAuYmxr X2xpbWl0X2hpdDogMzY5MjIwDQpkZWJ1Zy5zb2Z0ZGVwLmlub19saW1pdF9wdXNoOiAwDQpk ZWJ1Zy5zb2Z0ZGVwLmJsa19saW1pdF9wdXNoOiAzNjk2OTANCmRlYnVnLnNvZnRkZXAud29y a2xpc3RfcHVzaDogMjE1Ng0KZGVidWcuc29mdGRlcC5tYXhpbmRpcmRlcHM6IDUwDQpkZWJ1 Zy5zb2Z0ZGVwLnRpY2tkZWxheTogMg0KZGVidWcuc29mdGRlcC5tYXhfc29mdGRlcHM6IDIz NTIzMDgNCmRlYnVnLnNvZnRkZXAud3JpdGUuamZzeW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndy aXRlLmp0cnVuYzogMA0KZGVidWcuc29mdGRlcC53cml0ZS5zYmRlcDogMA0KZGVidWcuc29m dGRlcC53cml0ZS5qc2VnZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpzZWc6IDANCmRl YnVnLnNvZnRkZXAud3JpdGUuamZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpm cmVlYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpuZXdibGs6IDANCmRlYnVnLnNvZnRk ZXAud3JpdGUuam12cmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpyZW1yZWY6IDANCmRl YnVnLnNvZnRkZXAud3JpdGUuamFkZHJlZjogMA0KZGVidWcuc29mdGRlcC53cml0ZS5mcmVl ZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmZyZWV3b3JrOiAwDQpkZWJ1Zy5zb2Z0ZGVw LndyaXRlLm5ld2RpcmJsazogMA0KZGVidWcuc29mdGRlcC53cml0ZS5kaXJyZW06IDANCmRl YnVnLnNvZnRkZXAud3JpdGUubWtkaXI6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZGlyYWRk OiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmZyZWVmaWxlOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndy aXRlLmZyZWVibGtzOiA2Njg5NjkNCmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZWZyYWc6IDAN CmRlYnVnLnNvZnRkZXAud3JpdGUuYWxsb2NpbmRpcjogMjI0ODAxNTYyMQ0KZGVidWcuc29m dGRlcC53cml0ZS5pbmRpcmRlcDogMTE1NDQwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmFsbG9j ZGlyZWN0OiA3NDI1NDE0OQ0KZGVidWcuc29mdGRlcC53cml0ZS5uZXdibGs6IDANCmRlYnVn LnNvZnRkZXAud3JpdGUuYm1zYWZlbWFwOiAyMzkzOTQ0DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRl Lmlub2RlZGVwOiA2ODAxMTY0DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLnBhZ2VkZXA6IDMyMDMy Mg0KZGVidWcuc29mdGRlcC5jdXJyZW50Lmpmc3luYzogMA0KZGVidWcuc29mdGRlcC5jdXJy ZW50Lmp0cnVuYzogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LnNiZGVwOiAwDQpkZWJ1Zy5z b2Z0ZGVwLmN1cnJlbnQuanNlZ2RlcDogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpzZWc6 IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qZnJlZWZyYWc6IDANCmRlYnVnLnNvZnRkZXAu Y3VycmVudC5qZnJlZWJsazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpuZXdibGs6IDAN CmRlYnVnLnNvZnRkZXAuY3VycmVudC5qbXZyZWY6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVu dC5qcmVtcmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuamFkZHJlZjogMA0KZGVidWcu c29mdGRlcC5jdXJyZW50LmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5mcmVl d29yazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50Lm5ld2RpcmJsazogMA0KZGVidWcuc29m dGRlcC5jdXJyZW50LmRpcnJlbTogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50Lm1rZGlyOiAw DQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZGlyYWRkOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJl bnQuZnJlZWZpbGU6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5mcmVlYmxrczogMA0KZGVi dWcuc29mdGRlcC5jdXJyZW50LmZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQu YWxsb2NpbmRpcjogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmluZGlyZGVwOiAwDQpkZWJ1 Zy5zb2Z0ZGVwLmN1cnJlbnQuYWxsb2NkaXJlY3Q6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVu dC5uZXdibGs6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5ibXNhZmVtYXA6IDANCmRlYnVn LnNvZnRkZXAuY3VycmVudC5pbm9kZWRlcDogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LnBh Z2VkZXA6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuamZzeW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVw LnRvdGFsLmp0cnVuYzogMA0KZGVidWcuc29mdGRlcC50b3RhbC5zYmRlcDogMA0KZGVidWcu c29mdGRlcC50b3RhbC5qc2VnZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmpzZWc6IDAN CmRlYnVnLnNvZnRkZXAudG90YWwuamZyZWVmcmFnOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFs LmpmcmVlYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmpuZXdibGs6IDANCmRlYnVnLnNv ZnRkZXAudG90YWwuam12cmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmpyZW1yZWY6IDAN CmRlYnVnLnNvZnRkZXAudG90YWwuamFkZHJlZjogMA0KZGVidWcuc29mdGRlcC50b3RhbC5m cmVlZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmZyZWV3b3JrOiA4MDU0ODg3Mw0KZGVi dWcuc29mdGRlcC50b3RhbC5uZXdkaXJibGs6IDE4MzM3DQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFs LmRpcnJlbTogMTMwODMwMzUNCmRlYnVnLnNvZnRkZXAudG90YWwubWtkaXI6IDI5NDM2DQpk ZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmRpcmFkZDogMTMwOTEyNjMNCmRlYnVnLnNvZnRkZXAudG90 YWwuZnJlZWZpbGU6IDY3MTM5NTINCmRlYnVnLnNvZnRkZXAudG90YWwuZnJlZWJsa3M6IDY2 MTEzMTUNCmRlYnVnLnNvZnRkZXAudG90YWwuZnJlZWZyYWc6IDQyNzU4MjkyMg0KZGVidWcu c29mdGRlcC50b3RhbC5hbGxvY2luZGlyOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmluZGly ZGVwOiA2MjI1MDM2DQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmFsbG9jZGlyZWN0OiAwDQpkZWJ1 Zy5zb2Z0ZGVwLnRvdGFsLm5ld2JsazogMjc4MTg2NzI4OA0KZGVidWcuc29mdGRlcC50b3Rh bC5ibXNhZmVtYXA6IDg5MzgzOTINCmRlYnVnLnNvZnRkZXAudG90YWwuaW5vZGVkZXA6IDc4 MzIxMDMNCmRlYnVnLnNvZnRkZXAudG90YWwucGFnZWRlcDogMTM5MTI1DQpkZWJ1Zy5kb2Jr Z3Jkd3JpdGU6IDENCmRlYnVnLmJpZ2NnczogMA0KZGVidWcuZGlyY2hlY2s6IDANCmRlYnVn LnBzbS5wa3RlcnJ0aHJlc2g6IDINCmRlYnVnLnBzbS51c2VjczogNTAwMDAwDQpkZWJ1Zy5w c20uc2VjczogMA0KZGVidWcucHNtLmVycnVzZWNzOiAwDQpkZWJ1Zy5wc20uZXJyc2Vjczog Mg0KZGVidWcucHNtLmh6OiAyMA0KZGVidWcucHNtLmxvZ2xldmVsOiAwDQpkZWJ1Zy52ZXNh LnNoYWRvd19yb206IDANCmRlYnVnLmZkYy5zZXR0bGU6IDANCmRlYnVnLmZkYy5zcGVjMjog MTYNCmRlYnVnLmZkYy5zcGVjMTogMTc1DQpkZWJ1Zy5mZGMucmV0cmllczogMTANCmRlYnVn LmZkYy5kZWJ1Z2ZsYWdzOiAwDQpkZWJ1Zy5mZGMuZmlmbzogOA0KZGVidWcuZWxmMzJfbGVn YWN5X2NvcmVkdW1wOiAwDQpkZWJ1Zy54ODZiaW9zLmludDogMA0KZGVidWcueDg2Ymlvcy5j YWxsOiAwDQpkZWJ1Zy5od3BzdGF0ZV92ZXJib3NlOiAwDQpkZWJ1Zy5taW5pZHVtcDogMQ0K VVNFUiAgICAgQ01EICAgICAgICAgIFBJRCAgIEZEIE1PVU5UICAgICAgSU5VTSBNT0RFICAg ICAgICAgU1p8RFYgUi9XDQoKU2NyaXB0IGRvbmUgb24gV2VkIE1heSAyOSAxODo1NzowMSAy MDEzCg== --------------010605080509040900010402 Content-Type: application/octet-stream; x-mac-type="0"; x-mac-creator="0"; name="after.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="after.log" U2NyaXB0IHN0YXJ0ZWQgb24gV2VkIE1heSAyOSAxODo1ODoxNyAyMDEzCg0KIyB1bW91bnQg L3Bnc3FsDQp1bW91bnQ6IHVubW91bnQgb2YgL3Bnc3FsIGZhaWxlZDogRGV2aWNlIGJ1c3kN CiMgdW1vdW50IC1mIAgIG1tLCBtbSwgIG1tLCBtbSwgbW0sIG1tLCBtbSwgbW0sHBwcHBwcH B2ZzdGF0IHwgZ3JlcCBwZ3NxbA0KIyBsc29mIHwgZ3JlcCBwZ3NxbA0KbHNvZjogV0FSTklO RzogY29tcGlsZWQgZm9yIEZyZWVCU0QgcmVsZWFzZSA5LjAtUkVMRUFTRS1wMzsgdGhpcyBp cyA5LjEtUkVMRUFTRS4NCnN5c2xvZ2QgICAgMTEyNiAgIHJvb3QgICAxOXcgIFZSRUcgICAg ICAgICAgICAgIDAsMTExICAgICAgICAgICAgIDQ1NDk3MyAgNjM2MDkyIC92YXIvbG9nL3Bn c3FsDQojIHVtb3VudCAtZiAvcGdzcWwNCg0KDQoNCg0KIyANCiMgDQojIA0KIyANCiMgLi9k aXNrc3BhY2VjaGVjay5zaCAICBtbSwgbW0sIG1tLCBtbSwgbW0sIG1tLCBtbSwgbW0sIG1tL CBtbSwgbW0sIG1tLCBtbSwgbW0sIG1tLCBtbSwgbW0sIG1tLCBtbSwcHBwcHBwdzaCAteCAu L2Rpc2tzcGFjZWNoZWNrLnNoIA0KKyBkZiAtaWggL3Bnc3FsDQpGaWxlc3lzdGVtICAgICBT aXplICAgIFVzZWQgICBBdmFpbCBDYXBhY2l0eSBpdXNlZCBpZnJlZSAlaXVzZWQgIE1vdW50 ZWQgb24NCi9kZXYvZGEwczFhICAgIDQ5NU0gICAgMzU0TSAgICAxMDFNICAgIDc4JSAgICAy LjBrICAgNjNrICAgIDMlICAgLw0KKyB2bXN0YXQgLXoNCklURU0gICAgICAgICAgICAgICAg ICAgU0laRSAgTElNSVQgICAgIFVTRUQgICAgIEZSRUUgICAgICBSRVEgRkFJTCBTTEVFUA0K DQpVTUEgS2VnczogICAgICAgICAgICAgICAyMDgsICAgICAgMCwgICAgICA4NiwgICAgICAx NiwgICAgICA4NiwgICAwLCAgIDANClVNQSBab25lczogICAgICAgICAgICAgMTQwOCwgICAg ICAwLCAgICAgIDg2LCAgICAgICAwLCAgICAgIDg2LCAgIDAsICAgMA0KVU1BIFNsYWJzOiAg ICAgICAgICAgICAgNTY4LCAgICAgIDAsICAgIDcwMTgsICAgICAzMjUsICA2MDkyODUsICAg MCwgICAwDQpVTUEgUkNudFNsYWJzOiAgICAgICAgICA1NjgsICAgICAgMCwgICAgNDMzNSwg ICAgIDg1MiwgIDM4NzI1NywgICAwLCAgIDANClVNQSBIYXNoOiAgICAgICAgICAgICAgIDI1 NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAzLCAgIDAsICAgMA0KMTYgQnVj a2V0OiAgICAgICAgICAgICAgMTUyLCAgICAgIDAsICAgICAgMjYsICAgICAgNzQsICAgICAy MTAsICAgMCwgICAwDQozMiBCdWNrZXQ6ICAgICAgICAgICAgICAyODAsICAgICAgMCwgICAg ICA0NywgICAgIDE0OSwgICAgIDMzOSwgICA2LCAgIDANCjY0IEJ1Y2tldDogICAgICAgICAg ICAgIDUzNiwgICAgICAwLCAgICAgIDc4LCAgICAgIDc2LCAgICAgNzUyLCAgOTAsICAgMA0K MTI4IEJ1Y2tldDogICAgICAgICAgICAxMDQ4LCAgICAgIDAsICAgIDIxMDAsICAgICAgIDAs IDE1MTMyMjIsMTQ5NTM1NjYsICAgMA0KVk0gT0JKRUNUOiAgICAgICAgICAgICAgMjMyLCAg ICAgIDAsICAgNzQ0MzMsICAxMTE1OTksMTM3NjIxNzI3LCAgIDAsICAgMA0KTUFQOiAgICAg ICAgICAgICAgICAgICAgMjMyLCAgICAgIDAsICAgICAgIDcsICAgICAgMjUsICAgICAgIDcs ICAgMCwgICAwDQpLTUFQIEVOVFJZOiAgICAgICAgICAgICAxMjAsIDExMjg3MTAsICAgICAg NzksICAgNTExMzMsMTcyNTkwMzM3NSwgICAwLCAgIDANCk1BUCBFTlRSWTogICAgICAgICAg ICAgIDEyMCwgICAgICAwLCAgICAgNjAxLCAgICA3MzY2LDI5MzAyMjUxNiwgICAwLCAgIDAN CmZha2VwZzogICAgICAgICAgICAgICAgIDEyMCwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMA0KbXRfem9uZTogICAgICAgICAgICAgICA0MTEyLCAgICAg IDAsICAgICAzMjYsICAgICAgIDEsICAgICAzMjYsICAgMCwgICAwDQoxNjogICAgICAgICAg ICAgICAgICAgICAgMTYsICAgICAgMCwgICAgMjgwMCwgICAgMTU2OCwxNDc0ODU2NywgICAw LCAgIDANCjMyOiAgICAgICAgICAgICAgICAgICAgICAzMiwgICAgICAwLCAgICAyOTMzLCAg ICAxNDEwLDQ4ODYxNTk3LCAgIDAsICAgMA0KNjQ6ICAgICAgICAgICAgICAgICAgICAgIDY0 LCAgICAgIDAsICAgIDUzNTAsICAgIDUxNzgsODA2MTY0NTYsICAgMCwgICAwDQoxMjg6ICAg ICAgICAgICAgICAgICAgICAxMjgsICAgICAgMCwgICAgOTg0NiwgICA1OTI5MCw2Njc4MDgx ODYsICAgMCwgICAwDQoyNTY6ICAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAg IDU2NywgICAgNTY1OCwyODE0ODY4NDgzLCAgIDAsICAgMA0KNTEyOiAgICAgICAgICAgICAg ICAgICAgNTEyLCAgICAgIDAsICAgIDI3MzYsICAgIDUzMjEsMTc1NzQxMzAsICAgMCwgICAw DQoxMDI0OiAgICAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgICA1MywgICAgMTIy NywgMjEzNzg0NSwgICAwLCAgIDANCjIwNDg6ICAgICAgICAgICAgICAgICAgMjA0OCwgICAg ICAwLCAgICA1NjI3LCAgICAxMjM3LCA0MDA5NTIyLCAgIDAsICAgMA0KNDA5NjogICAgICAg ICAgICAgICAgICA0MDk2LCAgICAgIDAsICAgICA0MTksICAgIDEwNTMsIDUxNzU3OTcsICAg MCwgICAwDQpGaWxlczogICAgICAgICAgICAgICAgICAgODAsICAgICAgMCwgICAgICA4Mywg ICAxMTEyMiwxOTMwNjE0MDQsICAgMCwgICAwDQpUVVJOU1RJTEU6ICAgICAgICAgICAgICAx MzYsICAgICAgMCwgICAgMTkzOSwgICAgIDEyMSwgICAgMTk0OCwgICAwLCAgIDANCnVtdHgg cGk6ICAgICAgICAgICAgICAgICA5NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMA0KTUFDIGxhYmVsczogICAgICAgICAgICAgIDQwLCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQpQUk9DOiAgICAgICAgICAgICAg ICAgIDExODQsICAgICAgMCwgICAgICA0NCwgICAgMTQ0MSwgNDQwNzAxNywgICAwLCAgIDAN ClRIUkVBRDogICAgICAgICAgICAgICAgMTEyOCwgICAgICAwLCAgICAxNTQ5LCAgICAgMzg5 LCAgICAxOTUxLCAgIDAsICAgMA0KU0xFRVBRVUVVRTogICAgICAgICAgICAgIDgwLCAgICAg IDAsICAgIDE5MzksICAgICAyNjUsICAgIDE5NDgsICAgMCwgICAwDQpWTVNQQUNFOiAgICAg ICAgICAgICAgICAzOTIsICAgICAgMCwgICAgICAyNSwgICAgMTU2NSwgNDQwNzAwMCwgICAw LCAgIDANCmNwdXNldDogICAgICAgICAgICAgICAgICA3MiwgICAgICAwLCAgICAgIDg1LCAg ICAgIDY1LCAgICAgIDg1LCAgIDAsICAgMA0KYXVkaXRfcmVjb3JkOiAgICAgICAgICAgOTYw LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwDQptYnVmX3Bh Y2tldDogICAgICAgICAgICAyNTYsICAgICAgMCwgICAgNDA4MCwgICAgMTI5Niw2ODg1MDM5 NjYsICAgMCwgICAwDQptYnVmOiAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAg MTAyMSwgICAgMTk3MywxOTQyMDI4NTA1LCAgIDAsICAgMA0KbWJ1Zl9jbHVzdGVyOiAgICAg ICAgICAyMDQ4LCAgMjU2MDAsICAgIDUzNzYsICAgIDE4OTQsIDE2OTMxODQsICAgMCwgICAw DQptYnVmX2p1bWJvX3BhZ2U6ICAgICAgIDQwOTYsICAxMjgwMCwgICAgICAgMCwgICAgIDcw MCw4MzMxNjU0NiwgICAwLCAgIDANCm1idWZfanVtYm9fOWs6ICAgICAgICAgOTIxNiwgICA2 NDAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0KbWJ1Zl9qdW1ib18x Nms6ICAgICAgIDE2Mzg0LCAgIDMyMDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwDQptYnVmX2V4dF9yZWZjbnQ6ICAgICAgICAgIDQsICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCmdfYmlvOiAgICAgICAgICAgICAgICAgIDIz MiwgICAgICAwLCAgICAgICAwLCAgICA2MDY0LDI4NzcxMTI0MTIsICAgMCwgICAwDQp0dHlp bnE6ICAgICAgICAgICAgICAgICAxNjAsICAgICAgMCwgICAgIDEzNSwgICAgIDM5MywgICAg MjUyMCwgICAwLCAgIDANCnR0eW91dHE6ICAgICAgICAgICAgICAgIDI1NiwgICAgICAwLCAg ICAgIDcyLCAgICAgMzMzLCAgICAxMzQ0LCAgIDAsICAgMA0KYXRhX3JlcXVlc3Q6ICAgICAg ICAgICAgMzI4LCAgICAgIDAsICAgICAgIDAsICAgICAgODQsICAgICAgMzIsICAgMCwgICAw DQphdGFfY29tcG9zaXRlOiAgICAgICAgICAzMzYsICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDANClZOT0RFOiAgICAgICAgICAgICAgICAgIDQ4MCwgICAg ICAwLCAgMjAxMjE0LCAgIDU4MDY2LDE1Mzc3NjU2OSwgICAwLCAgIDANClZOT0RFUE9MTDog ICAgICAgICAgICAgIDExMiwgICAgICAwLCAgICAgICAwLCAgICAgMTMyLCAgICAgICA2LCAg IDAsICAgMA0KTkFNRUk6ICAgICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAgICAgIDAs ICAgIDEyMTIsNDE4OTEzOTY2LCAgIDAsICAgMA0KUyBWRlMgQ2FjaGU6ICAgICAgICAgICAg MTA4LCAgICAgIDAsICAyMDgyMTMsICAgNjc4NjUsMTU4MDQ5NTQzLCAgIDAsICAgMA0KU1RT IFZGUyBDYWNoZTogICAgICAgICAgMTQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwDQpMIFZGUyBDYWNoZTogICAgICAgICAgICAzMjgsICAgICAgMCwg ICAgIDY4MSwgICAgNDk1OSwgNzM3NjcyOSwgICAwLCAgIDANCkxUUyBWRlMgQ2FjaGU6ICAg ICAgICAgIDM2OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MA0KTkNMTk9ERTogICAgICAgICAgICAgICAgNTY4LCAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgMCwgICAwDQpESVJIQVNIOiAgICAgICAgICAgICAgIDEwMjQsICAg ICAgMCwgICAgMTc0NSwgICAgIDgzOSwgMjk4MTg4MCwgICAwLCAgIDANCk1vdW50cG9pbnRz OiAgICAgICAgICAgIDc5MiwgICAgICAwLCAgICAgICA3LCAgICAgIDIzLCAgICAgICA4LCAg IDAsICAgMA0KcGlwZTogICAgICAgICAgICAgICAgICAgNzI4LCAgICAgIDAsICAgICAgIDIs ICAgIDEyMjgsIDM4NDg5NTEsICAgMCwgICAwDQprc2lnaW5mbzogICAgICAgICAgICAgICAx MTIsICAgICAgMCwgICAgMTQ3NCwgICAgMTQzMCwgOTc3MDU0MSwgICAwLCAgIDANCml0aW1l cjogICAgICAgICAgICAgICAgIDM0NCwgICAgICAwLCAgICAgICAxLCAgICAgIDIxLCAgICAg ICAxLCAgIDAsICAgMA0KS05PVEU6ICAgICAgICAgICAgICAgICAgMTI4LCAgICAgIDAsICAg ICAgIDAsICAgIDE3MTEsIDEwOTgwMjksICAgMCwgICAwDQpzb2NrZXQ6ICAgICAgICAgICAg ICAgICA2ODAsIDEwMDAwMiwgICAgICAyNiwgICAgMTQzMiwgOTM2ODAyNiwgICAwLCAgIDAN CmlwcTogICAgICAgICAgICAgICAgICAgICA1NiwgICAgODE5LCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMA0KdWRwX2lucGNiOiAgICAgICAgICAgICAgMzkyLCAxMDAw MDAsICAgICAgMTIsICAgIDE0MTgsIDczMjgzNzgsICAgMCwgICAwDQp1ZHBjYjogICAgICAg ICAgICAgICAgICAgMTYsIDEwMDEyOCwgICAgICAxMiwgICAgMTgzNiwgNzMyODM3OCwgICAw LCAgIDANCnRjcF9pbnBjYjogICAgICAgICAgICAgIDM5MiwgMTAwMDAwLCAgICAgICA1LCAg ICAxNzU1LCAgNjUyMDYwLCAgIDAsICAgMA0KdGNwY2I6ICAgICAgICAgICAgICAgICAgOTc2 LCAxMDAwMDAsICAgICAgIDUsICAgIDE3NjcsICA2NTIwNjAsICAgMCwgICAwDQp0Y3B0dzog ICAgICAgICAgICAgICAgICAgNzIsICAyMDAwMCwgICAgICAgMCwgICAgIDU1MCwgICAgMzI1 NCwgICAwLCAgIDANCnN5bmNhY2hlOiAgICAgICAgICAgICAgIDE1MiwgIDE1Mzc1LCAgICAg ICAwLCAgICAgNjI1LCAgNTA1NDM5LCAgIDAsICAgMA0KaG9zdGNhY2hlOiAgICAgICAgICAg ICAgMTM2LCAgMTUzNzIsICAgICAgIDQsICAgICA0NDQsICAgIDE4MjAsICAgMCwgICAwDQp0 Y3ByZWFzczogICAgICAgICAgICAgICAgNDAsICAgMTY4MCwgICAgICAgMCwgICAgMTU5Niwg ICAyMTY5MCwgICAwLCAgIDANCnNhY2tob2xlOiAgICAgICAgICAgICAgICAzMiwgICAgICAw LCAgICAgICAwLCAgICAgOTA5LCAgICAgODc1LCAgIDAsICAgMA0Kc2N0cF9lcDogICAgICAg ICAgICAgICAxMzc2LCAxMDAwMDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwDQpzY3RwX2Fzb2M6ICAgICAgICAgICAgIDIyODgsICA0MDAwMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfbGFkZHI6ICAgICAgICAgICAgICA0OCwg IDgwMDY0LCAgICAgICAwLCAgICAgMjg4LCAgICAgICA2LCAgIDAsICAgMA0Kc2N0cF9yYWRk cjogICAgICAgICAgICAgNzA0LCAgODAwMDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwDQpzY3RwX2NodW5rOiAgICAgICAgICAgICAxMzYsIDQwMDAwOCwgICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfcmVhZHE6ICAgICAgICAgICAg IDEwNCwgNDAwMDMyLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMA0Kc2N0 cF9zdHJlYW1fbXNnX291dDogICAgMTEyLCA0MDAwMjYsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwDQpzY3RwX2FzY29uZjogICAgICAgICAgICAgNDAsIDQwMDAwOCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCnNjdHBfYXNjb25mX2Fjazog ICAgICAgICA0OCwgNDAwMDMyLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MA0KcmlwY2I6ICAgICAgICAgICAgICAgICAgMzkyLCAxMDAwMDAsICAgICAgIDAsICAgICAx MDAsICAgICAxMjIsICAgMCwgICAwDQp1bnBjYjogICAgICAgICAgICAgICAgICAyNDAsIDEw MDAwMCwgICAgICAgOCwgICAgMTMyMCwgMTM4NzQ2MCwgICAwLCAgIDANCnJ0ZW50cnk6ICAg ICAgICAgICAgICAgIDIwMCwgICAgICAwLCAgICAgIDIzLCAgICAgIDkxLCAgICAgIDIzLCAg IDAsICAgMA0Kc2VsZmQ6ICAgICAgICAgICAgICAgICAgIDU2LCAgICAgIDAsICAgIDIwMTQs ICAgIDEzMjUsMzAwMTkxMTg2LCAgIDAsICAgMA0KU1dBUE1FVEE6ICAgICAgICAgICAgICAg Mjg4LCAxMTY1MTksICAgICAgMzMsICAgICA1NjUsIDEwNTM1NzQsICAgMCwgICAwDQpGRlMg aW5vZGU6ICAgICAgICAgICAgICAxNjgsICAgICAgMCwgIDE5NzAyMCwgICA2ODk4MiwxNTM3 NzQzMjYsICAgMCwgICAwDQpGRlMxIGRpbm9kZTogICAgICAgICAgICAxMjgsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDANCkZGUzIgZGlub2RlOiAgICAg ICAgICAgIDI1NiwgICAgICAwLCAgMTk3MDIwLCAgIDY3Njg1LDE1Mzc3NDMyMCwgICAwLCAg IDANCg0KKyB2bXN0YXQgLW0NCiAgICAgICAgIFR5cGUgSW5Vc2UgTWVtVXNlIEhpZ2hVc2Ug UmVxdWVzdHMgIFNpemUocykNCkNBTSBkZXYgcXVldWUgICAgIDQgICAgIDFLICAgICAgIC0g ICAgICAgIDQgIDEyOA0KICBtZF9zaWlfZGF0YSAgICAgMCAgICAgMEsgICAgICAgLSAgICAg ICA0MiAgNTEyDQogICAgICBDQU0gWFBUICAgNTcxICAxMDQ1SyAgICAgICAtICAgICAgOTQ4 ICAxNiwzMiw2NCwxMjgsMjU2LDEwMjQsMjA0OA0KICAgICAgIGlzYWRldiAgICAgOCAgICAg MUsgICAgICAgLSAgICAgICAgOCAgMTI4DQogICAgICAgICBVQVJUICAgICA2ICAgICA0SyAg ICAgICAtICAgICAgICA2ICAxNiw1MTIsMTAyNA0KICAgICBhY3BpaW50ciAgICAgMSAgICAg MUsgICAgICAgLSAgICAgICAgMSAgNjQNCiAgICAgICAgIGNkZXYgICAgIDcgICAgIDJLICAg ICAgIC0gICAgICAgIDcgIDI1Ng0KICAgICAgIGFjcGljYSAgMTQ1MSAgIDEzOUsgICAgICAg LSAgNjMwODY4OCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNA0KICAgICAgICBzaWdpbyAg ICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNjQNCiAgICAgZmlsZWRlc2MgICAgNDcg ICAgMjVLICAgICAgIC0gIDQ5MDQwODAgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0 OCw0MDk2DQogICAgICAgICBrZW52ICAgIDc4ICAgIDExSyAgICAgICAtICAgICAgIDg5ICAx NiwzMiw2NCwxMjgNCiAgICAgICBrcXVldWUgICAgIDAgICAgIDBLICAgICAgIC0gIDEwNTY5 OTUgIDI1Niw1MTIsMjA0OA0KICAgIHByb2MtYXJncyAgICAyNSAgICAgMksgICAgICAgLSAg Njk2NzQ5MSAgMTYsMzIsNjQsMTI4LDI1Ng0KICAgICAgICBoaG9vayAgICAgMiAgICAgMUsg ICAgICAgLSAgICAgICAgMiAgMTI4DQogICAgIGFjcGl0YXNrICAgICAxICAgICAySyAgICAg ICAtICAgICAgICAxICAyMDQ4DQogICAgICBpdGhyZWFkICAgIDk5ICAgIDE2SyAgICAgICAt ICAgICAgIDk5ICAzMiwxMjgsMjU2DQogICAgQ0FNIHF1ZXVlICAgIDE5ICAgICA3SyAgICAg ICAtICAgICAgNDA3ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwyMDQ4DQogICAgICAgS1RSQUNF ICAgMTAwICAgIDEzSyAgICAgICAtICAgICAgMTAwICAxMjgNCiAgICAgICBsaW5rZXIgICAx NTggICAgMTFLICAgICAgIC0gICAgICAxNjAgIDE2LDMyLDY0LDUxMg0KICAgICAgICBsb2Nr ZiAgICAyMCAgICAgM0sgICAgICAgLSAgICAyNDAwOCAgNjQsMTI4DQogICBsb2dpbmNsYXNz ICAgICAyICAgICAxSyAgICAgICAtICAgIDU5MDY1ICA2NA0KICAgICAgIGlwNm5kcCAgICAx MiAgICAgMUsgICAgICAgLSAgICAgICAxNCAgNjQsMTI4DQogICAgICAgICB0ZW1wICAgIDUx ICAgICAySyAgICAgICAtICA4MjIxNjIxICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIw NDgsNDA5Ng0KICAgICAgIGRldmJ1ZiAgODY0OCA0MTg4OUsgICAgICAgLSAgICAxMDE0MyAg MTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgICBtb2R1bGUgICA0 NzcgICAgNjBLICAgICAgIC0gICAgICA0NzcgIDEyOA0KICAgIGNpc3NfZGF0YSAgICAxNSAg ICAxNEsgICAgICAgLSAgICAgNTkyMSAgMTYsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYN CiAgICAgbXR4X3Bvb2wgICAgIDIgICAgMTZLICAgICAgIC0gICAgICAgIDIgIA0KICAgICAg IFVTQmRldiAgICAzNCAgICAgOEsgICAgICAgLSAgICAgICA0NCAgNjQsMTI4LDUxMiw0MDk2 DQogICAgICAgICAgVVNCICAgIDUyICAgIDMxSyAgICAgICAtICAgICAgIDY2ICAxNiwzMiw2 NCwxMjgsMjU2LDIwNDgsNDA5Ng0KICAgICBwbWNob29rcyAgICAgMSAgICAgMUsgICAgICAg LSAgICAgICAgMSAgMTI4DQogICAgICBzdWJwcm9jICAxNTMyICAgOTI0SyAgICAgICAtICA0 NDA4NTA2ICA1MTIsNDA5Ng0KICAgICAgICAgcHJvYyAgICAgMiAgICAxNksgICAgICAgLSAg ICAgICAgMiAgDQogICAgICBzZXNzaW9uICAgIDIxICAgICAzSyAgICAgICAtICAzNTUwNjg0 ICAxMjgNCiAgICAgICAgIHBncnAgICAgMjQgICAgIDNLICAgICAgIC0gIDM1NTUxNTcgIDEy OA0KICAgICAgICAgY3JlZCAgICA0MCAgICAgN0sgICAgICAgLSAzMjg3NzYzMiAgNjQsMjU2 DQogICAgICB1aWRpbmZvICAgICA0ICAgICAzSyAgICAgICAtICAgMTg2ODYxICAxMjgsMjA0 OA0KICAgICAgIHBsaW1pdCAgICAxNCAgICAgNEsgICAgICAgLSAgIDc3MDc2MyAgMjU2DQog ICAgICBhdGFfcGNpICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICA2NA0KICAgICAg c2NzaV9jZCAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxMCAgMTYNCiAgICBzeXNjdGx0 bXAgICAgIDAgICAgIDBLICAgICAgIC0gICAgMTQyNTcgIDE2LDMyLDY0LDEyOCw0MDk2DQog ICAgc3lzY3Rsb2lkICA0OTc4ICAgMjUxSyAgICAgICAtICAgICA1MzYwICAxNiwzMiw2NCwx MjgNCiAgICAgICBzeXNjdGwgICAgIDAgICAgIDBLICAgICAgIC0gIDc5NTYzNDIgIDE2LDMy LDY0DQogICAgICB0aWRoYXNoICAgICAxICAgIDE2SyAgICAgICAtICAgICAgICAxICANCiAg ICAgIGNhbGxvdXQgICAgIDcgMTQzMzZLICAgICAgIC0gICAgICAgIDcgIA0KICAgICAgICAg dW10eCAgMzg3NiAgIDQ4NUsgICAgICAgLSAgICAgMzg5NCAgMTI4DQogICAgIHAxMDAzLjFi ICAgICAxICAgICAxSyAgICAgICAtICAgICAgICAxICAxNg0KICAgICAgICAgU1dBUCAgICAg MiAgIDU0OUsgICAgICAgLSAgICAgICAgMiAgNjQNCiAgICAgICBidXMtc2MgICAxMTMgICA3 ODFLICAgICAgIC0gICAgIDUyMzQgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0 MDk2DQogICAgICAgICAgYnVzICAxMjgyICAgMTA5SyAgICAgICAtICAgICA4NjQwICAxNiwz Miw2NCwxMjgsMjU2LDEwMjQNCiAgICAgIGRldnN0YXQgICAgMTIgICAgMjVLICAgICAgIC0g ICAgICAgMTIgIDMyLDQwOTYNCiBldmVudGhhbmRsZXIgICAgNzcgICAgIDZLICAgICAgIC0g ICAgICAgNzcgIDY0LDEyOA0KICAgICAgYWNwaXNlbSAgICAxOSAgICAgM0sgICAgICAgLSAg ICAgICAxOSAgMTI4DQogICAgICAgICBrb2JqICAgMzMwICAxMzIwSyAgICAgICAtICAgICAg NjUwICA0MDk2DQogICAgICBDQU0gU0lNICAgICA1ICAgICAySyAgICAgICAtICAgICAgICA1 ICAyNTYNCiAgICAgIFBlci1jcHUgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDMy DQogICBDQU0gcGVyaXBoICAgIDEwICAgICAzSyAgICAgICAtICAgICAgIDU0ICAxNiwzMiw2 NCwxMjgsMjU2DQogICAgICAgICBybWFuICAgMjQ4ICAgIDI2SyAgICAgICAtICAgICAgNjEz ICAxNiwzMiwxMjgNCiAgICAgICAgIHNidWYgICAgIDEgICAgIDFLICAgICAgIC0gICAgIDIx MTAgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2DQogICAgICBlbnRyb3B5 ICAxMDI0ICAgIDY0SyAgICAgICAtICAgICAxMDI0ICA2NA0KICAgICAgIGN0bG1lbSAgNTA2 MiAxMDExM0sgICAgICAgLSAgICAgNTA2MiAgMTI4LDIwNDgNCiAgICAgICAgc3RhY2sgICAg IDAgICAgIDBLICAgICAgIC0gICAgICAgIDIgIDI1Ng0KICAgIHRhc2txdWV1ZSAgICAxNSAg ICAgMksgICAgICAgLSAgICAgICAxNSAgMTYsMzIsMTI4DQogICAgICAgVW5pdG5vICAgIDE0 ICAgICAxSyAgICAgICAtICAgNTk2NzY2ICAzMiw2NA0KICAgICAgICAgIGlvdiAgICAgMCAg ICAgMEsgICAgICAgLSAgMTU2MDc5NCAgMTYsMzIsNjQsMTI4LDI1Niw1MTINCiAgICAgICBz ZWxlY3QgIDE0NTUgICAxODJLICAgICAgIC0gICAgIDE0NTUgIDEyOA0KICAgICBpb2N0bG9w cyAgICAgMCAgICAgMEsgICAgICAgLSAgODQ5Nzg1MiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIs MTAyNCwyMDQ4LDQwOTYNCiAgICAgICAgICBtc2cgICAgIDQgICAgMzBLICAgICAgIC0gICAg ICAgIDQgIDIwNDgsNDA5Ng0KICAgICAgICAgIHNlbSAgICAgNCAgIDE5NksgICAgICAgLSAg ICAgICAgNCAgDQogICAgICAgICAgc2htICAgICAxICAgIDIwSyAgICAgICAtICAzMzQ5Mjgz ICAyMDQ4DQogICAgICAgICAgdHR5ICAgIDIyICAgIDIySyAgICAgICAtICAgICAgMTUwICAx MDI0LDIwNDgNCiAgICAgICAgICBwdHMgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAxMjcg IDI1Ng0KICAgICBtYnVmX3RhZyAgICAgMCAgICAgMEsgICAgICAgLSA0MzM0NDY5OSAgMzIs MTI4DQogICAgICAgIHNobWZkICAgICAxICAgICA4SyAgICAgICAtICAgICAgICAxICANCiAg ICAgICAgICBwY2IgICAgMjAgICAxNTdLICAgICAgIC0gICA2MjkwOTMgIDE2LDMyLDEyOCwx MDI0LDIwNDgsNDA5Ng0KICAgICAgIHNvbmFtZSAgICAgMyAgICAgMUsgICAgICAgLSA1MjIz MDM1NyAgMTYsMzIsMTI4DQogICAgICAgICAgYWNsICAgICAwICAgICAwSyAgICAgICAtICAg MTQ0MTAxICA0MDk2DQogICAgICAgYmlvYnVmICAgICAwICAgICAwSyAgICAgICAtICAgIDE0 NjgzICAyMDQ4DQogICAgIHZmc2NhY2hlICAgICAxICA4MTkySyAgICAgICAtICAgICAgICAx ICANCiAgIGNsX3NhdmVidWYgICAgIDAgICAgIDBLICAgICAgIC0gMTAxNzA4NTU4ICA2NCwx MjgNCiAgICAgdmZzX2hhc2ggICAgIDEgIDQwOTZLICAgICAgIC0gICAgICAgIDEgIA0KICAg ICAgIERFVkZTMSAgIDExNSAgICA1OEsgICAgICAgLSAgICAgIDI2NCAgNTEyDQogICAgICAg dm5vZGVzICAgICAyICAgICAxSyAgICAgICAtICAgICAgICA0ICA2NCwyNTYNCiAgICAgICBE RVZGUzMgICAxMzQgICAgMzRLICAgICAgIC0gICAgICAyOTMgIDI1Ng0KICAgICAgICBtb3Vu dCAgICA5MSAgICAgNUsgICAgICAgLSAgICAgIDE3NiAgMTYsMzIsNjQsMTI4LDI1Ng0KICB2 bm9kZW1hcmtlciAgICAgMCAgICAgMEsgICAgICAgLSAgNTA2MjQ5NiAgNTEyDQogICAgICAg ICAgQlBGICAgICA5ICAgICAySyAgICAgICAtICAgICAgICA5ICAxMjgNCiAgZXRoZXJfbXVs dGkgICAgNTYgICAgIDNLICAgICAgIC0gICAgICAgNjYgIDE2LDMyLDY0DQogICAgICAgaWZh ZGRyICAgIDg3ICAgIDIySyAgICAgICAtICAgICAgIDg3ICAzMiw2NCwxMjgsMjU2LDUxMiw0 MDk2DQogICAgICAgIGlmbmV0ICAgIDEwICAgIDE5SyAgICAgICAtICAgICAgIDEwICAxMjgs MjA0OA0KICAgICAgICBjbG9uZSAgICAgNiAgICAyNEsgICAgICAgLSAgICAgICAgNiAgNDA5 Ng0KICAgICAgIGFycGNvbSAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTYNCiAg ICAgIGxsdGFibGUgICAgMzEgICAgMTNLICAgICAgIC0gICAgNTg0ODIgIDI1Niw1MTINCiAg ICAgICAgREVWRlMgICAgMTcgICAgIDFLICAgICAgIC0gICAgICAgMjAgIDE2LDEyOA0KICAg ICAgIERFVkZTUCAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQNCiAgICAgcm91 dGV0YmwgICAgNDQgICAgIDZLICAgICAgIC0gIDE0NjQyNDQgIDMyLDY0LDEyOCwyNTYsNTEy DQogICAgICAgICBpZ21wICAgICA5ICAgICAzSyAgICAgICAtICAgICAgICA5ICAyNTYNCiAg ICAgaW5fbXVsdGkgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDI1Ng0KICAgIHNj dHBfaXRlciAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgNCAgMjU2DQogICAgIHNjdHBf aWZuICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAxMjgNCiAgICAgc2N0cF9pZmEg ICAgIDcgICAgIDFLICAgICAgIC0gICAgICAgIDcgIDEyOA0KICAgICBzY3RwX3ZyZiAgICAg MSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNjQNCiAgICBzY3RwX2FfaXQgICAgIDAgICAg IDBLICAgICAgIC0gICAgICAgIDQgIDE2DQogICAgaG9zdGNhY2hlICAgICAxICAgIDI4SyAg ICAgICAtICAgICAgICAxICANCiAgICAgc3luY2FjaGUgICAgIDEgICAgOTZLICAgICAgIC0g ICAgICAgIDEgIA0KICAgIGluNl9tdWx0aSAgICAyOCAgICAgNEsgICAgICAgLSAgICAgICAy OCAgMzIsMjU2DQogICAgICAgICAgbWxkICAgICA5ICAgICAySyAgICAgICAtICAgICAgICA5 ICAxMjgNCiAgICAgICAgICBycGMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1 Ng0KYXVkaXRfZXZjbGFzcyAgIDE3OSAgICAgNksgICAgICAgLSAgICAgIDIxOCAgMzINCiAg ICAgc2F2ZWRpbm8gICAgIDAgICAgIDBLICAgICAgIC0gIDMwODMyMjcgIDI1Ng0KICAgICBm cmVld29yayAgICAgMSAgICAgMUsgICAgICAgLSA4MDYwMjkwMiAgMTYsMTI4DQogICAgbmV3 ZGlyYmxrICAgICAwICAgICAwSyAgICAgICAtICAgIDE4MzM3ICA2NA0KICAgICAgIGRpcnJl bSAgICAgMCAgICAgMEsgICAgICAgLSAxMzA4MzAzNSAgMTI4DQogICAgICAgIG1rZGlyICAg ICAwICAgICAwSyAgICAgICAtICAgIDI5NDM2ICAxMjgNCiAgICAgICBkaXJhZGQgICAgIDAg ICAgIDBLICAgICAgIC0gMTMwOTEyNjMgIDEyOA0KICAgICBmcmVlZmlsZSAgICAgMCAgICAg MEsgICAgICAgLSAgNjcxODEwOCAgNjQNCiAgICAgZnJlZWJsa3MgICAgIDAgICAgIDBLICAg ICAgIC0gIDY2MTU0NzEgIDEyOA0KICAgICBmcmVlZnJhZyAgICAgMCAgICAgMEsgICAgICAg LSA0Mjc1ODI5MjIgIDEyOA0KICAgICBpbmRpcmRlcCAgICAgMCAgICAgMEsgICAgICAgLSAg NjI1MTkxNyAgMTI4DQogICAgICAgbmV3YmxrICAgICAxICAgNTEySyAgICAgICAtIDI3ODE4 NjcyODkgIDI1Ng0KICAgIGJtc2FmZW1hcCAgICAgMSAgICAgOEsgICAgICAgLSAgODkzODgx NyAgMjU2DQogICAgIGlub2RlZGVwICAgICAxICA0MDk2SyAgICAgICAtICA3ODQwNDE2ICA1 MTINCiAgICAgIHBhZ2VkZXAgICAgIDEgICA1MTJLICAgICAgIC0gICAxMzkxMjYgIDI1Ng0K ICB1ZnNfZGlyaGFzaCAgMTQwNyAgIDM1OUsgICAgICAgLSAgIDQwMTY0OSAgMTYsMzIsNjQs MTI4LDI1Niw1MTIsMTAyNA0KICAgIHVmc19tb3VudCAgICAxNSAgICA1MUsgICAgICAgLSAg ICAgICAxOCAgNTEyLDIwNDgsNDA5Ng0KICAgIHZtX3BnZGF0YSAgICAgMiAgIDEyOUsgICAg ICAgLSAgICAgICAgMiAgMTI4DQogICAgICBVTUFIYXNoICAgICAzICAgIDIySyAgICAgICAt ICAgICAgIDEzICA1MTIsMTAyNCwyMDQ4LDQwOTYNCiAgICAgIG1lbWRlc2MgICAgIDEgICAg IDRLICAgICAgIC0gICAgICAgIDEgIDQwOTYNCiAgICAgYXRrYmRkZXYgICAgIDIgICAgIDFL ICAgICAgIC0gICAgICAgIDIgIDY0DQogICAgcGZzX25vZGVzICAgIDIxICAgICA2SyAgICAg ICAtICAgICAgIDIxICAyNTYNCiAgcGZzX3ZuY2FjaGUgICAgIDEgICAgIDFLICAgICAgIC0g ICAgICAyNjAgIDY0DQogICAgICAgY3RsYmxrICAgMjAwICAxNjAwSyAgICAgICAtICAgICAg MjAwICANCiAgICAgICAgIEdFT00gICAxMzMgICAgNDFLICAgICAgIC0gICAgIDE0MTkgIDE2 LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OA0KICAgICAgcmFtZGlzayAgICAgMSAgNDA5 NksgICAgICAgLSAgICAgICAgMSAgDQogICAgICBhY3BpZGV2ICAgIDMwICAgICAySyAgICAg ICAtICAgICAgIDMwICA2NA0KICAgICAgY3RscG9vbCAgIDUzMiAgIDE0MksgICAgICAgLSAg ICAgIDUzMiAgMzIsNTEyDQogICAgICAga2JkbXV4ICAgICA3ICAgIDE4SyAgICAgICAtICAg ICAgICA4ICAxNiw1MTIsMTAyNCwyMDQ4DQogICAgICAgYXBtZGV2ICAgICAxICAgICAxSyAg ICAgICAtICAgICAgICAxICAxMjgNCiAgIG1hZHRfdGFibGUgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAgIDEgIDQwOTYNCiAgICAgICBmZWVkZXIgICAgIDcgICAgIDFLICAgICAgIC0g ICAgICAgIDcgIDMyDQogICAgICBzY3NpX2RhICAgICAwICAgICAwSyAgICAgICAtICAgICAg Mjk2ICAxNg0KICAgICBwY2lfbGluayAgICAxNiAgICAgMksgICAgICAgLSAgICAgICAxNiAg MTYsMTI4DQogICAgcmFpZF9kYXRhICAgICAwICAgICAwSyAgICAgICAtICAgICAgMjU4ICAz MiwxMjgsMjU2DQogICAgICBpb19hcGljICAgICAxICAgICAySyAgICAgICAtICAgICAgICAx ICAyMDQ4DQogICAgICAgICAgTUNBICAgICA4ICAgICAxSyAgICAgICAtICAgICAgICA4ICAx MjgNCiAgICAgICAgICBtc2kgICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDEyOA0K ICAgICBuZXh1c2RldiAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMTYNCm1kX252 aWRpYV9kYXRhICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDQyICA1MTINCisgc3lzY3Rs IGRlYnVnDQpkZWJ1Zy5hY3BpLnN1c3BlbmRfYm91bmNlOiAwDQpkZWJ1Zy5hY3BpLnJlc2V0 X2Nsb2NrOiAxDQpkZWJ1Zy5hY3BpLmludGVycHJldGVyX3NsYWNrOiAxDQpkZWJ1Zy5hY3Bp LmVuYWJsZV9kZWJ1Z19vYmplY3RzOiAwDQpkZWJ1Zy5hY3BpLmFjcGlfY2FfdmVyc2lvbjog MjAxMTA1MjcNCmRlYnVnLmFjcGkuY3B1X3Vub3JkZXJlZDogMA0KZGVidWcuYWNwaS5lYy50 aW1lb3V0OiA3NTANCmRlYnVnLmFjcGkuZWMucG9sbGVkOiAwDQpkZWJ1Zy5hY3BpLmVjLmJ1 cnN0OiAwDQpkZWJ1Zy5hY3BpLmJhdHQuYmF0dF9zbGVlcF9tczogMA0KZGVidWcuYWNwaS5y ZXN1bWVfYmVlcDogMA0KZGVidWcuZmlyZXdpcmVfZGVidWc6IDANCmRlYnVnLmZ3bWVtX2Rl YnVnOiAwDQpkZWJ1Zy5pZl9md2VfZGVidWc6IDANCmRlYnVnLmlmX2Z3aXBfZGVidWc6IDAN CmRlYnVnLmlwdzogMA0KZGVidWcuaXdpOiAwDQpkZWJ1Zy5tZGRlYnVnOiAwDQpkZWJ1Zy53 cGk6IDANCmRlYnVnLmVsZjY0X2xlZ2FjeV9jb3JlZHVtcDogMA0KZGVidWcuYm9vdHZlcmJv c2U6IDANCmRlYnVnLmJvb3Rob3d0bzogMA0KZGVidWcuY3B1ZnJlcS52ZXJib3NlOiAwDQpk ZWJ1Zy5jcHVmcmVxLmxvd2VzdDogMA0KZGVidWcuZmFpbF9wb2ludC5zeXNjdGxfcnVubmlu Zzogb2ZmDQpkZWJ1Zy5mYWlsX3BvaW50LmJ1Zl9wcmVzc3VyZTogb2ZmDQpkZWJ1Zy5mYWls X3BvaW50Lm5sbV9kZW55X2dyYW50OiBvZmYNCmRlYnVnLmFkYXB0aXZlX21hY2hpbmVfYXJj aDogMQ0KZGVidWcuc2l6ZW9mLmNkZXZfcHJpdjogMzc2DQpkZWJ1Zy5zaXplb2YuY2Rldjog Mjg4DQpkZWJ1Zy5zaXplb2YuZ19iaW9xOiA1Ng0KZGVidWcuc2l6ZW9mLmdfY29uc3VtZXI6 IDk2DQpkZWJ1Zy5zaXplb2YuZ19wcm92aWRlcjogMTM2DQpkZWJ1Zy5zaXplb2YuZ19nZW9t OiAxNjANCmRlYnVnLnNpemVvZi5nX2NsYXNzOiAxNjANCmRlYnVnLnNpemVvZi5raW5mb19w cm9jOiAxMDg4DQpkZWJ1Zy5zaXplb2YuYnVmOiA2MDgNCmRlYnVnLnNpemVvZi5iaW86IDIz Mg0KZGVidWcuc2l6ZW9mLnByb2M6IDExODQNCmRlYnVnLnNpemVvZi52bm9kZTogNDgwDQpk ZWJ1Zy5zaXplb2YuZGV2c3RhdDogMjg4DQpkZWJ1Zy5zaXplb2YubmFtZWNhY2hlOiA3Mg0K ZGVidWcub3NkOiAwDQpkZWJ1Zy50cmFjZV9vbl9wYW5pYzogMQ0KZGVidWcuZGVidWdnZXJf b25fcGFuaWM6IDENCmRlYnVnLm5jb3JlczogNQ0KZGVidWcudG9fYXZnX21wY2FsbHM6IDc0 Mw0KZGVidWcudG9fYXZnX2xvY2tjYWxsczogMjUxDQpkZWJ1Zy50b19hdmdfZ2NhbGxzOiA0 OTENCmRlYnVnLnRvX2F2Z19kZXB0aDogMTczNA0KZGVidWcudW10eC51bXR4X3BpX2FsbG9j YXRlZDogMA0KZGVidWcuY2xvY2t0aW1lOiAwDQpkZWJ1Zy5rZGIuYWx0X2JyZWFrX3RvX2Rl YnVnZ2VyOiAwDQpkZWJ1Zy5rZGIuYnJlYWtfdG9fZGVidWdnZXI6IDANCmRlYnVnLmtkYi50 cmFwX2NvZGU6IDANCmRlYnVnLmtkYi50cmFwOiAwDQpkZWJ1Zy5rZGIucGFuaWM6IDANCmRl YnVnLmtkYi5lbnRlcjogMA0KZGVidWcua2RiLmN1cnJlbnQ6IA0KZGVidWcucm1hbl9kZWJ1 ZzogMA0KZGVidWcuaW9zaXplX21heF9jbGFtcDogMQ0KZGVidWcuZGlzYWJsZWZ1bGxwYXRo OiAwDQpkZWJ1Zy5kaXNhYmxlY3dkOiAwDQpkZWJ1Zy52ZnNjYWNoZTogMQ0KZGVidWcubnVt Y2FjaGVodjogMjUxNTgNCmRlYnVnLm51bWNhY2hlOiAyMDg4OTQNCmRlYnVnLm51bW5lZzog MTE2OTQNCmRlYnVnLm5jaGFzaDogMTA0ODU3NQ0KZGVidWcudm5scnVfbm93aGVyZTogMA0K ZGVidWcucnVzaF9yZXF1ZXN0czogMzcwMjgxDQpkZWJ1Zy5pZl90dW5fZGVidWc6IDANCmRl YnVnLm5sbV9kZWJ1ZzogMA0KZGVidWcuZnNja2NtZHM6IDANCmRlYnVnLmNvbGxlY3RzbmFw c3RhdHM6IDANCmRlYnVnLnNuYXBkZWJ1ZzogMA0KZGVidWcuZG9wZXJzaXN0ZW5jZTogMA0K ZGVidWcuc29mdGRlcC5jbGVhbnVwX2ZhaWx1cmVzOiAzNjk2MzQNCmRlYnVnLnNvZnRkZXAu Y2xlYW51cF9yZXRyaWVzOiA4MjYNCmRlYnVnLnNvZnRkZXAuY2xlYW51cF9oaWdoX2RlbGF5 OiAxNA0KZGVidWcuc29mdGRlcC5jbGVhbnVwX2lub3JlcXVlc3RzOiAwDQpkZWJ1Zy5zb2Z0 ZGVwLmNsZWFudXBfYmxrcmVxdWVzdHM6IDM2OTY5MA0KZGVidWcuc29mdGRlcC5qd2FpdF9u ZXdibGs6IDANCmRlYnVnLnNvZnRkZXAuandhaXRfaW5vZGU6IDANCmRlYnVnLnNvZnRkZXAu andhaXRfZnJlZWJsa3M6IDANCmRlYnVnLnNvZnRkZXAuandhaXRfZmlsZXBhZ2U6IDANCmRl YnVnLnNvZnRkZXAuam91cm5hbF93YWl0OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmpvdXJuYWxfbWlu OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmpvdXJuYWxfbG93OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmpuZXdi bGtfcm9sbGJhY2s6IDANCmRlYnVnLnNvZnRkZXAuamFkZHJlZl9yb2xsYmFjazogMA0KZGVi dWcuc29mdGRlcC5kaXJfZW50cnk6IDE5NTY2MA0KZGVidWcuc29mdGRlcC5kaXJlY3RfYmxr X3B0cnM6IDMzOTAyMw0KZGVidWcuc29mdGRlcC5pbm9kZV9iaXRtYXA6IDI1MDM3MzQNCmRl YnVnLnNvZnRkZXAuaW5kaXJfYmxrX3B0cnM6IDI2ODgxDQpkZWJ1Zy5zb2Z0ZGVwLnN5bmNf bGltaXRfaGl0OiA1OTENCmRlYnVnLnNvZnRkZXAuaW5vX2xpbWl0X2hpdDogMA0KZGVidWcu c29mdGRlcC5ibGtfbGltaXRfaGl0OiAzNjkyMjANCmRlYnVnLnNvZnRkZXAuaW5vX2xpbWl0 X3B1c2g6IDANCmRlYnVnLnNvZnRkZXAuYmxrX2xpbWl0X3B1c2g6IDM2OTY5MA0KZGVidWcu c29mdGRlcC53b3JrbGlzdF9wdXNoOiAyMTU2DQpkZWJ1Zy5zb2Z0ZGVwLm1heGluZGlyZGVw czogNTANCmRlYnVnLnNvZnRkZXAudGlja2RlbGF5OiAyDQpkZWJ1Zy5zb2Z0ZGVwLm1heF9z b2Z0ZGVwczogMjM1MjMwOA0KZGVidWcuc29mdGRlcC53cml0ZS5qZnN5bmM6IDANCmRlYnVn LnNvZnRkZXAud3JpdGUuanRydW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLnNiZGVwOiAw DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmpzZWdkZXA6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUu anNlZzogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qZnJlZWZyYWc6IDANCmRlYnVnLnNvZnRk ZXAud3JpdGUuamZyZWVibGs6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuam5ld2JsazogMA0K ZGVidWcuc29mdGRlcC53cml0ZS5qbXZyZWY6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuanJl bXJlZjogMA0KZGVidWcuc29mdGRlcC53cml0ZS5qYWRkcmVmOiAwDQpkZWJ1Zy5zb2Z0ZGVw LndyaXRlLmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZXdvcms6IDANCmRl YnVnLnNvZnRkZXAud3JpdGUubmV3ZGlyYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmRp cnJlbTogMA0KZGVidWcuc29mdGRlcC53cml0ZS5ta2RpcjogMA0KZGVidWcuc29mdGRlcC53 cml0ZS5kaXJhZGQ6IDANCmRlYnVnLnNvZnRkZXAud3JpdGUuZnJlZWZpbGU6IDANCmRlYnVn LnNvZnRkZXAud3JpdGUuZnJlZWJsa3M6IDY3MzEyNQ0KZGVidWcuc29mdGRlcC53cml0ZS5m cmVlZnJhZzogMA0KZGVidWcuc29mdGRlcC53cml0ZS5hbGxvY2luZGlyOiAyMjQ4MDE1NjIx DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLmluZGlyZGVwOiAxMTU0NDANCmRlYnVnLnNvZnRkZXAu d3JpdGUuYWxsb2NkaXJlY3Q6IDc0MjU0MTQ5DQpkZWJ1Zy5zb2Z0ZGVwLndyaXRlLm5ld2Js azogMA0KZGVidWcuc29mdGRlcC53cml0ZS5ibXNhZmVtYXA6IDIzOTQzNjgNCmRlYnVnLnNv ZnRkZXAud3JpdGUuaW5vZGVkZXA6IDY4MDUzMjANCmRlYnVnLnNvZnRkZXAud3JpdGUucGFn ZWRlcDogMzIwMzIyDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuamZzeW5jOiAwDQpkZWJ1Zy5z b2Z0ZGVwLmN1cnJlbnQuanRydW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuc2JkZXA6 IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qc2VnZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1 cnJlbnQuanNlZzogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmpmcmVlZnJhZzogMA0KZGVi dWcuc29mdGRlcC5jdXJyZW50LmpmcmVlYmxrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQu am5ld2JsazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmptdnJlZjogMA0KZGVidWcuc29m dGRlcC5jdXJyZW50LmpyZW1yZWY6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5qYWRkcmVm OiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZnJlZWRlcDogMA0KZGVidWcuc29mdGRlcC5j dXJyZW50LmZyZWV3b3JrOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQubmV3ZGlyYmxrOiAw DQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZGlycmVtOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJl bnQubWtkaXI6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5kaXJhZGQ6IDANCmRlYnVnLnNv ZnRkZXAuY3VycmVudC5mcmVlZmlsZTogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmZyZWVi bGtzOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuZnJlZWZyYWc6IDANCmRlYnVnLnNvZnRk ZXAuY3VycmVudC5hbGxvY2luZGlyOiAwDQpkZWJ1Zy5zb2Z0ZGVwLmN1cnJlbnQuaW5kaXJk ZXA6IDANCmRlYnVnLnNvZnRkZXAuY3VycmVudC5hbGxvY2RpcmVjdDogMA0KZGVidWcuc29m dGRlcC5jdXJyZW50Lm5ld2JsazogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50LmJtc2FmZW1h cDogMA0KZGVidWcuc29mdGRlcC5jdXJyZW50Lmlub2RlZGVwOiAwDQpkZWJ1Zy5zb2Z0ZGVw LmN1cnJlbnQucGFnZWRlcDogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qZnN5bmM6IDANCmRl YnVnLnNvZnRkZXAudG90YWwuanRydW5jOiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLnNiZGVw OiAwDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmpzZWdkZXA6IDANCmRlYnVnLnNvZnRkZXAudG90 YWwuanNlZzogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qZnJlZWZyYWc6IDANCmRlYnVnLnNv ZnRkZXAudG90YWwuamZyZWVibGs6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuam5ld2Jsazog MA0KZGVidWcuc29mdGRlcC50b3RhbC5qbXZyZWY6IDANCmRlYnVnLnNvZnRkZXAudG90YWwu anJlbXJlZjogMA0KZGVidWcuc29mdGRlcC50b3RhbC5qYWRkcmVmOiAwDQpkZWJ1Zy5zb2Z0 ZGVwLnRvdGFsLmZyZWVkZXA6IDANCmRlYnVnLnNvZnRkZXAudG90YWwuZnJlZXdvcms6IDgw NjAyOTAxDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLm5ld2RpcmJsazogMTgzMzcNCmRlYnVnLnNv ZnRkZXAudG90YWwuZGlycmVtOiAxMzA4MzAzNQ0KZGVidWcuc29mdGRlcC50b3RhbC5ta2Rp cjogMjk0MzYNCmRlYnVnLnNvZnRkZXAudG90YWwuZGlyYWRkOiAxMzA5MTI2Mw0KZGVidWcu c29mdGRlcC50b3RhbC5mcmVlZmlsZTogNjcxODEwOA0KZGVidWcuc29mdGRlcC50b3RhbC5m cmVlYmxrczogNjYxNTQ3MQ0KZGVidWcuc29mdGRlcC50b3RhbC5mcmVlZnJhZzogNDI3NTgy OTIyDQpkZWJ1Zy5zb2Z0ZGVwLnRvdGFsLmFsbG9jaW5kaXI6IDANCmRlYnVnLnNvZnRkZXAu dG90YWwuaW5kaXJkZXA6IDYyMjUwMzYNCmRlYnVnLnNvZnRkZXAudG90YWwuYWxsb2NkaXJl Y3Q6IDANCmRlYnVnLnNvZnRkZXAudG90YWwubmV3YmxrOiAyNzgxODY3Mjg4DQpkZWJ1Zy5z b2Z0ZGVwLnRvdGFsLmJtc2FmZW1hcDogODkzODgxNg0KZGVidWcuc29mdGRlcC50b3RhbC5p bm9kZWRlcDogNzg0MDQxNQ0KZGVidWcuc29mdGRlcC50b3RhbC5wYWdlZGVwOiAxMzkxMjUN CmRlYnVnLmRvYmtncmR3cml0ZTogMQ0KZGVidWcuYmlnY2dzOiAwDQpkZWJ1Zy5kaXJjaGVj azogMA0KZGVidWcucHNtLnBrdGVycnRocmVzaDogMg0KZGVidWcucHNtLnVzZWNzOiA1MDAw MDANCmRlYnVnLnBzbS5zZWNzOiAwDQpkZWJ1Zy5wc20uZXJydXNlY3M6IDANCmRlYnVnLnBz bS5lcnJzZWNzOiAyDQpkZWJ1Zy5wc20uaHo6IDIwDQpkZWJ1Zy5wc20ubG9nbGV2ZWw6IDAN CmRlYnVnLnZlc2Euc2hhZG93X3JvbTogMA0KZGVidWcuZmRjLnNldHRsZTogMA0KZGVidWcu ZmRjLnNwZWMyOiAxNg0KZGVidWcuZmRjLnNwZWMxOiAxNzUNCmRlYnVnLmZkYy5yZXRyaWVz OiAxMA0KZGVidWcuZmRjLmRlYnVnZmxhZ3M6IDANCmRlYnVnLmZkYy5maWZvOiA4DQpkZWJ1 Zy5lbGYzMl9sZWdhY3lfY29yZWR1bXA6IDANCmRlYnVnLng4NmJpb3MuaW50OiAwDQpkZWJ1 Zy54ODZiaW9zLmNhbGw6IDANCmRlYnVnLmh3cHN0YXRlX3ZlcmJvc2U6IDANCmRlYnVnLm1p bmlkdW1wOiAxDQorIGZzdGF0IC1mIC9wZ3NxbA0KVVNFUiAgICAgQ01EICAgICAgICAgIFBJ RCAgIEZEIE1PVU5UICAgICAgSU5VTSBNT0RFICAgICAgICAgU1p8RFYgUi9XDQpyb290ICAg ICBmc3RhdCAgICAgIDEyOTc0ICAgd2QgLyAgICAgICAgIDMyOTAyIGRyd3hyLXhyLXggICAg MTAyNCAgcg0Kcm9vdCAgICAgZnN0YXQgICAgICAxMjk3NCByb290IC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGZzdGF0ICAgICAgMTI5NzQgICAg MyAvICAgICAgICAgNDk3ODQgLXJ3LS0tLS0tLSAgIDQwOTYwICByDQpyb290ICAgICBzaCAg ICAgICAgIDEyOTY5IHRleHQgLyAgICAgICAgIDMyOTU2IC1yLXhyLXhyLXggIDE0Mjk4NCAg cg0Kcm9vdCAgICAgc2ggICAgICAgICAxMjk2OSAgIHdkIC8gICAgICAgICAzMjkwMiBkcnd4 ci14ci14ICAgIDEwMjQgIHINCnJvb3QgICAgIHNoICAgICAgICAgMTI5Njkgcm9vdCAvICAg ICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBzaCAgICAgICAg IDEyOTY5ICAgMTAgLyAgICAgICAgIDMyOTc4IC1yd3hyLXhyLXggICAgICA3NCAgcg0Kcm9v dCAgICAgc2ggICAgICAgICAxMjk2MSB0ZXh0IC8gICAgICAgICAzMjk1NiAtci14ci14ci14 ICAxNDI5ODQgIHINCnJvb3QgICAgIHNoICAgICAgICAgMTI5NjEgICB3ZCAvICAgICAgICAg MzI5MDIgZHJ3eHIteHIteCAgICAxMDI0ICByDQpyb290ICAgICBzaCAgICAgICAgIDEyOTYx IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAg c2NyaXB0ICAgICAxMjk2MCAgIHdkIC8gICAgICAgICAzMjkwMiBkcnd4ci14ci14ICAgIDEw MjQgIHINCnJvb3QgICAgIHNjcmlwdCAgICAgMTI5NjAgcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBzY3JpcHQgICAgIDEyOTYwICAgIDMg LSAgICAgICAgIDMyOTgyIC1ydy1yLS1yLS0gICAxNjgzMyAgdw0Kcm9vdCAgICAgc2ggICAg ICAgICAxMjk0MiB0ZXh0IC8gICAgICAgICAzMjk1NiAtci14ci14ci14ICAxNDI5ODQgIHIN CnJvb3QgICAgIHNoICAgICAgICAgMTI5NDIgICB3ZCAvICAgICAgICAgMzI5MDIgZHJ3eHIt eHIteCAgICAxMDI0ICByDQpyb290ICAgICBzaCAgICAgICAgIDEyOTQyIHJvb3QgLyAgICAg ICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgbG9naW4gICAgICAx Mjk0MSAgIHdkIC8gICAgICAgICAzMjkwMiBkcnd4ci14ci14ICAgIDEwMjQgIHINCnJvb3Qg ICAgIGxvZ2luICAgICAgMTI5NDEgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAgNTEyICByDQpuYWdpb3MgICBucnBlMiAgICAgICA4NDEwICAgd2QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0KbmFnaW9zICAgbnJwZTIgICAgICAgODQxMCBy b290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIG1v dXNlZCAgICAgNjg5NzQgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEy ICByDQpyb290ICAgICBtb3VzZWQgICAgIDY4OTc0IHJvb3QgLyAgICAgICAgICAgICAyIGRy d3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgZ2V0dHkgICAgICAgMTMyMCAgIHdkIC8g ICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGdldHR5ICAg ICAgIDEzMjAgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpy b290ICAgICBnZXR0eSAgICAgICAxMzE5ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhy LXggICAgIDUxMiAgcg0Kcm9vdCAgICAgZ2V0dHkgICAgICAgMTMxOSByb290IC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGdldHR5ICAgICAgIDEz MTggICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAg ICBnZXR0eSAgICAgICAxMzE4IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAg IDUxMiAgcg0Kcm9vdCAgICAgZ2V0dHkgICAgICAgMTMxNyAgIHdkIC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGdldHR5ICAgICAgIDEzMTcgcm9v dCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBnZXR0 eSAgICAgICAxMzE2ICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAg cg0Kcm9vdCAgICAgZ2V0dHkgICAgICAgMTMxNiByb290IC8gICAgICAgICAgICAgMiBkcnd4 ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGdldHR5ICAgICAgIDEzMTUgICB3ZCAvICAg ICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBnZXR0eSAgICAg ICAxMzE1IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9v dCAgICAgZ2V0dHkgICAgICAgMTMxNCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14 ICAgICA1MTIgIHINCnJvb3QgICAgIGdldHR5ICAgICAgIDEzMTQgcm9vdCAvICAgICAgICAg ICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBjcm9uICAgICAgICAxMjc1 IHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kc21tc3AgICAg c2VuZG1haWwgICAgMTI3MSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1 MTIgIHINCnJvb3QgICAgIHNlbmRtYWlsICAgIDEyNjggcm9vdCAvICAgICAgICAgICAgIDIg ZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBzc2hkICAgICAgICAxMjQ5ICAgd2Qg LyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgc3NoZCAg ICAgICAgMTI0OSByb290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHIN CnJvb3QgICAgIG50cGQgICAgICAgIDEyMTIgICB3ZCAvICAgICAgICAgICAgIDIgZHJ3eHIt eHIteCAgICAgNTEyICByDQpyb290ICAgICBudHBkICAgICAgICAxMjEyIHJvb3QgLyAgICAg ICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgc25tcGQgICAgICAg MTE4MCAgIHdkIC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3Qg ICAgIHNubXBkICAgICAgIDExODAgcm9vdCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAg ICAgNTEyICByDQpyb290ICAgICBzeXNsb2dkICAgICAxMTI2ICAgd2QgLyAgICAgICAgICAg ICAyIGRyd3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgc3lzbG9nZCAgICAgMTEyNiBy b290IC8gICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGRl dmQgICAgICAgIDEwMTIgdGV4dCAvICAgICAgICAgICAxMDUgLXIteHIteHIteCAgNDU0NTI4 ICByDQpyb290ICAgICBkZXZkICAgICAgICAxMDEyICAgd2QgLyAgICAgICAgICAgICAyIGRy d3hyLXhyLXggICAgIDUxMiAgcg0Kcm9vdCAgICAgZGV2ZCAgICAgICAgMTAxMiByb290IC8g ICAgICAgICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGFkamtlcm50 eiAgICAxMjIgdGV4dCAvICAgICAgICAgICAxMDAgLXIteHIteHIteCAgICA5MjY0ICByDQpy b290ICAgICBhZGprZXJudHogICAgMTIyICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhy LXggICAgIDUxMiAgcg0Kcm9vdCAgICAgYWRqa2VybnR6ICAgIDEyMiByb290IC8gICAgICAg ICAgICAgMiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGluaXQgICAgICAgICAg IDEgdGV4dCAvICAgICAgICAgICAxMTIgLXIteHIteHIteCAgNzkyMTI4ICByDQpyb290ICAg ICBpbml0ICAgICAgICAgICAxICAgd2QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAg IDUxMiAgcg0Kcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSByb290IC8gICAgICAgICAgICAg MiBkcnd4ci14ci14ICAgICA1MTIgIHINCnJvb3QgICAgIGtlcm5lbCAgICAgICAgIDAgICB3 ZCAvICAgICAgICAgICAgIDIgZHJ3eHIteHIteCAgICAgNTEyICByDQpyb290ICAgICBrZXJu ZWwgICAgICAgICAwIHJvb3QgLyAgICAgICAgICAgICAyIGRyd3hyLXhyLXggICAgIDUxMiAg cg0KIyBkZiAtaCAvcGdzcWwNCkZpbGVzeXN0ZW0gICAgIFNpemUgICAgVXNlZCAgIEF2YWls IENhcGFjaXR5ICBNb3VudGVkIG9uDQovZGV2L2RhMHMxYSAgICA0OTVNICAgIDM1NE0gICAg MTAxTSAgICA3OCUgICAgLw0KIyBtb3VudCAvcGdzcWwNCiMgbW91bnQgL3Bnc3FsG1sxMkRk ZiAtaBtbN0MNCkZpbGVzeXN0ZW0gICAgIFNpemUgICAgVXNlZCAgIEF2YWlsIENhcGFjaXR5 ICBNb3VudGVkIG9uDQovZGV2L2RhMnMxZCAgICAxMjhHICAgICA4MkcgICAgIDM2RyAgICA3 MCUgICAgL3Bnc3FsDQojIGR1IC1zaCAvcGdzcWwNCiA4MkcJL3Bnc3FsDQojIGV4aXQNCgpT Y3JpcHQgZG9uZSBvbiBXZWQgTWF5IDI5IDE5OjAwOjEyIDIwMTMK --------------010605080509040900010402-- From owner-freebsd-fs@FreeBSD.ORG Thu May 30 22:42:42 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EED4167A for ; Thu, 30 May 2013 22:42:42 +0000 (UTC) (envelope-from prvs=186297d80c=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7C330F94 for ; Thu, 30 May 2013 22:42:42 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004086366.msg for ; Thu, 30 May 2013 23:42:39 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 30 May 2013 23:42:39 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=186297d80c=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Message-ID: From: "Steven Hartland" To: "Ajit Jain" References: <9681E07546D348168052D4FC5365B4CD@multiplay.co.uk> <3E9CA9334E6F433A8F135ACD5C237340@multiplay.co.uk> <93D0677B373A452BAF58C8EA6823783D@multiplay.co.uk> <35ABA7AAEB7F4D86A1ED54C4C47FEB49@multiplay.co.uk> <2C2F5CAAE72B4658BFA09E4694A21375@multiplay.co.uk> <6E4EBFE196274519B847A47A062950EE@multiplay.co.uk> Subject: Re: seeing data corruption with zfs trim functionality Date: Thu, 30 May 2013 23:42:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 22:42:43 -0000 Tar archive of /usr/src and /usr/obj with built world and GENERIC kernel for ams64 can be found here:- http://blog.multiplay.co.uk/dropzone/freebsd/stable-9-r251096.tar.gz This is based off r251096 with current proposed MFC of CAM BIO_DELETE & ZFS TRIM. Regards Steve ----- Original Message ----- From: "Ajit Jain" > Hi Steven, > > That would be really great. I'll install build provided by you and can > quickly > update the result. I am kind of feeling that I am asking too much of fever > from you. > > thanks for the help and bearing me, > ajit > > > On Wed, May 29, 2013 at 6:39 PM, Steven Hartland wrote: > >> Unfortunately FS corruption is a serious matters so even though I'm 99.99% >> convinced there isn't a problem I'd still prefer to confirm this was indeed >> an issue with your code base and not an issue with the current code prior >> to MFC'ing. >> >> Would a pre-patched stable/9 source / build help. If so I can look at >> making >> that available for you. >> >> >> Regards >> Steve >> >> ----- Original Message ----- From: "Ajit Jain" >> >> >> Hi Steven, >>> >>> Sorry for the long delay, but might delay even further. >>> I think the reason for the corruption was, my code >>> was not updated specially cam directory. >>> >>> I request please do not stop just because of the issue I reported. >>> I'll update my src tree and rerun the experiments I was running >>> if I see some issue then probably we fix the bug rather then stopping >>> for MFC. >>> >>> thanks, >>> ajit >>> >>> >>> >>> On Wed, May 29, 2013 at 5:19 PM, Steven Hartland >> >**wrote: >>> >>> Sorry to pester, but any update on this Ajit? >>>> >>>> I ask as its currently blocking the MFC of TRIM to stable/8 & 9 and I've >>>> been >>>> unable to reproduce this issue even with your testing code on working FW >>>> versions. >>>> >>>> >>>> Regards >>>> Steve >>>> >>>> ----- Original Message ----- From: "Ajit Jain" >>>> >>>> >>>> Sure Steven, >>>> >>>>> I'll apply the patches and update ASAP. >>>>> >>>>> thanks >>>>> ajit >>>>> >>>>> >>>>> On Thu, May 23, 2013 at 3:03 PM, Steven Hartland < >>>>> killing@multiplay.co.uk >>>>> >**wrote: >>>>> >>>>> >>>>> I've attacked the two patch sets I'm looking to MFC to stable-9, one >>>>> >>>>>> adds BIO_DELETE CAM changes and the other is ZFS TRIM support. >>>>>> >>>>>> They should both apply cleanly to stable-9, if you could test with >>>>>> those on your machine and let me know. >>>>>> >>>>>> Regards >>>>>> Steve >>>>>> >>>>>> ----- Original Message ----- From: "Ajit Jain" < >>>>>> ajit.jain@cloudbyte.com> >>>>>> >>>>>> >>>>>> Hi Steven, >>>>>> >>>>>> >>>>>>> FW version on the setup is P15. >>>>>>> I will upgrade the FW to P16, but I think my >>>>>>> best bet will be to update code base to 9 stable as unlike you, >>>>>>> I was seeing corruption for all three delete methods. >>>>>>> >>>>>>> thanks >>>>>>> ajit >>>>>>> >>>>>>> On Sat, May 18, 2013 at 4:15 AM, Steven Hartland < >>>>>>> killing@multiplay.co.uk >>>>>>> >**wrote: >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- From: "Steven Hartland" < >>>>>>> >>>>>>> killing@multiplay.co.uk> >>>>>>>> >>>>>>>> >>>>>>>> After initially seeing not issues, our overnight monitoring started >>>>>>>> >>>>>>>> moaning >>>>>>>>> big time on the test box. So we checked and there was zpool >>>>>>>>> corruption >>>>>>>>> as >>>>>>>>> well >>>>>>>>> as a missing boot loader and a corrupt GPT, so I believe we have >>>>>>>>> reproduced >>>>>>>>> your issue. >>>>>>>>> >>>>>>>>> After recovering the machine I created 3 pools on 3 different disks >>>>>>>>> each >>>>>>>>> running a different delete_method. >>>>>>>>> >>>>>>>>> We then re-ran the tests which resulted in the pool running with >>>>>>>>> delete_method >>>>>>>>> WS16 being so broken it had suspended IO. A reboot resulted in it >>>>>>>>> once >>>>>>>>> again >>>>>>>>> reporting no partition table via gpart. >>>>>>>>> >>>>>>>>> A third test run again produced a corrupt pool for WS16. >>>>>>>>> >>>>>>>>> I've conducted a preliminary review of the CAM WS16 code path along >>>>>>>>> with >>>>>>>>> SBC-3 >>>>>>>>> spec which didn't identify any obvious issues. >>>>>>>>> >>>>>>>>> Given we're both using LSI 2008 based controllers it could be FW >>>>>>>>> issue >>>>>>>>> specific >>>>>>>>> to WS16 but that's just speculation atm, so I'll continue to >>>>>>>>> investigate. >>>>>>>>> >>>>>>>>> If you could re-test you end without using WS16 to see if you can >>>>>>>>> reproduce the >>>>>>>>> problem with either UNMAP or ATA_TRIM that would be a very useful >>>>>>>>> data >>>>>>>>> point. >>>>>>>>> >>>>>>>>> >>>>>>>>> After much playing I narrow down a test case of one delete which >>>>>>>>> was >>>>>>>>> >>>>>>>> causing >>>>>>>> disc corruption for us (deleted the partition table instead of data >>>>>>>> in >>>>>>>> the middle of the disk). >>>>>>>> >>>>>>>> The conclusion is LSI 2008 HBA with FW below P13 will eat the data on >>>>>>>> your >>>>>>>> SATA >>>>>>>> disks if you use WS16 due to the following bug:- >>>>>>>> SCGCQ00230159 (DFCT) - Write same command to a SATA drive that >>>>>>>> doesn't >>>>>>>> support >>>>>>>> SCT write same may write wrong region. >>>>>>>> >>>>>>>> After updating here to P16, which we would generally be running, but >>>>>>>> test >>>>>>>> box >>>>>>>> was new and hadnt updated yet the corruption issue is no longer >>>>>>>> reproducable. >>>>>>>> >>>>>>>> So Ajit please check your FW version, I'm hoping to here your on >>>>>>>> something >>>>>>>> below P13, P12 possibly? >>>>>>>> >>>>>>>> If so then this is your issue, to fix simply update to P16 and the >>>>>>>> problem >>>>>>>> should be gone. >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> ==============================********================== >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. >>>>>>>> and >>>>>>>> the person or entity to whom it is addressed. In the event of >>>>>>>> misdirection, >>>>>>>> the recipient is prohibited from using, copying, printing or >>>>>>>> otherwise >>>>>>>> disseminating it or any information contained in it. >>>>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>>>> please >>>>>>>> telephone +44 845 868 1337 >>>>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ==============================******================== >>>>>>> >>>>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>>>> the person or entity to whom it is addressed. In the event of >>>>>> misdirection, >>>>>> the recipient is prohibited from using, copying, printing or otherwise >>>>>> disseminating it or any information contained in it. >>>>>> In the event of misdirection, illegible or incomplete transmission >>>>>> please >>>>>> telephone +44 845 868 1337 >>>>>> or return the E.mail to postmaster@multiplay.co.uk. >>>>>> >>>>>> >>>>>> >>>>> ==============================****================== >>>> This e.mail is private and confidential between Multiplay (UK) Ltd. and >>>> the person or entity to whom it is addressed. In the event of >>>> misdirection, >>>> the recipient is prohibited from using, copying, printing or otherwise >>>> disseminating it or any information contained in it. >>>> In the event of misdirection, illegible or incomplete transmission please >>>> telephone +44 845 868 1337 >>>> or return the E.mail to postmaster@multiplay.co.uk. >>>> >>>> >>>> >>> >> ==============================**================== >> This e.mail is private and confidential between Multiplay (UK) Ltd. and >> the person or entity to whom it is addressed. In the event of misdirection, >> the recipient is prohibited from using, copying, printing or otherwise >> disseminating it or any information contained in it. >> In the event of misdirection, illegible or incomplete transmission please >> telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >> >> > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Fri May 31 14:53:29 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4C2EE1F9; Fri, 31 May 2013 14:53:29 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 1348D8DA; Fri, 31 May 2013 14:53:29 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id k13so4265431iea.4 for ; Fri, 31 May 2013 07:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=xiF5QfWPGKpMM/0inKPAXCRx7bTYXq1vDdxZgKl7n9E=; b=otfa+nOtYQet6FvMrcwnOHt16L+VUzDeL5fwFof3kKymM8naS93H72tEXtRg1U4zU3 HHh2LGQAzDiaUjeZ/GPviqmly+UjYDMxoef5ihb2ik8asqdkuDEiTb+/HnxjhxCYnITo 0nHugV7I1uCPYMsG6yE5TctKnamSFBAvHpIlTpFIG9VwLgV/pp/1VWEQBqrMJxfcQJFA NYYu1BYuSH+816zcdmJp1pYM4e+IZRtq/3XKPynxkk/dsqaHvv+KS0aut3HUUA0uuiUT hpgZ2G1rJ2svEQhshxOFfiTDZFcoKzU8sEniehFgWCV8+Av9SQ8QybMsti3TQzB/nX3m bWpQ== X-Received: by 10.50.178.198 with SMTP id da6mr1917044igc.49.1370012008776; Fri, 31 May 2013 07:53:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.71.101 with HTTP; Fri, 31 May 2013 07:52:58 -0700 (PDT) From: Chris Rees Date: Fri, 31 May 2013 15:52:58 +0100 Message-ID: Subject: Re: docs/178818: gmirror(8) says to use rc.early which is no longer available To: "bug-followup@freebsd.org" , "freebsd-fs@freebsd.org" , Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 14:53:29 -0000 I think this shouldn't be too hard to automate in the dumpon script, to be honest. Please can you try the patch at [1], and set dumpdev=/dev/mirror/*your_target_mirror* in /etc/rc.conf, and let me know if it works OK? Pawel, does this look sane? Chris [1] http://www.bayofrum.net/~crees/patches/gmirror-dumps.diff From owner-freebsd-fs@FreeBSD.ORG Fri May 31 18:25:45 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 99CA3ED9; Fri, 31 May 2013 18:25:45 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA3963F; Fri, 31 May 2013 18:25:45 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r4VIPeFV077457; Fri, 31 May 2013 11:25:41 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201305311825.r4VIPeFV077457@chez.mckusick.com> To: Palle Girgensohn Subject: Re: leaking lots of unreferenced inodes (pg_xlog files?) In-reply-to: <51A73076.8020609@FreeBSD.org> Date: Fri, 31 May 2013 11:25:40 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@FreeBSD.org, Dan Thomas , Jeff Roberson , Julian Akehurst X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 18:25:45 -0000 > Date: Thu, 30 May 2013 12:56:54 +0200 > From: Palle Girgensohn > To: Kirk McKusick > CC: freebsd-fs@FreeBSD.org, Jeff Roberson , > Dan Thomas , Julian Akehurst > Subject: Re: leaking lots of unreferenced inodes (pg_xlog files?) > > Hello again! > > I have now remounted the postgresql filesystem on a test server that > experiences the same problem. The production server is not remounted > yet, we're planning that in a weeks time approximately, but I though I > could gain som time by running the suggested procedure on the test box. > > The base problem was this: > > # df -h /pgsql ; du -hxs /pgsql > Filesystem Size Used Avail Capacity Mounted on > /dev/da2s1d 128G 101G 17G 86% /pgsql > 82G /pgsql > > df says 101 GB used, but du only finds 82 GB, and fstat cannot find any > open files that are unreferenced in the file system. Stopping postgresql > does not help. It seems the OS is leaking inode references. > > FreeBSD 9.1, postgresql 9.2.3 from port. > > I ran the suggested commans (in attached diskspacecheck) before stopping > postgresql (before.log), after stopping postgresql but before unmount > /pgsql (before2.log), and then i unmounted /pgsql (had to run umount -f > /pgsql, and it took about 20 seconds). I did not enter single-user mode, > since I really did not have to this time (On the production server, the > disk is /usr, so that will require more shutting down...) > > I've attach the logs here. Hope it helps! > > The commands run in diskspaccheck are > #! /bin/sh > df -ih /pgsql > vmstat -z > vmstat -m > sysctl debug > fstat -f /pgsql > > as suggested by Kirk. Your results are very enlightening. Especially the fact that you have to do a forcible unmount of the filesystem. What that tells me is that somehow we are getting vnodes that have phantom references. That is there is some system call where we get a reference on a vnode (vref, vget, or similar) that does not ultimately have a corresponding drop of the reference (vrele, vput, or similar). The net effect is that the file is held open despite the fact that there are no longer any connections to it. When you do the forcible unmount, the kernel walks the list of vnodes associated with the filesystem and does a vgone on each of them. That causes each to be inactivated which then triggers the release of their associated disk space. The reason that the unmount takes 20 seconds is to process all the releasing of the space. My guess is that there is an error path in some system call that is missing the vrele or vput. Assuming that you are able to run some more tests on your test machine, the next step in narrowing down the set of code to look at is to try running your system with soft updates disabled. The idea is to find out whether the miss-matched references are in the soft updates code or are in one of the filesystem system calls themselves. To disable soft updates run the command `tunefs -n disable /pgsql' on the unmounted /pgsql filesystem. If the system then runs without the problem, I will know to search the soft updates code. If the problem persists, then I'll know to look in the system calls themselves. You may want to do some preliminary tests to see how quickly the problem manifests itself. You can do this by running it for a short time (10 minutes say) and then checking to see if you need to do a forcible unmount of the filesystem. Once you establish how long you have to run before you reliably have to do a forcible unmount, you will know how long to run the test with soft updates turned off. If you find that running with soft updates turned off makes your application run too slowly you can mount your filesystem asynchronously. Note however, that you should not run asynchronously if the data on the filesystem is critical as you may end up with an unrecoverable filesystem after a power failure or system crash. So only run asynchronously if you can afford to lose your filesystem. Finally, it would be helpful if you could add two more commands to your diskspacecheck.sh script: sysctl -a | egrep vnode mount -v The first shows the vnode usage and the second shows the operational state of your filesystems. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Fri May 31 20:23:33 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BFB6B1C; Fri, 31 May 2013 20:23:33 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 700A4AB3; Fri, 31 May 2013 20:23:31 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id EDC9510B8149; Fri, 31 May 2013 22:15:10 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 24.8224] X-CRM114-CacheID: sfid-20130531_22151_6C749A0E X-CRM114-Status: Good ( pR: 24.8224 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri May 31 22:15:10 2013 X-DSPAM-Confidence: 0.9955 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 51a904ce773232005934266 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, >+On, 0.00060, wrote+>>, 0.00147, wrote+>, 0.00223, >>+>, 0.00338, References*fsn.hu>, 0.00372, References*fsn.hu>, 0.00372, the+code, 0.00399, In-Reply-To*fsn.hu>, 0.00399, >>>+>>>, 0.00399, >>>+>>>, 0.00399, can+I, 0.00429, dump, 0.00429, revision, 0.00507, (), 0.00507, (), 0.00507, wrote, 0.00546, wrote, 0.00546, To*FreeBSD.org>, 0.00557, References*FreeBSD.org>, 0.00557, svn, 0.00597, stack, 0.00619, stack, 0.00619, #0, 0.00619, From*Attila, 0.00619, I+get, 0.00655, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id BC54210B813C; Fri, 31 May 2013 22:15:09 +0200 (CEST) Message-ID: <51A904CB.3080203@fsn.hu> Date: Fri, 31 May 2013 22:15:07 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: zfs panic, solaris_assert References: <50CC86D4.2070502@fsn.hu> <50CDBCD0.5070305@FreeBSD.org> <50CDBD2A.2010504@fsn.hu> In-Reply-To: <50CDBD2A.2010504@fsn.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 20:23:33 -0000 Hi, On 12/16/2012 01:23 PM, Attila Nagy wrote: > On 12/16/2012 01:21 PM, Andriy Gapon wrote: >> on 15/12/2012 16:19 Attila Nagy said the following: >>> Hi, >>> >>> Since running svn revision r243704 I get frequent panics: >>> panic: solaris assert: sa.sa_magic == 0x2F505A (0x4f22a8ed == 0x2f505a), >>> file: >>> /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, >>> line: 597 >>> cpuid = 0 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >>> kdb_backtrace() at kdb_backtrace+0x37 >>> panic() at panic+0x1ce >>> assfail3() at assfail3+0x29 >>> zfs_space_delta_cb() at zfs_space_delta_cb+0xbe >>> dmu_objset_userquota_get_ids() at dmu_objset_userquota_get_ids+0x142 >>> dnode_sync() at dnode_sync+0xc5 >>> dmu_objset_sync_dnodes() at dmu_objset_sync_dnodes+0x5d >>> dmu_objset_sync() at dmu_objset_sync+0x17f >>> dsl_pool_sync() at dsl_pool_sync+0xca >>> spa_sync() at spa_sync+0x34a >>> txg_sync_thread() at txg_sync_thread+0x139 >>> fork_exit() at fork_exit+0x11f >>> fork_trampoline() at fork_trampoline+0xe >>> --- trap 0, rip = 0, rsp = 0xffffff90231accf0, rbp = 0 --- >>> >>> I can't tell whether it's the data or the code. If the latter, is this fixed in >>> later revisions? >>> If it's the file system, what can I do with this? >> Nobody's sure. >> Do you have a crash dump? >> > Not yet. Sorry, I've had better things to work on, but after a half year I can clearly say that something with that mega commit (maybe the v28 stuff, I can't really remember) broke this machine. Since last December I was running r237433 (fallback, it had to work) without any problems. Then last week I did an upgrade to r250452. After that, I've had some 5 or 6 crashes, two in a row today. So now I have a more recent OS (reverted to r237433 again, but can easily switch versions) and a crash dump too. The current panic message: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4e814a76 == 0x2f505a), file: /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffffa68ce6b4d0 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffffa68ce6b590 panic() at panic+0x1ce/frame 0xffffffa68ce6b690 assfail3() at assfail3+0x29/frame 0xffffffa68ce6b6b0 zfs_space_delta_cb() at zfs_space_delta_cb+0xbe/frame 0xffffffa68ce6b700 dmu_objset_userquota_get_ids() at dmu_objset_userquota_get_ids+0x142/frame 0xffffffa68ce6b750 dnode_sync() at dnode_sync+0xc5/frame 0xffffffa68ce6b820 dmu_objset_sync_dnodes() at dmu_objset_sync_dnodes+0x5d/frame 0xffffffa68ce6b850 dmu_objset_sync() at dmu_objset_sync+0x169/frame 0xffffffa68ce6b920 dsl_pool_sync() at dsl_pool_sync+0xca/frame 0xffffffa68ce6ba00 spa_sync() at spa_sync+0x3ba/frame 0xffffffa68ce6bad0 txg_sync_thread() at txg_sync_thread+0x139/frame 0xffffffa68ce6bbe0 fork_exit() at fork_exit+0x11f/frame 0xffffffa68ce6bc30 fork_trampoline() at fork_trampoline+0xe/frame 0xffffffa68ce6bc30 --- trap 0, rip = 0, rsp = 0xffffffa68ce6bcf0, rbp = 0 --- Uptime: 10m6s 10 minutes of uptime. :-O (kgdb) bt #0 doadump (textdump=1) at /data/usr/src/sys/kern/kern_shutdown.c:266 #1 0xffffffff8092c754 in kern_reboot (howto=260) at /data/usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff8092cc57 in panic (fmt=0x1
) at /data/usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff81b64109 in vcmn_err (ce=0, fmt=0x0, adx=0x0) at /data/usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:29 #4 0xffffffff81abdc1e in zfs_freebsd_getattr (ap=) at /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2826 #5 0xffffffff81a44cd2 in dmu_tx_hold_object_impl (tx=0xfffffe080e38c6b0, os=, object=, type=, arg1=, arg2=) at /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c:124 #6 0xffffffff81a4bd55 in dsl_dir_willuse_space_impl (dd=0xfffffe07d7100a00, space=-2164424915280, tx=0x5) at /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:919 #7 0xffffffff81a4305d in dmu_objset_snapshot (fsname=0x0, snapname=0x1
, tag=0xffffffff8141dc40 "", props=0xfffffe0049be1de0, recursive=1237196368, temporary=1237196256, cleanup_fd=-1931036464) at /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1018 #8 0xffffffff81a431e9 in dmu_objset_byteswap (buf=0x0, size=18446744071589605469) at /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:250 #9 0xffffffff81a5930a in dmu_zfetch_dofetch (zf=0x0, zs=0x0) at /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c:200 #10 0xffffffff81a6b02a in spa_load (spa=0x0, state=10031132, type=3608152576, mosconfig=1237195776) at /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:2077 #11 0xffffffff81a7d109 in vdev_free (vd=0xfffffe006f580800) at /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:601 #12 0xffffffff808f971f in fork_exit (callout=0xffffffff81a7cfd0 , arg=0xfffffe006f580800, frame=0xffffffa68ce6bc40) at /data/usr/src/sys/kern/kern_fork.c:988 #13 0xffffffff80c8ad1e in fork_trampoline () at /data/usr/src/sys/amd64/amd64/exception.S:602 #14 0x0000000000000000 in ?? () I can do any non-destructive (for the data and the operation of the machine) stuff, if needed. Thanks,