From owner-freebsd-fs@FreeBSD.ORG Sun Nov 28 09:22:35 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EE531065672; Sun, 28 Nov 2010 09:22:35 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 043C58FC0A; Sun, 28 Nov 2010 09:22:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAS9MYDM077869; Sun, 28 Nov 2010 09:22:34 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAS9MXoI077865; Sun, 28 Nov 2010 09:22:33 GMT (envelope-from jh) Date: Sun, 28 Nov 2010 09:22:33 GMT Message-Id: <201011280922.oAS9MXoI077865@freefall.freebsd.org> To: daniel@zhelev.biz, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/149495: [zfs] chflags sappend on zfs not working right X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 09:22:35 -0000 Synopsis: [zfs] chflags sappend on zfs not working right State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Sun Nov 28 09:22:33 UTC 2010 State-Changed-Why: Duplicate of kern/151082. Patched in head (r213634). http://www.freebsd.org/cgi/query-pr.cgi?pr=149495 From owner-freebsd-fs@FreeBSD.ORG Sun Nov 28 09:24:08 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 192621065694; Sun, 28 Nov 2010 09:24:08 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E285E8FC17; Sun, 28 Nov 2010 09:24:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAS9O7As077935; Sun, 28 Nov 2010 09:24:07 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAS9O7rn077931; Sun, 28 Nov 2010 09:24:07 GMT (envelope-from jh) Date: Sun, 28 Nov 2010 09:24:07 GMT Message-Id: <201011280924.oAS9O7rn077931@freefall.freebsd.org> To: cal@linu.gs, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/151082: [zfs] [patch] sappend-flaged files on ZFS not working correctly X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 09:24:08 -0000 Synopsis: [zfs] [patch] sappend-flaged files on ZFS not working correctly State-Changed-From-To: open->patched State-Changed-By: jh State-Changed-When: Sun Nov 28 09:22:58 UTC 2010 State-Changed-Why: Patched in head (r213634). http://www.freebsd.org/cgi/query-pr.cgi?pr=151082 From owner-freebsd-fs@FreeBSD.ORG Sun Nov 28 10:00:24 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7E7B1065670 for ; Sun, 28 Nov 2010 10:00:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CCD028FC0C for ; Sun, 28 Nov 2010 10:00:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oASA0Ndr007886 for ; Sun, 28 Nov 2010 10:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oASA0Nc4007875; Sun, 28 Nov 2010 10:00:23 GMT (envelope-from gnats) Date: Sun, 28 Nov 2010 10:00:23 GMT Message-Id: <201011281000.oASA0Nc4007875@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/149495: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 10:00:24 -0000 The following reply was made to PR kern/149495; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/149495: commit references a PR Date: Sun, 28 Nov 2010 09:52:14 +0000 (UTC) Author: mm Date: Sun Nov 28 09:52:06 2010 New Revision: 215992 URL: http://svn.freebsd.org/changeset/base/215992 Log: MFC r213634, r213673: MFC r213634: Change FAPPEND to IO_APPEND as this is a ioflag and not a fflag. This corrects writing to append-only files on ZFS. MFC r213673 (pjd): Provide internal ioflags() function that converts ioflag provided by FreeBSD's VFS to OpenSolaris-specific ioflag expected by ZFS. Use it for read and write operations. PR: kern/149495 [1], kern/151082 [2] Submitted by: Daniel Zhelev [1], Michael Naef [2] Reviewed by: mm (r213673) Approved by: delphij (mentor) Modified: stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c ============================================================================== --- stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Sun Nov 28 09:35:56 2010 (r215991) +++ stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Sun Nov 28 09:52:06 2010 (r215992) @@ -682,7 +682,7 @@ zfs_prefault_write(ssize_t n, struct uio * IN: vp - vnode of file to be written to. * uio - structure supplying write location, range info, * and data buffer. - * ioflag - IO_APPEND flag set if in append mode. + * ioflag - FAPPEND flag set if in append mode. * cr - credentials of caller. * ct - caller context (NFS/CIFS fem monitor only) * @@ -749,7 +749,7 @@ zfs_write(vnode_t *vp, uio_t *uio, int i /* * If in append mode, set the io offset pointer to eof. */ - if (ioflag & IO_APPEND) { + if (ioflag & FAPPEND) { /* * Range lock for a file append: * The value for the start of range will be determined by @@ -4176,6 +4176,21 @@ zfs_setsecattr(vnode_t *vp, vsecattr_t * } static int +ioflags(int ioflags) +{ + int flags = 0; + + if (ioflags & IO_APPEND) + flags |= FAPPEND; + if (ioflags & IO_NDELAY) + flags |= FNONBLOCK; + if (ioflags & IO_SYNC) + flags |= (FSYNC | FDSYNC | FRSYNC); + + return (flags); +} + +static int zfs_getpages(struct vnode *vp, vm_page_t *m, int count, int reqpage) { znode_t *zp = VTOZ(vp); @@ -4322,7 +4337,8 @@ zfs_freebsd_read(ap) } */ *ap; { - return (zfs_read(ap->a_vp, ap->a_uio, ap->a_ioflag, ap->a_cred, NULL)); + return (zfs_read(ap->a_vp, ap->a_uio, ioflags(ap->a_ioflag), + ap->a_cred, NULL)); } static int @@ -4335,7 +4351,8 @@ zfs_freebsd_write(ap) } */ *ap; { - return (zfs_write(ap->a_vp, ap->a_uio, ap->a_ioflag, ap->a_cred, NULL)); + return (zfs_write(ap->a_vp, ap->a_uio, ioflags(ap->a_ioflag), + ap->a_cred, NULL)); } static int _______________________________________________ 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 Sun Nov 28 10:00:29 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0361E10656ED for ; Sun, 28 Nov 2010 10:00:29 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E4DE18FC17 for ; Sun, 28 Nov 2010 10:00:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oASA0SI1008920 for ; Sun, 28 Nov 2010 10:00:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oASA0SEc008902; Sun, 28 Nov 2010 10:00:28 GMT (envelope-from gnats) Date: Sun, 28 Nov 2010 10:00:28 GMT Message-Id: <201011281000.oASA0SEc008902@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/151082: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 10:00:29 -0000 The following reply was made to PR kern/151082; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/151082: commit references a PR Date: Sun, 28 Nov 2010 09:52:15 +0000 (UTC) Author: mm Date: Sun Nov 28 09:52:06 2010 New Revision: 215992 URL: http://svn.freebsd.org/changeset/base/215992 Log: MFC r213634, r213673: MFC r213634: Change FAPPEND to IO_APPEND as this is a ioflag and not a fflag. This corrects writing to append-only files on ZFS. MFC r213673 (pjd): Provide internal ioflags() function that converts ioflag provided by FreeBSD's VFS to OpenSolaris-specific ioflag expected by ZFS. Use it for read and write operations. PR: kern/149495 [1], kern/151082 [2] Submitted by: Daniel Zhelev [1], Michael Naef [2] Reviewed by: mm (r213673) Approved by: delphij (mentor) Modified: stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c ============================================================================== --- stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Sun Nov 28 09:35:56 2010 (r215991) +++ stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Sun Nov 28 09:52:06 2010 (r215992) @@ -682,7 +682,7 @@ zfs_prefault_write(ssize_t n, struct uio * IN: vp - vnode of file to be written to. * uio - structure supplying write location, range info, * and data buffer. - * ioflag - IO_APPEND flag set if in append mode. + * ioflag - FAPPEND flag set if in append mode. * cr - credentials of caller. * ct - caller context (NFS/CIFS fem monitor only) * @@ -749,7 +749,7 @@ zfs_write(vnode_t *vp, uio_t *uio, int i /* * If in append mode, set the io offset pointer to eof. */ - if (ioflag & IO_APPEND) { + if (ioflag & FAPPEND) { /* * Range lock for a file append: * The value for the start of range will be determined by @@ -4176,6 +4176,21 @@ zfs_setsecattr(vnode_t *vp, vsecattr_t * } static int +ioflags(int ioflags) +{ + int flags = 0; + + if (ioflags & IO_APPEND) + flags |= FAPPEND; + if (ioflags & IO_NDELAY) + flags |= FNONBLOCK; + if (ioflags & IO_SYNC) + flags |= (FSYNC | FDSYNC | FRSYNC); + + return (flags); +} + +static int zfs_getpages(struct vnode *vp, vm_page_t *m, int count, int reqpage) { znode_t *zp = VTOZ(vp); @@ -4322,7 +4337,8 @@ zfs_freebsd_read(ap) } */ *ap; { - return (zfs_read(ap->a_vp, ap->a_uio, ap->a_ioflag, ap->a_cred, NULL)); + return (zfs_read(ap->a_vp, ap->a_uio, ioflags(ap->a_ioflag), + ap->a_cred, NULL)); } static int @@ -4335,7 +4351,8 @@ zfs_freebsd_write(ap) } */ *ap; { - return (zfs_write(ap->a_vp, ap->a_uio, ap->a_ioflag, ap->a_cred, NULL)); + return (zfs_write(ap->a_vp, ap->a_uio, ioflags(ap->a_ioflag), + ap->a_cred, NULL)); } static int _______________________________________________ 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 Sun Nov 28 10:10:12 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C45B31065670 for ; Sun, 28 Nov 2010 10:10:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9810B8FC19 for ; Sun, 28 Nov 2010 10:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oASAAC8l020284 for ; Sun, 28 Nov 2010 10:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oASAACtu020281; Sun, 28 Nov 2010 10:10:12 GMT (envelope-from gnats) Date: Sun, 28 Nov 2010 10:10:12 GMT Message-Id: <201011281010.oASAACtu020281@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/149495: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 10:10:12 -0000 The following reply was made to PR kern/149495; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/149495: commit references a PR Date: Sun, 28 Nov 2010 10:05:33 +0000 (UTC) Author: mm Date: Sun Nov 28 10:05:26 2010 New Revision: 215993 URL: http://svn.freebsd.org/changeset/base/215993 Log: MFC r213634, r213673: MFC r213634: Change FAPPEND to IO_APPEND as this is a ioflag and not a fflag. This corrects writing to append-only files on ZFS. MFC r213673 (pjd): Provide internal ioflags() function that converts ioflag provided by FreeBSD's VFS to OpenSolaris-specific ioflag expected by ZFS. Use it for read and write operations. PR: kern/149495 [1], kern/151082 [2] Submitted by: Daniel Zhelev [1], Michael Naef [2] Reviewed by: mm (r213673) Approved by: delphij (mentor) Modified: stable/7/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Directory Properties: stable/7/sys/ (props changed) stable/7/sys/cddl/contrib/opensolaris/ (props changed) stable/7/sys/contrib/dev/acpica/ (props changed) stable/7/sys/contrib/pf/ (props changed) Modified: stable/7/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c ============================================================================== --- stable/7/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Sun Nov 28 09:52:06 2010 (r215992) +++ stable/7/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Sun Nov 28 10:05:26 2010 (r215993) @@ -660,7 +660,7 @@ zfs_prefault_write(ssize_t n, struct uio * IN: vp - vnode of file to be written to. * uio - structure supplying write location, range info, * and data buffer. - * ioflag - IO_APPEND flag set if in append mode. + * ioflag - FAPPEND flag set if in append mode. * cr - credentials of caller. * ct - caller context (NFS/CIFS fem monitor only) * @@ -726,7 +726,7 @@ zfs_write(vnode_t *vp, uio_t *uio, int i /* * If in append mode, set the io offset pointer to eof. */ - if (ioflag & IO_APPEND) { + if (ioflag & FAPPEND) { /* * Range lock for a file append: * The value for the start of range will be determined by @@ -3887,6 +3887,21 @@ zfs_setsecattr(vnode_t *vp, vsecattr_t * #endif /* TODO */ static int +ioflags(int ioflags) +{ + int flags = 0; + + if (ioflags & IO_APPEND) + flags |= FAPPEND; + if (ioflags & IO_NDELAY) + flags |= FNONBLOCK; + if (ioflags & IO_SYNC) + flags |= (FSYNC | FDSYNC | FRSYNC); + + return (flags); +} + +static int zfs_freebsd_open(ap) struct vop_open_args /* { struct vnode *a_vp; @@ -3944,7 +3959,8 @@ zfs_freebsd_read(ap) } */ *ap; { - return (zfs_read(ap->a_vp, ap->a_uio, ap->a_ioflag, ap->a_cred, NULL)); + return (zfs_read(ap->a_vp, ap->a_uio, ioflags(ap->a_ioflag), + ap->a_cred, NULL)); } static int @@ -3957,7 +3973,8 @@ zfs_freebsd_write(ap) } */ *ap; { - return (zfs_write(ap->a_vp, ap->a_uio, ap->a_ioflag, ap->a_cred, NULL)); + return (zfs_write(ap->a_vp, ap->a_uio, ioflags(ap->a_ioflag), + ap->a_cred, NULL)); } static int _______________________________________________ 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 Sun Nov 28 10:10:14 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B94C106564A for ; Sun, 28 Nov 2010 10:10:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 59A8E8FC0A for ; Sun, 28 Nov 2010 10:10:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oASAAEhb020292 for ; Sun, 28 Nov 2010 10:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oASAAE8F020291; Sun, 28 Nov 2010 10:10:14 GMT (envelope-from gnats) Date: Sun, 28 Nov 2010 10:10:14 GMT Message-Id: <201011281010.oASAAE8F020291@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/151082: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 10:10:14 -0000 The following reply was made to PR kern/151082; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/151082: commit references a PR Date: Sun, 28 Nov 2010 10:05:34 +0000 (UTC) Author: mm Date: Sun Nov 28 10:05:26 2010 New Revision: 215993 URL: http://svn.freebsd.org/changeset/base/215993 Log: MFC r213634, r213673: MFC r213634: Change FAPPEND to IO_APPEND as this is a ioflag and not a fflag. This corrects writing to append-only files on ZFS. MFC r213673 (pjd): Provide internal ioflags() function that converts ioflag provided by FreeBSD's VFS to OpenSolaris-specific ioflag expected by ZFS. Use it for read and write operations. PR: kern/149495 [1], kern/151082 [2] Submitted by: Daniel Zhelev [1], Michael Naef [2] Reviewed by: mm (r213673) Approved by: delphij (mentor) Modified: stable/7/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Directory Properties: stable/7/sys/ (props changed) stable/7/sys/cddl/contrib/opensolaris/ (props changed) stable/7/sys/contrib/dev/acpica/ (props changed) stable/7/sys/contrib/pf/ (props changed) Modified: stable/7/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c ============================================================================== --- stable/7/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Sun Nov 28 09:52:06 2010 (r215992) +++ stable/7/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Sun Nov 28 10:05:26 2010 (r215993) @@ -660,7 +660,7 @@ zfs_prefault_write(ssize_t n, struct uio * IN: vp - vnode of file to be written to. * uio - structure supplying write location, range info, * and data buffer. - * ioflag - IO_APPEND flag set if in append mode. + * ioflag - FAPPEND flag set if in append mode. * cr - credentials of caller. * ct - caller context (NFS/CIFS fem monitor only) * @@ -726,7 +726,7 @@ zfs_write(vnode_t *vp, uio_t *uio, int i /* * If in append mode, set the io offset pointer to eof. */ - if (ioflag & IO_APPEND) { + if (ioflag & FAPPEND) { /* * Range lock for a file append: * The value for the start of range will be determined by @@ -3887,6 +3887,21 @@ zfs_setsecattr(vnode_t *vp, vsecattr_t * #endif /* TODO */ static int +ioflags(int ioflags) +{ + int flags = 0; + + if (ioflags & IO_APPEND) + flags |= FAPPEND; + if (ioflags & IO_NDELAY) + flags |= FNONBLOCK; + if (ioflags & IO_SYNC) + flags |= (FSYNC | FDSYNC | FRSYNC); + + return (flags); +} + +static int zfs_freebsd_open(ap) struct vop_open_args /* { struct vnode *a_vp; @@ -3944,7 +3959,8 @@ zfs_freebsd_read(ap) } */ *ap; { - return (zfs_read(ap->a_vp, ap->a_uio, ap->a_ioflag, ap->a_cred, NULL)); + return (zfs_read(ap->a_vp, ap->a_uio, ioflags(ap->a_ioflag), + ap->a_cred, NULL)); } static int @@ -3957,7 +3973,8 @@ zfs_freebsd_write(ap) } */ *ap; { - return (zfs_write(ap->a_vp, ap->a_uio, ap->a_ioflag, ap->a_cred, NULL)); + return (zfs_write(ap->a_vp, ap->a_uio, ioflags(ap->a_ioflag), + ap->a_cred, NULL)); } static int _______________________________________________ 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 Sun Nov 28 10:16:54 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFB7A106566B; Sun, 28 Nov 2010 10:16:54 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B55458FC0A; Sun, 28 Nov 2010 10:16:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oASAGsXg030805; Sun, 28 Nov 2010 10:16:54 GMT (envelope-from mm@freefall.freebsd.org) Received: (from mm@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oASAGsMq030801; Sun, 28 Nov 2010 10:16:54 GMT (envelope-from mm) Date: Sun, 28 Nov 2010 10:16:54 GMT Message-Id: <201011281016.oASAGsMq030801@freefall.freebsd.org> To: cal@linu.gs, mm@FreeBSD.org, freebsd-fs@FreeBSD.org From: mm@FreeBSD.org Cc: Subject: Re: kern/151082: [zfs] [patch] sappend-flaged files on ZFS not working correctly X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 10:16:55 -0000 Synopsis: [zfs] [patch] sappend-flaged files on ZFS not working correctly State-Changed-From-To: patched->closed State-Changed-By: mm State-Changed-When: Sun Nov 28 10:16:54 UTC 2010 State-Changed-Why: Resolved. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=151082 From owner-freebsd-fs@FreeBSD.ORG Sun Nov 28 14:23:29 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88C37106564A for ; Sun, 28 Nov 2010 14:23:29 +0000 (UTC) (envelope-from freebsd@deman.com) Received: from cp11.openaccess.org (cp11.openaccess.org [66.114.41.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6D70E8FC08 for ; Sun, 28 Nov 2010 14:23:29 +0000 (UTC) Received: from mono-sis1.s.bli.openaccess.org ([66.114.32.149] helo=[192.168.2.226]) by cp11.openaccess.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PMiA4-0004GI-Cp for freebsd-fs@freebsd.org; Sun, 28 Nov 2010 06:23:28 -0800 From: Michael DeMan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 28 Nov 2010 06:23:28 -0800 Message-Id: <6D67119B-2285-4FED-844C-854E64B38D4E@deman.com> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp11.openaccess.org X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deman.com X-Source: X-Source-Args: X-Source-Dir: Subject: status on Perc3 'aacli' toolset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 14:23:29 -0000 Hi All, Sorry if I am mis-posting here, if I should be posting to a 'device = drivers' list or something, please advise. For some old hardware that was pressed back into production, I am unable = to locate or advise anybody about tools to mange it. The pertinent = dmesg is: aac0: mem 0xf0000000-0xf7ffffff irq 18 at device 8.1 on = pci1 There used to be a tool in FBSD ports, if I recall correctly it was = something like 'aacli' and under sysutils. Is there a more modern way to manage this old stuff, or is it totally = (not just deprecated, but) wiped out from FBSD support? This is on FBSD 8.1, totally stock: FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010 = root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Thanks, - Mike From owner-freebsd-fs@FreeBSD.ORG Sun Nov 28 14:45:44 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7132106566C for ; Sun, 28 Nov 2010 14:45:44 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7FA8FC0A for ; Sun, 28 Nov 2010 14:45:44 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id oASEjfNX065815 for ; Sun, 28 Nov 2010 08:45:41 -0600 (CST) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=lm886BUYvuHPK53Jwz9Q5cmrBDookA00DDMaQE8G81caxhDWQwh0L06KkRvoqIFC7 YUd40Far+wxmjsppUxwHyMarr0gYGjS+NTyeSwyCwHUoncTkEKlh+juKgkgxKknpTIR RUSWOv/lBBrXQ8npo2vLl93JCW7bQQOAgJtVB4Q= Message-ID: <4CF26B15.6090009@jrv.org> Date: Sun, 28 Nov 2010 08:45:41 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ZFS panic: empty ZFS ACL X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 14:45:44 -0000 amd64 Version String: FreeBSD 9.0-CURRENT #0 r214378M: Sun Nov 28 07:52:25 CST 2010 root@kraken.housenet.jrv:/usr/obj/usr/src/sys/GENERIC Panic String: empty ZFS ACL I got this panic via "ls -l" after copying in a very old pool via zfs send/recv: the pool originated on Macintosh ZFS just after Apple first released the initial build of that. Steps: kraken:/root# zpool create STUFF raidz2 ada{0,1,2,3,8,9,10,11} # new destination kraken:/root# zpool import fearhome # foreign, old pool kraken:/root# zfs umount fearhome kraken:/root# zfs snapshot -r fearhome@now kraken:/root# zfs create STUFF/fearhome kraken:/root# zfs send -R fearhome@now | zfs recv -duvF STUFF/fearhome receiving full stream of fearhome@now into STUFF/fearhome@now received 1.52TB stream in 85275 seconds (18.7MB/sec) kraken:/root# zpool export fearhome kraken:/root# ls -l /STUFF/fearhome/ total 6951425 Read from remote host kraken: Operation timed out Connection to kraken closed. relevant dump backtrace: #9 0xffffffff805cb490 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #10 0xffffffff810c9f85 in acl_from_aces (aclp=Variable "aclp" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_acl.c:108 #11 0xffffffff8114aa3a in zfs_freebsd_getacl (ap=0xffffff82472be840) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5314 #12 0xffffffff80645701 in vacl_get_acl (td=Variable "td" is not available. ) at vnode_if.h:1221 #13 0xffffffff806459bf in __acl_get_link (td=0xffffff00088bf000, uap=0xffffff82472bebb0) at /usr/src/sys/kern/vfs_acl.c:355 #14 0xffffffff8060caea in syscallenter (td=0xffffff00088bf000, sa=0xffffff82472beba0) at /usr/src/sys/kern/subr_trap.c:318 #15 0xffffffff808c612c in syscall (frame=0xffffff82472bec40) at /usr/src/sys/amd64/amd64/trap.c:939 #16 0xffffffff808b0422 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:381 #17 0x000000080096f4fc in ?? () Previous frame inner to this frame (corrupt stack?) From owner-freebsd-fs@FreeBSD.ORG Sun Nov 28 21:18:46 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 313F21065670 for ; Sun, 28 Nov 2010 21:18:46 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D7AA98FC0C for ; Sun, 28 Nov 2010 21:18:45 +0000 (UTC) Received: by qwg8 with SMTP id 8so2885562qwg.13 for ; Sun, 28 Nov 2010 13:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ADIPqbiIWvzqls8jyV+0clffsUTlVwmufPT4R6Bl5AI=; b=S470iOlYWZeeCX3uoyF+6cYav06YgvQfjmMDF8YQDlAggnfYMX9C6jcTfMQEEVlI6H 6Ot6QJ/+i18AyQUpRO0Rr8tsn7bjpK8gBV4mHvlsgSnBAM0wIqWIlvqcCC3BfzrPtx6Q acbAY4o0Vh2b7yLMYwvp+HFSQ55jPnLR/AVEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=R24UCR/xHcvyp5QjSHCbVBsk6LnXX5nd9cp0dhyd7piPTdvVLan4D1+FtoNGrGttqc laRrptlP7DZYyTOXY6NdPV2TXTK+benr5tJa7/8Z8yJRJSdOXdS3oHtJV/XYHL608WVY fz3hi2WEexN2sk89XgjbGL/2nTR4D5MRFHPKA= MIME-Version: 1.0 Received: by 10.229.186.15 with SMTP id cq15mr4149001qcb.271.1290979124878; Sun, 28 Nov 2010 13:18:44 -0800 (PST) Received: by 10.229.39.147 with HTTP; Sun, 28 Nov 2010 13:18:44 -0800 (PST) In-Reply-To: <6D67119B-2285-4FED-844C-854E64B38D4E@deman.com> References: <6D67119B-2285-4FED-844C-854E64B38D4E@deman.com> Date: Mon, 29 Nov 2010 00:18:44 +0300 Message-ID: From: Sergey Kandaurov To: Michael DeMan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: status on Perc3 'aacli' toolset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 21:18:46 -0000 On 28 November 2010 17:23, Michael DeMan wrote: > Hi All, > > Sorry if I am mis-posting here, if I should be posting to a 'device drive= rs' list or something, please advise. > > > For some old hardware that was pressed back into production, I am unable = to locate or advise anybody about tools to mange it. =A0The pertinent dmesg= is: > > aac0: mem 0xf0000000-0xf7ffffff irq 18 at device 8.1 on = pci1 > > There used to be a tool in FBSD ports, if I recall correctly it was somet= hing like 'aacli' and under sysutils. > > Is there a more modern way to manage this old stuff, or is it totally (no= t just deprecated, but) wiped out from FBSD support? > > This is on FBSD 8.1, totally stock: > FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010 =A0 =A0 root@almeida= .cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > > Mike, please, look at sysutils/arcconf to manage aac(4) devices. --=20 wbr, pluknet From owner-freebsd-fs@FreeBSD.ORG Sun Nov 28 23:15:43 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85FF91065695 for ; Sun, 28 Nov 2010 23:15:43 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1188A8FC08 for ; Sun, 28 Nov 2010 23:15:42 +0000 (UTC) Received: by fxm16 with SMTP id 16so2125597fxm.13 for ; Sun, 28 Nov 2010 15:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=oo3J9jO17I4fx5Uz6DlAmmXDW1jsLp7cL9lFhbwHD1c=; b=j0Un4annM8/djw1234hVedF32m94V3SebqVluOJKDqe0U49UAvBPNLqgMRjdTEhWKj oDOQhHZ5NlwMTKJi6/XD2R3PqyU1d0cvw3S3RW+0GKusTg3sCSfbH/MFso635U5KgW98 F5Xv8EqLcxLv7dhRHTRG0ryjYghfr4LxIOUtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ghgvadgvDq4vXWcWLYF+9kDY5w8naN3yNRa/jvDtLYPkCLL3i1ZBFkJUT00yAjrWPL EIFZeWukyytjrBtJ0iOxe1Krj6H+uUIa2Yzqoi2ZWGIXn+Ats7F+EPkrRXJP5UTPBpwp 67WuboxYXVAw0+g8tQfaAUffXKn/e/Vn2Nmrk= Received: by 10.223.101.131 with SMTP id c3mr4714822fao.95.1290984799246; Sun, 28 Nov 2010 14:53:19 -0800 (PST) Received: from [192.168.1.102] (45.81.datacomsa.pl [195.34.81.45]) by mx.google.com with ESMTPS id f24sm426995fak.24.2010.11.28.14.53.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Nov 2010 14:53:18 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <4CF26B15.6090009@jrv.org> Date: Sun, 28 Nov 2010 23:53:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7A3D90B8-EEC0-4FC2-9744-C58379709901@FreeBSD.org> References: <4CF26B15.6090009@jrv.org> To: James R. Van Artsdalen X-Mailer: Apple Mail (2.1082) Cc: freebsd-fs Subject: Re: ZFS panic: empty ZFS ACL X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 23:15:43 -0000 Wiadomo=B6=E6 napisana przez James R. Van Artsdalen w dniu 2010-11-28, o = godz. 15:45: > amd64 > Version String: FreeBSD 9.0-CURRENT #0 r214378M: Sun Nov 28 07:52:25 > CST 2010 root@kraken.housenet.jrv:/usr/obj/usr/src/sys/GENERIC > Panic String: empty ZFS ACL >=20 > I got this panic via "ls -l" after copying in a very old pool via zfs > send/recv: the pool originated on Macintosh ZFS just after Apple first > released the initial build of that. Could you try the patch below? Index: sys/cddl/compat/opensolaris/kern/opensolaris_acl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/cddl/compat/opensolaris/kern/opensolaris_acl.c (revision = 215553) +++ sys/cddl/compat/opensolaris/kern/opensolaris_acl.c (working copy) @@ -105,7 +105,10 @@ struct acl_entry *entry; const ace_t *ace; =20 - KASSERT(nentries >=3D 1, ("empty ZFS ACL")); + if (nentries < 1) { + printf("acl_from_aces: empty ZFS ACL; returning = EINVAL.\n"); + return (EINVAL); + } =20 if (nentries > ACL_MAX_ENTRIES) { /* -- If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-fs@FreeBSD.ORG Mon Nov 29 01:08:09 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5147106566C for ; Mon, 29 Nov 2010 01:08:09 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id A24AF8FC0C for ; Mon, 29 Nov 2010 01:08:09 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id oAT0plF3093216; Sun, 28 Nov 2010 18:51:48 -0600 (CST) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=ZNsuagqzqqmgeNLUe8v5phUoYm9PGdG7ibWjr2NbM+K7WxeJbJ0eNSQqKAIY/U41b AFHaLxdtBNsOV4h6hTJe8S4mgE9ZoA5Xp49uAY7d/95n1DgMmL+8VtLHE5VhOQ3wXji p0GAAUW4y1MYMUgAZNxQ8uVEpqkJmgj1lT8/7pw= Message-ID: <4CF2F923.1050104@jrv.org> Date: Sun, 28 Nov 2010 18:51:47 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= References: <4CF26B15.6090009@jrv.org> <7A3D90B8-EEC0-4FC2-9744-C58379709901@FreeBSD.org> In-Reply-To: <7A3D90B8-EEC0-4FC2-9744-C58379709901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs Subject: Re: ZFS panic: empty ZFS ACL X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 01:08:10 -0000 Edward Tomasz Napiera=B3a wrote: > Could you try the patch below? > > Index: sys/cddl/compat/opensolaris/kern/opensolaris_acl.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/cddl/compat/opensolaris/kern/opensolaris_acl.c (revision 21555= 3) > +++ sys/cddl/compat/opensolaris/kern/opensolaris_acl.c (working copy) > @@ -105,7 +105,10 @@ > struct acl_entry *entry; > const ace_t *ace; > =20 > - KASSERT(nentries >=3D 1, ("empty ZFS ACL")); > + if (nentries < 1) { > + printf("acl_from_aces: empty ZFS ACL; returning EINVAL.= \n"); > + return (EINVAL); > + } > =20 > if (nentries > ACL_MAX_ENTRIES) { > /* > > -- > If you cut off my head, what would I say? Me and my head, or me and my= body? > =20 The patch prevents the panic but EINVAL propagates back up to the application in an undesirable way: kraken:/root# ls -ld /STUFF/fearhome/Backups ls: /STUFF/fearhome/Backups: Invalid argument drwxr-xr-x 9 james james 10 Oct 17 2007 /STUFF/fearhome/Backups kraken:/root# From owner-freebsd-fs@FreeBSD.ORG Mon Nov 29 11:07:00 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9597910656C5 for ; Mon, 29 Nov 2010 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 685548FC18 for ; Mon, 29 Nov 2010 11:07:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oATB70nJ053073 for ; Mon, 29 Nov 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oATB6xrQ053069 for freebsd-fs@FreeBSD.org; Mon, 29 Nov 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Nov 2010 11:06:59 GMT Message-Id: <201011291106.oATB6xrQ053069@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 11:07:00 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode o kern/152079 fs [msdosfs] [patch] Small cleanups from the other NetBSD 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 kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un 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/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150796 fs [panic] [suj] [ufs] [softupdates] Panic on portbuild 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/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149855 fs [gvinum] growfs causes fsck to report errors in Filesy o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149022 fs [hang] File system operations hangs with suspfs state 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 bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload 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/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take 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 o kern/146375 fs [nfs] [patch] Typos in macro variables names in sys/fs 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 o 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 o kern/144458 fs [nfs] [patch] nfsd fails as a kld 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/143345 fs [ext2fs] [patch] extfs minor header cleanups to better o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142924 fs [ext2fs] [patch] Small cleanup for the inode struct in o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/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/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/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/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs o bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high 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 o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135667 fs [lor] LORs causing ufs filesystem corruption on XEN Do 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 o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int 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 p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat 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 bin/118249 fs [ufs] mv(1): moving a directory changes its mtime 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/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes 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 bin/94635 fs snapinfo(8)/libufs only works for disk-backed filesyst 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 kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi 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. f kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot 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/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash 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 211 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 29 13:37:22 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7342106566B for ; Mon, 29 Nov 2010 13:37:22 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2BEEB8FC12 for ; Mon, 29 Nov 2010 13:37:21 +0000 (UTC) Received: by bwz2 with SMTP id 2so4126137bwz.13 for ; Mon, 29 Nov 2010 05:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=e6ekA6MUduTYS+udSplbhVXRgb3Nl/TbA1Xak+LmX0s=; b=AHhbSyRngX9nq/XdoX1QDDM3/3igxm+rpQB7VQBNmZVV5pLpP0XKM3yt4+Ee6SsG4U WvUk3MMSfvKHYnXFIZgL/XwYg1l+mW8DzeINwBn0KPznSD2CQO06WuxkM9P9q4HxMgQC m1ltjbhhT7pXcyCP8Vz6mDNk5C9ryJKMs2+5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ZTbtzroH6Q/kSZBqxXRN/qivCJiwlBKX5xjk8xGHRg7gSF6PoB+4ila+diT8aR0LM4 x2U/WMeJgxRj+MQkXqh/RIPr6SOYYnlYXntYGBHlLFvOLx22zvi5k4iF1NdAmzQi8htG V/3/kycE6a6FbfLLbh8xXIgou/1fphzGhrSJU= Received: by 10.204.118.207 with SMTP id w15mr4840211bkq.197.1291037840929; Mon, 29 Nov 2010 05:37:20 -0800 (PST) Received: from enapierala.whl (58.wheelsystems.com [83.12.187.58]) by mx.google.com with ESMTPS id v1sm2034233bkt.17.2010.11.29.05.37.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Nov 2010 05:37:19 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <4CF2F923.1050104@jrv.org> Date: Mon, 29 Nov 2010 14:37:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CF26B15.6090009@jrv.org> <7A3D90B8-EEC0-4FC2-9744-C58379709901@FreeBSD.org> <4CF2F923.1050104@jrv.org> To: James R. Van Artsdalen X-Mailer: Apple Mail (2.1082) Cc: freebsd-fs Subject: Re: ZFS panic: empty ZFS ACL X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 13:37:22 -0000 Wiadomo=B6=E6 napisana przez James R. Van Artsdalen w dniu 2010-11-29, o = godz. 01:51: > Edward Tomasz Napiera=B3a wrote: >> Could you try the patch below? >>=20 >> Index: sys/cddl/compat/opensolaris/kern/opensolaris_acl.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/cddl/compat/opensolaris/kern/opensolaris_acl.c (revision = 215553) >> +++ sys/cddl/compat/opensolaris/kern/opensolaris_acl.c (working = copy) >> @@ -105,7 +105,10 @@ >> struct acl_entry *entry; >> const ace_t *ace; >>=20 >> - KASSERT(nentries >=3D 1, ("empty ZFS ACL")); >> + if (nentries < 1) { >> + printf("acl_from_aces: empty ZFS ACL; returning = EINVAL.\n"); >> + return (EINVAL); >> + } >>=20 >> if (nentries > ACL_MAX_ENTRIES) { >> /* >>=20 >> -- >> If you cut off my head, what would I say? Me and my head, or me and = my body? >>=20 >=20 >=20 > The patch prevents the panic but EINVAL propagates back up to the > application in an undesirable way: >=20 > kraken:/root# ls -ld /STUFF/fearhome/Backups > ls: /STUFF/fearhome/Backups: Invalid argument > drwxr-xr-x 9 james james 10 Oct 17 2007 /STUFF/fearhome/Backups > kraken:/root# That's intentional. Empty ACL is not a valid condition - it's kind of = like filesystem corruption; no idea why OSX port allowed for that. To get rid of the error, try using chmod(1). Please report whether it = works or not. -- If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-fs@FreeBSD.ORG Tue Nov 30 02:10:57 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 654B510656A3; Tue, 30 Nov 2010 02:10:57 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 36EC28FC23; Tue, 30 Nov 2010 02:10:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 99B7D509A5; Tue, 30 Nov 2010 01:52:33 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoehBdLFhYQc; Tue, 30 Nov 2010 01:52:33 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 54587509A3 ; Tue, 30 Nov 2010 01:52:33 +0000 (GMT) Message-ID: <4CF458EE.7030109@langille.org> Date: Mon, 29 Nov 2010 20:52:46 -0500 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Terry Kennedy References: <01NUB1F8POL000BNN4@tmk.com> <01NUB3IOMZJW00BNN4@tmk.com> <01NUC6V4LBAQ00BNN4@tmk.com> In-Reply-To: <01NUC6V4LBAQ00BNN4@tmk.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ZFS panic after replacing log device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 02:10:57 -0000 On 11/16/2010 8:41 PM, Terry Kennedy wrote: >> I would say it is definitely very odd that writes are a problem. Sounds >> like it might be a hardware problem. Is it possible to export the pool, >> remove the ZIL and re-import it? I myself would be pretty nervous trying >> that, but it would help isolate the problem? If you can risk it. > > I think it is unlikely to be a hardware problem. While I haven't run any > destructive testing on the ZFS pool, the fact that it can be read without > error, combined with ECC throughout the system and the panic always happen- > ing on the first write, makes me think that it is a software issue in ZFS. > > When I do: > > zpool export data; zpool remove data da0 > > I get a "No such pool: data". I then re-imported the pool and did: > > zpool offline data da0; zpool export data; zpool import data > > After doing that, I can write to the pool without a panic. But once I > online the log device and do any writes, I get the panic again. > > As I mentioned, I have this data replicated elsewere, so I can exper- > iment with the pool if it will help track down this issue. Any more news on this? -- Dan Langille - http://langille.org/ From owner-freebsd-fs@FreeBSD.ORG Wed Dec 1 00:54:38 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACA0C106567A for ; Wed, 1 Dec 2010 00:54:38 +0000 (UTC) (envelope-from brucec@muon.cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 77CE68FC20 for ; Wed, 1 Dec 2010 00:54:38 +0000 (UTC) Received: by muon.cran.org.uk (Postfix, from userid 1001) id 7E1E7E60EB; Wed, 1 Dec 2010 00:54:37 +0000 (GMT) Date: Wed, 1 Dec 2010 00:54:37 +0000 From: Bruce Cran To: freebsd-fs@freebsd.org Message-ID: <20101201005437.GA18296@muon.cran.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: ZFS hang during reboot after updating / to rw X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 00:54:38 -0000 Hi, I don't know if I'm doing something wrong, but I've found a way to reliably hang the system during reboot - I'm running the latest HEAD amd64 with ZFS on all the filesystems. After booting into single-user mode I wanted to mount all the filesystems rw so I did: # mount -a (realised I needed to use "zfs mount -a" instead) # zfs mount -a (/ is still ro, so update it to rw) # mount -u -o rw / Then, when rebooting the reboot task got stuck with the following backtrace: sched_switch() mi_switch() sleepq_switch() sleepq_wait() _sleep() zfsvfs_teardown() zfs_unmount() dounmount() vfs_unmountall() kern_reboot() reboot() syscallenter() syscall() Xfast_syscall() -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Wed Dec 1 09:12:19 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C89D106564A for ; Wed, 1 Dec 2010 09:12:19 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id E09648FC08 for ; Wed, 1 Dec 2010 09:12:18 +0000 (UTC) Received: by ewy24 with SMTP id 24so3465722ewy.13 for ; Wed, 01 Dec 2010 01:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=3PQmuwGgOOeBrsxbkqDj5RgqJaF5C8nwKOcFbLsXyIU=; b=c4eUXtaKCVkdF/t6/dnDf+PDX7qOiQZth5l7mbYeY8ps0//H96Pdx56tP1DHBPhLi0 bxfiBNAdKinfCFaloNLhAuSnuQCR+vteLFI9GU1cT+h+pvQVaNHIMS3nQTZqcylyWGBu xntNnweLO6NInFU4Ek8yTUyruRd2A0kOfG3GI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=YaGjv7rMgyTsDBuToDm/W4/WrHsEmEyB7C9Gh2HCPgy93LLb+wpvyBYAFuxJcZkdbD Iaf3sjgq/mt6pUT32mauOx1FsiOBoGWosjcY1GP+cNkhGtVzqshta31tcZA40LUO/XjZ OG43QWmBiI7J2xBAA0tvCKPwSD1YMME4JAvDo= Received: by 10.213.15.135 with SMTP id k7mr9699931eba.76.1291194737690; Wed, 01 Dec 2010 01:12:17 -0800 (PST) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id q58sm7315185eeh.3.2010.12.01.01.12.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 01:12:17 -0800 (PST) Date: Wed, 1 Dec 2010 11:12:03 +0200 From: Gleb Kurtsou To: freebsd-fs@freebsd.org Message-ID: <20101201091203.GA3933@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [rfc] 64-bit inode numbers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 09:12:19 -0000 Hi, I've been working on adding support for 64 bit ino_t and 32 bit nlink_t. I have a patchset which is still work in progress, but I wasn't able to find time to continue the project for a month already. Notes: * Keep using 32 bit inodes in UFS and UFS boot code: UFS is a critical component and switching it to 64bit ino_t won't improve anything * Don't use nlink_t in UFS on-disk structs, introduce ufs_ino_t * Deprecate incomplete set of NetBSD emulation nstat* syscalls. Remove COMPAT_FREEBSD32 support which was never functional, mark as COMPAT8 * Implement both kernel level and libc compatibility shims, support COMPAT_FREEBSD32 * Add d_off (now unused) to struct dirent to facilitate removing cookies argument from VOP_READDIR. (both OpenSolaris and Linux do the same) * Libc compatibility shims for struct dirent users Tar archive of individual patches to make review easier. First several patches are bug fixes and can be commited as they are: https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch.tgz The same but as a single patch: https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64.big.patch.gz Patches are against recent CURRENT: svn r215808. Code is also hosted on gitorious: http://gitorious.org/~glk/glk-freebsd-ino64 Thanks, Gleb. From owner-freebsd-fs@FreeBSD.ORG Wed Dec 1 13:33:59 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2335E106564A for ; Wed, 1 Dec 2010 13:33:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 972158FC13 for ; Wed, 1 Dec 2010 13:33:58 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id oB1DXcj7053042; Wed, 1 Dec 2010 14:33:53 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id oB1DXcCB053041; Wed, 1 Dec 2010 14:33:38 +0100 (CET) (envelope-from olli) Date: Wed, 1 Dec 2010 14:33:38 +0100 (CET) Message-Id: <201012011333.oB1DXcCB053041@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, gleb.kurtsou@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Wed, 01 Dec 2010 14:33:53 +0100 (CET) Cc: Subject: Re: [rfc] 64-bit inode numbers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, gleb.kurtsou@gmail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 13:33:59 -0000 Gleb Kurtsou wrote: > I've been working on adding support for 64 bit ino_t and 32 bit nlink_t. Great! That will enable us to get rid of the MSDOSFS_LARGEFS hack, right? So large FAT file systems > 128 GB will finally be exportable via NFS and don't wast kernel memory anymore. Best regards Oliver PS: Just in case someone rading this doesn't know about the MSDOSFS_LARGEFS hack (i.e. mount_msdosfs -o large), here's a source comment for reference: /* * Experimental support for large MS-DOS filesystems. * WARNING: This uses at least 32 bytes of kernel memory (which is not * reclaimed until the FS is unmounted) for each file on disk to map * between the 32-bit inode numbers used by VFS and the 64-bit * pseudo-inode numbers used internally by msdosfs. This is only * safe to use in certain controlled situations (e.g. read-only FS * with less than 1 million files). * Since the mappings do not persist across unmounts (or reboots), these * filesystems are not suitable for exporting through NFS, or any other * application that requires fixed inode numbers. */ -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd (On the statement print "42 monkeys" + "1 snake":) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer is clearly "41 monkeys and 1 fat snake". -- Jim Fulton From owner-freebsd-fs@FreeBSD.ORG Wed Dec 1 13:57:46 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9D861065670; Wed, 1 Dec 2010 13:57:46 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 35F108FC0C; Wed, 1 Dec 2010 13:57:45 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id CAFA519E02D; Wed, 1 Dec 2010 14:40:02 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id EA53319E023; Wed, 1 Dec 2010 14:39:56 +0100 (CET) Message-ID: <4CF6502C.7020007@quip.cz> Date: Wed, 01 Dec 2010 14:39:56 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.15) Gecko/20101027 SeaMonkey/2.0.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: mandree@freebsd.org Subject: can't set ext2 volume label with tune2fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 13:57:47 -0000 Hi, I have an external disk WD320 connected by USB to machine running FreeBSD 8.1-RELEASE i386 GENERIC. I need to use this disk for rsync backups. I tried to set label on existing filesystem, but label is still empty: Order of commands: root@kapo ~/# tune2fs -l /dev/da0s1 tune2fs 1.41.12 (17-May-2010) Filesystem volume name: Last mounted on: Filesystem UUID: e17f87a5-8448-4518-b899-4e2ce2918354 Filesystem magic number: 0xEF53 . . root@kapo ~/# tune2fs -L usbWD320m5Sbkp1 /dev/da0s1 tune2fs 1.41.12 (17-May-2010) root@kapo ~/# tune2fs -l /dev/da0s1 tune2fs 1.41.12 (17-May-2010) Filesystem volume name: Last mounted on: Filesystem UUID: e17f87a5-8448-4518-b899-4e2ce2918354 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal filetype sparse_super Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 39075840 Block count: 78142160 Reserved block count: 3907108 Free blocks: 11412001 Free inodes: 38767335 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16384 Inode blocks per group: 512 Filesystem created: Tue May 23 15:24:24 2006 Last mount time: Sun Apr 29 23:09:04 2007 Last write time: Thu Oct 7 11:30:43 2010 Mount count: 21 Maximum mount count: 34 Last checked: Tue May 23 15:24:24 2006 Check interval: 15552000 (6 months) Next check after: Sun Nov 19 14:24:24 2006 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group wheel) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: tea Directory Hash Seed: 8ff346bb-24c2-4ea4-b07f-993fd3f21f61 As you can see, this is rather old disk formated on an old Linux machine (4 years ago). Is it a known bug, that label can't be set by tune2fs? I need to mount external disks by label instead of device name as the mount and backup will be scripted and I can't be sure what the device number (da0, da1, da2...) will be if somebody connect another disk device to this machine. Setting volume label with mke2fs works fine (on new disks), but I don't want to do it on this disk because it contains valuable data. Next strange thing is error message when I run `ls` command on /dev/ext2fs root@kapo ~/# ls -al /dev/ext2fs/ ls: : No such file or directory total 1 dr-xr-xr-x 3 root wheel 512 Oct 22 04:04 . dr-xr-xr-x 10 root wheel 512 Oct 22 06:04 .. As you can see, /dev/ext2fs exists. Plain `ls /dev/ext2fs/` is OK, but if I add '-l', it prints error "ls: : No such file or directory" Miroslav Lachman From owner-freebsd-fs@FreeBSD.ORG Wed Dec 1 17:19:18 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F0F61065679 for ; Wed, 1 Dec 2010 17:19:18 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF12E8FC24 for ; Wed, 1 Dec 2010 17:19:17 +0000 (UTC) Received: by eyb7 with SMTP id 7so3833296eyb.13 for ; Wed, 01 Dec 2010 09:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=LA7JT7ZDWfI1t6atwrmynDVyHbh3pz4XxSg6KpHRAhg=; b=VqviSYyhxOpQ2rakJvAvMKa+JvW/Pll/KP2iEumX+WO7nZyGbHqDS7Z75YfuzLe+v9 W1XZuwhK4VuLV87cEhQJvSM/lkFiyW00hEmqzDumgYvzWF+2B2jMtvOLZ8VLeFUbdVfD MSqg+AYqpW0MIhxTEekShACQP3hVCYT2A9rxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=MhePSeS5QvM/dY82QbA3AV9rc0Ri2pRSrEdZ8BgiXfH80LLp1DvB+zRSx7lz3tcUoC bi+hZ+EF1qpKHUtMtlCWqG1Vn/5iKNfIOAQdvwDVpzG0DqFKsHuURyV1eNoKD0/wvCE+ lvtJLqIWtx3+9D+QGtXuledFgQAebhFoAmx8s= Received: by 10.213.11.9 with SMTP id r9mr887400ebr.11.1291223956515; Wed, 01 Dec 2010 09:19:16 -0800 (PST) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id b52sm164154eei.19.2010.12.01.09.19.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 09:19:14 -0800 (PST) Date: Wed, 1 Dec 2010 19:18:59 +0200 From: Gleb Kurtsou To: Oliver Fromme Message-ID: <20101201171859.GA5991@tops> References: <201012011333.oB1DXcCB053041@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201012011333.oB1DXcCB053041@lurza.secnetix.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: [rfc] 64-bit inode numbers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 17:19:18 -0000 On (01/12/2010 14:33), Oliver Fromme wrote: > Gleb Kurtsou wrote: > > I've been working on adding support for 64 bit ino_t and 32 bit nlink_t. > > Great! > > That will enable us to get rid of the MSDOSFS_LARGEFS hack, > right? So large FAT file systems > 128 GB will finally be > exportable via NFS and don't wast kernel memory anymore. Yes, that was one of the reasons I've started working on the patch. All the infrastructure work necessary for eliminating largefs should already be there, but patch is really *untested*. Don't expect it just to work yet. Besides situation with ZFS is still unclear for me, looks like it expects 64-bit ino_t and silently shorts inode numbers to 32 bit. > > Best regards > Oliver > > PS: Just in case someone rading this doesn't know about > the MSDOSFS_LARGEFS hack (i.e. mount_msdosfs -o large), > here's a source comment for reference: > > /* > * Experimental support for large MS-DOS filesystems. > * WARNING: This uses at least 32 bytes of kernel memory (which is not > * reclaimed until the FS is unmounted) for each file on disk to map > * between the 32-bit inode numbers used by VFS and the 64-bit > * pseudo-inode numbers used internally by msdosfs. This is only > * safe to use in certain controlled situations (e.g. read-only FS > * with less than 1 million files). > * Since the mappings do not persist across unmounts (or reboots), these > * filesystems are not suitable for exporting through NFS, or any other > * application that requires fixed inode numbers. > */ > > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, GeschÀftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht MÃŒn- > chen, HRB 125758, GeschÀftsfÃŒhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > (On the statement print "42 monkeys" + "1 snake":) By the way, > both perl and Python get this wrong. Perl gives 43 and Python > gives "42 monkeys1 snake", when the answer is clearly "41 monkeys > and 1 fat snake". -- Jim Fulton From owner-freebsd-fs@FreeBSD.ORG Thu Dec 2 00:02:40 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ADA7106564A; Thu, 2 Dec 2010 00:02:40 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B957A8FC12; Thu, 2 Dec 2010 00:02:36 +0000 (UTC) Received: by yxh35 with SMTP id 35so4003174yxh.13 for ; Wed, 01 Dec 2010 16:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=W0yGGdKr5QzoDa7gFSuy5V/Bs/LItbcBRGn7m0+cuKU=; b=QoZNrYSAGeunpFRPt077djqFrXSLCJKrl0CLkrXCwd+msxiLjftKdUeEbRR9mu633M SJmpavKJl050+zcnku2rdjauPVLdWdnRleASaYMOoylD0+q4kiZYdgC2bKWpsF+RDaRD 5NRVRpsXqNiDIqWkh+YfY2UtawNOlZlPaI+yQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=dhgSSDkv4+1yWevaWi4ZwMXjjgIdJ4lnK/2S4dTAnfYWhIMc7CL67qs5fF7qeNpkEI /+FwplRi2DAtvNMSvb6sYjUMQZiQGhje8ucowZk3SE7P7dzOLFz8r4cqnCu/Z0MM/poP RaXY9MrCKUZnMMF2FHsWoi/zxPYYNoXEJ5XrQ= MIME-Version: 1.0 Received: by 10.91.17.5 with SMTP id u5mr167242agi.165.1291248155669; Wed, 01 Dec 2010 16:02:35 -0800 (PST) Received: by 10.90.226.2 with HTTP; Wed, 1 Dec 2010 16:02:35 -0800 (PST) Date: Wed, 1 Dec 2010 16:02:35 -0800 Message-ID: From: Freddie Cash To: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-Current Subject: Update to zfs command removes Python dep X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 00:02:40 -0000 Just a head's up, the Illumos devs have committed an update to zfs that removes the dependency on Python. Blog report here: http://gdamore.blogspot.com/2010/12/zfs-should-not-depend-on-python-and.html This may (or may not) make it easier to import a newer version of ZFS into -CURRENT. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Dec 2 11:59:17 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE9341065693 for ; Thu, 2 Dec 2010 11:59:17 +0000 (UTC) (envelope-from drb@karlov.mff.cuni.cz) Received: from mail.karlov.mff.cuni.cz (mail.karlov.mff.cuni.cz [195.113.27.114]) by mx1.freebsd.org (Postfix) with ESMTP id E37C58FC0A for ; Thu, 2 Dec 2010 11:59:16 +0000 (UTC) Received: from nat-r.karlov.mff.cuni.cz ([195.113.27.73] helo=[10.32.82.27]) by mail.karlov.mff.cuni.cz with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1PO7TO-000C6x-5D for freebsd-fs@freebsd.org; Thu, 02 Dec 2010 12:37:14 +0100 Message-ID: <4CF784E8.20609@karlov.mff.cuni.cz> Date: Thu, 02 Dec 2010 12:37:12 +0100 From: =?UTF-8?B?VG9tw6HFoSBEcmJvaGxhdg==?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary="------------080507000706050401030902" Subject: Linux (client) - FreeBSD (server) NFS4 interoperability problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 11:59:18 -0000 This is a multi-part message in MIME format. --------------080507000706050401030902 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, I am setting up an experimental (kerberized) NFSv4 server on FreeBSD 8.1-RELEASE-p1 and while between fBSD server and client it seems to work more or less ok, while connecting from Linux (Ubuntu), I am not able to read any file contents. Walking through dirs is ok, but when clients asks for a file, it freezes. As I noticed in the list, tcpdump may be useful, so I made one, see attached file. Although I am not an nfs expert, when I opened the dump in WireShark it seems to me, that server does not respond to packet #83, Compound Call containing OPEN opcode. That is probably the thing which disturbes Linux client. But why? It is beyond my capabilities. What can I do to make i work? Is it me or server, who si broken? I'll be happy to provide any data/testing needed. Thanks a lot, Drb --------------080507000706050401030902 Content-Type: application/octet-stream; name="dom-z-dump" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dom-z-dump" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAxGT2TM/EAgA8AAAAPAAAAAAZ0ZRtdwAcwHEV4QgA RQAALAUUQABABn0kCiBSHwogUjUDJwgBtgwlhwAAAABgAhbQ4gYAAAIEBbQAAMRk9kwBxQIA OgAAADoAAAAAHMBxFeEAGdGUbXcIAEUAACwHUEAAQAZ66AogUjUKIFIfCAEDJ9kLsOW2DCWI YBL//27UAAACBAW0xGT2THzFAgA8AAAAPAAAAAAZ0ZRtdwAcwHEV4QgARQAAKAUVQABABn0n CiBSHwogUjUDJwgBtgwliNkLsOZQEBbQb8EAAAAAAAAAAMRk9kyixQIAPAAAADwAAAAAGdGU bXcAHMBxFeEIAEUAACgFFkAAQAZ9JgogUh8KIFI1AycIAbYMJYjZC7DmUBEW0G/AAAAAAAAA AADEZPZMsMUCADYAAAA2AAAAABzAcRXhABnRlG13CABFAAAoB1FAAEAGeusKIFI1CiBSHwgB AyfZC7DmtgwliVAQ//+GkAAAxGT2TM7FAgA2AAAANgAAAAAcwHEV4QAZ0ZRtdwgARQAAKAdS QABABnrqCiBSNQogUh8IAQMn2Quw5rYMJYlQEf//ho8AAMRk9kwsxgIAPAAAADwAAAAAGdGU bXcAHMBxFeEIAEUAACgFF0AAQAZ9JQogUh8KIFI1AycIAbYMJYnZC7DnUBAW0G+/AAAAAAAA AADSZPZMYOsKADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAspehAAEAG3E8KIFIfCiBSNQK1 CAEANYOpAAAAAGACFtA6LgAAAgQFtAAA0mT2TJTrCgA6AAAAOgAAAAAcwHEV4QAZ0ZRtdwgA RQAALAdTQABABnrlCiBSNQogUh8IAQK1aQ2oZQA1g6pgEv//P3oAAAIEBbTSZPZMD+wKADwA AAA8AAAAABnRlG13ABzAcRXhCABFAAAopelAAEAG3FIKIFIfCiBSNQK1CAEANYOqaQ2oZlAQ FtBAZwAAAAAAAAAA0mT2TDrsCgBiAAAAYgAAAAAZ0ZRtdwAcwHEV4QgARQAAVKXqQABABtwl CiBSHwogUjUCtQgBADWDqmkNqGZQGBbQtDEAAIAAACgkFGEaAAAAAAAAAAIAAYajAAAABAAA AAAAAAAAAAAAAAAAAAAAAAAA0mT2TGHsCgBSAAAAUgAAAAAcwHEV4QAZ0ZRtdwgARQAARAdU QABABnrMCiBSNQogUh8IAQK1aQ2oZgA1g9ZQGP//UZ8AAIAAABgkFGEaAAAAAQAAAAAAAAAA AAAAAAAAAADSZPZM2OwKADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAopetAAEAG3FAKIFIf CiBSNQK1CAEANYPWaQ2oglAQFtBAHwAAAAAAAAAA0mT2TLLzCgA8AAAAPAAAAAAZ0ZRtdwAc wHEV4QgARQAALHXcQABABgxcCiBSHwogUjWvWAgB//ZTnQAAAABgAhbQvdQAAAIEBbQAANJk 9kzO8woAOgAAADoAAAAAHMBxFeEAGdGUbXcIAEUAACwHVUAAQAZ64wogUjUKIFIfCAGvWNTR bOv/9lOeYBL//5LWAAACBAW00mT2TEn0CgA8AAAAPAAAAAAZ0ZRtdwAcwHEV4QgARQAAKHXd QABABgxfCiBSHwogUjWvWAgB//ZTntTRbOxQEBbQk8MAAAAAAAAAANJk9kwn/QoAxgIAAMYC AAAAGdGUbXcAHMBxFeEIAEUAArh13kAAQAYJzgogUh8KIFI1r1gIAf/2U57U0WzsUBgW0Edd AACAAAKMMTc/CAAAAAAAAAACAAGGowAAAAQAAAAAAAAABgAAABQAAAABAAAAAQAAAAAAAAAB AAAAAAAAAAAAAAAAAAACSWCCAkUGCSqGSIb3EgECAgEAboICNDCCAjCgAwIBBaEDAgEOogcD BQAgAAAAo4IBUGGCAUwwggFIoAMCAQWhDRsLTUZGLkNVTkkuQ1qiKjAooAMCAQOhITAfGwNu ZnMbGG1zMi1yLmthcmxvdi5tZmYuY3VuaS5jeqOCAQQwggEAoAMCAQGhAwIBAaKB8wSB8AwC LL8+2rijx2EEV7/VL0cXp+AH0oAGobZL3mKPSfS3LNNsJL7Qf2Y6FKQziKkWb1gMvNfBRRdV HGXfXiWdThlHXeGW0gVMyQIPY+p8a06BwES1nnAlrLqegKQzi2zQmWDoD+I3s6liUh+t5o7/ 6rY/f6e2KJGEfT4H13ZAJG6UWhAVreJNTdNfeRCNEhdS0wPi31ysdaqGbOXUa3MWjaybnoCd jDfoUSKn2gumJ5kX4aKSswmaKq+Z0LgJ9yahcuC1snoxXcurNtJ7WzgDaWA4dxAE3ZoNIi2D wdIvVym6UOAX7T67nqOz+5yvlum5AaSBxjCBw6ADAgEBooG7BIG4AXx8r5PRz/KyorTWM21u EKgGS5AwU8zmcIQ5BdVCSb4PDMis6Ug5fdEQ+xqF9CIHsTRhfAVmlUXaxCQdWswehkcEWWgr y0YygYhB2h5H4jYY7dk2/EcJWY/SbstnsdlArv+oDG7ZFkz9vajwP7A/GKejyq9HU0tcDk5l 9sDv+0W9JILQuLzFdH4MdU2D2+nq16VZe8usWEIzAHxQCuBy99P7UbTkZ3vH4it6Zjs8l4tw ktNXpObdoQAAANJk9kz8/woAAgEAAAIBAAAAHMBxFeEAGdGUbXcIAEUAAPQHVkAAQAZ6Ggog UjUKIFIfCAGvWNTRbOz/9lYuUBj//4b5AACAAADIMTc/CAAAAAEAAAAAAAAABgAAACVgIwYJ KoZIhvcSAQICAQEAAP/////U4lQO50Hr4dgK/3xpiDTUAAAAAAAAAAAAABAeYvLrAAAAAJdW 9kwFAAAAAAAAAAAAAAAAAACAAAAAYmBgBgkqhkiG9xIBAgICAG9RME+gAwIBBaEDAgEPokMw QaADAgEBojoEOKp7ibnC9GX2cSQ+YYoTCEMeGzeCUPouDk71wSe2juRTK1r5/kAam92HAh94 8bGBI8pfNtirkHuRAADSZPZMdgALADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAodd9AAEAG DF0KIFIfCiBSNa9YCAH/9lYu1NFtuFAQGSCOFwAAAAAAAAAA0mT2TF8MCwA8AAAAPAAAAAAZ 0ZRtdwAcwHEV4QgARQAAKHXgQABABgxcCiBSHwogUjWvWAgB//ZWLtTRbbhQERkgjhYAAAAA AAAAANJk9kx2DAsANgAAADYAAAAAHMBxFeEAGdGUbXcIAEUAACgHV0AAQAZ65QogUjUKIFIf CAGvWNTRbbj/9lYvUBD//6c2AADSZPZMeQwLANIAAADSAAAAABnRlG13ABzAcRXhCABFAADE pexAAEAG27MKIFIfCiBSNQK1CAEANYPWaQ2oglAYFtC6RQAAgAAAmCUUYRoAAAAAAAAAAgAB hqMAAAAEAAAAAQAAAAYAAAAkAAAAAQAAAAAAAAABAAAAAQAAABAeYvLrAAAAAJdW9kwFAAAA AAAABgAAACVgIwYJKoZIhvcSAQICAQEAAP//////q1Cneofjr1MJP1S2XF6WAAAAAAAAAAAA AAAAAAADAAAAGAAAAAoAAAAJAAAAAgAQARoAMKI60mT2TIcMCwA2AAAANgAAAAAcwHEV4QAZ 0ZRtdwgARQAAKAdYQABABnrkCiBSNQogUh8IAa9Y1NFtuP/2Vi9QEf//pzUAANJk9kzxDAsA PAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACgAAEAAQAaCPAogUh8KIFI1r1gIAf/2Vi/U0W25 UBAZII4VAAAAAAAAAADSZPZMdQ4LAG4BAABuAQAAABzAcRXhABnRlG13CABFAAFgB11AAEAG eacKIFI1CiBSHwgBArVpDaiCADWEclAY//8PdAAAgAABNCUUYRoAAAABAAAAAAAAAAYAAAAl YCMGCSqGSIb3EgECAgEBAAD/////NrOD4ClJigu03JUqhirE9gAAAAAAAAAAAAAAAAAAAAAA AAMAAAAYAAAAAAAAAAoAAAAAAAAAHNol4UzDauKIDAAAAADYcAA7paL9AAAAAAAAAAAAAAAJ AAAAAAAAAAIAEAEaADCiOgAAAKAAAAACAAAAAAAAAAUAAAAAAAACAAAAAABM4SXaAAAAAIji asMAAAAAAHDYAAAAAe0AAAACAAAAF3Jvb3RAa2FybG92Lm1mZi5jdW5pLmN6AAAAABh3aGVl bEBrYXJsb3YubWZmLmN1bmkuY3oAAACvAcIAaAAAAAAAAAgAAAAAAEz2XiAAAAAAAAAAAEzi imwAAAAAAAAAAEziimwAAAAA0mT2THgPCwDqAAAA6gAAAAAZ0ZRtdwAcwHEV4QgARQAA3KXt QABABtuaCiBSHwogUjUCtQgBADWEcmkNqbpQGBkgyH4AAIAAALAmFGEaAAAAAAAAAAIAAYaj AAAABAAAAAEAAAAGAAAAJAAAAAEAAAAAAAAAAgAAAAEAAAAQHmLy6wAAAACXVvZMBQAAAAAA AAYAAAAlYCMGCSqGSIb3EgECAgEBAAD/////rTJA/8hucr6N4aFAU+5fHgAAAAAAAAAAAAAA AAAAAgAAABYAAAAc2iXhTMNq4ogMAAAAANhwADulov0AAAAAAAAAAAAAAAkAAAABAAAgYdJk 9kzkDwsAtgAAALYAAAAAHMBxFeEAGdGUbXcIAEUAAKgHXkAAQAZ6XgogUjUKIFIfCAECtWkN qboANYUmUBj//76/AACAAAB8JhRhGgAAAAEAAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEA AP////9b/OeqxgLTwvOLl5HxeM1nAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAAAAAACQAA AAAAAAABAAAAYQAAABQAAAAC/f+P/wD5vj4AAAABAAAAAdJk9kzJEQsA7gAAAO4AAAAAGdGU bXcAHMBxFeEIAEUAAOCl7kAAQAbblQogUh8KIFI1ArUIAQA1hSZpDao6UBgdUFfeAACAAAC0 JxRhGgAAAAAAAAACAAGGowAAAAQAAAABAAAABgAAACQAAAABAAAAAAAAAAMAAAABAAAAEB5i 8usAAAAAl1b2TAUAAAAAAAAGAAAAJWAjBgkqhkiG9xIBAgIBAQAA/////woRTXwNwf3SZ0Dp EPB4+mAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAHNol4UzDauKIDAAAAADYcAA7paL9AAAAAAAA AAAAAAAJAAAAAsgABAAAAAAA0mT2TBYSCwC+AAAAvgAAAAAcwHEV4QAZ0ZRtdwgARQAAsAdf QABABnpVCiBSNQogUh8IAQK1aQ2qOgA1hd5QGP//R3EAAIAAAIQnFGEaAAAAAQAAAAAAAAAG AAAAJWAjBgkqhkiG9xIBAgIBAQAA/////zm6XnjMQwmJ9R90dpr11FUAAAAAAAAAAAAAAAAA AAAAAAACAAAAFgAAAAAAAAAJAAAAAAAAAAHIAAQAAAAAHAAAAHgAAIAAAAAAAAAAAAAAAQAA AAAAAAABAADSZPZMjBILAOoAAADqAAAAABnRlG13ABzAcRXhCABFAADcpe9AAEAG25gKIFIf CiBSNQK1CAEANYXeaQ2qwlAYIYAF6AAAgAAAsCgUYRoAAAAAAAAAAgABhqMAAAAEAAAAAQAA AAYAAAAkAAAAAQAAAAAAAAAEAAAAAQAAABAeYvLrAAAAAJdW9kwFAAAAAAAABgAAACVgIwYJ KoZIhvcSAQICAQEAAP/////+Ale+1ab2fz5d5Pl9IgniAAAAAAAAAAAAAAAAAAACAAAAFgAA ABzaJeFMw2riiAwAAAAA2HAAO6Wi/QAAAAAAAAAAAAAACQAAAAEAACBh0mT2TNESCwC2AAAA tgAAAAAcwHEV4QAZ0ZRtdwgARQAAqAdgQABABnpcCiBSNQogUh8IAQK1aQ2qwgA1hpJQGP// YcAAAIAAAHwoFGEaAAAAAQAAAAAAAAAGAAAAJWAjBgkqhkiG9xIBAgIBAQAA/////1+UfCUC 2yXQibweRXamj7YAAAAAAAAAAAAAAAAAAAAAAAACAAAAFgAAAAAAAAAJAAAAAAAAAAEAAABh AAAAFAAAAAL9/4//APm+PgAAAAEAAAAB0mT2TFATCwDuAAAA7gAAAAAZ0ZRtdwAcwHEV4QgA RQAA4KXwQABABtuTCiBSHwogUjUCtQgBADWGkmkNq0JQGCWwvCYAAIAAALQpFGEaAAAAAAAA AAIAAYajAAAABAAAAAEAAAAGAAAAJAAAAAEAAAAAAAAABQAAAAEAAAAQHmLy6wAAAACXVvZM BQAAAAAAAAYAAAAlYCMGCSqGSIb3EgECAgEBAAD/////KWNmui3BzF9jjO8BQs1gQQAAAAAA AAAAAAAAAAAAAgAAABYAAAAc2iXhTMNq4ogMAAAAANhwADulov0AAAAAAAAAAAAAAAkAAAAC yAAEAAAAAADSZPZMlRMLAL4AAAC+AAAAABzAcRXhABnRlG13CABFAACwB2FAAEAGelMKIFI1 CiBSHwgBArVpDatCADWHSlAY//+VgAAAgAAAhCkUYRoAAAABAAAAAAAAAAYAAAAlYCMGCSqG SIb3EgECAgEBAAD/////IYPsZzfBJSur+Xsda77F4QAAAAAAAAAAAAAAAAAAAAAAAAIAAAAW AAAAAAAAAAkAAAAAAAAAAcgABAAAAAAcAAAAeAAAgAAAAAAAAAAAAAABAAAAAAAAAAEAANJk 9kzZFAsA6gAAAOoAAAAAGdGUbXcAHMBxFeEIAEUAANyl8UAAQAbblgogUh8KIFI1ArUIAQA1 h0ppDavKUBgp4Pz9AACAAACwKhRhGgAAAAAAAAACAAGGowAAAAQAAAABAAAABgAAACQAAAAB AAAAAAAAAAYAAAABAAAAEB5i8usAAAAAl1b2TAUAAAAAAAAGAAAAJWAjBgkqhkiG9xIBAgIB AQAA/////+MSNJJExDwrK4bxRiTxZt0AAAAAAAAAAAAAAAAAAAIAAAAWAAAAHNol4UzDauKI DAAAAADYcAA7paL9AAAAAAAAAAAAAAAJAAAAATAAAADSZPZMJhULAKoAAACqAAAAABzAcRXh ABnRlG13CABFAACcB2JAAEAGemYKIFI1CiBSHwgBArVpDavKADWH/lAY//+RkQAAgAAAcCoU YRoAAAABAAAAAAAAAAYAAAAlYCMGCSqGSIb3EgECAgEBAAD/////lDb7SoGYt+XH5pC90Kk8 3gAAAAAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAAAAAAAkAAAAAAAAAATAAAAAAAAAIAAB//wAA AP/SZPZMLBYLAOoAAADqAAAAABnRlG13ABzAcRXhCABFAADcpfJAAEAG25UKIFIfCiBSNQK1 CAEANYf+aQ2sPlAYKeBX2gAAgAAAsCsUYRoAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAYAAAAk AAAAAQAAAAAAAAAHAAAAAQAAABAeYvLrAAAAAJdW9kwFAAAAAAAABgAAACVgIwYJKoZIhvcS AQICAQEAAP/////OO6x3aWJaK0e8RD8R2v7LAAAAAAAAAAAAAAAAAAACAAAAFgAAABzaJeFM w2riiAwAAAAA2HAAO6Wi/QAAAAAAAAAAAAAACQAAAAEAACBh0mT2THAWCwC2AAAAtgAAAAAc wHEV4QAZ0ZRtdwgARQAAqAdjQABABnpZCiBSNQogUh8IAQK1aQ2sPgA1iLJQGP//q/8AAIAA AHwrFGEaAAAAAQAAAAAAAAAGAAAAJWAjBgkqhkiG9xIBAgIBAQAA/////weKLfbO7Cp3Nqlz VN56IBYAAAAAAAAAAAAAAAAAAAAAAAACAAAAFgAAAAAAAAAJAAAAAAAAAAEAAABhAAAAFAAA AAL9/4//APm+PgAAAAEAAAAB0mT2TBgYCwDuAAAA7gAAAAAZ0ZRtdwAcwHEV4QgARQAA4KXz QABABtuQCiBSHwogUjUCtQgBADWIsmkNrL5QGC4Q/MoAAIAAALQsFGEaAAAAAAAAAAIAAYaj AAAABAAAAAEAAAAGAAAAJAAAAAEAAAAAAAAACAAAAAEAAAAQHmLy6wAAAACXVvZMBQAAAAAA AAYAAAAlYCMGCSqGSIb3EgECAgEBAAD/////oOTZ+qt30i9ZdNrqkV2KcAAAAAAAAAAAAAAA AAAAAgAAABYAAAAc2iXhTMNq4ogMAAAAANhwADulov0AAAAAAAAAAAAAAAkAAAACABABGgAw ojrSZPZMYxgLAEYBAABGAQAAABzAcRXhABnRlG13CABFAAE4B2RAAEAGecgKIFI1CiBSHwgB ArVpDay+ADWJalAY//9c/wAAgAABDCwUYRoAAAABAAAAAAAAAAYAAAAlYCMGCSqGSIb3EgEC AgEBAAD/////LsQBBl+I31Iw5pIb/g9uuQAAAAAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAAAAA AAkAAAAAAAAAAgAQARoAMKI6AAAAoAAAAAIAAAAAAAAABQAAAAAAAAIAAAAAAEzhJdoAAAAA iOJqwwAAAAAAcNgAAAAB7QAAAAIAAAAXcm9vdEBrYXJsb3YubWZmLmN1bmkuY3oAAAAAGHdo ZWVsQGthcmxvdi5tZmYuY3VuaS5jegAAAK8BwgBoAAAAAAAACAAAAAAATPZeIAAAAAAAAAAA TOKKbAAAAAAAAAAATOKKbAAAAADSZPZMPKMLADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAo pfRAAEAG3EcKIFIfCiBSNQK1CAEANYlqaQ2tzlAQMkAZzwAAAAAAAAAA02T2TFBLCwA8AAAA PAAAAAAZ0ZRtdwAcwHEV4QgARQAALITXQABABv1gCiBSHwogUjWIDQgBAV2icAAAAABgAhbQ lOYAAAIEBbQAANNk9kx/SwsAOgAAADoAAAAAHMBxFeEAGdGUbXcIAEUAACwHZUAAQAZ60wog UjUKIFIfCAGIDbVuTeUBXaJxYBL//6hRAAACBAW002T2TPpLCwA8AAAAPAAAAAAZ0ZRtdwAc wHEV4QgARQAAKITYQABABv1jCiBSHwogUjWIDQgBAV2icbVuTeZQEBbQqT4AAAAAAAAAANNk 9kzIWQsAmgIAAJoCAAAAGdGUbXcAHMBxFeEIAEUAAoyE2UAAQAb6/gogUh8KIFI1iA0IAQFd onG1bk3mUBgW0FmRAACAAAJgft9EYgAAAAAAAAACAAGGowAAAAQAAAAAAAAABgAAABQAAAAB AAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAACH2CCAhsGCSqGSIb3EgECAgEAboICCjCCAgag AwIBBaEDAgEOogcDBQAgAAAAo4IBPmGCATowggE2oAMCAQWhDRsLTUZGLkNVTkkuQ1qiKjAo oAMCAQOhITAfGwNuZnMbGG1zMi1yLmthcmxvdi5tZmYuY3VuaS5jeqOB8zCB8KADAgEBoQMC AQGigeMEgeBTeB2tChH8v2UnzU8yLaXnPI91Iw2GpAqR1p6fO+571tmvqyhkHS7WRzjvuqTj KEzxXHAZvE8E3yzrZoccGr/k/FsSafA8ysd2uU9EOiJEDRciM0WsGca5Akjte5sMmYGu//hT mo3dCt1eOxuuD0h3Kj4G/28Pa3JyHoX+Ng/b1B7sX0QkeZ7jPUxlqLXtuuLydssrCJExPzG/ uzVC7YaOLldoipzmhS10nEoztUunPsEhArqR86R0PoqPAh0o1vAzgGM9uJJqwsTkJQvNyyjU DGw+J3PsXNwKMvtSJqAInKSBrjCBq6ADAgEBooGjBIGgOy+xuasmjrOx7+HBH03zqISvPwe8 ry7+U0HMedR0Qs+vGUZcjVb/Z2xrqTe0D/8VGbKRk+appyr9Kkw4NR1IpJAQkyDK22pCAex5 I8NoAtN6uu+KhL6XTie/vKXUgkvlqDwj3Rs+2A+Uls+mBY2NoXHD7NNLMJt4MGtJHDtNSO0y HBVNdPOuvQooUkdyNNHdrAmaospMTF491ijcoKjoQwDTZPZM1VwLAAIBAAACAQAAABzAcRXh ABnRlG13CABFAAD0B2ZAAEAGegoKIFI1CiBSHwgBiA21bk3mAV2k1VAY//8NwQAAgAAAyH7f RGIAAAABAAAAAAAAAAYAAAAlYCMGCSqGSIb3EgECAgEBAAD/////7JHYEXTgpU4TGdKB9ZCR MwAAAAAAAAAAAAAQHmLy6wAAAACXVvZMBgAAAAAAAAAAAAAAAAAAgAAAAGJgYAYJKoZIhvcS AQICAgBvUTBPoAMCAQWhAwIBD6JDMEGgAwIBAaI6BDgMSSbd/nN+hf81nJhBnhawVIEdX1Ab MAtZTxzUdKOhd+KKau+5kmjer6tIXAATRac/Et5Q3BaZ9wAA02T2TFBdCwA8AAAAPAAAAAAZ 0ZRtdwAcwHEV4QgARQAAKITaQABABv1hCiBSHwogUjWIDQgBAV2k1bVuTrJQEBkgo74AAAAA AAAAANNk9kyWZwsAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACiE20AAQAb9YAogUh8KIFI1 iA0IAQFdpNW1bk6yUBEZIKO9AAAAAAAAAADTZPZMqGcLADYAAAA2AAAAABzAcRXhABnRlG13 CABFAAAoB2dAAEAGetUKIFI1CiBSHwgBiA21bk6yAV2k1lAQ//+83QAA02T2TKpnCwD2AAAA 9gAAAAAZ0ZRtdwAcwHEV4QgARQAA6KX1QABABtuGCiBSHwogUjUCtQgBADWJamkNrc5QGDJA e4MAAIAAALwtFGEaAAAAAAAAAAIAAYajAAAABAAAAAEAAAAGAAAAJAAAAAEAAAAAAAAAAQAA AAEAAAAQHmLy6wAAAACXVvZMBgAAAAAAAAYAAAAlYCMGCSqGSIb3EgECAgEBAAD/////1v2n BqOt12pYdEUNOwOaiwAAAAAAAAAAAAAAAAAAAwAAABYAAAAc2iXhTMNq4ogMAAAAANhwADul ov0AAAAAAAAAAAAAAAMAAAAfAAAACQAAAAIAEAEaADCiOtNk9ky0ZwsANgAAADYAAAAAHMBx FeEAGdGUbXcIAEUAACgHaEAAQAZ61AogUjUKIFIfCAGIDbVuTrIBXaTWUBH//7zcAADTZPZM vWcLAO4AAADuAAAAABnRlG13ABzAcRXhCABFAADgpfZAAEAG240KIFIfCiBSNQK1CAEANYoq aQ2tzlAYMkC3nAAAgAAAtC4UYRoAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAYAAAAkAAAAAQAA AAAAAAACAAAAAQAAABAeYvLrAAAAAJdW9kwGAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEA AP////8pUxfp5nSfU9CXZRcGWXZpAAAAAAAAAAAAAAAAAAACAAAAFgAAABzaJeFMw2riiAwA AAAA2HAAO6Wi/QAAAAAAAAAAAAAACQAAAAIA4AAAAAAcANNk9kzIZwsANgAAADYAAAAAHMBx FeEAGdGUbXcIAEUAACgHaUAAQAZ60wogUjUKIFIfCAECtWkNrc4ANYriUBD//0qXAADTZPZM G2gLADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAoAABAAEAGgjwKIFIfCiBSNYgNCAEBXaTW tW5Os1AQGSCjvAAAAAAAAAAA02T2TDBoCwBWAQAAVgEAAAAcwHEV4QAZ0ZRtdwgARQABSAdq QABABnmyCiBSNQogUh8IAQK1aQ2tzgA1iuJQGP//socAAIAAARwtFGEaAAAAAQAAAAAAAAAG AAAAJWAjBgkqhkiG9xIBAgIBAQAA/////5FSQvtSpHZd5xIdzhRTkZMAAAAAAAAAAAAAAAAA AAAAAAADAAAAFgAAAAAAAAADAAAAAAAAAB8AAAADAAAACQAAAAAAAAACABABGgAwojoAAACg AAAAAgAAAAAAAAAFAAAAAAAAAgAAAAAATOEl2gAAAACI4mrDAAAAAABw2AAAAAHtAAAAAgAA ABdyb290QGthcmxvdi5tZmYuY3VuaS5jegAAAAAYd2hlZWxAa2FybG92Lm1mZi5jdW5pLmN6 AAAArwHCAGgAAAAAAAAIAAAAAABM9l4gAAAAAAAAAABM4opsAAAAAAAAAABM4opsAAAAANNk 9kxLaAsA1gAAANYAAAAAHMBxFeEAGdGUbXcIAEUAAMgHa0AAQAZ6MQogUjUKIFIfCAECtWkN ru4ANYriUBj//+hYAACAAACcLhRhGgAAAAEAAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEA AP/////qxkOIEawWFrH/qejDOp+LAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAAAAAACQAA AAAAAAACAOAAAAAAHAAAAAAwAAAAAACBDkAAAAAAAIEOQAAAAAAAhVP+AAAADtxpqAAAAAAO 3GmoAAAAABAb4ggA02T2TKhoCwA8AAAAPAAAAAAZ0ZRtdwAcwHEV4QgARQAAKKX3QABABtxE CiBSHwogUjUCtQgBADWK4mkNru5QEDZwEwcAAAAAAAAAANNk9ky2aAsAPAAAADwAAAAAGdGU bXcAHMBxFeEIAEUAACil+EAAQAbcQwogUh8KIFI1ArUIAQA1iuJpDa+OUBA6oA43AAAAAAAA AADTZPZMvmgLAAIBAAACAQAAABnRlG13ABzAcRXhCABFAAD0pflAAEAG23YKIFIfCiBSNQK1 CAEANYriaQ2vjlAYOqDQMwAAgAAAyC8UYRoAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAYAAAAk AAAAAQAAAAAAAAADAAAAAQAAABAeYvLrAAAAAJdW9kwGAAAAAAAABgAAACVgIwYJKoZIhvcS AQICAQEAAP////+k+UtNy5DqMT23YL2JIiAWAAAAAAAAAAAAAAAAAAAEAAAAFgAAABzaJeFM w2riiAwAAAAA2HAAO6Wi/QAAAAAAAAAAAAAADwAAAAYuVHJhc2gAAAAAAAoAAAAJAAAAAgAQ ARoAMKI602T2TAxpCwCWAAAAlgAAAAAcwHEV4QAZ0ZRtdwgARQAAiAdsQABABnpwCiBSNQog Uh8IAQK1aQ2vjgA1i65QGP//YlgAAIAAAFwvFGEaAAAAAQAAAAAAAAAGAAAAJWAjBgkqhkiG 9xIBAgIBAQAA//////mKHGZ6qxoMLbhnbq+8KnQAAAAAAAAAAAAAAgAAAAAAAAACAAAAFgAA AAAAAAAPAAAAAtNk9kxBagsABgEAAAYBAAAAGdGUbXcAHMBxFeEIAEUAAPil+kAAQAbbcQog Uh8KIFI1ArUIAQA1i65pDa/uUBg6oIQHAACAAADMMBRhGgAAAAAAAAACAAGGowAAAAQAAAAB AAAABgAAACQAAAABAAAAAAAAAAQAAAABAAAAEB5i8usAAAAAl1b2TAYAAAAAAAAGAAAAJWAj BgkqhkiG9xIBAgIBAQAA/////zyv50XaCudKXPmcxlaUE9IAAAAAAAAAAAAAAAAAAAQAAAAW AAAAHNol4UzDauKIDAAAAADYcAA7paL9AAAAAAAAAAAAAAAPAAAADC5UcmFzaC0yMTExMgAA AAoAAAAJAAAAAgAQARoAMKI602T2TIhqCwCWAAAAlgAAAAAcwHEV4QAZ0ZRtdwgARQAAiAdt QABABnpvCiBSNQogUh8IAQK1aQ2v7gA1jH5QGP//Aa8AAIAAAFwwFGEaAAAAAQAAAAAAAAAG AAAAJWAjBgkqhkiG9xIBAgIBAQAA/////wblVmswOd7OxB+j2FF9bZAAAAAAAAAAAAAAAgAA AAAAAAACAAAAFgAAAAAAAAAPAAAAAtNk9kxS8QsAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUA ACil+0AAQAbcQAogUh8KIFI1ArUIAQA1jH5pDbBOUBA6oAvbAAAAAAAAAADtZPZMnUgJAAYB AAAGAQAAABnRlG13ABzAcRXhCABFAAD4pfxAAEAG228KIFIfCiBSNQK1CAEANYx+aQ2wTlAY OqCY7wAAgAAAzDEUYRoAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAYAAAAkAAAAAQAAAAAAAAAF AAAAAQAAABAeYvLrAAAAAJdW9kwGAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEAAP////8h L2+vwBAbIykxmUtnSvCnAAAAAAAAAAAAAAAAAAACAAAAFgAAABzaJeFMw2riiAwAAAAA2HAA O6Wi/QAAAAAAAAAAAAAAGgAAAAAAAAAAAAAAAAAAAAAAAAfYAAAPsAAAAAIAAAgAAIAAAO1k 9kwxSQkACgEAAAoBAAAAHMBxFeEAGdGUbXcIAEUAAPwHb0AAQAZ5+QogUjUKIFIfCAECtWkN sE4ANY1OUBj//7PBAACAAADQMRRhGgAAAAEAAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEA AP////+4qoOVDkd8LjqMsIO+GZzXAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAAAAAAGgAA AAAAAAAAAAAABQAAAAEAAAAAAAAAKAAAAAZzb3Vib3IAAAAAAAIAAAgAAIAAAAAAAAwAAAAA AAAAAABw2AEAAAABAAAAAAAAAgAAAAAEaG9tZQAAAAIAAAgAAIAAAAAAAAwAAAAAAAAAAABw 2AMAAAAAAAAAAe1k9kyoSQkAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACil/UAAQAbcPgog Uh8KIFI1ArUIAQA1jU5pDbEiUBA+0AYHAAAAAAAAAAD7ZPZMaV4AAPYAAAD2AAAAABnRlG13 ABzAcRXhCABFAADopf5AAEAG230KIFIfCiBSNQK1CAEANY1OaQ2xIlAYPtBGwQAAgAAAvDIU YRoAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAYAAAAkAAAAAQAAAAAAAAAGAAAAAQAAABAeYvLr AAAAAJdW9kwGAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEAAP////9QASGgaRTygepuI181 w1CAAAAAAAAAAAAAAAAAAAADAAAAFgAAABzaJeFMw2riiAwAAAAA2HAAO6Wi/QAAAAAAAAAA AAAAAwAAAB8AAAAJAAAAAgAQARoAMKI6+2T2TPZeAABWAQAAVgEAAAAcwHEV4QAZ0ZRtdwgA RQABSAdyQABABnmqCiBSNQogUh8IAQK1aQ2xIgA1jg5QGP//mAoAAIAAARwyFGEaAAAAAQAA AAAAAAAGAAAAJWAjBgkqhkiG9xIBAgIBAQAA/////15v/l5AF0fLPUWtZ3xtLFQAAAAAAAAA AAAAAAAAAAAAAAADAAAAFgAAAAAAAAADAAAAAAAAAB8AAAADAAAACQAAAAAAAAACABABGgAw ojoAAACgAAAAAgAAAAAAAAAFAAAAAAAAAgAAAAAATOEl2gAAAACI4mrDAAAAAABw2AAAAAHt AAAAAgAAABdyb290QGthcmxvdi5tZmYuY3VuaS5jegAAAAAYd2hlZWxAa2FybG92Lm1mZi5j dW5pLmN6AAAArwHCAGgAAAAAAAAIAAAAAABM9mTtAAAAAAAAAABM4opsAAAAAAAAAABM4ops AAAAAPtk9kxsXwAAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACil/0AAQAbcPAogUh8KIFI1 ArUIAQA1jg5pDbJCUBBDAP/2AAAAAAAAAAD7ZPZMVGYAADwAAAA8AAAAABnRlG13ABzAcRXh CABFAAAs2eNAAEAGqFQKIFIfCiBSNbGeCAElie/jAAAAAGACFtD5tQAAAgQFtAAA+2T2TIJm AAA6AAAAOgAAAAAcwHEV4QAZ0ZRtdwgARQAALAdzQABABnrFCiBSNQogUh8IAbGeiJvpZyWJ 7+RgEv//nnEAAAIEBbT7ZPZM/WYAADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAo2eRAAEAG qFcKIFIfCiBSNbGeCAElie/kiJvpaFAQFtCfXgAAAAAAAAAA+2T2TPZvAAC+AgAAvgIAAAAZ 0ZRtdwAcwHEV4QgARQACsNnlQABABqXOCiBSHwogUjWxnggBJYnv5Iib6WhQGBbQOEYAAIAA AoRM8/HqAAAAAAAAAAIAAYajAAAABAAAAAAAAAAGAAAAFAAAAAEAAAABAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAJBYIICPQYJKoZIhvcSAQICAQBuggIsMIICKKADAgEFoQMCAQ6iBwMFACAA AACjggFQYYIBTDCCAUigAwIBBaENGwtNRkYuQ1VOSS5DWqIqMCigAwIBA6EhMB8bA25mcxsY bXMyLXIua2FybG92Lm1mZi5jdW5pLmN6o4IBBDCCAQCgAwIBAaEDAgEBooHzBIHwDAIsvz7a uKPHYQRXv9UvRxen4AfSgAahtkveYo9J9Lcs02wkvtB/ZjoUpDOIqRZvWAy818FFF1UcZd9e JZ1OGUdd4ZbSBUzJAg9j6nxrToHARLWecCWsup6ApDOLbNCZYOgP4jezqWJSH63mjv/qtj9/ p7YokYR9PgfXdkAkbpRaEBWt4k1N0195EI0SF1LTA+LfXKx1qoZs5dRrcxaNrJuegJ2MN+hR IqfaC6YnmRfhopKzCZoqr5nQuAn3JqFy4LWyejFdy6s20ntbOANpYDh3EATdmg0iLYPB0i9X KbpQ4BftPrueo7P7nK+W6bkBpIG+MIG7oAMCAQGigbMEgbCWTlUvrXmGLUiBTbXUosYp75rn IeFOasWMtibNwRKxW9SIhVl1+FotNeU3EuDVhFczTL2DcSwzGxG02XI8/aZsTTCmVheZ6CGY fx/UjnnjwjdSZYQKgfVsvfP3LjLqonfnbwjvdispn1kxoWlUmdg5HOkB3eR8ujhNiYP3izpt oZhsKdLw/c7ZVU09TiANxpvnQoB7P9r0j8Ok12brBbIZZXpRZoJ/QRZKKx3xO89yewAAAPtk 9kx7cgAAAgEAAAIBAAAAHMBxFeEAGdGUbXcIAEUAAPQHdEAAQAZ5/AogUjUKIFIfCAGxnoib 6WglifJsUBj//6nXAACAAADITPPx6gAAAAEAAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEA AP////+unlMSI7Q4rBrzEyl8PdiRAAAAAAAAAAAAABAeYvLrAAAAAJdW9kwHAAAAAAAAAAAA AAAAAACAAAAAYmBgBgkqhkiG9xIBAgICAG9RME+gAwIBBaEDAgEPokMwQaADAgEBojoEOEEc 6kWzTmh3Rm99IYflqTbWfe/p1XqRafGSXx1VR1o4jpt8Z3CuMoIMlLfRI+wrDWYpnYaYOq+F AAD7ZPZM9XIAADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAo2eZAAEAGqFUKIFIfCiBSNbGe CAElifJsiJvqNFAQGSCZugAAAAAAAAAA+2T2TEZ8AAA8AAAAPAAAAAAZ0ZRtdwAcwHEV4QgA RQAAKNnnQABABqhUCiBSHwogUjWxnggBJYnybIib6jRQERkgmbkAAAAAAAAAAPtk9kxdfAAA NgAAADYAAAAAHMBxFeEAGdGUbXcIAEUAACgHdUAAQAZ6xwogUjUKIFIfCAGxnoib6jQlifJt UBD//7LZAAD7ZPZMYHwAABoBAAAaAQAAABnRlG13ABzAcRXhCABFAAEMpgBAAEAG21cKIFIf CiBSNQK1CAEANY4OaQ2yQlAYQwBL8gAAgAAA4DMUYRoAAAAAAAAAAgABhqMAAAAEAAAAAQAA AAYAAAAkAAAAAQAAAAAAAAABAAAAAQAAABAeYvLrAAAAAJdW9kwHAAAAAAAABgAAACVgIwYJ KoZIhvcSAQICAQEAAP////8wXXGsbvAQgKc+LFi3lg4uAAAAAAAAAAAAAAAAAAABAAAAI0z2 ZNIqVuvlAAAAKDEwLjMyLjgyLjMxLzEwLjMyLjgyLjUzIHRjcCBSUENTRUNfR1NTIDBAAAAA AAAAA3RjcAAAAAATMTAuMzIuODIuMzEuMjIxLjI1NQAAAAAA+2T2TG58AAA2AAAANgAAAAAc wHEV4QAZ0ZRtdwgARQAAKAd2QABABnrGCiBSNQogUh8IAbGeiJvqNCWJ8m1QEf//stgAAPtk 9kzafAAAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACgAAEAAQAaCPAogUh8KIFI1sZ4IASWJ 8m2Im+o1UBAZIJm4AAAAAAAAAAD7ZPZM5HwAAJ4AAACeAAAAABzAcRXhABnRlG13CABFAACQ B3dAAEAGel0KIFI1CiBSHwgBArVpDbJCADWO8lAY///nOwAAgAAAZDMUYRoAAAABAAAAAAAA AAYAAAAlYCMGCSqGSIb3EgECAgEBAAD/////zTRkmRI0p2CekJFQAi10XQAAAAAAAAAAAAAA AAAAAAAAAAEAAAAjAAAAAKZW9kwDAAAAAwAAAAAAAAD7ZPZMX30AAOIAAADiAAAAABnRlG13 ABzAcRXhCABFAADUpgFAAEAG244KIFIfCiBSNQK1CAEANY7yaQ2yqlAYQwD6LwAAgAAAqDQU YRoAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAYAAAAkAAAAAQAAAAAAAAACAAAAAQAAABAeYvLr AAAAAJdW9kwHAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEAAP/////8ZNBmoNir6GXWjFj/ KqJeAAAAAAAAAAAAAAAAAAADAAAAJKZW9kwDAAAAAwAAAAAAAAAAAAAYAAAACQAAAAIAAAQA AAAAAPtk9kyyfQAArgAAAK4AAAAAHMBxFeEAGdGUbXcIAEUAAKAHeEAAQAZ6TAogUjUKIFIf CAECtWkNsqoANY+eUBj//zxGAACAAAB0NBRhGgAAAAEAAAAAAAAABgAAACVgIwYJKoZIhvcS AQICAQEAAP////+Hri43xj/PqK+f4Tbrw42sAAAAAAAAAAAAAAAAAAAAAAAAAwAAACQAAAAA AAAAGAAAAAAAAAAJAAAAAAAAAAEAAAQAAAAABAAAAHj7ZPZMKH4AAEoBAABKAQAAABnRlG13 ABzAcRXhCABFAAE8pgJAAEAG2yUKIFIfCiBSNQK1CAEANY+eaQ2zIlAYQwA4tgAAgAABEDUU YRoAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAYAAAAkAAAAAQAAAAAAAAAHAAAAAQAAABAeYvLr AAAAAJdW9kwGAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEAAP////+sKzfkU6J0lNeq8QY8 hepBAAAAAAAAAAAAAAAAAAAHAAAAFgAAABzaJeFMw2riiAwAAAAA2HAAO6Wi/QAAAAAAAAAA AAAAIAAAABIAAAAAAAAAAQAAAACmVvZMAwAAAAAAABBvcGVuIGlkOlv3nFdThUp1AAAAAAAA AAAAAAAGc291Ym9yAAAAAAAKAAAACQAAAAIAEAEaADCiOgAAAB8AAAAJAAAAAgAQARoAMKI6 +2T2TKB+AABKAAAASgAAAAAcwHEV4QAZ0ZRtdwgARQAAPAd5QABABnqvCiBSNQogUh9l1t3/ pbA5OAAAAACgAv//orgAAAIEBbQBAwMDBAIICgA1ycMAAAAA+2T2TF4VAgA2AAAANgAAAAAc wHEV4QAZ0ZRtdwgARQAAKAd6QABABnrCCiBSNQogUh8IAQK1aQ2zIgA1kLJQEP//P3MAAP5k 9kxniQIASgAAAEoAAAAAHMBxFeEAGdGUbXcIAEUAADwHfkAAQAZ6qgogUjUKIFIfZdbd/6Ww OTgAAAAAoAL//5cAAAACBAW0AQMDAwQCCAoANdV7AAAAAABl9kyfnQIAPAAAADwAAAAAGdGU bXcAHMBxFeEIAEUAACwdiUAAQAZkrwogUh8KIFI1AycIAbYNJYoAAAAAYAIW0OICAAACBAW0 AAAAZfZMyp0CADoAAAA6AAAAABzAcRXhABnRlG13CABFAAAsB39AAEAGerkKIFI1CiBSHwgB AyfZ3VHqtg0li2AS///M+QAAAgQFtABl9kxFngIAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUA ACgdikAAQAZksgogUh8KIFI1AycIAbYNJYvZ3VHrUBAW0M3mAAAAAAAAAAAAZfZMZp4CADwA AAA8AAAAABnRlG13ABzAcRXhCABFAAAoHYtAAEAGZLEKIFIfCiBSNQMnCAG2DSWL2d1R61AR FtDN5QAAAAAAAAAAAGX2THqeAgA2AAAANgAAAAAcwHEV4QAZ0ZRtdwgARQAAKAeAQABABnq8 CiBSNQogUh8IAQMn2d1R67YNJYxQEP//5LUAAABl9kyangIANgAAADYAAAAAHMBxFeEAGdGU bXcIAEUAACgHgUAAQAZ6uwogUjUKIFIfCAEDJ9ndUeu2DSWMUBH//+S0AAAAZfZM9Z4CADwA AAA8AAAAABnRlG13ABzAcRXhCABFAAAoHYxAAEAGZLAKIFIfCiBSNQMnCAG2DSWM2d1R7FAQ FtDN5AAAAAAAAAAAAWX2TK7FBwBKAAAASgAAAAAcwHEV4QAZ0ZRtdwgARQAAPAeCQABABnqm CiBSNQogUh9l1t3/pbA5OAAAAACgAv//ioAAAAIEBbQBAwMDBAIICgA14fsAAAAABGX2TPYB DQA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAeDQABABnqxCiBSNQogUh9l1t3/pbA5OAAA AABwAv//qM0AAAIEBbQEAgAACGX2TP77AgA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAeE QABABnqwCiBSNQogUh9l1t3/pbA5OAAAAABwAv//qM0AAAIEBbQEAgAAC2X2TEo4CAA+AAAA PgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAeFQABABnqvCiBSNQogUh9l1t3/pbA5OAAAAABwAv// qM0AAAIEBbQEAgAAEGX2TIwGBQDuAAAA7gAAAAAZ0ZRtdwAcwHEV4QgARQAA4KYDQABABtuA CiBSHwogUjUCtQgBADWQsmkNsyJQGEMARFQAAIAAALQ2FGEaAAAAAAAAAAIAAYajAAAABAAA AAEAAAAGAAAAJAAAAAEAAAAAAAAACAAAAAEAAAAQHmLy6wAAAACXVvZMBgAAAAAAAAYAAAAl YCMGCSqGSIb3EgECAgEBAAD/////r6lfVdqOiIgXUljXHfYfjwAAAAAAAAAAAAAAAAAAAgAA ABYAAAAc2iXhTMNq4ogMAAAAANhwADulov0AAAAAAAAAAAAAAAkAAAACAOAAAAAAHAAQZfZM CQcFANYAAADWAAAAABzAcRXhABnRlG13CABFAADIB4ZAAEAGehYKIFI1CiBSHwgBArVpDbMi ADWRalAY//93QAAAgAAAnDYUYRoAAAABAAAAAAAAAAYAAAAlYCMGCSqGSIb3EgECAgEBAAD/ ////p4vfXytoq2j4d0v148TrLwAAAAAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAAAAAAAkAAAAA AAAAAgDgAAAAABwAAAAAMAAAAAAAgQ5AAAAAAACBDkAAAAAAAIVT/gAAAA7caagAAAAADtxp qAAAAAAQG+IIABBl9ky+gwUAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACimBEAAQAbcNwog Uh8KIFI1ArUIAQA1kWppDbPCUBBHMPbqAAAAAAAAAAASZfZMZD0AAD4AAAA+AAAAABzAcRXh ABnRlG13CABFAAAwB6RAAEAGepAKIFI1CiBSH2XW3f+lsDk4AAAAAHAC//+ozQAAAgQFtAQC AAAeZfZM9ZELAD4AAAA+AAAAABzAcRXhABnRlG13CABFAAAwB71AAEAGencKIFI1CiBSH2XW 3f+lsDk4AAAAAHAC//+ozQAAAgQFtAQCAAA3ZfZMW38AADwAAAA8AAAAABnRlG13ABzAcRXh CABFAAAopgVAAEAG3DYKIFIfCiBSNQK1CAEANZFqaQ2zwlARRzD26QAAAAAAAAAAN2X2THp/ AAA2AAAANgAAAAAcwHEV4QAZ0ZRtdwgARQAAKAhOQABABnnuCiBSNQogUh8IAQK1aQ2zwgA1 kWtQEP//PhoAADhl9kxegQAAPgAAAD4AAAAAHMBxFeEAGdGUbXcIAEUAADAIT0AAQAZ55Qog UjUKIFIfZdbd/6WwOTgAAAAAcAL//6jNAAACBAW0BAIAADxl9ky9nQIAPAAAADwAAAAAGdGU bXcAHMBxFeEIAEUAACxq/kAAQAYXOgogUh8KIFI1AycIAbYOJY0AAAAAYAIW0OH+AAACBAW0 AAA8ZfZM750CADoAAAA6AAAAABzAcRXhABnRlG13CABFAAAsCFdAAEAGeeEKIFI1CiBSHwgB Ayc7Mf7vtg4ljmAS//++nAAAAgQFtDxl9kxrngIAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUA AChq/0AAQAYXPQogUh8KIFI1AycIAbYOJY47Mf7wUBAW0L+JAAAAAAAAAAA8ZfZMkJ4CADwA AAA8AAAAABnRlG13ABzAcRXhCABFAAAoawBAAEAGFzwKIFIfCiBSNQMnCAG2DiWOOzH+8FAR FtC/iAAAAAAAAAAAPGX2TKWeAgA2AAAANgAAAAAcwHEV4QAZ0ZRtdwgARQAAKAhYQABABnnk CiBSNQogUh8IAQMnOzH+8LYOJY9QEP//1lgAADxl9kzMngIANgAAADYAAAAAHMBxFeEAGdGU bXcIAEUAACgIWUAAQAZ54wogUjUKIFIfCAEDJzsx/vC2DiWPUBH//9ZXAAA8ZfZMIJ8CADwA AAA8AAAAABnRlG13ABzAcRXhCABFAAAoawFAAEAGFzsKIFIfCiBSNQMnCAG2DiWPOzH+8VAQ FtC/hwAAAAAAAAAARmX2TKt/AAA8AAAAPAAAAAAZ0ZRtdwAcwHEV4QgARQAAKKYGQABABtw1 CiBSHwogUjUCtQgBADWRa2kNs8JQFEcw9uUAAAAAAAAAAEll9kyxfwAAPAAAADwAAAAAGdGU bXcAHMBxFeEIAEUAACzFFUAAQAa9IgogUh8KIFI1ArUIAQA2kWwAAAAAYAIW0CxqAAACBAW0 AABJZfZM8n8AADoAAAA6AAAAABzAcRXhABnRlG13CABFAAAsCFpAAEAGed4KIFI1CiBSHwgB ArXJH5bmADaRbWAS///jIgAAAgQFtEll9kxsgAAAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUA ACjFFkAAQAa9JQogUh8KIFI1ArUIAQA2kW3JH5bnUBAW0OQPAAAAAAAAAABJZfZMi4AAADwA AAA8AAAAABnRlG13ABzAcRXhCABFAAAoxRdAAEAGvSQKIFIfCiBSNQK1CAEANpFtyR+W51AR FtDkDgAAAAAAAAAASWX2TKeAAAA2AAAANgAAAAAcwHEV4QAZ0ZRtdwgARQAAKAhbQABABnnh CiBSNQogUh8IAQK1yR+W5wA2kW5QEP//+t4AAEll9kzAgAAANgAAADYAAAAAHMBxFeEAGdGU bXcIAEUAACgIXEAAQAZ54AogUjUKIFIfCAECtckflucANpFuUBH///rdAABJZfZMI4EAADwA AAA8AAAAABnRlG13ABzAcRXhCABFAAAoxRhAAEAGvSMKIFIfCiBSNQK1CAEANpFuyR+W6FAQ FtDkDQAAAAAAAAAASmX2TFxoBgBKAAAASgAAAAAcwHEV4QAZ0ZRtdwgARQAAPAhdQABABnnL CiBSNQogUh9U3t3/NlonPAAAAACgAv//DCIAAAIEBbQBAwMDBAIICgA28qMAAAAATWX2TNVz CABKAAAASgAAAAAcwHEV4QAZ0ZRtdwgARQAAPAheQABABnnKCiBSNQogUh9U3t3/NlonPAAA AACgAv//AGoAAAIEBbQBAwMDBAIICgA2/lsAAAAAUGX2TA6wDQBKAAAASgAAAAAcwHEV4QAZ 0ZRtdwgARQAAPAhfQABABnnJCiBSNQogUh9U3t3/NlonPAAAAACgAv//8+kAAAIEBbQBAwMD BAIICgA3CtsAAAAAVGX2TBWqAwA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAhhQABABnnT CiBSNQogUh9U3t3/NlonPAAAAABwAv//OxgAAAIEBbQEAgAAV2X2TF3mCAA+AAAAPgAAAAAc wHEV4QAZ0ZRtdwgARQAAMAhiQABABnnSCiBSNQogUh9U3t3/NlonPAAAAABwAv//OxgAAAIE BbQEAgAAWmX2TGgiDgA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAhjQABABnnRCiBSNQog Uh9U3t3/NlonPAAAAABwAv//OxgAAAIEBbQEAgAAYWX2THAoBgA+AAAAPgAAAAAcwHEV4QAZ 0ZRtdwgARQAAMAhkQABABnnQCiBSNQogUh9U3t3/NlonPAAAAABwAv//OxgAAAIEBbQEAgAA a2X2THAOBAA8AAAAPAAAAAAZ0ZRtdwAcwHEV4QgARQAALKKAQABABt+3CiBSHwogUjUCtAgB jcjDWAAAAABgAhbQbOwAAAIEBbQAAGtl9kykDgQAOgAAADoAAAAAHMBxFeEAGdGUbXcIAEUA ACwIZUAAQAZ50wogUjUKIFIfCAECtD7GRGmNyMNZYBL//wB8AAACBAW0a2X2TB8PBAA8AAAA PAAAAAAZ0ZRtdwAcwHEV4QgARQAAKKKBQABABt+6CiBSHwogUjUCtAgBjcjDWT7GRGpQEBbQ AWkAAAAAAAAAAGtl9kysEQQArgAAAK4AAAAAGdGUbXcAHMBxFeEIAEUAAKCigkAAQAbfQQog Uh8KIFI1ArQIAY3Iw1k+xkRqUBgW0PKjAACAAAB0OBRhGgAAAAAAAAACAAGGowAAAAQAAAAA AAAABgAAACQAAAABAAAAAwAAAAMAAAABAAAAEB5i8usAAAAAl1b2TAcAAAAAAAAGAAAAJWAj BgkqhkiG9xIBAgIBAQAA/////0xe1Jay3MuZiT/BXh91QHQAAABrZfZMuhEEAK4AAACuAAAA ABnRlG13ABzAcRXhCABFAACgooNAAEAG30AKIFIfCiBSNQK0CAGNyMPRPsZEalAYFtBCFQAA gAAAdDkUYRoAAAAAAAAAAgABhqMAAAAEAAAAAAAAAAYAAAAkAAAAAQAAAAMAAAAJAAAAAQAA ABAeYvLrAAAAAJdW9kwFAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEAAP////+JZSIKNZ8L ZcB6CpUcU4bNAAAAa2X2TMoRBAA2AAAANgAAAAAcwHEV4QAZ0ZRtdwgARQAAKAhmQABABnnW CiBSNQogUh8IAQK0PsZEao3IxElQEP//F0kAAGtl9kzYEQQArgAAAK4AAAAAGdGUbXcAHMBx FeEIAEUAAKCihEAAQAbfPwogUh8KIFI1ArQIAY3IxEk+xkRqUBgW0GreAACAAAB0OhRhGgAA AAAAAAACAAGGowAAAAQAAAAAAAAABgAAACQAAAABAAAAAwA5L7MAAAABAAAAEB5i8usAAAAA l1b2TAYAAAAAAAAGAAAAJWAjBgkqhkiG9xIBAgIBAQAA/////ylPLq+c7sdS7UNxKZG8id8A AABrZfZMDRIEAHoAAAB6AAAAABzAcRXhABnRlG13CABFAABsCGdAAEAGeZEKIFI1CiBSHwgB ArQ+xkRqjcjEwVAY//+sowAAgAAAQDgUYRoAAAABAAAAAAAAAAYAAAAlYCMGCSqGSIb3EgEC AgEBAAD/////DrAsJ410qzOMmnRT1B6u7wAAAAAAAABrZfZMMhIEAHoAAAB6AAAAABzAcRXh ABnRlG13CABFAABsCGhAAEAGeZAKIFI1CiBSHwgBArQ+xkSujcjEwVAY//8ByQAAgAAAQDkU YRoAAAABAAAAAAAAAAYAAAAlYCMGCSqGSIb3EgECAgEBAAD/////3AfEWjB4od1uUH+YJXAI FAAAAAAAAABrZfZMzBIEADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAoooVAAEAG37YKIFIf CiBSNQK0CAGNyMTBPsZErlAQFtD/vAAAAAAAAAAAa2X2TNUSBAA8AAAAPAAAAAAZ0ZRtdwAc wHEV4QgARQAAKKKGQABABt+1CiBSHwogUjUCtAgBjcjEwT7GRPJQEBbQ/3gAAAAAAAAAAGtl 9kxXEwQAegAAAHoAAAAAHMBxFeEAGdGUbXcIAEUAAGwIaUAAQAZ5jwogUjUKIFIfCAECtD7G RPKNyMTBUBj//+XiAACAAABAOhRhGgAAAAEAAAAAAAAABgAAACVgIwYJKoZIhvcSAQICAQEA AP////9+wPibYFsQ/6zHeoWF4ZpaAAAAAAAAAGtl9kzOEwQAPAAAADwAAAAAGdGUbXcAHMBx FeEIAEUAACiih0AAQAbftAogUh8KIFI1ArQIAY3IxME+xkU2UBAW0P80AAAAAAAAAABrZfZM TBoEADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAooohAAEAG37MKIFIfCiBSNQK0CAGNyMTB PsZFNlARFtD/MwAAAAAAAAAAa2X2TGEaBAA2AAAANgAAAAAcwHEV4QAZ0ZRtdwgARQAAKAhq QABABnnSCiBSNQogUh8IAQK0PsZFNo3IxMJQEP//FgQAAGtl9kxwGgQANgAAADYAAAAAHMBx FeEAGdGUbXcIAEUAACgIa0AAQAZ50QogUjUKIFIfCAECtD7GRTaNyMTCUBH//xYDAABrZfZM 3BoEADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAoAABAAEAGgjwKIFIfCiBSNQK0CAGNyMTC PsZFN1AQFtD/MgAAAAAAAAAAbmX2TKZGAgA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAhs QABABnnICiBSNQogUh9U3t3/NlonPAAAAABwAv//OxgAAAIEBbQEAgAAeGX2TGaiAgA8AAAA PAAAAAAZ0ZRtdwAcwHEV4QgARQAALENzQABABj7FCiBSHwogUjUDJwgBtg8lkAAAAABgAhbQ 4foAAAIEBbQAAHhl9kyYogIAOgAAADoAAAAAHMBxFeEAGdGUbXcIAEUAACwIckAAQAZ5xgog UjUKIFIfCAEDJwP8lmC2DyWRYBL//15dAAACBAW0eGX2TBSjAgA8AAAAPAAAAAAZ0ZRtdwAc wHEV4QgARQAAKEN0QABABj7ICiBSHwogUjUDJwgBtg8lkQP8lmFQEBbQX0oAAAAAAAAAAHhl 9kw3owIAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAAChDdUAAQAY+xwogUh8KIFI1AycIAbYP JZED/JZhUBEW0F9JAAAAAAAAAAB4ZfZMS6MCADYAAAA2AAAAABzAcRXhABnRlG13CABFAAAo CHNAAEAGeckKIFI1CiBSHwgBAycD/JZhtg8lklAQ//92GQAAeGX2TGqjAgA2AAAANgAAAAAc wHEV4QAZ0ZRtdwgARQAAKAh0QABABnnICiBSNQogUh8IAQMnA/yWYbYPJZJQEf//dhgAAHhl 9kzBowIAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAAChDdkAAQAY+xgogUh8KIFI1AycIAbYP JZID/JZiUBAW0F9IAAAAAAAAAACHZfZMk5IGAD4AAAA+AAAAABzAcRXhABnRlG13CABFAAAw CHVAAEAGeb8KIFI1CiBSH1Te3f82Wic8AAAAAHAC//87GAAAAgQFtAQCAACZZfZM4noMAEoA AABKAAAAABzAcRXhABnRlG13CABFAAA8CHhAAEAGebAKIFI1CiBSH4TC3f+JoCXSAAAAAKAC //9hgAAAAgQFtAEDAwMEAggKADgbgwAAAACcZfZMyIYOAEoAAABKAAAAABzAcRXhABnRlG13 CABFAAA8CHlAAEAGea8KIFI1CiBSH4TC3f+JoCXSAAAAAKAC//9VyAAAAgQFtAEDAwMEAggK ADgnOwAAAACgZfZMwoAEAEoAAABKAAAAABzAcRXhABnRlG13CABFAAA8CHpAAEAGea4KIFI1 CiBSH4TC3f+JoCXSAAAAAKAC//9JSAAAAgQFtAEDAwMEAggKADgzuwAAAACjZfZMDL0JAD4A AAA+AAAAABzAcRXhABnRlG13CABFAAAwCHtAAEAGebkKIFI1CiBSH4TC3f+JoCXSAAAAAHAC //+5VwAAAgQFtAQCAACmZfZMR/kOAD4AAAA+AAAAABzAcRXhABnRlG13CABFAAAwCHxAAEAG ebgKIFI1CiBSH4TC3f+JoCXSAAAAAHAC//+5VwAAAgQFtAQCAACqZfZMS/MEAD4AAAA+AAAA ABzAcRXhABnRlG13CABFAAAwCH1AAEAGebcKIFI1CiBSH4TC3f+JoCXSAAAAAHAC//+5VwAA AgQFtAQCAACwZfZMsDsMAD4AAAA+AAAAABzAcRXhABnRlG13CABFAAAwCIJAAEAGebIKIFI1 CiBSH4TC3f+JoCXSAAAAAHAC//+5VwAAAgQFtAQCAAC0ZfZMaqICADwAAAA8AAAAABnRlG13 ABzAcRXhCABFAAAsW8BAAEAGJngKIFIfCiBSNQMnCAG2ECWTAAAAAGACFtDh9gAAAgQFtAAA tGX2TJWiAgA6AAAAOgAAAAAcwHEV4QAZ0ZRtdwgARQAALAiDQABABnm1CiBSNQogUh8IAQMn 6rOs57YQJZRgEv//YRoAAAIEBbS0ZfZMEKMCADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAo W8FAAEAGJnsKIFIfCiBSNQMnCAG2ECWU6rOs6FAQFtBiBwAAAAAAAAAAtGX2TDOjAgA8AAAA PAAAAAAZ0ZRtdwAcwHEV4QgARQAAKFvCQABABiZ6CiBSHwogUjUDJwgBthAllOqzrOhQERbQ YgYAAAAAAAAAALRl9kxHowIANgAAADYAAAAAHMBxFeEAGdGUbXcIAEUAACgIhEAAQAZ5uAog UjUKIFIfCAEDJ+qzrOi2ECWVUBD//3jWAAC0ZfZMZ6MCADYAAAA2AAAAABzAcRXhABnRlG13 CABFAAAoCIVAAEAGebcKIFI1CiBSHwgBAyfqs6zothAllVAR//941QAAtGX2TMGjAgA8AAAA PAAAAAAZ0ZRtdwAcwHEV4QgARQAAKFvDQABABiZ5CiBSHwogUjUDJwgBthAlleqzrOlQEBbQ YgUAAAAAAAAAAL1l9kz6WQgAPgAAAD4AAAAAHMBxFeEAGdGUbXcIAEUAADAIh0AAQAZ5rQog UjUKIFIfhMLd/4mgJdIAAAAAcAL//7lXAAACBAW0BAIAANZl9kytqAwAPgAAAD4AAAAAHMBx FeEAGdGUbXcIAEUAADAIiUAAQAZ5qwogUjUKIFIfhMLd/4mgJdIAAAAAcAL//7lXAAACBAW0 BAIAAA== --------------080507000706050401030902-- From owner-freebsd-fs@FreeBSD.ORG Thu Dec 2 12:06:52 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70C3710656A3 for ; Thu, 2 Dec 2010 12:06:52 +0000 (UTC) (envelope-from a.smith@ukgrid.net) Received: from mx0.ukgrid.net (mx0.ukgrid.net [89.21.28.41]) by mx1.freebsd.org (Postfix) with ESMTP id 31F178FC15 for ; Thu, 2 Dec 2010 12:06:51 +0000 (UTC) Received: from [89.21.28.38] (port=46431 helo=omicron.ukgrid.net) by mx0.ukgrid.net with esmtp (Exim 4.72; FreeBSD) envelope-from a.smith@ukgrid.net envelope-to freebsd-fs@freebsd.org id 1PO7bG-000MGr-EI; Thu, 02 Dec 2010 11:45:22 +0000 Received: from voip.ukgrid.net (voip.ukgrid.net [89.107.16.9]) by webmail2.ukgrid.net (Horde Framework) with HTTP; Thu, 02 Dec 2010 11:45:22 +0000 Message-ID: <20101202114522.16601wx7crv5zhz4@webmail2.ukgrid.net> Date: Thu, 02 Dec 2010 11:45:22 +0000 From: a.smith@ukgrid.net To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) / FreeBSD-8.1 Subject: spurious ZFS "dataset does not exist" errors X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 12:06:52 -0000 Hi, I have been setting up a new ZFS pool to which I am replicate via ZFS send/receive a (raw) volume from another pool. After creating the duplicate volume in the new pool and having tested that it works (it does) I exported the ZFS pool and it gives me the following errors: # zpool export nas1bkp cannot open 'nas1bkp/iscsi-cctvp3': dataset does not exist cannot open 'nas1bkp/iscsi-cctvp2': dataset does not exist cannot open 'nas1bkp/iscsi-cctvp1': dataset does not exist Its quite right, those datasets don't exist. But why is it even trying to touch something that doesn't and has never existed. Devices that actually exist are shown here: # zfs list NAME USED AVAIL REFER MOUNTPOINT nas1 3.19T 2.15T 648M /nas1 nas1/cctv 2.53M 2.15T 2.53M /nas1/cctv nas1/iscsi-cctv 3.19T 2.65T 2.65T - nas1/zfssend 28.4K 50.0G 28.4K /nas1/zfssend nas1bkp 3.19T 2.15T 28.4K /nas1bkp nas1bkp/iscsi-cctv 3.19T 2.65T 2.65T - nas1bkp/zfsrecv 26.9K 50.0G 26.9K /nas1bkp/zfsrecv Anyone any idea whats going on? Spurious errors make me nervous! thanks Andy. From owner-freebsd-fs@FreeBSD.ORG Thu Dec 2 15:48:52 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D441065698; Thu, 2 Dec 2010 15:48:52 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id BE2B38FC18; Thu, 2 Dec 2010 15:48:51 +0000 (UTC) Received: by vws9 with SMTP id 9so3254944vws.13 for ; Thu, 02 Dec 2010 07:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=EpB0lTzPJ2WAamRbzSv5IqPh5VNoNOvGiPrF7qG/tF8=; b=Tj/u5IynUoenTQvtmv31dgm046jBGq0/wroXRZRn6CmxvFTL8FHvCdBnZ/jLI8Vvw9 v2C9LGEH7DrVtPYc94zMOD/DF12fGofS4Vu5rpjTP//toBPESKh0ZvzrI49Gsgy97oR+ CUohv4Am4rIU5ICFus+c67SKQ6qam7PUP4TP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=IHB+AYqRMWJ6W3ro3V4cLadD1JbTNb4nyVe7/JWsPKhYE6TyR5frsPtTFgtoNJcfD0 7TjcjQRxCYnyNPZZ+eZBrPmlc7AXDTPg5ngi6Wky04QDIQdIcX3OllNs+1uGSK8ddpeu 6vYLDO7+odQf3bLI9wSQD1/3PGQpyExpMz3vQ= Received: by 10.220.180.4 with SMTP id bs4mr72858vcb.29.1291304930627; Thu, 02 Dec 2010 07:48:50 -0800 (PST) Received: from centel.dataix.local (adsl-99-19-40-65.dsl.klmzmi.sbcglobal.net [99.19.40.65]) by mx.google.com with ESMTPS id e18sm80250vcf.12.2010.12.02.07.48.47 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Dec 2010 07:48:48 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4CF7BFDD.5000500@DataIX.net> Date: Thu, 02 Dec 2010 10:48:45 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Freddie Cash References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems , FreeBSD-Current Subject: Re: Update to zfs command removes Python dep X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 15:48:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2010 19:02, Freddie Cash wrote: > Just a head's up, the Illumos devs have committed an update to zfs > that removes the dependency on Python. Good news. Another heads up for those that might interpret this wrongly. ZFS does not depend on python for normal day to day use. Though if you would like to use the functions listed below you would need to install python as well, ports/sysutils/py-zfs. You should refer to the man page for zfs(1) for further details on these commands. As per UPDATING: (20100915) A new version of ZFS (version 15) has been merged. This version uses a python library for the following subcommands: zfs allow, zfs unallow, zfs groupspace, zfs userspace. For full functionality of these commands the following port must be installed: sysutils/py-zfs > > Blog report here: > http://gdamore.blogspot.com/2010/12/zfs-should-not-depend-on-python-and.html > > This may (or may not) make it easier to import a newer version of ZFS > into -CURRENT. > Regards, - -- jhell,v -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJM97/dAAoJEJBXh4mJ2FR+62EH/2KVyAClgHpp+mQt6J0ywSYl AApeUrZ7+PoVKA35kc7j0Z99ji2MZsLX3g4YgNaYlp9QbxiQLowRkoTvtHcZ13cT 4KWGSpgjHdrFF0geqFRVQ+ny8FSHoKrHTudWECWkNeKaoWTmtNwIhQvpLugvBX4K dCVpzof8LNl5IpgJFp5rjBqwt9js/VLztcnb93Yu0qhBUVb32HhhU5IiPkirZcQl 4N2xbRpCINLlAnO+ZidOaJYVmP9RILym3GibcL2Nk/FXmOCcBLt6dQLhgSUamPiY 5qWgWbaW1hnVDxSeMisS236kzdUzxdUVbjRqpLeE4TMvGXaH+YInZXeuIshgJHQ= =ZGMI -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Thu Dec 2 19:09:57 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81FD81065696 for ; Thu, 2 Dec 2010 19:09:57 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id B03F18FC17 for ; Thu, 2 Dec 2010 19:09:56 +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 oB2IknXX006899; Thu, 2 Dec 2010 10:46:49 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201012021846.oB2IknXX006899@chez.mckusick.com> To: David Rhodus In-reply-to: Date: Thu, 02 Dec 2010 10:46:49 -0800 From: Kirk McKusick Cc: Jeff Roberson , Michael Butler , freebsd-fs@freebsd.org Subject: PR kern/152605 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 19:09:57 -0000 > From: David Rhodus > Date: Thu, 2 Dec 2010 12:33:35 -0500 > Subject: Re: How a full fsck screwed up my SU+J filesystem > To: Michael Butler > Cc: Kirk McKusick , > Kostik Belousov , current@freebsd.org > X-ASK-Info: Message Queued (2010/12/02 09:34:03) > X-ASK-Info: Confirmed by User (2010/12/02 09:35:13) > > Hello, what do you make of this PR report ? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/152605 > > This panic happens during bg-fsck every time. I have to boot into > single user-mode and do a fsck to correct. I have not seen this bug report yet. It would be helpful if you could identify which file is associated with inode 18, e.g., cd find . -x -inum 18 -ls Also, a transcript of the fsck that you run to clean up the mess so that I can see what is broken in the filesystem. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Thu Dec 2 21:53:33 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B27E1106566B for ; Thu, 2 Dec 2010 21:53:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4BA8FC16 for ; Thu, 2 Dec 2010 21:53:33 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAJKj90yDaFvO/2dsb2JhbACDUaBLsmeQWYEhgzNzBIRehgk X-IronPort-AV: E=Sophos;i="4.59,289,1288584000"; d="scan'208";a="102867276" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 02 Dec 2010 16:53:32 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 238BEB3F30; Thu, 2 Dec 2010 16:53:32 -0500 (EST) Date: Thu, 2 Dec 2010 16:53:32 -0500 (EST) From: Rick Macklem To: =?utf-8?Q?Tom=C3=A1=C5=A1_Drbohlav?= Message-ID: <798450027.1098255.1291326812088.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4CF784E8.20609@karlov.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [173.13.57.82] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-fs@freebsd.org Subject: Re: Linux (client) - FreeBSD (server) NFS4 interoperability problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:53:33 -0000 > Hello, > > I am setting up an experimental (kerberized) NFSv4 server on FreeBSD > 8.1-RELEASE-p1 and while between fBSD server and client it seems to > work > more or less ok, while connecting from Linux (Ubuntu), I am not able > to > read any file contents. Walking through dirs is ok, but when clients > asks for a file, it freezes. > > As I noticed in the list, tcpdump may be useful, so I made one, see > attached file. > > Although I am not an nfs expert, when I opened the dump in WireShark > it > seems to me, that server does not respond to packet #83, Compound Call > containing OPEN opcode. That is probably the thing which disturbes > Linux > client. But why? It is beyond my capabilities. > > What can I do to make i work? Is it me or server, who si broken? > I'll take a look at the packet dump when I get home in a couple of days. The main thing I'd suggest is trying a non-Kerberized NFSv4 mount from Linux->FreeBSD and see how that does? rick From owner-freebsd-fs@FreeBSD.ORG Fri Dec 3 10:55:23 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09DE21065672 for ; Fri, 3 Dec 2010 10:55:23 +0000 (UTC) (envelope-from drb@karlov.mff.cuni.cz) Received: from mail.karlov.mff.cuni.cz (mail.karlov.mff.cuni.cz [195.113.27.114]) by mx1.freebsd.org (Postfix) with ESMTP id 546818FC18 for ; Fri, 3 Dec 2010 10:55:22 +0000 (UTC) Received: from nat-r.karlov.mff.cuni.cz ([195.113.27.73] helo=[10.32.82.27]) by mail.karlov.mff.cuni.cz with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1POTIO-000NJO-Mf for freebsd-fs@freebsd.org; Fri, 03 Dec 2010 11:55:20 +0100 Message-ID: <4CF8CC96.3040901@karlov.mff.cuni.cz> Date: Fri, 03 Dec 2010 11:55:18 +0100 From: =?UTF-8?B?VG9tw6HFoSBEcmJvaGxhdg==?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <798450027.1098255.1291326812088.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <798450027.1098255.1291326812088.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: multipart/mixed; boundary="------------010706010509060008040903" Subject: Re: Linux (client) - FreeBSD (server) NFS4 interoperability problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 10:55:23 -0000 This is a multi-part message in MIME format. --------------010706010509060008040903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2.12.2010 22:53, Rick Macklem wrote: >> Hello, >> >> I am setting up an experimental (kerberized) NFSv4 server on FreeBSD >> 8.1-RELEASE-p1 and while between fBSD server and client it seems to >> work >> more or less ok, while connecting from Linux (Ubuntu), I am not able >> to >> read any file contents. Walking through dirs is ok, but when clients >> asks for a file, it freezes. >> >> As I noticed in the list, tcpdump may be useful, so I made one, see >> attached file. >> >> Although I am not an nfs expert, when I opened the dump in WireShark >> it >> seems to me, that server does not respond to packet #83, Compound Call >> containing OPEN opcode. That is probably the thing which disturbes >> Linux >> client. But why? It is beyond my capabilities. >> >> What can I do to make i work? Is it me or server, who si broken? >> > I'll take a look at the packet dump when I get home in a couple of > days. Thank, we appreciate any help! > The main thing I'd suggest is trying a non-Kerberized NFSv4 > mount from Linux->FreeBSD and see how that does? Looks almost the same to me. Attaching dump. Please note: server is 10.32.82.53, client 10.32.82.31 Thanks, Drb --------------010706010509060008040903 Content-Type: application/octet-stream; name="dom-z-sys" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dom-z-sys" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAnsP4TFfGDQA8AAAAPAAAAP///////wAcwHEV4QgG AAEIAAYEAAEAHMBxFeEKIFIfAAAAAAAACiBSNQAAAAAAAAAAAAAAAAAAAAAAAJ7D+Expxg0A KgAAACoAAAAAHMBxFeEAGdGUbXcIBgABCAAGBAACABnRlG13CiBSNQAcwHEV4QogUh+ew/hM 5MYNADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAsOd1AAEAGSFsKIFIfCiBSNQK9CAEVBZ0o AAAAAGACFtAL1wAAAgQFtAAAnsP4TB3HDQA6AAAAOgAAAAAcwHEV4QAZ0ZRtdwgARQAALAsv QABABncJCiBSNQogUh8IAQK9NSov7RUFnSlgEv//vX4AAAIEBbSew/hMmMcNADwAAAA8AAAA ABnRlG13ABzAcRXhCABFAAAoOd5AAEAGSF4KIFIfCiBSNQK9CAEVBZ0pNSov7lAQFtC+awAA AAAAAAAAnsP4TL7HDQBiAAAAYgAAAAAZ0ZRtdwAcwHEV4QgARQAAVDnfQABABkgxCiBSHwog UjUCvQgBFQWdKTUqL+5QGBbQqUoAAIAAACh58pQnAAAAAAAAAAIAAYajAAAABAAAAAAAAAAA AAAAAAAAAAAAAAAAnsP4TPPHDQBSAAAAUgAAAAAcwHEV4QAZ0ZRtdwgARQAARAswQABABnbw CiBSNQogUh8IAQK9NSov7hUFnVVQGP//RrgAAIAAABh58pQnAAAAAQAAAAAAAAAAAAAAAAAA AACew/hMasgNADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAoOeBAAEAGSFwKIFIfCiBSNQK9 CAEVBZ1VNSowClAQFtC+IwAAAAAAAAAAnsP4TPLIDQCmAAAApgAAAAAZ0ZRtdwAcwHEV4QgA RQAAmDnhQABABkfrCiBSHwogUjUCvQgBFQWdVTUqMApQGBbQ7poAAIAAAGx68pQnAAAAAAAA AAIAAYajAAAABAAAAAEAAAABAAAAIAKQxsUAAAAFZG9tLXoAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAYAAAACgAAAAkAAAACABABGgAwojqew/hMEc0NAEYB AABGAQAAABzAcRXhABnRlG13CABFAAE4CzVAAEAGdfcKIFI1CiBSHwgBAr01KjAKFQWdxVAY //+IegAAgAABDHrylCcAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAABgAAAAA AAAACgAAAAAAAAAc2iXhTMNq4ogMAAAAANhwADulov0AAAAAAAAAAAAAAAkAAAAAAAAAAgAQ ARoAMKI6AAAAoAAAAAIAAAAAAAAABQAAAAAAAAIAAAAAAEzhJdoAAAAAiOJqwwAAAAAAcNgA AAAB7QAAAAIAAAAXcm9vdEBrYXJsb3YubWZmLmN1bmkuY3oAAAAAGHdoZWVsQGthcmxvdi5t ZmYuY3VuaS5jegAAAK8BwgBoAAAAAAAACAAAAAAATPjAKQAAAAAAAAAATOKKbAAAAAAAAAAA TOKKbAAAAACew/hMWs4NAL4AAAC+AAAAABnRlG13ABzAcRXhCABFAACwOeJAAEAGR9IKIFIf CiBSNQK9CAEVBZ3FNSoxGlAYGSCv3gAAgAAAhHvylCcAAAAAAAAAAgABhqMAAAAEAAAAAQAA AAEAAAAgApDGxQAAAAVkb20tegAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAgAAABYAAAAc2iXhTMNq4ogMAAAAANhwADulov0AAAAAAAAAAAAAAAkAAAABAAAgYZ7D +EzEzg0AjgAAAI4AAAAAHMBxFeEAGdGUbXcIAEUAAIALNkAAQAZ2rgogUjUKIFIfCAECvTUq MRoVBZ5NUBj///RJAACAAABUe/KUJwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC AAAAFgAAAAAAAAAJAAAAAAAAAAEAAABhAAAAFAAAAAL9/4//APm+PgAAAAEAAAABnsP4TD7P DQDCAAAAwgAAAAAZ0ZRtdwAcwHEV4QgARQAAtDnjQABABkfNCiBSHwogUjUCvQgBFQWeTTUq MXJQGBkgAlYAAIAAAIh88pQnAAAAAAAAAAIAAYajAAAABAAAAAEAAAABAAAAIAKQxsUAAAAF ZG9tLXoAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAHNol 4UzDauKIDAAAAADYcAA7paL9AAAAAAAAAAAAAAAJAAAAAsgABAAAAAAAnsP4TILPDQCWAAAA lgAAAAAcwHEV4QAZ0ZRtdwgARQAAiAs3QABABnalCiBSNQogUh8IAQK9NSoxchUFntlQGP// 824AAIAAAFx88pQnAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAAAAA AAkAAAAAAAAAAcgABAAAAAAcAAAAeAAAgAAAAAAAAAAAAAABAAAAAAAAAAEAAJ7D+Ez7zw0A vgAAAL4AAAAAGdGUbXcAHMBxFeEIAEUAALA55EAAQAZH0AogUh8KIFI1Ar0IARUFntk1KjHS UBgZIKwSAACAAACEffKUJwAAAAAAAAACAAGGowAAAAQAAAABAAAAAQAAACACkMbFAAAABWRv bS16AAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAFgAAABzaJeFM w2riiAwAAAAA2HAAO6Wi/QAAAAAAAAAAAAAACQAAAAEAACBhnsP4TDnQDQCOAAAAjgAAAAAc wHEV4QAZ0ZRtdwgARQAAgAs4QABABnasCiBSNQogUh8IAQK9NSox0hUFn2FQGP//8H0AAIAA AFR98pQnAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAAAAAAAkAAAAA AAAAAQAAAGEAAAAUAAAAAv3/j/8A+b4+AAAAAQAAAAGew/hMsNANAMIAAADCAAAAABnRlG13 ABzAcRXhCABFAAC0OeVAAEAGR8sKIFIfCiBSNQK9CAEVBZ9hNSoyKlAYGSD+iQAAgAAAiH7y lCcAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAEAAAAgApDGxQAAAAVkb20tegAAAAAAAAAAAAAA AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAc2iXhTMNq4ogMAAAAANhwADul ov0AAAAAAAAAAAAAAAkAAAACyAAEAAAAAACew/hM6dANAJYAAACWAAAAABzAcRXhABnRlG13 CABFAACICzlAAEAGdqMKIFI1CiBSHwgBAr01KjIqFQWf7VAY///vogAAgAAAXH7ylCcAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAAAAAACQAAAAAAAAAByAAEAAAA ABwAAAB4AACAAAAAAAAAAAAAAAEAAAAAAAAAAQAAnsP4TF7RDQC+AAAAvgAAAAAZ0ZRtdwAc wHEV4QgARQAAsDnmQABABkfOCiBSHwogUjUCvQgBFQWf7TUqMopQGBkgmKcAAIAAAIR/8pQn AAAAAAAAAAIAAYajAAAABAAAAAEAAAABAAAAIAKQxsUAAAAFZG9tLXoAAAAAAAAAAAAAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAHNol4UzDauKIDAAAAADYcAA7paL9 AAAAAAAAAAAAAAAJAAAAATAAAACew/hMktENAIIAAACCAAAAABzAcRXhABnRlG13CABFAAB0 CzpAAEAGdrYKIFI1CiBSHwgBAr01KjKKFQWgdVAY//+JcwAAgAAASH/ylCcAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAAAAAACQAAAAAAAAABMAAAAAAAAAgAAH// AAAA/57D+Eyi0g0AvgAAAL4AAAAAGdGUbXcAHMBxFeEIAEUAALA550AAQAZHzQogUh8KIFI1 Ar0IARUFoHU1KjLWUBgZIKZyAACAAACEgPKUJwAAAAAAAAACAAGGowAAAAQAAAABAAAAAQAA ACACkMbFAAAABWRvbS16AAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC AAAAFgAAABzaJeFMw2riiAwAAAAA2HAAO6Wi/QAAAAAAAAAAAAAACQAAAAEAACBhnsP4TNXS DQCOAAAAjgAAAAAcwHEV4QAZ0ZRtdwgARQAAgAs7QABABnapCiBSNQogUh8IAQK9NSoy1hUF oP1QGP//6t0AAIAAAFSA8pQnAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAW AAAAAAAAAAkAAAAAAAAAAQAAAGEAAAAUAAAAAv3/j/8A+b4+AAAAAQAAAAGew/hM0tMNAMIA AADCAAAAABnRlG13ABzAcRXhCABFAAC0OehAAEAGR8gKIFIfCiBSNQK9CAEVBaD9NSozLlAY GSAhVgAAgAAAiIHylCcAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAEAAAAgApDGxQAAAAVkb20t egAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAc2iXhTMNq 4ogMAAAAANhwADulov0AAAAAAAAAAAAAAAkAAAACABABGgAwojqew/hMFdQNAB4BAAAeAQAA ABzAcRXhABnRlG13CABFAAEQCzxAAEAGdhgKIFI1CiBSHwgBAr01KjMuFQWhiVAY//837QAA gAAA5IHylCcAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAAAAAACQAA AAAAAAACABABGgAwojoAAACgAAAAAgAAAAAAAAAFAAAAAAAAAgAAAAAATOEl2gAAAACI4mrD AAAAAABw2AAAAAHtAAAAAgAAABdyb290QGthcmxvdi5tZmYuY3VuaS5jegAAAAAYd2hlZWxA a2FybG92Lm1mZi5jdW5pLmN6AAAArwHCAGgAAAAAAAAIAAAAAABM+MApAAAAAAAAAABM4ops AAAAAAAAAABM4opsAAAAAJ7D+EyQYg4APAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACg56UAA QAZIUwogUh8KIFI1Ar0IARUFoYk1KjQWUBAdUK9jAAAAAAAAAACfw/hM3NYNAOIAAADiAAAA ABnRlG13ABzAcRXhCABFAADUOepAAEAGR6YKIFIfCiBSNQK9CAEVBaGJNSo0FlAYHVBBGAAA gAAAqILylCcAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAEAAABAApDGxgAAAAVkb20tegAAAAAA UngAAAPoAAAACQAAAAQAAAAUAAAAGAAAAC4AAABoAAAAcwAAAHgAAAPoAAAD7AAAAAAAAAAA AAAAAAAAAAAAAAACAAAAFgAAABzaJeFMw2riiAwAAAAA2HAAO6Wi/QAAAAAAAAAAAAAACQAA AAIA4AAAAAAcAJ/D+Ewk1w0ArgAAAK4AAAAAHMBxFeEAGdGUbXcIAEUAAKALPUAAQAZ2hwog UjUKIFIfCAECvTUqNBYVBaI1UBj//4foAACAAAB0gvKUJwAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAACAAAAFgAAAAAAAAAJAAAAAAAAAAIA4AAAAAAcAAAAADAAAAAAAIEOPQAA AAAAgQ49AAAAAACFU/4AAAAO3GagAAAAAA7cZqAAAAAAEBviCACfw/hMm9cNADwAAAA8AAAA ABnRlG13ABzAcRXhCABFAAAoOetAAEAGSFEKIFIfCiBSNQK9CAEVBaI1NSo0jlAQHVCuPwAA AAAAAAAAn8P4TEkjDgDqAAAA6gAAAAAZ0ZRtdwAcwHEV4QgARQAA3DnsQABABkecCiBSHwog UjUCvQgBFQWiNTUqNI5QGB1QuAwAAIAAALCD8pQnAAAAAAAAAAIAAYajAAAABAAAAAEAAAAB AAAAQAKQxsYAAAAFZG9tLXoAAAAAAFJ4AAAD6AAAAAkAAAAEAAAAFAAAABgAAAAuAAAAaAAA AHMAAAB4AAAD6AAAA+wAAAAAAAAAAAAAAAAAAAAAAAAAAwAAABYAAAAc2iXhTMNq4ogMAAAA ANhwADulov0AAAAAAAAAAAAAAAMAAAAfAAAACQAAAAIAEAEaADCiOp/D+EyFIw4ALgEAAC4B AAAAHMBxFeEAGdGUbXcIAEUAASALPkAAQAZ2BgogUjUKIFIfCAECvTUqNI4VBaLpUBj//zLn AACAAAD0g/KUJwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAFgAAAAAAAAAD AAAAAAAAAB8AAAADAAAACQAAAAAAAAACABABGgAwojoAAACgAAAAAgAAAAAAAAAFAAAAAAAA AgAAAAAATOEl2gAAAACI4mrDAAAAAABw2AAAAAHtAAAAAgAAABdyb290QGthcmxvdi5tZmYu Y3VuaS5jegAAAAAYd2hlZWxAa2FybG92Lm1mZi5jdW5pLmN6AAAArwHCAGgAAAAAAAAIAAAA AABM+MApAAAAAAAAAABM4opsAAAAAAAAAABM4opsAAAAAJ/D+EytJA4A9gAAAPYAAAAAGdGU bXcAHMBxFeEIAEUAAOg57UAAQAZHjwogUh8KIFI1Ar0IARUFouk1KjWGUBghgJz8AACAAAC8 hPKUJwAAAAAAAAACAAGGowAAAAQAAAABAAAAAQAAAEACkMbGAAAABWRvbS16AAAAAABSeAAA A+gAAAAJAAAABAAAABQAAAAYAAAALgAAAGgAAABzAAAAeAAAA+gAAAPsAAAAAAAAAAAAAAAA AAAAAAAAAAQAAAAWAAAAHNol4UzDauKIDAAAAADYcAA7paL9AAAAAAAAAAAAAAAPAAAABi5U cmFzaAAAAAAACgAAAAkAAAACABABGgAwojqfw/hM7iQOAG4AAABuAAAAABzAcRXhABnRlG13 CABFAABgCz9AAEAGdsUKIFI1CiBSHwgBAr01KjWGFQWjqVAY//8vaQAAgAAANITylCcAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAgAAABYAAAAAAAAADwAAAAKfw/hMCiYOAPoA AAD6AAAAABnRlG13ABzAcRXhCABFAADsOe5AAEAGR4oKIFIfCiBSNQK9CAEVBaOpNSo1vlAY IYALYQAAgAAAwIXylCcAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAEAAABAApDGxgAAAAVkb20t egAAAAAAUngAAAPoAAAACQAAAAQAAAAUAAAAGAAAAC4AAABoAAAAcwAAAHgAAAPoAAAD7AAA AAAAAAAAAAAAAAAAAAAAAAAEAAAAFgAAABzaJeFMw2riiAwAAAAA2HAAO6Wi/QAAAAAAAAAA AAAADwAAAAwuVHJhc2gtMjExMTIAAAAKAAAACQAAAAIAEAEaADCiOp/D+ExEJg4AbgAAAG4A AAAAHMBxFeEAGdGUbXcIAEUAAGALQEAAQAZ2xAogUjUKIFIfCAECvTUqNb4VBaRtUBj//y1t AACAAAA0hfKUJwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAACAAAAFgAAAAAAAAAP AAAAAp/D+EyItQ4APAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACg570AAQAZITQogUh8KIFI1 Ar0IARUFpG01KjX2UBAhgKZvAAAAAAAAAAClw/hMRxgDAMoAAADKAAAAABnRlG13ABzAcRXh CABFAAC8OfBAAEAGR7gKIFIfCiBSNQK9CAEVBaRtNSo19lAYIYANhQAAgAAAkIbylCcAAAAA AAAAAgABhqMAAAAEAAAAAQAAAAEAAAAgApDGywAAAAVkb20tegAAAAAAAAAAAAAAAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAABYAAAAc2iXhTMNq4ogMAAAAANhwADulov0AAAAA AAAAAAAAAAMAAAAfAAAACQAAAAIAEAEaADCiOqXD+EyjGAMALgEAAC4BAAAAHMBxFeEAGdGU bXcIAEUAASALQUAAQAZ2AwogUjUKIFIfCAECvTUqNfYVBaUBUBj//yxnAACAAAD0hvKUJwAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAFgAAAAAAAAADAAAAAAAAAB8AAAAD AAAACQAAAAAAAAACABABGgAwojoAAACgAAAAAgAAAAAAAAAFAAAAAAAAAgAAAAAATOEl2gAA AACI4mrDAAAAAABw2AAAAAHtAAAAAgAAABdyb290QGthcmxvdi5tZmYuY3VuaS5jegAAAAAY d2hlZWxAa2FybG92Lm1mZi5jdW5pLmN6AAAArwHCAGgAAAAAAAAIAAAAAABM+MApAAAAAAAA AABM4opsAAAAAAAAAABM4opsAAAAAKXD+EwZGQMAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUA ACg58UAAQAZISwogUh8KIFI1Ar0IARUFpQE1KjbuUBAlsKCzAAAAAAAAAAClw/hM50MDANoA AADaAAAAABnRlG13ABzAcRXhCABFAADMOfJAAEAGR6YKIFIfCiBSNQK9CAEVBaUBNSo27lAY JbCKRwAAgAAAoIfylCcAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAEAAAAgApDGywAAAAVkb20t egAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAc2iXhTMNq 4ogMAAAAANhwADulov0AAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAAAAAAAAAH2AAAD7AAAAAC AAAIAACAAAClw/hMMkQDAOIAAADiAAAAABzAcRXhABnRlG13CABFAADUC0JAAEAGdk4KIFI1 CiBSHwgBAr01KjbuFQWlpVAY//81wQAAgAAAqIfylCcAAAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAgAAABYAAAAAAAAAGgAAAAAAAAAAAAAABQAAAAEAAAAAAAAAKAAAAAZzb3Vi b3IAAAAAAAIAAAgAAIAAAAAAAAwAAAAAAAAAAABw2AEAAAABAAAAAAAAAgAAAAAEaG9tZQAA AAIAAAgAAIAAAAAAAAwAAAAAAAAAAABw2AMAAAAAAAAAAaXD+EwlRQMA1gAAANYAAAAAGdGU bXcAHMBxFeEIAEUAAMg580AAQAZHqQogUh8KIFI1Ar0IARUFpaU1KjeaUBgp4KfuAACAAACc iPKUJwAAAAAAAAACAAGGowAAAAQAAAABAAAAAQAAACACkMbLAAAABWRvbS16AAAAAAAAAAAA AAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAFgAAABzaJeFMw2riiAwAAAAA2HAA O6Wi/QAAAAAAAAAAAAAADwAAAAZzb3Vib3IAAAAAAAoAAAAJAAAAAgAQARoAMKI6pcP4TGlF AwBOAQAATgEAAAAcwHEV4QAZ0ZRtdwgARQABQAtDQABABnXhCiBSNQogUh8IAQK9NSo3mhUF pkVQGP//cR4AAIAAARSI8pQnAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAW AAAAAAAAAA8AAAAAAAAACgAAAAAAAAAc2iXhTMNq4ogMAAAAAdhwAHcaWTkAAAAAAAAAAAAA AAkAAAAAAAAAAgAQARoAMKI6AAAAoAAAAAEAAAAAAAAABwAAAAAAAAAEAAAAAEzhJdoAAAAA iOJqwwAAAAAAcNgBAAABtgAAAAEAAAAXcm9vdEBrYXJsb3YubWZmLmN1bmkuY3oAAAAAGHdo ZWVsQGthcmxvdi5tZmYuY3VuaS5jegAAAK8BwgBqAAAAAAAACAAAAAAATPjALwAAAAAAAAAA TOUOvQAAAAAAAAAATOUOvQAAAAClw/hM4EUDANIAAADSAAAAABnRlG13ABzAcRXhCABFAADE OfRAAEAGR6wKIFIfCiBSNQK9CAEVBaZFNSo4slAYLhAjgAAAgAAAmInylCcAAAAAAAAAAgAB hqMAAAAEAAAAAQAAAAEAAAAgApDGywAAAAVkb20tegAAAAAAAAAAAAAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABAAAABYAAAAc2iXhTMNq4ogMAAAAANhwADulov0AAAAAAAAAAAAA AA8AAAAEaG9tZQAAAAoAAAAJAAAAAgAQARoAMKI6pcP4TB5GAwBOAQAATgEAAAAcwHEV4QAZ 0ZRtdwgARQABQAtEQABABnXgCiBSNQogUh8IAQK9NSo4shUFpuFQGP//nvQAAIAAARSJ8pQn AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAWAAAAAAAAAA8AAAAAAAAACgAA AAAAAAAc2iXhTMNq4ogMAAAAA9hwAEmTL0kAAAAAAAAAAAAAAAkAAAAAAAAAAgAQARoAMKI6 AAAAoAAAAAUAAAAAAAAACwAAAAAAAAAFAAAAAEzhJdoAAAAAiOJqwwAAAAAAcNgDAAAB7QAA AAEAAAAXcm9vdEBrYXJsb3YubWZmLmN1bmkuY3oAAAAAGHdoZWVsQGthcmxvdi5tZmYuY3Vu aS5jegAAAGhtbwAvAAAAAAAAAAAAAAAATOKKbAAAAAAAAAAATOKKbAAAAAAAAAAATOKKbAAA AAClw/hMBEcDALYAAAC2AAAAABnRlG13ABzAcRXhCABFAACoOfVAAEAGR8cKIFIfCiBSNQK9 CAEVBabhNSo5ylAYMkD5EgAAgAAAfIrylCcAAAAAAAAAAgABhqMAAAAEAAAAAQAAAAEAAAAg ApDGywAAAAVkb20tegAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAA ABYAAAAc2iXhTMNq4ogMAAAAA9hwAEmTL0kAAAAAAAAAAAAAABulw/hMN0cDAHoAAAB6AAAA ABzAcRXhABnRlG13CABFAABsC0VAAEAGdrMKIFI1CiBSHwgBAr01KjnKFQWnYVAY//8dcgAA gAAAQIrylCcAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAAAAAAGwAA AAAAAAAFL2hvbWUAAAClw/hMVgIEADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAoOfZAAEAG SEYKIFIfCiBSNQK9CAEVBadhNSo6DlAQMkCOowAAAAAAAAAAqMP4TJPRAADCAAAAwgAAAAAZ 0ZRtdwAcwHEV4QgARQAAtDn3QABABke5CiBSHwogUjUCvQgBFQWnYTUqOg5QGDJA8OgAAIAA AIiL8pQnAAAAAAAAAAIAAYajAAAABAAAAAEAAAABAAAAIAKQxs4AAAAFZG9tLXoAAAAAAAAA AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAHNol4UzDauKIDAAAAADY cAA7paL9AAAAAAAAAAAAAAAJAAAAAgAQARoAMKI6qMP4TOTRAAAeAQAAHgEAAAAcwHEV4QAZ 0ZRtdwgARQABEAtGQABABnYOCiBSNQogUh8IAQK9NSo6DhUFp+1QGP//HS0AAIAAAOSL8pQn AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAWAAAAAAAAAAkAAAAAAAAAAgAQ ARoAMKI6AAAAoAAAAAIAAAAAAAAABQAAAAAAAAIAAAAAAEzhJdoAAAAAiOJqwwAAAAAAcNgA AAAB7QAAAAIAAAAXcm9vdEBrYXJsb3YubWZmLmN1bmkuY3oAAAAAGHdoZWVsQGthcmxvdi5t ZmYuY3VuaS5jegAAAK8BwgBoAAAAAAAACAAAAAAATPjDpQAAAAAAAAAATOKKbAAAAAAAAAAA TOKKbAAAAACow/hMW9IAADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAoOfhAAEAGSEQKIFIf CiBSNQK9CAEVBaftNSo69lAQNnCI/wAAAAAAAAAAqMP4TInWAADqAAAA6gAAAAAZ0ZRtdwAc wHEV4QgARQAA3Dn5QABABkePCiBSHwogUjUCvQgBFQWn7TUqOvZQGDZwg6UAAIAAALCM8pQn AAAAAAAAAAIAAYajAAAABAAAAAEAAAABAAAAIAKQxs4AAAAFZG9tLXoAAAAAAAAAAAAAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAjTPjDnjU5cR0AAAAiMTAuMzIuODIuMzEv MTAuMzIuODIuNTMgdGNwIFVOSVggMAAAQAAAAAAAAAN0Y3AAAAAAEzEwLjMyLjgyLjMxLjE0 NS4yNTIAAAAAAKjD+Ey21gAAdgAAAHYAAAAAHMBxFeEAGdGUbXcIAEUAAGgLR0AAQAZ2tQog UjUKIFIfCAECvTUqOvYVBaihUBj///yRAACAAAA8jPKUJwAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAAIwAAAAAhGfdMBAAAAAQAAAAAAAAAqMP4TC3XAAC2AAAAtgAAAAAZ 0ZRtdwAcwHEV4QgARQAAqDn6QABABkfCCiBSHwogUjUCvQgBFQWooTUqOzZQGDZwJG4AAIAA AHyN8pQnAAAAAAAAAAIAAYajAAAABAAAAAEAAAABAAAAIAKQxs4AAAAFZG9tLXoAAAAAAAAA AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAkIRn3TAQAAAAEAAAAAAAAAAAA ABgAAAAJAAAAAgAABAAAAAAAqMP4TGfXAACGAAAAhgAAAAAcwHEV4QAZ0ZRtdwgARQAAeAtI QABABnakCiBSNQogUh8IAQK9NSo7NhUFqSFQGP//FncAAIAAAEyN8pQnAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAkAAAAAAAAABgAAAAAAAAACQAAAAAAAAABAAAEAAAA AAQAAAB4qMP4TFnYAAAeAQAAHgEAAAAZ0ZRtdwAcwHEV4QgARQABEDn7QABABkdZCiBSHwog UjUCvQgBFQWpITUqO4ZQGDZwjM4AAIAAAOSO8pQnAAAAAAAAAAIAAYajAAAABAAAAAEAAAAB AAAAIAKQxs4AAAAFZG9tLXoAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAAAAWAAAAHNol4UzDauKIDAAAAADYcAA7paL9AAAAAAAAAAAAAAAgAAAAEgAAAAAAAAAB AAAAACEZ90wEAAAAAAAAEG9wZW4gaWQ6qEyoOCJkc80AAAAAAAAAAAAAAAZzb3Vib3IAAAAA AAoAAAAJAAAAAgAQARoAMKI6AAAAHwAAAAkAAAACABABGgAwojqow/hMyNgAAEoAAABKAAAA ABzAcRXhABnRlG13CABFAAA8C0lAAEAGdt8KIFI1CiBSH1xdkfwF8OC+AAAAAKAC//8NtAAA AgQFtAEDAwMEAggKBjumeAAAAACow/hM9G8CADYAAAA2AAAAABzAcRXhABnRlG13CABFAAAo C0pAAEAGdvIKIFI1CiBSHwgBAr01KjuGFQWqCVAQ//+8wwAAq8P4TADkAgBKAAAASgAAAAAc wHEV4QAZ0ZRtdwgARQAAPAtLQABABnbdCiBSNQogUh9cXZH8BfDgvgAAAACgAv//AfwAAAIE BbQBAwMDBAIICgY7sjAAAAAArsP4TEYgCABKAAAASgAAAAAcwHEV4QAZ0ZRtdwgARQAAPAtM QABABnbcCiBSNQogUh9cXZH8BfDgvgAAAACgAv//9XsAAAIEBbQBAwMDBAIICgY7vrAAAAAA scP4TINcDQA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAtNQABABnbnCiBSNQogUh9cXZH8 BfDgvgAAAABwAv//9oMAAAIEBbQEAgAAtcP4TJhWAwA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgA RQAAMAtOQABABnbmCiBSNQogUh9cXZH8BfDgvgAAAABwAv//9oMAAAIEBbQEAgAAuMP4TPSS CAA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAtPQABABnblCiBSNQogUh9cXZH8BfDgvgAA AABwAv//9oMAAAIEBbQEAgAAv8P4TBiRAAA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAtQ QABABnbkCiBSNQogUh9cXZH8BfDgvgAAAABwAv//9oMAAAIEBbQEAgAAy8P4TKnxCwA+AAAA PgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAtRQABABnbjCiBSNQogUh9cXZH8BfDgvgAAAABwAv// 9oMAAAIEBbQEAgAA3MP4TKBfCQDiAAAA4gAAAAAZ0ZRtdwAcwHEV4QgARQAA1Dn8QABABkeU CiBSHwogUjUCvQgBFQWqCTUqO4ZQGDZwCswAAIAAAKiP8pQnAAAAAAAAAAIAAYajAAAABAAA AAEAAAABAAAAQAKQxwIAAAAFZG9tLXoAAAAAAFJ4AAAD6AAAAAkAAAAEAAAAFAAAABgAAAAu AAAAaAAAAHMAAAB4AAAD6AAAA+wAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAc2iXhTMNq 4ogMAAAAANhwADulov0AAAAAAAAAAAAAAAkAAAACAOAAAAAAHADcw/hMJGAJAK4AAACuAAAA ABzAcRXhABnRlG13CABFAACgC1JAAEAGdnIKIFI1CiBSHwgBAr01KjuGFQWqtVAY//9q+AAA gAAAdI/ylCcAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAAAAAACQAA AAAAAAACAOAAAAAAHAAAAAAwAAAAAACBDj0AAAAAAIEOPQAAAAAAhVP+AAAADtxmoAAAAAAO 3GagAAAAABAb4ggA3MP4TBZhCQDiAAAA4gAAAAAZ0ZRtdwAcwHEV4QgARQAA1Dn9QABABkeT CiBSHwogUjUCvQgBFQWqtTUqO/5QGDZwgfMAAIAAAKiQ8pQnAAAAAAAAAAIAAYajAAAABAAA AAEAAAABAAAAQAKQxwIAAAAFZG9tLXoAAAAAAFJ4AAAD6AAAAAkAAAAEAAAAFAAAABgAAAAu AAAAaAAAAHMAAAB4AAAD6AAAA+wAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAc2iXhTMNq 4ogMAAAAANhwADulov0AAAAAAAAAAAAAAAkAAAACABABGgAwojrcw/hMG2MJAB4BAAAeAQAA ABzAcRXhABnRlG13CABFAAEQC1dAAEAGdf0KIFI1CiBSHwgBAr01Kjv+FQWrYVAY//8SyQAA gAAA5JDylCcAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABYAAAAAAAAACQAA AAAAAAACABABGgAwojoAAACgAAAAAgAAAAAAAAAFAAAAAAAAAgAAAAAATOEl2gAAAACI4mrD AAAAAABw2AAAAAHtAAAAAgAAABdyb290QGthcmxvdi5tZmYuY3VuaS5jegAAAAAYd2hlZWxA a2FybG92Lm1mZi5jdW5pLmN6AAAArwHCAGgAAAAAAAAIAAAAAABM+MOlAAAAAAAAAABM4ops AAAAAAAAAABM4opsAAAAANzD+Eza9wkAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACg5/kAA QAZIPgogUh8KIFI1Ar0IARUFq2E1KjzmUBA6oH9rAAAAAAAAAADkw/hM6c0AADwAAAA8AAAA ABnRlG13ABzAcRXhCABFAAAoOf9AAEAGSD0KIFIfCiBSNQK9CAEVBathNSo85lAROqB/agAA AAAAAAAA5MP4TA7OAAA2AAAANgAAAAAcwHEV4QAZ0ZRtdwgARQAAKAtYQABABnbkCiBSNQog Uh8IAQK9NSo85hUFq2JQEP//ugoAAOXD+EwR9gAAPgAAAD4AAAAAHMBxFeEAGdGUbXcIAEUA ADALWUAAQAZ22wogUjUKIFIfXF2R/AXw4L4AAAAAcAL///aDAAACBAW0BAIAAPPD+EzdzQAA PAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACg6AEAAQAZIPAogUh8KIFI1Ar0IARUFq2I1Kjzm UBQ6oH9mAAAAAAAAAAD2w/hM5M0AADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAsbGJAAEAG FdYKIFIfCiBSNQK9CAEVBqtjAAAAAGACFtD9mgAAAgQFtAAA9sP4TBbOAAA6AAAAOgAAAAAc wHEV4QAZ0ZRtdwgARQAALAtaQABABnbeCiBSNQogUh8IAQK96qLi4BUGq2RgEv//RtYAAAIE BbT2w/hMks4AADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAobGNAAEAGFdkKIFIfCiBSNQK9 CAEVBqtk6qLi4VAQFtBHwwAAAAAAAAAA9sP4TLTOAAA8AAAAPAAAAAAZ0ZRtdwAcwHEV4QgA RQAAKGxkQABABhXYCiBSHwogUjUCvQgBFQarZOqi4uFQERbQR8IAAAAAAAAAAPbD+EzHzgAA NgAAADYAAAAAHMBxFeEAGdGUbXcIAEUAACgLW0AAQAZ24QogUjUKIFIfCAECveqi4uEVBqtl UBD//16SAAD2w/hM7s4AADYAAAA2AAAAABzAcRXhABnRlG13CABFAAAoC1xAAEAGduAKIFI1 CiBSHwgBAr3qouLhFQarZVAR//9ekQAA9sP4TELPAAA8AAAAPAAAAAAZ0ZRtdwAcwHEV4QgA RQAAKGxlQABABhXXCiBSHwogUjUCvQgBFQarZeqi4uJQEBbQR8EAAAAAAAAAAPfD+Exb3gYA SgAAAEoAAAAAHMBxFeEAGdGUbXcIAEUAADwLXUAAQAZ2ywogUjUKIFIfRNuR/NP7Ms8AAAAA oAL//9w4AAACBAW0AQMDAwQCCAoGPM9YAAAAAPrD+ExX6ggASgAAAEoAAAAAHMBxFeEAGdGU bXcIAEUAADwLXkAAQAZ2ygogUjUKIFIfRNuR/NP7Ms8AAAAAoAL//9CAAAACBAW0AQMDAwQC CAoGPNsQAAAAAP3D+EywHg4ASgAAAEoAAAAAHMBxFeEAGdGUbXcIAEUAADwLX0AAQAZ2yQog UjUKIFIfRNuR/NP7Ms8AAAAAoAL//8QAAAACBAW0AQMDAwQCCAoGPOeQAAAAAAHE+Ey1GAQA PgAAAD4AAAAAHMBxFeEAGdGUbXcIAEUAADALYEAAQAZ21AogUjUKIFIfRNuR/NP7Ms8AAAAA cAL//+3pAAACBAW0BAIAAATE+EwMVQkAPgAAAD4AAAAAHMBxFeEAGdGUbXcIAEUAADALYUAA QAZ20wogUjUKIFIfRNuR/NP7Ms8AAAAAcAL//+3pAAACBAW0BAIAAAfE+ExSkQ4APgAAAD4A AAAAHMBxFeEAGdGUbXcIAEUAADALYkAAQAZ20gogUjUKIFIfRNuR/NP7Ms8AAAAAcAL//+3p AAACBAW0BAIAAA7E+Ex3lwYAPgAAAD4AAAAAHMBxFeEAGdGUbXcIAEUAADALY0AAQAZ20Qog UjUKIFIfRNuR/NP7Ms8AAAAAcAL//+3pAAACBAW0BAIAABvE+EzhtQIAPgAAAD4AAAAAHMBx FeEAGdGUbXcIAEUAADALZEAAQAZ20AogUjUKIFIfRNuR/NP7Ms8AAAAAcAL//+3pAAACBAW0 BAIAADLE+Eyw0gAAPAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACx1F0AAQAYNIQogUh8KIFI1 Ar0IARUHq2YAAAAAYAIW0P2WAAACBAW0AAAyxPhM9tIAADoAAAA6AAAAABzAcRXhABnRlG13 CABFAAAsC2VAAEAGdtMKIFI1CiBSHwgBAr3xKGXvFQerZ2AS//+9PQAAAgQFtDLE+Exx0wAA PAAAADwAAAAAGdGUbXcAHMBxFeEIAEUAACh1GEAAQAYNJAogUh8KIFI1Ar0IARUHq2fxKGXw UBAW0L4qAAAAAAAAAAAyxPhMldMAADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAodRlAAEAG DSMKIFIfCiBSNQK9CAEVB6tn8Shl8FARFtC+KQAAAAAAAAAAMsT4TKvTAAA2AAAANgAAAAAc wHEV4QAZ0ZRtdwgARQAAKAtmQABABnbWCiBSNQogUh8IAQK98Shl8BUHq2hQEP//1PkAADLE +EzQ0wAANgAAADYAAAAAHMBxFeEAGdGUbXcIAEUAACgLZ0AAQAZ21QogUjUKIFIfCAECvfEo ZfAVB6toUBH//9T4AAAyxPhMJtQAADwAAAA8AAAAABnRlG13ABzAcRXhCABFAAAodRpAAEAG DSIKIFIfCiBSNQK9CAEVB6to8Shl8VAQFtC+KAAAAAAAAAAANMT4TNX8BgA+AAAAPgAAAAAc wHEV4QAZ0ZRtdwgARQAAMAtoQABABnbMCiBSNQogUh9E25H80/syzwAAAABwAv//7ekAAAIE BbQEAgAARsT4TDbdDABKAAAASgAAAAAcwHEV4QAZ0ZRtdwgARQAAPAtpQABABna/CiBSNQog Uh84cpH8KjUYywAAAACgAv//g4sAAAIEBbQBAwMDBAIICgY9+DgAAAAAScT4TAbhDgBKAAAA SgAAAAAcwHEV4QAZ0ZRtdwgARQAAPAtxQABABna3CiBSNQogUh84cpH8KjUYywAAAACgAv// d9MAAAIEBbQBAwMDBAIICgY+A/AAAAAATcT4TBHbBABKAAAASgAAAAAcwHEV4QAZ0ZRtdwgA RQAAPAtyQABABna2CiBSNQogUh84cpH8KjUYywAAAACgAv//a1MAAAIEBbQBAwMDBAIICgY+ EHAAAAAAUMT4TFcXCgA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAtzQABABnbBCiBSNQog Uh84cpH8KjUYywAAAABwAv//vh0AAAIEBbQEAgAAVMT4TPcQAAA+AAAAPgAAAAAcwHEV4QAZ 0ZRtdwgARQAAMAt0QABABnbACiBSNQogUh84cpH8KjUYywAAAABwAv//vh0AAAIEBbQEAgAA V8T4TDtNBQA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAt1QABABna/CiBSNQogUh84cpH8 KjUYywAAAABwAv//vh0AAAIEBbQEAgAAXcT4TK2VDAA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgA RQAAMAt2QABABna+CiBSNQogUh84cpH8KjUYywAAAABwAv//vh0AAAIEBbQEAgAAasT4TAKs CAA+AAAAPgAAAAAcwHEV4QAZ0ZRtdwgARQAAMAt3QABABna9CiBSNQogUh84cpH8KjUYywAA AABwAv//vh0AAAIEBbQEAgAA --------------010706010509060008040903-- From owner-freebsd-fs@FreeBSD.ORG Fri Dec 3 19:41:10 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 771911065673 for ; Fri, 3 Dec 2010 19:41:10 +0000 (UTC) (envelope-from peter@pean.org) Received: from smtprelay-h22.telenor.se (smtprelay-h22.telenor.se [195.54.99.197]) by mx1.freebsd.org (Postfix) with ESMTP id 34CF18FC1A for ; Fri, 3 Dec 2010 19:41:09 +0000 (UTC) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 8AB71EBC85 for ; Fri, 3 Dec 2010 20:41:08 +0100 (CET) X-SENDER-IP: [85.225.7.221] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncVABPX+ExV4QfdPGdsb2JhbAAHlR2OIQEBAQE1w2iFSASKaw X-IronPort-AV: E=Sophos;i="4.59,294,1288566000"; d="scan'208";a="156476096" Received: from c-dd07e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.40]) ([85.225.7.221]) by ipb1.telenor.se with ESMTP; 03 Dec 2010 20:40:50 +0100 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Dec 2010 20:40:50 +0100 Message-Id: <4CF017C8-9D3C-483D-B508-5BF70E32AA14@pean.org> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: zfs snapshots. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 19:41:10 -0000 Is there a way to take a snapshot without using space from the parent = filesystem? -- Peter Ankerst=E5l peter@pean.org http://www.pean.org/ From owner-freebsd-fs@FreeBSD.ORG Fri Dec 3 19:51:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4525C1065670 for ; Fri, 3 Dec 2010 19:51:05 +0000 (UTC) (envelope-from peter@pean.org) Received: from smtprelay-b11.telenor.se (smtprelay-b11.telenor.se [62.127.194.20]) by mx1.freebsd.org (Postfix) with ESMTP id F32798FC1D for ; Fri, 3 Dec 2010 19:51:04 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b11.telenor.se (Postfix) with ESMTP id B1ADECDCE for ; Fri, 3 Dec 2010 20:51:03 +0100 (CET) X-SENDER-IP: [85.225.7.221] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlETALfY+ExV4QfdPGdsb2JhbAAHoz4BAQEBNcNshUgEims X-IronPort-AV: E=Sophos;i="4.59,294,1288566000"; d="scan'208";a="155411070" Received: from c-dd07e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.40]) ([85.225.7.221]) by ipb2.telenor.se with ESMTP; 03 Dec 2010 20:51:03 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: <4CF949B0.5060405@obsysa.net> Date: Fri, 3 Dec 2010 20:51:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CF017C8-9D3C-483D-B508-5BF70E32AA14@pean.org> <4CF949B0.5060405@obsysa.net> To: Bartosz Stec X-Mailer: Apple Mail (2.1082) Cc: freebsd-fs@freebsd.org Subject: Re: zfs snapshots. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 19:51:05 -0000 > On 2010-12-03 20:40, Peter Ankerst=E5l wrote: >> Is there a way to take a snapshot without using space from the parent = filesystem? >>=20 >> -- >> Peter Ankerst=E5l >> peter@pean.org >> http://www.pean.org/ >>=20 > AFAIK snapshot doesn't take any space as long as filesystem hasn't = changed from the time when snapshot was taken. > For instance - If you take snapshot on filesystem and after that, 10MB = file is deleted, snapshot is using only 10MB space from (because it's = only difference between snapshot and actual filesystem). >=20 > -- > Bartosz Stec >=20 Yes, this is correct. But it still uses up 10MB from the parent = filesystem. This is a problem if you use both snapshots and quotas. (and = use alot of snapshots)= From owner-freebsd-fs@FreeBSD.ORG Fri Dec 3 20:25:41 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 993681065693 for ; Fri, 3 Dec 2010 20:25:41 +0000 (UTC) (envelope-from admin@obsysa.net) Received: from serwer.obsysa.net (static-78-8-144-74.ssp.dialog.net.pl [78.8.144.74]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA958FC29 for ; Fri, 3 Dec 2010 20:25:41 +0000 (UTC) Received: from [192.168.0.2] by serwer.obsysa.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PObcx-0009uK-5u; Fri, 03 Dec 2010 20:49:17 +0100 Message-ID: <4CF949B0.5060405@obsysa.net> Date: Fri, 03 Dec 2010 20:49:04 +0100 From: Bartosz Stec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101028 Lanikai/3.1.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= References: <4CF017C8-9D3C-483D-B508-5BF70E32AA14@pean.org> In-Reply-To: <4CF017C8-9D3C-483D-B508-5BF70E32AA14@pean.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: admin@obsysa.net X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.72 (build at 10-Jun-2010 12:49:35) X-Date: 2010-12-03 20:49:17 X-Connected-IP: 192.168.0.2:54915 X-Message-Linecount: 29 X-Body-Linecount: 16 X-Message-Size: 1090 X-Body-Size: 527 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 X-Mailman-Approved-At: Fri, 03 Dec 2010 20:27:33 +0000 Cc: freebsd-fs@freebsd.org Subject: Re: zfs snapshots. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 20:25:41 -0000 On 2010-12-03 20:40, Peter Ankerstål wrote: > Is there a way to take a snapshot without using space from the parent filesystem? > > -- > Peter Ankerstål > peter@pean.org > http://www.pean.org/ > AFAIK snapshot doesn't take any space as long as filesystem hasn't changed from the time when snapshot was taken. For instance - If you take snapshot on filesystem and after that, 10MB file is deleted, snapshot is using only 10MB space from (because it's only difference between snapshot and actual filesystem). -- Bartosz Stec From owner-freebsd-fs@FreeBSD.ORG Fri Dec 3 21:19:07 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E0B9106566B for ; Fri, 3 Dec 2010 21:19:07 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 542918FC2D for ; Fri, 3 Dec 2010 21:19:07 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id oB3L0kNW009649; Fri, 3 Dec 2010 15:00:46 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id oB3L0j2c009648; Fri, 3 Dec 2010 15:00:45 -0600 (CST) (envelope-from brooks) Date: Fri, 3 Dec 2010 15:00:45 -0600 From: Brooks Davis To: Peter Ankerst?l Message-ID: <20101203210045.GB7429@lor.one-eyed-alien.net> References: <4CF017C8-9D3C-483D-B508-5BF70E32AA14@pean.org> <4CF949B0.5060405@obsysa.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 03 Dec 2010 15:00:47 -0600 (CST) Cc: freebsd-fs@freebsd.org, Bartosz Stec Subject: Re: zfs snapshots. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 21:19:07 -0000 --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 03, 2010 at 08:51:02PM +0100, Peter Ankerst?l wrote: >=20 >=20 > > On 2010-12-03 20:40, Peter Ankerst?l wrote: > >> Is there a way to take a snapshot without using space from the parent = filesystem? > >>=20 > > AFAIK snapshot doesn't take any space as long as filesystem hasn't > > changed from the time when snapshot was taken. For instance - > > If you take snapshot on filesystem and after that, 10MB file is > > deleted, snapshot is using only 10MB space from (because it's only > > difference between snapshot and actual filesystem). > > Yes, this is correct. But it still uses up 10MB from the parent > filesystem. This is a problem if you use both snapshots and quotas. > (and use alot of snapshots) You many be able to use the refquota attribute instead of quota unless you're trying to place quotas on filesystem hiearchies. -- Brooks --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFM+Vp9XY6L6fI4GtQRAheCAJ9qYdVMCpFlVCtMWmsutavK6749RwCfZfaS Rd8ldPXj+uL8wBm5Xf+sP2k= =4fLO -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From owner-freebsd-fs@FreeBSD.ORG Fri Dec 3 21:25:30 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42424106566B for ; Fri, 3 Dec 2010 21:25:30 +0000 (UTC) (envelope-from peter@pean.org) Received: from smtprelay-b12.telenor.se (smtprelay-b12.telenor.se [62.127.194.21]) by mx1.freebsd.org (Postfix) with ESMTP id EF46A8FC08 for ; Fri, 3 Dec 2010 21:25:29 +0000 (UTC) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id 4D226CAAD; Fri, 3 Dec 2010 22:25:27 +0100 (CET) X-SENDER-IP: [85.225.7.221] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQVAIPu+ExV4QfdPGdsb2JhbAAHiBibJgEBAQE1wzyCdoJSBIpr X-IronPort-AV: E=Sophos;i="4.59,295,1288566000"; d="scan'208";a="156488920" Received: from c-dd07e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.40]) ([85.225.7.221]) by ipb1.telenor.se with ESMTP; 03 Dec 2010 22:25:27 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: <20101203210045.GB7429@lor.one-eyed-alien.net> Date: Fri, 3 Dec 2010 22:25:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7554F69B-0E03-42E3-8BB2-FD7CFE19805A@pean.org> References: <4CF017C8-9D3C-483D-B508-5BF70E32AA14@pean.org> <4CF949B0.5060405@obsysa.net> <20101203210045.GB7429@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1082) Cc: freebsd-fs@freebsd.org, Bartosz Stec Subject: Re: zfs snapshots. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 21:25:30 -0000 >>>=20 >>=20 >> Yes, this is correct. But it still uses up 10MB from the parent >> filesystem. This is a problem if you use both snapshots and quotas. >> (and use alot of snapshots) >=20 > You many be able to use the refquota attribute instead of quota unless > you're trying to place quotas on filesystem hiearchies. >=20 > -- Brooks Oh. Thanks. How could I miss that.. It seems I have to change some of = the "logic" in my setup for this to work as needed but overall this will = work fine. Thanks! From owner-freebsd-fs@FreeBSD.ORG Sat Dec 4 14:00:25 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BA82106566B for ; Sat, 4 Dec 2010 14:00:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6EFA48FC12 for ; Sat, 4 Dec 2010 14:00:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oB4E0PZD029493 for ; Sat, 4 Dec 2010 14:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB4E0PSn029482; Sat, 4 Dec 2010 14:00:25 GMT (envelope-from gnats) Date: Sat, 4 Dec 2010 14:00:25 GMT Message-Id: <201012041400.oB4E0PSn029482@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Ralf Folkerts Cc: Subject: Re: kern/149855: [gvinum] growfs causes fsck to report errors in Filesystem grown with gvinum X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ralf Folkerts List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 14:00:25 -0000 The following reply was made to PR kern/149855; it has been noted by GNATS. From: Ralf Folkerts To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/149855: [gvinum] growfs causes fsck to report errors in Filesystem grown with gvinum Date: Sat, 04 Dec 2010 14:26:56 +0100 Hi, with the "recent" commit to gorwfs __FBSDID("$FreeBSD: src/sbin/growfs/growfs.c,v 1.26.2.6 2010/11/07 22:33:55 brian Exp $"); this problem got fixed. I just checked a few times, verything works nice now! Thanks for the fix! I have no Idea how to close this ticket - could someone pls. close it? Thanks! Cheers, _ralf_ From owner-freebsd-fs@FreeBSD.ORG Sat Dec 4 21:56:59 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B596B106566C; Sat, 4 Dec 2010 21:56:59 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8ADB88FC1E; Sat, 4 Dec 2010 21:56:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oB4LuxqW031258; Sat, 4 Dec 2010 21:56:59 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB4Lux4W031254; Sat, 4 Dec 2010 21:56:59 GMT (envelope-from jh) Date: Sat, 4 Dec 2010 21:56:59 GMT Message-Id: <201012042156.oB4Lux4W031254@freefall.freebsd.org> To: ralffmail-news2@yahoo.de, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/149855: [gvinum] growfs causes fsck to report errors in Filesystem grown with gvinum X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 21:56:59 -0000 Synopsis: [gvinum] growfs causes fsck to report errors in Filesystem grown with gvinum State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Sat Dec 4 21:56:59 UTC 2010 State-Changed-Why: Closed at submitter's request. http://www.freebsd.org/cgi/query-pr.cgi?pr=149855