From owner-freebsd-fs@freebsd.org Sun Dec 4 17:55:33 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C658C67963 for ; Sun, 4 Dec 2016 17:55:33 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E92291BB0 for ; Sun, 4 Dec 2016 17:55:32 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from moby.local ([95.119.248.22]) by mail.gmx.com (mrgmx101 [212.227.17.174]) with ESMTPSA (Nemesis) id 0M9wrU-1cOcZI2Miu-00B4Co for ; Sun, 04 Dec 2016 18:55:24 +0100 From: Nikos Vassiliadis Subject: unionfs/zfs panic To: freebsd-fs@FreeBSD.org Message-ID: <1394db91-ea6e-4d24-41c1-d0ad762c493f@gmx.com> Date: Sun, 4 Dec 2016 18:55:23 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0jjkkrW9iTPooAhn1WnJJtxHNmr6i2MN9OPNHHraOF5PANN798L kTM3siMjrqaM2CzNEcKGEDO9TwWvaj8Jg1puSO2ksrdB7EIWmx1kKXfzsASTChs/prw3YJD /V31ZMLKrVhk2HvYkx/E63ENZIe0OqsmGcDQ4TzBnkYnzLp5VlCgWcS2/zbxks/MJcs1KiN 5OFCSHchUvK0HMtadB7FA== X-UI-Out-Filterresults: notjunk:1;V01:K0:C9rBp7uH0yI=:44oUY/97b8G1aXiQcojT+x KJVgkmZzCQcZufbEf0Ojk/aX85ZgV3HGvk2PYQWmiXJAfdu2hsBiLc1LsmQ5MSuyVka/zMF01 oGWNiS+JzLZNcvhWR4M1MCW3HizngjTnvJdJt2cygSXKAqGtW2yj31vPq2EczeWxnlFLSY9hd zwrxhbXfqQmKYCAyQXpkd/KvwqnvM3Pp7LUSrt6xCkHTbzX23TsGqRfXvqnRDVXH4dZ5EEX0a UGfI1NmI2fPQJexjw6SoJyjrDoJ50HHFlnA54xqNsOYB5+s0OXLQ9dy+har7CEqLs62wi56kn yl/5py+VwSDv0qFvqJoeBZHa21hL+294Jq9n3Zfx62u9s7D6MmAtJctm66Ur/6eRdgv8LOIoO xC5bVJHp2aUyYd7sl6OSZ/74dQyUfCDXUY4Xmg0rJvb9bIrietKepjlO2gKWyElWDOV5fagmP ROaJ2EfJ3fmyO5W93w3NynxtXjOuK/nl2DwiYs1zWm/2ZP7Mt6xAzfN/uNtnsqVRzyz2nmnhm AshV53XU5ynHotlKWCE8tjVFZAUr1mMCilmaG9QiW2LO059Zixz8hjkRcMIRLZevFvzh8imFr 9MrjFBtxMc3nFudE7l6OdtOixEGs9A0ja4n3YndrDRXAW1O8Bd10MCNDMNpeHLxGPvupMpHmq 5bqzd067kKxjK7dXg77RL5ppURDc888eU4VFq27IODSgPop/ee6/oi1Ymyxy3FtyB+JvEgHAJ h7dh9UakWLc8fDhioGhu45jAva50H4dP3T9cuCOh8hjAJWMNa/yjnzguA1czVw75DoH/4XuAV SAlGStg X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 17:55:33 -0000 Hi, I got a panic while trying to use a zfs / unionfs combination for jails. The following script can be used to reproduce the panic: basejail=/jail mkdir -p /tmp/i24420/n0 mkdir -p /tmp/i24420/upper/n0 mount_nullfs -o ro $basejail /tmp/i24420/n0 mount_unionfs -o noatime /tmp/i24420/upper/n0 /tmp/i24420/n0 mkdir -p /tmp/i24420/n1 mkdir -p /tmp/i24420/upper/n1 mount_nullfs -o ro $basejail /tmp/i24420/n1 mount_unionfs -o noatime /tmp/i24420/upper/n1 /tmp/i24420/n1 mkdir -p /tmp/i24420/n2 mkdir -p /tmp/i24420/upper/n2 mount_nullfs -o ro $basejail /tmp/i24420/n2 mount_unionfs -o noatime /tmp/i24420/upper/n2 /tmp/i24420/n2 mkdir -p /tmp/i24420/n3 mkdir -p /tmp/i24420/upper/n3 mount_nullfs -o ro $basejail /tmp/i24420/n3 mount_unionfs -o noatime /tmp/i24420/upper/n3 /tmp/i24420/n3 chroot /tmp/i24420/n0 rm -rv /var Any ideas how to debug this further? TIA, Nikos > panic: solaris assert: cnp->cn_namelen < sizeof(nm), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line: 4945 > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > lock order reversal: > 1st 0xfffff8000eb6b7c8 zfs (zfs) @ /usr/src/sys/kern/vfs_lookup.c:1080 > 2nd 0xfffff8000eba85f0 unionfs (unionfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:359 > stack backtrace: > #0 0xffffffff80ac0ed0 at witness_debugger+0x70 > #1 0xffffffff80ac0dc4 at witness_checkorder+0xe54 > #2 0xffffffff80a381f2 at __lockmgr_args+0x4c2 > #3 0xffffffff828208ef at unionfs_noderem+0x19f > #4 0xffffffff82825fd4 at unionfs_reclaim+0x14 > #5 0xffffffff810663b0 at VOP_RECLAIM_APV+0xe0 > #6 0xffffffff80b2901e at vgonel+0x20e > #7 0xffffffff80b2955e at vrecycle+0x3e > #8 0xffffffff82825fbc at unionfs_inactive+0x1c > #9 0xffffffff81066250 at VOP_INACTIVE_APV+0xe0 > #10 0xffffffff80b27e56 at vinactive+0xc6 > #11 0xffffffff80b2839e at vputx+0x30e > #12 0xffffffff80b31d41 at kern_rmdirat+0x1e1 > #13 0xffffffff80ef8d44 at amd64_syscall+0x314 > #14 0xffffffff80ed84ab at Xfast_syscall+0xfb > panic: solaris assert: cnp->cn_namelen < sizeof(nm), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line: 4945 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00952092a0 > vpanic() at vpanic+0x182/frame 0xfffffe0095209320 > panic() at panic+0x43/frame 0xfffffe0095209380 > assfail() at assfail+0x1a/frame 0xfffffe0095209390 > zfs_freebsd_lookup() at zfs_freebsd_lookup+0x47/frame 0xfffffe00952094d0 > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xda/frame 0xfffffe0095209500 > vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfffffe0095209560 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xda/frame 0xfffffe0095209590 > relookup() at relookup+0xa1/frame 0xfffffe00952095f0 > unionfs_relookup() at unionfs_relookup+0xfa/frame 0xfffffe0095209650 > unionfs_remove() at unionfs_remove+0xc8/frame 0xfffffe0095209710 > VOP_REMOVE_APV() at VOP_REMOVE_APV+0xe0/frame 0xfffffe0095209740 > kern_unlinkat() at kern_unlinkat+0x208/frame 0xfffffe0095209930 > amd64_syscall() at amd64_syscall+0x314/frame 0xfffffe0095209ab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0095209ab0 > --- syscall (10, FreeBSD ELF64, sys_unlink), rip = 0x80097915a, rsp = 0x7fffffffea58, rbp = 0x7fffffffeb20 --- > KDB: enter: panic > #0 doadump (textdump=-5) at pcpu.h:222 > 222 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=-5) at pcpu.h:222 > #1 0xffffffff80397db6 in db_fncall (dummy1=, > dummy2=, dummy3=, > dummy4=) at /usr/src/sys/ddb/db_command.c:581 > #2 0xffffffff80397919 in db_command (cmd_table=) > at /usr/src/sys/ddb/db_command.c:453 > #3 0xffffffff80397674 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:506 > #4 0xffffffff8039a72f in db_trap (type=, > code=) at /usr/src/sys/ddb/db_main.c:248 > #5 0xffffffff80aa2db3 in kdb_trap (type=, > code=, tf=) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80ef7cc4 in trap (frame=0xfffffe00952091d0) > at /usr/src/sys/amd64/amd64/trap.c:537 > #7 0xffffffff80ed81c1 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:236 > #8 0xffffffff80aa245b in kdb_enter (why=0xffffffff814339c1 "panic", > msg=0x80
) at cpufunc.h:63 > #9 0xffffffff80a609bf in vpanic (fmt=, > ap=0xfffffe0095209360) at /usr/src/sys/kern/kern_shutdown.c:752 > #10 0xffffffff80a60a23 in panic (fmt=0xffffffff81c23810 "\004") > at /usr/src/sys/kern/kern_shutdown.c:690 > #11 0xffffffff825cb23a in assfail (a=, > f=, l=) > at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81 > #12 0xffffffff8231f957 in zfs_freebsd_lookup (ap=0xfffffe0095209518) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4945 > #13 0xffffffff81063caa in VOP_CACHEDLOOKUP_APV (vop=, > a=) at vnode_if.c:195 > #14 0xffffffff80b12786 in vfs_cache_lookup (ap=) > at vnode_if.h:80 > #15 0xffffffff81063b4a in VOP_LOOKUP_APV (vop=, > a=) at vnode_if.c:127 > #16 0xffffffff80b1c611 in relookup (dvp=0xfffff8000eb6ab10, > vpp=0xfffffe00952096c0, cnp=0xfffffe0095209680) at vnode_if.h:54 > #17 0xffffffff82820f9a in unionfs_relookup (dvp=0xfffff8000eb6ab10, > vpp=0xfffffe00952096c0, cnp=0xfffffe0095209890, cn=0xfffffe0095209680, > td=0xfffff8000e95e000, path=, pathlen=10240, > nameiop=) > at /usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:544 > #18 0xffffffff82824cf8 in unionfs_remove (ap=0xfffffe00952098e8) > at /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:992 > #19 0xffffffff810656d0 in VOP_REMOVE_APV (vop=, > a=) at vnode_if.c:1400 > #20 0xffffffff80b31ab8 in kern_unlinkat (td=, fd=-100, > path=0x800e20748
, > pathseg=UIO_USERSPACE, oldinum=) at vnode_if.h:575 > #21 0xffffffff80ef8d44 in amd64_syscall (td=0xfffff8000e95e000, traced=0) > at subr_syscall.c:135 > #22 0xffffffff80ed84ab in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:396 > #23 0x000000080097915a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) From owner-freebsd-fs@freebsd.org Sun Dec 4 21:00:04 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1C56C67D05 for ; Sun, 4 Dec 2016 21:00:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98D4F1721 for ; Sun, 4 Dec 2016 21:00:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB4L018G021875 for ; Sun, 4 Dec 2016 21:00:04 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201612042100.uB4L018G021875@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 04 Dec 2016 21:00:04 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 21:00:04 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 140068 | [smbfs] [patch] smbfs does not allow semicolon in Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 203419 | solaris assert: (dn->dn_phys->dn_nlevels == 0 && Open | 211491 | System hangs after "Uptime" on reboot with ZFS 7 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Sun Dec 4 21:42:30 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91028C673C0 for ; Sun, 4 Dec 2016 21:42:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80A991BBB for ; Sun, 4 Dec 2016 21:42:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB4LgUcN088731 for ; Sun, 4 Dec 2016 21:42:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 200663] zfs allow/unallow doesn't show numeric UID when the ID no longer exists in the password file Date: Sun, 04 Dec 2016 21:42:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ler@lerctr.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 21:42:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200663 --- Comment #4 from Larry Rosenman --- Any news? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Mon Dec 5 09:25:09 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E7D3C671E8 for ; Mon, 5 Dec 2016 09:25:09 +0000 (UTC) (envelope-from honzhan@microsoft.com) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0120.outbound.protection.outlook.com [104.47.33.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29FAC1CE7 for ; Mon, 5 Dec 2016 09:25:08 +0000 (UTC) (envelope-from honzhan@microsoft.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B4VocbBYt3MXiGLrnInWJXBn+yRu6oLS4DPpDI1KoQ8=; b=JpMPmk2uaFH3vrDjKQSEWHR85xx/sL/uTzIX2+Ea4Mom/CxMMvhzTK+wVLTjU02cblfYZiFRpklef+HLuoE36PFpuhMJJ4SHzo8O7NC29dSXX/bshP587w0hP2Y9Whp7wcwwNhTC6st8esuLZBJ9S3gTOIJ+sBxLcUnRnrDt2Qg= Received: from CY1PR03MB1517.namprd03.prod.outlook.com (10.163.17.23) by CY1PR03MB1520.namprd03.prod.outlook.com (10.163.17.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Mon, 5 Dec 2016 07:50:50 +0000 Received: from CY1PR03MB1517.namprd03.prod.outlook.com ([10.163.17.23]) by CY1PR03MB1517.namprd03.prod.outlook.com ([10.163.17.23]) with mapi id 15.01.0761.016; Mon, 5 Dec 2016 07:50:50 +0000 From: Hongjiang Zhang To: "freebsd-fs@FreeBSD.org" Subject: zfs suspend/resume Thread-Topic: zfs suspend/resume Thread-Index: AdJOy0GE970q4n8+T2ei3l7QseNlxQ== Date: Mon, 5 Dec 2016 07:50:49 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=honzhan@microsoft.com; x-originating-ip: [2404:f801:9000:19::28d] x-ms-office365-filtering-correlation-id: 6ef83d13-0f9b-45fb-3a6f-08d41ce36e63 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR03MB1520; x-microsoft-exchange-diagnostics: 1; CY1PR03MB1520; 7:1wRtUaNIBZ3jrsmh+CPmfkSmIQ63877ckF5Gtr7zgrdaGGogbLGmgDG65Qzg92Fdb4T+0TsB7OmuTS0uiPx1bg6Mn4ueBawglyQgUejo7rEhGnceqMpDVL3XtsGZVBWI1v5mppFo8dVS0V8vlpO5aU16JbNyJWC9pWFrVXOmdgzLDnV2vMgqpnENgBHE85obwlfSk2Z6PGPiwthDFvchFSGLNjuhpRq6EpKAB8l96rXX3o4njSsqnYzWUmxf2anKwpaxhqBS+UbBaU3fSsNxJOcqDdODIXZ8TAbGQyxQ1xWPsCLhsTZ2WZzvUXi+qq8cLe0+7r+vst3ipqW7v2mr9hhlIgjmAmM3NR5gnoCODmwnjAofsIy9McVgVPQ8pREZLc29tXyblgo8VgPIfWy1rFGlFtclQFCZA2Ue/3+KeBzOmoBPsOue/VWvkS7y+JiQ2uN+Oc7+xKZMmr3+FI7fgs+6mfCVN4rFjXjxoBM/cs4= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558021)(6072148)(6047074); SRVR:CY1PR03MB1520; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB1520; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(2906002)(81156014)(106356001)(7846002)(7736002)(101416001)(2351001)(50986999)(99286002)(86612001)(54356999)(105586002)(8990500004)(5640700002)(5005710100001)(8676002)(6506006)(76576001)(39850400001)(97736004)(10290500002)(5660300001)(39450400002)(39410400001)(77096006)(38730400001)(107886002)(189998001)(86362001)(2501003)(7696004)(450100001)(10090500001)(3660700001)(122556002)(3280700002)(9686002)(6116002)(9326002)(5630700001)(6916009)(68736007)(8936002)(92566002)(74316002)(2900100001)(33656002)(790700001)(102836003)(39840400001)(81166006)(110136003)(39860400001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB1520; H:CY1PR03MB1517.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 07:50:49.9811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB1520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 09:25:09 -0000 Hi, I want to implement a feature to freeze/thaw the ZFS filesystem through zfs= _suspend/zfs_resume. This is used for FreeBSD in Hyper-V: Hyper-V supports = VSS (Volume Shadow Copy), and it requires the VM running on Hyper-V to supp= ort filesystem Freeze/Thaw. I found zfs_ioc_rollback has invoked zfs_suspend_fs and zfs_resume_fs. But = either zfs_suspend_fs or zfs_resume_fs was exposed to userland. I don't und= erstand why zfs_suspend_fs/zfs_resume_fs cannot be used through zfs_ioctl. = Anyone know? Or is it reasonable to add zfs_ioc_suspend and zfs_ioc_resume? Thanks Hongjiang Zhang From owner-freebsd-fs@freebsd.org Mon Dec 5 16:19:19 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61850C682CB for ; Mon, 5 Dec 2016 16:19:19 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A85C1CD3 for ; Mon, 5 Dec 2016 16:19:18 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 9826A1DA04; Mon, 5 Dec 2016 17:19:15 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PvX9s40TD33; Mon, 5 Dec 2016 17:19:13 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 129E01DA03; Mon, 5 Dec 2016 17:19:13 +0100 (CET) Subject: FreeBSD-Ceph: Jenkins build is back to normal : ceph-master #70 References: <1011204597.37.1480951219760.JavaMail.jenkins@cephdev.digiware.nl> To: Ceph Development From: Willem Jan Withagen Cc: FreeBSD Filesystems X-Forwarded-Message-Id: <1011204597.37.1480951219760.JavaMail.jenkins@cephdev.digiware.nl> Message-ID: Date: Mon, 5 Dec 2016 17:19:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <1011204597.37.1480951219760.JavaMail.jenkins@cephdev.digiware.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 16:19:19 -0000 Hi, It been just a bit more than 1 year ago I started this undertaking: Ceph on FreeBSD. So as sort as anniversary I'm sort of pleased to say that quite a lot of the code in Ceph/ceph now actually builds/runs/tests according the testset that comes with the repo. (And tonight is sort of Dutch pre-Xmas: Sinterklaas, and we give away presents. :D ) What I have not looked into are RBD, CephFS and fuse. * RBD has 2 sides: libRBD which is largely just userspace code. Porting that will not be a major undertaking. Kernel RBD might be possible, but then with largely different code.(more based on ggated) * CephFS and fuse are still uncharted territory so I'll have to see what is going to happen there. The code has not been stress tested at all. Like I said: it gets thru the testset. But it requires ZFS and some hand holding. Certainly ceph-disk will not do all things it does on Linux. So most/all of the setup needs to be done with care and double checking. Building a FreeBSD package is in the works, but I've yet to learn how to get the embedded Python parts installed in a way that they work. And some tweaks are needed to DIY. For those interested, I've started Jenkins to build a FreeBSD version once per day from master.... The results are public for everybody. -------- Forwarded Message -------- Subject: Jenkins build is back to normal : ceph-master #70 Date: Mon, 5 Dec 2016 16:20:19 +0100 (CET) From: jenkins@digiware.nl Reply-To: jenkins@digiware.nl To: wjw@digiware.nl http://cephdev.digiware.nl:8180/jenkins/job/ceph-master/70/ ------------------------------- To get here there are still a few patches required. This you see happening at the beginning of the jobs. The following patches are still under review, but applied here: Buildsystem: CMakeLists.txt-boost.diff Subsystem: src_rocksdb_CMakeText.txt.diff Code: msg_async_AsyncMessenger.cc.diff src_rgw_rgw_file.cc.diff Code/compiler-bug: test_test_denc.cc.diff test_test_mempool.cc.diff Tests: qa_workunits_ceph-disk.diff src_ceph-disk_tests_ceph-disk.sh.diff src_ceph-disk_tests_test_main.py.diff src_test_pybind_CMakeLists.txt.diff src_test_pybind_nosetests.diff If anybody wants to have these patches, I'll put them online. The alternative is to fetch my https://github.com/wjwithagen/ceph tree, and checkout wip.FreeBSD. But that is sort of a moving target and will not always compile. Thanx to: Sage Weil Kefu Chai Haomai Wang and many more Ceph developers that were patient enough with me, and helped me to get this far. Thanx, --WjW --WjW From owner-freebsd-fs@freebsd.org Mon Dec 5 21:25:37 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C588BC68E35 for ; Mon, 5 Dec 2016 21:25:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B5453AA9 for ; Mon, 5 Dec 2016 21:25:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB5LPbFE088139 for ; Mon, 5 Dec 2016 21:25:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 178238] [nullfs] nullfs don't release i-nodes on unlink. Date: Mon, 05 Dec 2016 21:25:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: leres@ee.lbl.gov X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 21:25:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D178238 leres@ee.lbl.gov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leres@ee.lbl.gov --- Comment #6 from leres@ee.lbl.gov --- This patch does not appear to be in base/stable/9 as of r309554. Would it be possible to add it? I have a 9 system that "fills up" a nullfs mount about a month after a reboot when I update and don't remember to re-apply the patch. Thanks! --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Dec 6 08:04:35 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFB45C66C47 for ; Tue, 6 Dec 2016 08:04:35 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: from mx3.lexa.ru (mx3.lexa.ru [198.27.68.102]) by mx1.freebsd.org (Postfix) with ESMTP id A18BD1A0D for ; Tue, 6 Dec 2016 08:04:35 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: by mx3.lexa.ru (Postfix, from userid 66) id AB0CA224A5B; Tue, 6 Dec 2016 02:56:06 -0500 (EST) Received: from [193.124.130.130] (unknown [193.124.130.130]) by home-gw.lexa.ru (Postfix) with ESMTP id 8DEF8B0583 for ; Tue, 6 Dec 2016 10:52:12 +0300 (MSK) To: "freebsd-fs@freebsd.org" From: Alex Tutubalin Subject: 12-CURRENT: ZFS single stream/large files read performance degradation Message-ID: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> Date: Tue, 6 Dec 2016 10:52:12 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 08:04:35 -0000 Hi, I'm using freebsd/zfs box to store/access media files (mostly RAW photos /thousands/ and some video), so it is 'single user NAS' (connected via 10G to my workstation). This box has upgraded to 12-current several weeks ago, it was also updated with new disks and after that I see serious read speed performance degradation. This hurts me so much, that I've run tests with separate set of HDDs yesterday, using FreeBSD 10.1, 10.2, 10.3, 11.0, 12-20161130 booted from memstick (so, default settings, no adjustments). In details: Box configuration: Intel i5-2400 (3.1Ghz), 16GB RAM, LSI-9211-8i controller in dumb IT-mode. Disks: WD1003FBYX (6-drive and 7-drive RAIDZ2 were tested) Testing methodology: boot from memstick zpool create -O recordsize=nn ztest raidz2 /dev/gpt/DISK[0-5/6] (for 6 and 7 disk RAIDZ2) zfs create ztest/pool dd if=/dev/zero of=/ztest/pool/100gfile bs=1m count=100k dd if=/ztest/pool/100gfile of=/dev/null bs=1m And write numbers (first free digits :) into excel table. I've tested 5 versions of FreeBSD (all memstick images are from ftp.freebsd.org), two recordsizes (128k and 1m) and two RAIDZ2 disc count: 6 and 7. Results are here in table: http://blog.lexa.ru/2016/12/06/freebsd_zfs_read_speed_oni_ubili_kenni.html My blog post is in Russian, but the table has english captions, so speaks for itself. In short, for 6-drive array and 11.0 against 12-20163011 128k recordsize: 11.0 503Mb/s(read)/462 Mb/s(write) 12-Current: 380/189 1m recordsize: 11.0: 507/521 12-current: 515/203. It is possible to get single-stream read speed back in 12-Current by setting vfs.zfs.zfetch.max_distance to very high number (1 gigabyte or even more, there is significant difference between 800m and 1800m), but this is not acceptable solution because any small read will become very large. For now, I'm downgrading back to 11.0, but it looks like I need to report this degradation to whom it may concern :) -- Alex Tutubalin Web: http://blog.lexa.ru mailto:lexa@lexa.ru From owner-freebsd-fs@freebsd.org Tue Dec 6 08:45:45 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A61BC68C84 for ; Tue, 6 Dec 2016 08:45:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6417F9D for ; Tue, 6 Dec 2016 08:45:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uB68jbPQ059071 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Dec 2016 10:45:37 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uB68jbPQ059071 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uB68jbhW059070; Tue, 6 Dec 2016 10:45:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 6 Dec 2016 10:45:37 +0200 From: Konstantin Belousov To: Alex Tutubalin Cc: "freebsd-fs@freebsd.org" Subject: Re: 12-CURRENT: ZFS single stream/large files read performance degradation Message-ID: <20161206084537.GJ54029@kib.kiev.ua> References: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 08:45:45 -0000 On Tue, Dec 06, 2016 at 10:52:12AM +0300, Alex Tutubalin wrote: > Hi, > > I'm using freebsd/zfs box to store/access media files (mostly RAW photos > /thousands/ and some video), so it is 'single user NAS' (connected via > 10G to my workstation). > > This box has upgraded to 12-current several weeks ago, it was also > updated with new disks and after that I see serious read speed > performance degradation. > > This hurts me so much, that I've run tests with separate set of HDDs > yesterday, using FreeBSD 10.1, 10.2, 10.3, 11.0, 12-20161130 booted from > memstick (so, default settings, no adjustments). > > In details: > > Box configuration: Intel i5-2400 (3.1Ghz), 16GB RAM, LSI-9211-8i > controller in dumb IT-mode. Disks: WD1003FBYX (6-drive and 7-drive > RAIDZ2 were tested) > > Testing methodology: > > boot from memstick > zpool create -O recordsize=nn ztest raidz2 /dev/gpt/DISK[0-5/6] (for 6 > and 7 disk RAIDZ2) > zfs create ztest/pool > dd if=/dev/zero of=/ztest/pool/100gfile bs=1m count=100k > dd if=/ztest/pool/100gfile of=/dev/null bs=1m > > And write numbers (first free digits :) into excel table. > > I've tested 5 versions of FreeBSD (all memstick images are from > ftp.freebsd.org), two recordsizes (128k and 1m) and two RAIDZ2 disc > count: 6 and 7. > > Results are here in table: > http://blog.lexa.ru/2016/12/06/freebsd_zfs_read_speed_oni_ubili_kenni.html > My blog post is in Russian, but the table has english captions, so > speaks for itself. > > In short, for 6-drive array and 11.0 against 12-20163011 > > 128k recordsize: > > 11.0 503Mb/s(read)/462 Mb/s(write) > > 12-Current: 380/189 > > 1m recordsize: > > 11.0: 507/521 > > 12-current: 515/203. > > It is possible to get single-stream read speed back in 12-Current by > setting vfs.zfs.zfetch.max_distance to very high number (1 gigabyte or > even more, there is significant difference between 800m and 1800m), but > this is not acceptable solution because any small read will become very > large. > > For now, I'm downgrading back to 11.0, but it looks like I need to > report this degradation to whom it may concern :) Are you using memstick image from the download site ? Note that all HEAD images produced by re@ have full debugging enabled, among which both kernel-side INVARIANTS and WITNESS, and usermode malloc debugging, have potentially huge impact on the system performance. From owner-freebsd-fs@freebsd.org Tue Dec 6 09:04:12 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAFE0C69694 for ; Tue, 6 Dec 2016 09:04:12 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: from mx3.lexa.ru (mx3.lexa.ru [198.27.68.102]) by mx1.freebsd.org (Postfix) with ESMTP id BD2521A3F for ; Tue, 6 Dec 2016 09:04:12 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: by mx3.lexa.ru (Postfix, from userid 66) id F228C224A5F; Tue, 6 Dec 2016 04:04:11 -0500 (EST) Received: from [193.124.130.130] (unknown [193.124.130.130]) by home-gw.lexa.ru (Postfix) with ESMTP id 02FF4B0583 for ; Tue, 6 Dec 2016 12:02:49 +0300 (MSK) Subject: Re: 12-CURRENT: ZFS single stream/large files read performance degradation To: "freebsd-fs@freebsd.org" References: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> <20161206084537.GJ54029@kib.kiev.ua> From: Alex Tutubalin Message-ID: <84782619-1a39-edb9-a04d-c3642ddc869e@lexa.ru> Date: Tue, 6 Dec 2016 12:02:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161206084537.GJ54029@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 09:04:13 -0000 On 12/6/2016 11:45 AM, Konstantin Belousov wrote:O > Are you using memstick image from the download site ? > Note that all HEAD images produced by re@ have full debugging enabled, > among which both kernel-side INVARIANTS and WITNESS, and usermode malloc > debugging, have potentially huge impact on the system performance. Yes, I've used memsticks from download site. Anyway, I see this single-stream read speed degradation on my 12-current compiled without INVARIANTS/WITNESS. Also, it looks like 11-STABLE is affected too, I'm compiling releng/11.0 now to see the difference, to be reported when I'll get results with this version. Alex Tutubalin From owner-freebsd-fs@freebsd.org Tue Dec 6 10:24:09 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AE14C6A15E for ; Tue, 6 Dec 2016 10:24:09 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: from mx3.lexa.ru (mx3.lexa.ru [198.27.68.102]) by mx1.freebsd.org (Postfix) with ESMTP id F170BF78 for ; Tue, 6 Dec 2016 10:24:08 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: by mx3.lexa.ru (Postfix, from userid 66) id 65120224A5D; Tue, 6 Dec 2016 05:24:07 -0500 (EST) Received: from [193.124.130.130] (unknown [193.124.130.130]) by home-gw.lexa.ru (Postfix) with ESMTP id 79137B0583 for ; Tue, 6 Dec 2016 13:22:18 +0300 (MSK) Subject: Re: 12-CURRENT AND 11-stable: ZFS single stream/large files read performance degradation To: freebsd-fs@freebsd.org References: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> From: Alex Tutubalin Message-ID: <1051d1c4-8ade-7a10-1007-c86e6f18cfe7@lexa.ru> Date: Tue, 6 Dec 2016 13:22:18 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 10:24:09 -0000 On 12/6/2016 10:52 AM, Alex Tutubalin wrote: > This box has upgraded to 12-current several weeks ago, it was also > updated with new disks and after that I see serious read speed > performance degradation. It is looks even worse, 11-stable is affected too: - Another box, different hardware: i3-6300T, 32Gb ram, C236 Chipset, 6 x 6Tb HGST drives (3x7k6000 and 3xHe8) connected to motherboard SATA ports. The only zfs related tunables are about ARC size: vm.kmem_size="30G" vfs.zfs.arc_max="29G" 11-STABLE: FreeBSD home-gw.lexa.ru 11.0-STABLE FreeBSD 11.0-STABLE #1 r308516: Fri Nov 11 13:15:21 MSK 2016 lexa@home-gw.lexa.ru:/usr/obj/usr/src/sys/GENERIC amd64 Read speed of 100Gb file: lexa@home-gw:~# dd if=/ztest/100g of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 640.324508 secs (167687135 bytes/sec) (zfs recordsize is 1m for this dataset) (Note, this is about single disk speed, He8 drives are capable to get 175Mb/sec at faster tracks, 7k600 are about 195Mb/s). Downgraded to 11-RELENG: FreeBSD home-gw.lexa.ru 11.0-RELEASE-p3 FreeBSD 11.0-RELEASE-p3 #2 r309605: Tue Dec 6 12:31:16 MSK 2016 lexa@home-gw.lexa.ru:/usr/obj/usr/src/sys/GENERIC amd64 read same file: same shit, about 160Mb/s. Re-created the file using downgdaded ZFS code: lexa@home-gw:/home/lexa# dd if=/dev/zero of=/ztest/100gb bs=1m count=100k 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 170.845743 secs (628486146 bytes/sec) Rebooted to get cold read and run read test: dd if=/ztest/100gb of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 168.924032 secs (635635919 bytes/sec) It is still not perfect, because only 4 disks are used in read iostat -x 5: device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b ada1 0 0 0.0 0.0 0 0 0 0 0 0 ada2 1229 0 157362.7 0.0 1 0 0 1 0 44 ada3 1231 0 157373.1 0.0 0 0 0 0 0 38 ada4 1229 0 157337.1 0.0 4 0 0 4 5 98 ada5 1231 0 157372.3 0.0 1 0 0 1 0 45 ada6 0 0 0.8 0.0 27 0 0 27 0 1 ada1 and ada6 are idle, while it is possible to read some data from it. But this is MUCH MUCH better, than on 11-STABLE and 12-CURRENT -- Alex Tutubalin Web: http://blog.lexa.ru mailto:lexa@lexa.ru From owner-freebsd-fs@freebsd.org Tue Dec 6 10:38:28 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03AF0C6A5D4 for ; Tue, 6 Dec 2016 10:38:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E756F1849 for ; Tue, 6 Dec 2016 10:38:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB6AcR3W077281 for ; Tue, 6 Dec 2016 10:38:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 178238] [nullfs] nullfs don't release i-nodes on unlink. Date: Tue, 06 Dec 2016 10:38:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 10:38:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D178238 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: kib Date: Tue Dec 6 10:37:28 UTC 2016 New revision: 309609 URL: https://svnweb.freebsd.org/changeset/base/309609 Log: MFC r292961, r295717: Force nullfs vnode reclaim after unlinking and directory removal. PR: 178238 Changes: _U stable/9/ _U stable/9/sys/ _U stable/9/sys/fs/ stable/9/sys/fs/nullfs/null_vnops.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Dec 6 16:20:09 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59FF3C6AE31 for ; Tue, 6 Dec 2016 16:20:09 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: from mx3.lexa.ru (mx3.lexa.ru [198.27.68.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3CAA7E4E for ; Tue, 6 Dec 2016 16:20:08 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: by mx3.lexa.ru (Postfix, from userid 66) id 5B11B224A5D; Tue, 6 Dec 2016 11:20:08 -0500 (EST) Received: from [193.124.130.130] (unknown [193.124.130.130]) by home-gw.lexa.ru (Postfix) with ESMTP id 6077FB0583 for ; Tue, 6 Dec 2016 19:17:40 +0300 (MSK) Subject: Re: 11-STABLE vs 11.0-RELENG test To: freebsd-fs@freebsd.org References: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> From: Alex Tutubalin Message-ID: Date: Tue, 6 Dec 2016 19:17:40 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 16:20:09 -0000 Followup, same box as in 1st message, but with different HBA and 5 HDD: Summary: 1) read speed depends on 'on-disk' data, not by code used while read. 2) FreeBSD 11.0-releng (svn up today) creates 'fast' big files (420+ Mb/s read speed) 3) FreeBSD 11-STABLE creates 'slow' big files. (~200 Mb/s) 4) zfs send slow-dataset | zfs recv (under 11.0-releng) creates 'intermediate' files (320Mb/s) 5) file copy slow-file ... (under 11.0-releng) creates fast copy (400+Mb/s) So, ZFS write code in 11-STABLE looks broken. Here detailed log of my tests: Box: Intel i5-2400, 16Gb of RAM, Adaptec 5805, 5x4Tb drives (HGST NAS drives) in JBOD, merged in RAIDZ2, enough free space: $ zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zdata 18,1T 5,11T 13,0T - 9% 28% 1.00x ONLINE - tunables in loader.conf: vm.kmem_size="15G" vfs.zfs.arc_max="14G" Boot 11.0-releng: $ uname -a FreeBSD iscsi.lexa.ru 11.0-RELEASE-p3 FreeBSD 11.0-RELEASE-p3 #7 r309605: Tue Dec 6 12:21:10 MSK 2016 lexa@iscsi.lexa.ru:/usr/obj/usr/src/sys/GENERIC amd64 create separate dataset for test: # zfs create -o recordsize=1m -o mountpoint=/test-11releng zdata/11releng write 100gb file: # dd if=/dev/zero of=/test-11releng/100g-created-on-11releng bs=1m count=100k 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 257.686751 secs (416684917 bytes/sec) reboot (still 11.0-releng) and read test file again: Cold read: $ dd if=/test-11releng/100g-created-on-11releng of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 250.526067 secs (428594850 bytes/sec) read again to see how cached metadata helps (if any): $ dd if=/test-11releng/100g-created-on-11releng of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 243.992662 secs (440071358 bytes/sec) Not much difference between cold and cached metadata, OK. Now boot 11.0-STABLE on same box: $ uname -a FreeBSD iscsi.lexa.ru 11.0-STABLE FreeBSD 11.0-STABLE #0 r309616: Tue Dec 6 16:15:48 MSK 2016 lexa@iscsi.lexa.ru:/usr/obj/usr/src11/sys/GENERIC amd64 Cold read of same data file: $ dd if=/test-11releng/100g-created-on-11releng of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 250.640950 secs (428398402 bytes/sec) Still OK: data created on 11.0-releng reads at full speed under 11-stable Create 11-stable own dataset: # zfs create -o recordsize=1m -o mountpoint=/test-11stable zdata/11stable And write similar 100g file: # dd if=/dev/zero of=/test-11stable/100g-created-on-11stable bs=1m count=100k 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 246.409501 secs (435755041 bytes/sec) Reboot (again into 11-stable) and read back created file $ dd if=/test-11stable/100g-created-on-11stable of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 524.488506 secs (204721707 bytes/sec) Hmm, about 1/2 of expected speed. Let's read fist test file, created on 11-releng: $ dd if=/test-11releng/100g-created-on-11releng of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 250.591102 secs (428483620 bytes/sec) Speed is still here. So, problem is related to on-disk data written by 11-stable. Let's try to recover 'bad data' into good one (assuming we're downgraded to 11-releng and want to get speed back) Boot into 11-releng: $ uname -a FreeBSD iscsi.lexa.ru 11.0-RELEASE-p3 FreeBSD 11.0-RELEASE-p3 #7 r309605: Tue Dec 6 12:21:10 MSK 2016 lexa@iscsi.lexa.ru:/usr/obj/usr/src/sys/GENERIC amd64 Try zfs send|recv: # zfs snapshot zdata/11stable@1 # zfs send zdata/11stable@1 | zfs recv zdata/11stable-sendrecv-on11releng # slow because same dataset used # zfs destroy zdata/11stable-sendrecv-on11releng@1 # zfs destroy zdata/11stable@1 # zfs set mountpoint=/test-11stable-sendrecv-on11releng zdata/11stable-sendrecv-on11releng Reboot and test read speed: $ dd if=/test-11stable-sendrecv-on11releng/100g-created-on-11stable of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 336.193935 secs (319381676 bytes/sec) INTERMEDIATE speed :( Better than 'bad datafile', worse than 'good datafile' Try file copy to another dataset: # zfs create -o recordsize=1m -o mountpoint=/test-11stable-copy-on11releng zdata/11stable-copy-on11releng # cd /test-11stable # tar cf - . | (cd /test-11stable-copy-on11releng/; tar xvf - ) Reboot again and test speed another time: $ dd if=/test-11stable-copy-on11releng/100g-created-on-11stable of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 261.484845 secs (410632526 bytes/sec) OK, per-file copy solves the problem (as expected). Finally, let's check that all testfiles still reads at the expected speed 'good' one, created on 11.0-releng: ]$ dd if=/test-11releng/100g-created-on-11releng of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 249.435476 secs (430468770 bytes/sec) 'bad' one, created on 11-stable: $ dd if=/test-11stable/100g-created-on-11stable of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 525.558477 secs (204304920 bytes/sec) and 'intermediate', created by zfs send bad-dataset | zfs recv: $ dd if=/test-11stable-sendrecv-on11releng/100g-created-on-11stable of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 336.570705 secs (319024148 bytes/sec) Boot into 11-stable again and test read speed too: $ uname -a FreeBSD iscsi.lexa.ru 11.0-STABLE FreeBSD 11.0-STABLE #0 r309616: Tue Dec 6 16:15:48 MSK 2016 lexa@iscsi.lexa.ru:/usr/obj/usr/src11/sys/GENERIC amd64 Good: ]$ dd if=/test-11releng/100g-created-on-11releng of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 256.322824 secs (418902151 bytes/sec) Bad: $ dd if=/test-11stable/100g-created-on-11stable of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 529.918422 secs (202623985 bytes/sec) Copied by tar (from bad to some intermediate state): $ dd if=/test-11stable-copy-on11releng/100g-created-on-11stable of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 260.234944 secs (412604783 bytes/sec) Copied by zfs send | zfs recv: $ dd if=/test-11stable-sendrecv-on11releng/100g-created-on-11stable of=/dev/null bs=1m 102400+0 records in 102400+0 records out 107374182400 bytes transferred in 336.240919 secs (319337047 bytes/sec) (virtually) same speed as under 11.0-releng, so read speed is limited by on-disk structures. -- Alex Tutubalin Web: http://blog.lexa.ru mailto:lexa@lexa.ru From owner-freebsd-fs@freebsd.org Tue Dec 6 17:14:24 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A93EC693A3 for ; Tue, 6 Dec 2016 17:14:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BE919173A for ; Tue, 6 Dec 2016 17:14:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23360; Tue, 06 Dec 2016 19:14:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1cEJJt-000Gp6-CM; Tue, 06 Dec 2016 19:14:21 +0200 Subject: Re: 11-STABLE vs 11.0-RELENG test To: Alex Tutubalin , freebsd-fs@FreeBSD.org References: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> From: Andriy Gapon Message-ID: Date: Tue, 6 Dec 2016 19:12:58 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 17:14:24 -0000 On 06/12/2016 18:17, Alex Tutubalin wrote: > Followup, same box as in 1st message, but with different HBA and 5 HDD: > > Summary: > 1) read speed depends on 'on-disk' data, not by code used while read. > 2) FreeBSD 11.0-releng (svn up today) creates 'fast' big files (420+ Mb/s read > speed) > 3) FreeBSD 11-STABLE creates 'slow' big files. (~200 Mb/s) > 4) zfs send slow-dataset | zfs recv (under 11.0-releng) creates > 'intermediate' files (320Mb/s) > 5) file copy slow-file ... (under 11.0-releng) creates fast copy (400+Mb/s) > > So, ZFS write code in 11-STABLE looks broken. > > Here detailed log of my tests: > > Box: Intel i5-2400, 16Gb of RAM, Adaptec 5805, 5x4Tb drives (HGST NAS drives) in > JBOD, merged in RAIDZ2, enough free space: > $ zpool list > NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT > zdata 18,1T 5,11T 13,0T - 9% 28% 1.00x ONLINE - That's an interesting observation. Could you please try starting with a freshly created pool and writing some data? I wonder if 'zpool list -v' will show any significant differences between different FreeBSD versions? Another thing to check would be 'zdb -mm' but it could be very large. However, a difference should be sufficiently small as most of the space would remain unused. And, just in case, please compare 'zpool get all' and 'zfs get all' between those two versions. -- Andriy Gapon From owner-freebsd-fs@freebsd.org Tue Dec 6 17:24:08 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E3E3C697D3 for ; Tue, 6 Dec 2016 17:24:08 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: from mx3.lexa.ru (mx3.lexa.ru [198.27.68.102]) by mx1.freebsd.org (Postfix) with ESMTP id 105F91CF0 for ; Tue, 6 Dec 2016 17:24:07 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: by mx3.lexa.ru (Postfix, from userid 66) id BADBE224A5C; Tue, 6 Dec 2016 12:24:06 -0500 (EST) Received: from [193.124.130.130] (unknown [193.124.130.130]) by home-gw.lexa.ru (Postfix) with ESMTP id 22279B0583 for ; Tue, 6 Dec 2016 20:23:22 +0300 (MSK) Subject: Re: 11-STABLE vs 11.0-RELENG test To: freebsd-fs@FreeBSD.org References: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> From: Alex Tutubalin Message-ID: Date: Tue, 6 Dec 2016 20:23:22 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 17:24:08 -0000 On 12/6/2016 8:12 PM, Andriy Gapon wrote: > Could you please try starting with a freshly created pool and writing some data? Sorry, this is working box with active data. No way to create fresh pool from it. Alex From owner-freebsd-fs@freebsd.org Tue Dec 6 17:58:41 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F0C9C6A48E for ; Tue, 6 Dec 2016 17:58:41 +0000 (UTC) (envelope-from orjan.tonder@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9B141141 for ; Tue, 6 Dec 2016 17:58:40 +0000 (UTC) (envelope-from orjan.tonder@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id f82so135545006wmf.1 for ; Tue, 06 Dec 2016 09:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=6JrUJMk5EfvJiqd5X7Iycrs8NZMSJOOUPffrBjCMRiw=; b=0/lG6hnAyNy08FAEWrielAFPXDfImcCtF6NBSo9EGFr2rDNzZlKDKhphFzdktW/gCa H3JXU0jwWQcUPIH32+XrGl/6f8oAbMNhidyqVj+4UZXgZZ9R89nxzDLuy3BJuPaxeHVu JHD/gDntKq+Dputgo2ID6EYOHJqiAUxU8GhL8fLNxctDHrH9pC2hDpyDMlZQ5lGf9O03 mKds1aostk2Tv6mc6e0NENx9APMATQgqKz1d709bLLqbxHsc48jEGQ2xFf3sAERlmpsr rxWoRb4oW/GgVfzsO3vNEkqtfrLNj+o9tviRo4zm+BRlEs1FkkWzyeXvd3/9o4gz54XU 0D6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6JrUJMk5EfvJiqd5X7Iycrs8NZMSJOOUPffrBjCMRiw=; b=gw99YbC0mVUUw8xwn6zib26vlpHQIXW9cBmRdQh8VOpeyouZguL3rtFdABNTjWNd2P WMy2kqgx4gCW7F573F10arE47GR2YhnozU9ZLmsHRK5rNXDHxBz4xSySUxo+OfDWDgcT ATBk6u8GSiGwGYNmO19SirTxNV15uv+3eivVNE4pGtSsW64Etz30KTAeIgg5LTC3pLa6 tq58tGov3961iepGCVCfMQwG+918stEtTrKR01MKoMYQwPVtq7b28GTmOPp8F3E2t2sI GlKgA9VpzhFz6sJAikvn6TtF2Oz57Y5rdHK5NikI3W8xqL9nOZl07ELgtE88CjR2sy5m UwVg== X-Gm-Message-State: AKaTC00ECBp1W2IU3/u5+PUJICbM4yrVN/dMLjH16/bnFqmtl0RbWyG4z6iJrIiaYyzOzK8JlvBY5GbtD0+q2g== X-Received: by 10.28.15.138 with SMTP id 132mr3645742wmp.41.1481047119026; Tue, 06 Dec 2016 09:58:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.222.214 with HTTP; Tue, 6 Dec 2016 09:58:38 -0800 (PST) From: =?UTF-8?B?w5hyamFuIFTDuG5kZXI=?= Date: Tue, 6 Dec 2016 18:58:38 +0100 Message-ID: Subject: freebsd zpool To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 17:58:41 -0000 i think i might have done a mistake trying too fix a faulted drive, what i did was 2016-12-06.16:15:04 zpool replace zroot 14907558934551777641 diskid/DISK-9VS5B1F8 i added all partions before hand and it all looked good in gpart show before i resilvered, now i cant find the drive in gpart. => 34 2930277101 diskid/DISK-WD-WMAY03724540 GPT (1.4T) 34 6 - free - (3.0K) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 2926080000 3 freebsd-zfs (1.4T) 2930276352 783 - free - (392K) => 34 2930277101 diskid/DISK-9VS48RLH GPT (1.4T) 34 6 - free - (3.0K) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 2926080000 3 freebsd-zfs (1.4T) 2930276352 783 - free - (392K) root@charon:/home/muad # zpool status pool: zroot state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(7) for details. scan: resilvered 208G in 1h13m with 0 errors on Tue Dec 6 17:28:53 2016 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 diskid/DISK-9VS5B1F8 ONLINE 0 0 0 diskid/DISK-WD-WMAY03724540p3 ONLINE 0 0 0 diskid/DISK-9VS48RLHp3 ONLINE 0 0 0 errors: No known data errors how can i correct this mistake? From owner-freebsd-fs@freebsd.org Tue Dec 6 18:12:21 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80D32C6AAB6 for ; Tue, 6 Dec 2016 18:12:21 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wj0-x229.google.com (mail-wj0-x229.google.com [IPv6:2a00:1450:400c:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D9681BAE for ; Tue, 6 Dec 2016 18:12:20 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wj0-x229.google.com with SMTP id tk12so36912917wjb.3 for ; Tue, 06 Dec 2016 10:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=yfTA/VGPDzgRznwPIojW7b2yjae4ATJRSVefVuIOEPQ=; b=H2/71YKwOSzaeGyvV1pjB0xaTTjhumZnCmNHLu8+akVGzw5qVaxys7m+YQyZx6mGdF 9LEr35RDtl9r3FnWumWSkHDI8XwOvvVIerXOuTzpCXexJsz/LZFGxw1J21VvX2HTEzwX DVaAjbnWZbIA22d+AsmksCNpPhqM++dzQuqf6KvRKq9N/a3jA9RrwHqEpq5C3C9uDm9l oZ4bej3TBs21GxdH2/p42VuRJdL6MIzdo0lEVm3iCLDxbnKs4FzpNTgfX9sFNm1K/fdN ylqfgIK7wZwffU/dW8hVBDe4CqV7Vb0Fks/vGOHjDw643E0ja6XytT5/P83bxqrUtKbp rT/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=yfTA/VGPDzgRznwPIojW7b2yjae4ATJRSVefVuIOEPQ=; b=cnMGXJRz5isYQHs8nmHJFL9KSMGortpbwC6JDMA9jbmYa7cDuTtxE36MTF+4c+R4gK rrueFwcjWNxHqBQc96K6wz1fEwTsAKloYorHlu30ZAy8Jg+UUblTdcjT+E7+kxEWqlLG aLnT0Abl5gNHU8RdEx8TOHfoRuuvKrKvP4A7NeK8PvhKF2/QmAW022a2WBZeGq8AiqP2 NMosS5yH1ZVX0YrnjwbQsO4uXyAYotp4vyp+CiJrRO79KZ1MCuzxASqewgp7cdnxpFyp jty3MbCzeY38FHJYLjqpsDTARne5JZCVzovGHs9r8mWl5A/p2oB7H5vqbsaDYHdF01fz nvvw== X-Gm-Message-State: AKaTC00+gT6zTT9WWwNaaUONjkF0mx+C4xl5OXDMQ20NGMq/nTCC5ZjDVgCmrRy6KmFgl0J3 X-Received: by 10.194.122.65 with SMTP id lq1mr57082220wjb.12.1481047938705; Tue, 06 Dec 2016 10:12:18 -0800 (PST) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id w7sm5215464wmd.24.2016.12.06.10.12.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 10:12:17 -0800 (PST) Subject: Re: freebsd zpool To: freebsd-fs@freebsd.org References: From: Steven Hartland Message-ID: <07f9dc30-11ae-99df-cb0f-77a4224b2442@multiplay.co.uk> Date: Tue, 6 Dec 2016 18:12:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 18:12:21 -0000 On 06/12/2016 17:58, rjan Tnder wrote: > i think i might have done a mistake trying too fix a faulted drive, what i > did was > > > 2016-12-06.16:15:04 zpool replace zroot 14907558934551777641 > diskid/DISK-9VS5B1F8 > > i added all partions before hand and it all looked good in gpart show > before i resilvered, now i cant find the drive in gpart. > > => 34 2930277101 diskid/DISK-WD-WMAY03724540 GPT (1.4T) > 34 6 - free - (3.0K) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 freebsd-swap (2.0G) > 4196352 2926080000 3 freebsd-zfs (1.4T) > 2930276352 783 - free - (392K) > > => 34 2930277101 diskid/DISK-9VS48RLH GPT (1.4T) > 34 6 - free - (3.0K) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 freebsd-swap (2.0G) > 4196352 2926080000 3 freebsd-zfs (1.4T) > 2930276352 783 - free - (392K) > > root@charon:/home/muad # zpool status > pool: zroot > state: ONLINE > status: Some supported features are not enabled on the pool. The pool can > still be used, but some features are unavailable. > action: Enable all features using 'zpool upgrade'. Once this is done, > the pool may no longer be accessible by software that does not > support > the features. See zpool-features(7) for details. > scan: resilvered 208G in 1h13m with 0 errors on Tue Dec 6 17:28:53 2016 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > diskid/DISK-9VS5B1F8 ONLINE 0 0 0 > diskid/DISK-WD-WMAY03724540p3 ONLINE 0 0 0 > diskid/DISK-9VS48RLHp3 ONLINE 0 0 0 > > errors: No known data errors > > how can i correct this mistake? You attached the direct disk and not the partition, the only way to fix this would be to do another replace. Regards Steve > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Tue Dec 6 18:58:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 037A6C6ADEB for ; Tue, 6 Dec 2016 18:58:10 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AB90E67 for ; Tue, 6 Dec 2016 18:58:09 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id uB6Iw0ov095527; Tue, 6 Dec 2016 21:58:00 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 6 Dec 2016 21:58:00 +0300 (MSK) From: Dmitry Morozovsky To: Alex Tutubalin cc: freebsd-fs@freebsd.org Subject: Re: 11-STABLE vs 11.0-RELENG test In-Reply-To: Message-ID: References: <477264f9-9263-6df8-4566-2911e84f2ad8@lexa.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 06 Dec 2016 21:58:00 +0300 (MSK) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 18:58:10 -0000 On Tue, 6 Dec 2016, Alex Tutubalin wrote: > On 12/6/2016 8:12 PM, Andriy Gapon wrote: > > > Could you please try starting with a freshly created pool and writing some > > data? > > Sorry, this is working box with active data. No way to create fresh pool from > it. I hope I could build a testbed (though rather slow machine, with only 4G of memory) to test this in the next few days. I'll report intermediate results as (and if) they come. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-fs@freebsd.org Tue Dec 6 20:26:26 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10656C6AA5D for ; Tue, 6 Dec 2016 20:26:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B07AF1001; Tue, 6 Dec 2016 20:26:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id u144so23699933wmu.0; Tue, 06 Dec 2016 12:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=rbgkUp1g3sVbNFFPCgueXPoCKV0sDZWuBHErZWLXGtE=; b=Hc124s1Tu++uWs3AoA8H8KU2XXLGtjIoIhRbbylQrne6rBw8Bx7WDy5LsW5f+rQuWa aPytFyWp1h/iCCeV2qKg6V/bxdcTs2Hik43wLSLzN8LN11cEtRoF65hw+29BGCoX0azD oXeXUpqwIhfRGwfl61bWGI82MmfyAA1oZW/o1BCmGy9Pe+5TPQBsi59SjNE9M4Hd6152 +z8AOGkgGXLVNXBsobKKLgkIN9vyP18C8GYPiPhhA1JCAQKBooRCvJgEPGfivtFjCDKS K5cWuZquZ+lSMcF5NlT3qcgUJutiOARx1dOGGzrjPH8NMf2VQKWVBmUFVz0rcRiP8bYo 4CQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:to:cc:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=rbgkUp1g3sVbNFFPCgueXPoCKV0sDZWuBHErZWLXGtE=; b=BlBUMaI/V7PJJSFboud4S9VzwDsf0buHVfKyFfAGWl/0D6Rzc//YzYf6FrtedtTqj8 0xVrqXRjHO0oSa8X4ql76sOlkQvhm0GOCQg4jDDscS0LRlf/DZ5wKGsQoo9n4y4hA4xu Ux4FJV0evisbQ9RWEeTU9U7QXl9bYFUNfo/w1FzP0ozLyQmlbxsP5GBar+diIRo2V27s n0k66b6LYKx36fOr30auFAnfqNPdmXP1mlbAbl59Ez9czWFlZmSOJQrQgXVZo36UuoO4 81JGjClcQpCn5BEKd2T4m9Y3yMyzg8mPvm1OWZLtXPfJEKqQ31VOqQ4a5Dhzm+LMlGzZ KxMA== X-Gm-Message-State: AKaTC00tSbToRHyB0os33D5CuoBNbwqx84c2HN8VBjNwa4glxmqrtoIaHniJsyxhJ3sdHQ== X-Received: by 10.46.76.18 with SMTP id z18mr30092861lja.38.1481055983079; Tue, 06 Dec 2016 12:26:23 -0800 (PST) Received: from spectre.mavhome.dp.ua ([134.249.139.101]) by smtp.gmail.com with ESMTPSA id y10sm4129645lja.45.2016.12.06.12.26.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 12:26:22 -0800 (PST) Sender: Alexander Motin To: freebsd-fs@FreeBSD.org Cc: Alex Tutubalin , Andriy Gapon From: Alexander Motin Subject: Re: 11-STABLE vs 11.0-RELENG test Message-ID: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> Date: Tue, 6 Dec 2016 22:26:21 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 20:26:26 -0000 On 06/12/2016 18:17, Alex Tutubalin wrote: > Followup, same box as in 1st message, but with different HBA and 5 HDD: > > Summary: > 1) read speed depends on 'on-disk' data, not by code used while read. > 2) FreeBSD 11.0-releng (svn up today) creates 'fast' big files (420+ Mb/s read > speed) > 3) FreeBSD 11-STABLE creates 'slow' big files. (~200 Mb/s) > 4) zfs send slow-dataset | zfs recv (under 11.0-releng) creates > 'intermediate' files (320Mb/s) > 5) file copy slow-file ... (under 11.0-releng) creates fast copy (400+Mb/s) > > So, ZFS write code in 11-STABLE looks broken. I've reproduced this issue with quick test on my lab system configured with 12-disk RAIDZ2 pool. I've measured write and read back (with and without prefetch) speeds for pool recreated on different FreeBSD head revisions: r309625 r305456 r305330 r305322 write 702 701 1115 1120 read w/ pref 232 228 518 512 read w/o pref 128 126 242 240 I suspect we could obtain the problem here: r305331 | mav | 2016-09-03 13:04:37 +0300 (сб, 03 сент. 2016) | 45 lines MFV r304155: 7090 zfs should improve allocation order and throttle allocations I'll take closer look on that change tomorrow. -- Alexander Motin From owner-freebsd-fs@freebsd.org Tue Dec 6 20:35:05 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A9EAC6AF60 for ; Tue, 6 Dec 2016 20:35:05 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4D01160F; Tue, 6 Dec 2016 20:35:04 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id uB6KZ1uH097358; Tue, 6 Dec 2016 23:35:01 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 6 Dec 2016 23:35:01 +0300 (MSK) From: Dmitry Morozovsky To: Alexander Motin cc: freebsd-fs@freebsd.org, Andriy Gapon Subject: Re: 11-STABLE vs 11.0-RELENG test In-Reply-To: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> Message-ID: References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 06 Dec 2016 23:35:01 +0300 (MSK) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 20:35:05 -0000 On Tue, 6 Dec 2016, Alexander Motin wrote: [snip] > > So, ZFS write code in 11-STABLE looks broken. > > I've reproduced this issue with quick test on my lab system configured > with 12-disk RAIDZ2 pool. I've measured write and read back (with and > without prefetch) speeds for pool recreated on different FreeBSD head > revisions: > r309625 r305456 r305330 r305322 > write 702 701 1115 1120 > read w/ pref 232 228 518 512 > read w/o pref 128 126 242 240 > > I suspect we could obtain the problem here: > > r305331 | mav | 2016-09-03 13:04:37 +0300 (сб, 03 сент. 2016) | 45 lines > > MFV r304155: 7090 zfs should improve allocation order and throttle > allocations > > I'll take closer look on that change tomorrow. Thanks a lot for quick test, I'll abandon my weak test lab then. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-fs@freebsd.org Tue Dec 6 20:43:30 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79EC3C6B297 for ; Tue, 6 Dec 2016 20:43:30 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wj0-x22d.google.com (mail-wj0-x22d.google.com [IPv6:2a00:1450:400c:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D6BB1A30 for ; Tue, 6 Dec 2016 20:43:30 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wj0-x22d.google.com with SMTP id v7so336843720wjy.2 for ; Tue, 06 Dec 2016 12:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=Fo4vYUBoOnRMFImXxAbkjc+GzK+DNhukC4eLPKoqEq8=; b=MFTZsszxP7/N8htOIb9xuMwGKyLJM1rJhpqolORQA91xZL+EgMMwtsCqvcZd4AENF7 9YI5ZIK81PEVMiSZaLj8LKJqBBZECfJS9V5AoJBNB0rBfaBc7W6dZR/K6Rk5Gt5gZkwj 7KzVDcRUAT7DWi2oCz4PqvSPIYxuubQ2ld8kXsb3Gfdd5+Me9OT8MKGprQhh0m4PIAaQ anj/OqRR+OpZ+jNtpqlEzg9Xj8HmJLpHgVvsvNA9s4Gwh6mgdsL7nQoBpAPIWZVNZ6YN 9wbL+XyVo2GTI7oGs8Noi7k1kEdF902FqgdDx6uEyLRKC7Sx4Ts9K0E1OQWb11BDWLVV 4VWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Fo4vYUBoOnRMFImXxAbkjc+GzK+DNhukC4eLPKoqEq8=; b=I7pC34QgqY6urlKqydTh79rOhit9m7M9aZYh0GV3RGLy/z0IYxZqyUZDPQGiNx7Go4 tuZWfm1k6NaM5dJhudYOkNFxRBO5U7RH270XRTlEGb2twkktL8qLloldojrhKOL9ps3i afiKM+vQZcW9aOpL3iQ2zpulPnRwIktL5Y09TRmENszvVhjifBTX2Izjnk1xvTOsjuez wmR3wAZCjwnOYgLMgUd6PxDIJs/PkitRl3hkt+rPGIhyIGaqWhdIRd/H0ki00Oh4GnyC vmkOlZxE9ewc3WUxLoE2ss39JdqAQeT420z1q1OaQsMj4gklKShmPL3lgIDcOb4TyAtj t84A== X-Gm-Message-State: AKaTC03QYp67+yzXFbiM1pN/+xlX3MHw6iQNfMnoaElIOVNH5cDxYnudaiRaS4UOD8Wlp6tv X-Received: by 10.194.107.97 with SMTP id hb1mr54505682wjb.134.1481057007973; Tue, 06 Dec 2016 12:43:27 -0800 (PST) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id bj1sm27621634wjc.17.2016.12.06.12.43.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 12:43:26 -0800 (PST) Subject: Re: 11-STABLE vs 11.0-RELENG test To: freebsd-fs@freebsd.org References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> From: Steven Hartland Message-ID: <4fec6972-c543-00a5-0d5c-b0614311ba13@multiplay.co.uk> Date: Tue, 6 Dec 2016 20:43:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 20:43:30 -0000 On 06/12/2016 20:26, Alexander Motin wrote: > On 06/12/2016 18:17, Alex Tutubalin wrote: >> Followup, same box as in 1st message, but with different HBA and 5 HDD: >> >> Summary: >> 1) read speed depends on 'on-disk' data, not by code used while read. >> 2) FreeBSD 11.0-releng (svn up today) creates 'fast' big files (420+ > Mb/s read >> speed) >> 3) FreeBSD 11-STABLE creates 'slow' big files. (~200 Mb/s) >> 4) zfs send slow-dataset | zfs recv (under 11.0-releng) creates >> 'intermediate' files (320Mb/s) >> 5) file copy slow-file ... (under 11.0-releng) creates fast copy > (400+Mb/s) >> So, ZFS write code in 11-STABLE looks broken. > I've reproduced this issue with quick test on my lab system configured > with 12-disk RAIDZ2 pool. I've measured write and read back (with and > without prefetch) speeds for pool recreated on different FreeBSD head > revisions: > r309625 r305456 r305330 r305322 > write 702 701 1115 1120 > read w/ pref 232 228 518 512 > read w/o pref 128 126 242 240 > > I suspect we could obtain the problem here: > > r305331 | mav | 2016-09-03 13:04:37 +0300 (сб, 03 сент. 2016) | 45 lines > > MFV r304155: 7090 zfs should improve allocation order and throttle > allocations > > I'll take closer look on that change tomorrow. > Does setting vfs.zfs.zio.dva_throttle_enabled=0 fix / improve performance? Regards Steve From owner-freebsd-fs@freebsd.org Tue Dec 6 21:00:36 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7543EC6B6BA for ; Tue, 6 Dec 2016 21:00:36 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0919E31E for ; Tue, 6 Dec 2016 21:00:36 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x231.google.com with SMTP id t79so140791151wmt.0 for ; Tue, 06 Dec 2016 13:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=t/n6EwmtLqMwHWDdW9AFEDsLWoOK/fPkkztRRnmTpcc=; b=wQfWr5xaauyG58eNQr6o+2gu/lyvrSyyGl57vd3sZQ0Im3Lwmo3mc4DsrLIFl9mk+4 RUGpHzZ4RuTYLuBrSq06RX6pFyZQg91NgC5zllrp4Z0nxIq2hp7KdcLKY0+tq4q14HSd DZS7u+qUSAq7G1+5x656rFSZ0KHBuMLto/qrYBODEYeoM0uuxODaBusGgASycPVi+HUj L3GMQDCkw3/XB7oqdiEeczZj/mvLFuLF4KVPbE2LVGROCcC192BSSxcu2Tq6+Z0bcPli U0sE6HRY7QbMVRx6B3WGuIctrpCyr+PMmR6e3O+/RPIOg2NxDlYxSPbUjJrfVtVg4zK9 yK2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=t/n6EwmtLqMwHWDdW9AFEDsLWoOK/fPkkztRRnmTpcc=; b=hJS2PrebLikkihQ3umIzwZ70cFP4xge4QX5+iv515ZwE7A4RvDye10cvkTaI9SkYVb VqgAdovhiutQetWvNOhRBJnZD1rn37pwTnenzMAJDQhUxZE4VjWbzNK2US3nivFp4NPD 1pEwj/1yS0Si43CiQxGfcU2SrPm3rYcMRzXRdvzNFvNYSjqvuEfzgHCJ+Mnxa7DYnHu/ yizUiOLFXOmCVzEO5zeCV4hXhksXa1pQwGNChanxVfg9VSCHlcPQXWtgPJ0xyy3qKiYn A/DfecrdJOo9fvnrapDLEiOZm9zbTRv7QY6c+lcYuEv0iY8g0/OZ+J6GQwIoz3FDGkA7 86Ww== X-Gm-Message-State: AKaTC02o9x0b7dAXX5/JbVTTMuI9cEUQnqBiKBxJcgh6hiHxF3LtJMRtdZecgSJd5MIByJEJ X-Received: by 10.28.164.196 with SMTP id n187mr418981wme.44.1481058034225; Tue, 06 Dec 2016 13:00:34 -0800 (PST) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id v2sm27660330wja.41.2016.12.06.13.00.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 13:00:33 -0800 (PST) Subject: Re: 11-STABLE vs 11.0-RELENG test To: freebsd-fs@freebsd.org References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> From: Steven Hartland Message-ID: Date: Tue, 6 Dec 2016 21:01:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 21:00:36 -0000 On 06/12/2016 20:26, Alexander Motin wrote: > On 06/12/2016 18:17, Alex Tutubalin wrote: >> Followup, same box as in 1st message, but with different HBA and 5 HDD: >> >> Summary: >> 1) read speed depends on 'on-disk' data, not by code used while read. >> 2) FreeBSD 11.0-releng (svn up today) creates 'fast' big files (420+ > Mb/s read >> speed) >> 3) FreeBSD 11-STABLE creates 'slow' big files. (~200 Mb/s) >> 4) zfs send slow-dataset | zfs recv (under 11.0-releng) creates >> 'intermediate' files (320Mb/s) >> 5) file copy slow-file ... (under 11.0-releng) creates fast copy > (400+Mb/s) >> So, ZFS write code in 11-STABLE looks broken. > I've reproduced this issue with quick test on my lab system configured > with 12-disk RAIDZ2 pool. I've measured write and read back (with and > without prefetch) speeds for pool recreated on different FreeBSD head > revisions: > r309625 r305456 r305330 r305322 > write 702 701 1115 1120 > read w/ pref 232 228 518 512 > read w/o pref 128 126 242 240 > > I suspect we could obtain the problem here: > > r305331 | mav | 2016-09-03 13:04:37 +0300 (сб, 03 сент. 2016) | 45 lines > > MFV r304155: 7090 zfs should improve allocation order and throttle > allocations > > I'll take closer look on that change tomorrow. > Other sysctls which may have an impact are: vfs.zfs.vdev.async_write_max_active vfs.zfs.vdev.queue_depth_pct Regards Steve From owner-freebsd-fs@freebsd.org Wed Dec 7 06:57:50 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99F3AC6BFC7 for ; Wed, 7 Dec 2016 06:57:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89BAA1039 for ; Wed, 7 Dec 2016 06:57:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB76voYg080568 for ; Wed, 7 Dec 2016 06:57:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212861] [tmpfs] uchg files can be removed by root Date: Wed, 07 Dec 2016 06:57:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 06:57:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212861 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: ngie Date: Wed Dec 7 06:57:09 UTC 2016 New revision: 309668 URL: https://svnweb.freebsd.org/changeset/base/309668 Log: MFC r306030,r306031,r306033,r306036,r306038,r307190,r307196,r307204,r307205,r30= 7701,r307702: r306030: Port vnode_leak_test:main to FreeBSD Use a simpler way of dumping kern.maxvnodes, i.e. `sysctl -n kern.maxvnod= es` The awk filtering method employed in NetBSD doesn't work on FreeBSD r306031: Port contrib/netbsd-tests/fs/h_funcs.subr to FreeBSD Use kldstat -m to determine whether or not a filesystem is loaded. This w= orks well with tmpfs, ufs, and zfs r306033: Port sizes_test and statvfs_test to FreeBSD Similar to r306030, use a simpler method for getting the value of `hw.pagesize`, i.e. `sysctl -n hw.pagesize`. The awk filtering method doe= sn't work on FreeBSD r306036: Port to mknod_test and readdir_test to FreeBSD The `mknod p` command doesn't exist on FreeBSD, like on NetBSD. Use mkfifo instead to create named pipes (FIFOs). r306038: Port vnd_test to FreeBSD Use mdmfs/mdconfig instead of vndconfig/newfs. vndconfig doesn't exist on FreeBSD. TODO: need to parameterize out the md(4) device as it's currently hardcod= ed to "3" (in both the FreeBSD and NetBSD cases). r307190: Skip :uchg on FreeBSD Unfortunately removing files with uchg set always succeeds with root on FreeBSD. Unfortunately running the test as an unprivileged user isn't doa= ble because mounting tmpfs requires root PR: 212861 r307196: Port contrib/netbsd-tests/fs/tmpfs/h_tools.c to FreeBSD - Add inttypes.h #include for PRId64 macro - Use FreeBSD's copy of getfh(2), which doesn't include a `fh_size` parameter. Use sizeof(fhandle_t) instead as the size of fhp is always fixed as fhandle_t, unlike NetBSD's copy of fhp, which is void*. r307204: Expect :large to fail on FreeBSD FreeBSD doesn't appear to validate large -o size values like NetBSD does PR: 212862 r307205: Change atf_skip call to atf_expect_fail to make it clear that a failure is expected PR: 212861 Suggested by: jmmv r307701: Expect tests/sys/fs/tmpfs/link_test:kqueue to fail It fails with: "dir/b did not receive NOTE_LINK" Also, add needed cleanup logic to cleanup the mountpoint after the fact PR: 213662 r307702: Integrate contrib/netbsd-tests/fs/tmpfs into the FreeBSD test suite as tests/sys/fs These testcases exercise tmpfs support Changes: _U stable/11/ stable/11/contrib/netbsd-tests/fs/h_funcs.subr stable/11/contrib/netbsd-tests/fs/tmpfs/h_tools.c stable/11/contrib/netbsd-tests/fs/tmpfs/t_link.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_mknod.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_mount.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_readdir.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_remove.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_sizes.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_statvfs.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_vnd.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_vnode_leak.sh stable/11/etc/mtree/BSD.tests.dist stable/11/tests/sys/Makefile stable/11/tests/sys/fs/ --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Dec 7 06:57:53 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC90AC6BFDB for ; Wed, 7 Dec 2016 06:57:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC8021044 for ; Wed, 7 Dec 2016 06:57:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uB76vr85080678 for ; Wed, 7 Dec 2016 06:57:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212861] [tmpfs] uchg files can be removed by root Date: Wed, 07 Dec 2016 06:57:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 06:57:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212861 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: ngie Date: Wed Dec 7 06:57:09 UTC 2016 New revision: 309668 URL: https://svnweb.freebsd.org/changeset/base/309668 Log: MFC r306030,r306031,r306033,r306036,r306038,r307190,r307196,r307204,r307205,r30= 7701,r307702: r306030: Port vnode_leak_test:main to FreeBSD Use a simpler way of dumping kern.maxvnodes, i.e. `sysctl -n kern.maxvnod= es` The awk filtering method employed in NetBSD doesn't work on FreeBSD r306031: Port contrib/netbsd-tests/fs/h_funcs.subr to FreeBSD Use kldstat -m to determine whether or not a filesystem is loaded. This w= orks well with tmpfs, ufs, and zfs r306033: Port sizes_test and statvfs_test to FreeBSD Similar to r306030, use a simpler method for getting the value of `hw.pagesize`, i.e. `sysctl -n hw.pagesize`. The awk filtering method doe= sn't work on FreeBSD r306036: Port to mknod_test and readdir_test to FreeBSD The `mknod p` command doesn't exist on FreeBSD, like on NetBSD. Use mkfifo instead to create named pipes (FIFOs). r306038: Port vnd_test to FreeBSD Use mdmfs/mdconfig instead of vndconfig/newfs. vndconfig doesn't exist on FreeBSD. TODO: need to parameterize out the md(4) device as it's currently hardcod= ed to "3" (in both the FreeBSD and NetBSD cases). r307190: Skip :uchg on FreeBSD Unfortunately removing files with uchg set always succeeds with root on FreeBSD. Unfortunately running the test as an unprivileged user isn't doa= ble because mounting tmpfs requires root PR: 212861 r307196: Port contrib/netbsd-tests/fs/tmpfs/h_tools.c to FreeBSD - Add inttypes.h #include for PRId64 macro - Use FreeBSD's copy of getfh(2), which doesn't include a `fh_size` parameter. Use sizeof(fhandle_t) instead as the size of fhp is always fixed as fhandle_t, unlike NetBSD's copy of fhp, which is void*. r307204: Expect :large to fail on FreeBSD FreeBSD doesn't appear to validate large -o size values like NetBSD does PR: 212862 r307205: Change atf_skip call to atf_expect_fail to make it clear that a failure is expected PR: 212861 Suggested by: jmmv r307701: Expect tests/sys/fs/tmpfs/link_test:kqueue to fail It fails with: "dir/b did not receive NOTE_LINK" Also, add needed cleanup logic to cleanup the mountpoint after the fact PR: 213662 r307702: Integrate contrib/netbsd-tests/fs/tmpfs into the FreeBSD test suite as tests/sys/fs These testcases exercise tmpfs support Changes: _U stable/11/ stable/11/contrib/netbsd-tests/fs/h_funcs.subr stable/11/contrib/netbsd-tests/fs/tmpfs/h_tools.c stable/11/contrib/netbsd-tests/fs/tmpfs/t_link.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_mknod.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_mount.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_readdir.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_remove.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_sizes.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_statvfs.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_vnd.sh stable/11/contrib/netbsd-tests/fs/tmpfs/t_vnode_leak.sh stable/11/etc/mtree/BSD.tests.dist stable/11/tests/sys/Makefile stable/11/tests/sys/fs/ --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Dec 7 13:34:06 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAA5CC6BA93 for ; Wed, 7 Dec 2016 13:34:06 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FC2311BA; Wed, 7 Dec 2016 13:34:06 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id u144so27828941wmu.0; Wed, 07 Dec 2016 05:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=WpWTUDBFz/th7g1U2rJcluVyKyUTqm8NxVnSNjWxA+8=; b=MEV35tajgyF8FTX8UiWQSH9dURiUqpIPjbjN6gWZYdTSyMbeVpD584H2x7yHY8rtvh uzQJny503WFWYmURi4C0bFRvgA9ztc8kK5i9shZPtSemwZu7LnaW9v71XpJeSO1iEry0 X9PbGgUpGHJ07qpK7bS6LyafYUgKGPGdoyoKGI8mTLScMMFcWkar8hkbEMmK2XvHVlbT x03KKT0pbuM4U+CX966Rc2mhVhQK9hfo08xA2F5diz5MYpYzgL3cDexVKauKLt/iq0Wq mQrySRMuSuLKhQvSvEBppP0W0BhplKp70MI8zMdH0FzLeIhWczX30GjSwX09aj+aPNnn LgMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WpWTUDBFz/th7g1U2rJcluVyKyUTqm8NxVnSNjWxA+8=; b=MYe59L0wkcmdC6bxv5hr5RWARV2pLEiuPzPMgArXIY5wy8leNjXqRUTi8Vxo95vWrF IyENUEW0VG2mR4QOeUCYfQ2EyEdAh++mcVoYbb6gdK1cu4CDo8yN7UtuZGMcwpqAfQre Li2azQBNO3NsCNl3m2fwwoYUR3ijFB1MyKTgWR1tkeGLYco+NoCK2+mRy5smpO2rmOAg YQMGoGIVqFtOXo1pGIQultPw20jlrNJRBtnsvncytomCsdM4o9emR4Z9i4xIVZ6jyiCe SAIx7N7EEkmnuG1FAZiBG9WaQA6qMhYkA4v4Ic12FChnOYc2WmtFfHOPtH6MZvPdmf+l IySw== X-Gm-Message-State: AKaTC00+Iv7ZYfBX7+IgcuEV3sxyShUK6FhSmf5n5wy2fduDCSsOp6OwuugxOV6w830b7A== X-Received: by 10.25.72.74 with SMTP id v71mr25245618lfa.130.1481117644505; Wed, 07 Dec 2016 05:34:04 -0800 (PST) Received: from spectre.mavhome.dp.ua ([134.249.139.101]) by smtp.gmail.com with ESMTPSA id z26sm4741330lja.49.2016.12.07.05.34.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Dec 2016 05:34:03 -0800 (PST) Sender: Alexander Motin Subject: Re: 11-STABLE vs 11.0-RELENG test To: freebsd-fs@FreeBSD.org References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> Cc: Alex Tutubalin , Andriy Gapon From: Alexander Motin Message-ID: <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> Date: Wed, 7 Dec 2016 15:34:02 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 13:34:07 -0000 On 06.12.2016 22:26, Alexander Motin wrote: > I've reproduced this issue with quick test on my lab system configured > with 12-disk RAIDZ2 pool. I've measured write and read back (with and > without prefetch) speeds for pool recreated on different FreeBSD head > revisions: > r309625 r305456 r305330 r305322 > write 702 701 1115 1120 > read w/ pref 232 228 518 512 > read w/o pref 128 126 242 240 > > I suspect we could obtain the problem here: > > r305331 | mav | 2016-09-03 13:04:37 +0300 (сб, 03 сент. 2016) | 45 lines > > MFV r304155: 7090 zfs should improve allocation order and throttle > allocations Closer look shown me the cause. This code sorts I/Os on time, offset and memory address. But time on FreeBSD (to reduce overhead) returned with 1ms resolution, so it does not provide reliable ordering. Offset sorting used by this patch is broken by design, since io_offset field is always zero there, since it is used only for physical I/Os, not for logical. As result, I/Os are "sorted" on memory address, that in fact means complete randomization of all allocations within one millisecond, predictably killing read performance. Switching gethrtime() emulation from getnanouptime() to nanouptime() fixes the read performance, resulting: nanouptime() write 702 read w/ pref 845 read w/o pref 272 It would be good to make offset sorting really work there rather then just switching to high resolution time source, but that maybe quite invasive. Will look more. -- Alexander Motin From owner-freebsd-fs@freebsd.org Wed Dec 7 15:56:16 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60B83C6B8EF for ; Wed, 7 Dec 2016 15:56:16 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: from mx3.lexa.ru (mx3.lexa.ru [198.27.68.102]) by mx1.freebsd.org (Postfix) with ESMTP id 43B091E64 for ; Wed, 7 Dec 2016 15:56:15 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: by mx3.lexa.ru (Postfix, from userid 66) id E5B7E224A5F; Wed, 7 Dec 2016 10:56:08 -0500 (EST) Received: from [193.124.130.130] (unknown [193.124.130.130]) by home-gw.lexa.ru (Postfix) with ESMTP id 7938EB0583 for ; Wed, 7 Dec 2016 18:54:30 +0300 (MSK) Subject: Re: 11-STABLE vs 11.0-RELENG test To: freebsd-fs@FreeBSD.org References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> From: Alex Tutubalin Message-ID: Date: Wed, 7 Dec 2016 18:54:31 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 15:56:16 -0000 On 12/6/2016 11:26 PM, Alexander Motin wrote: > I've reproduced this issue with quick test on my lab system configured Do I need to file official bug, or (hopefully) things will go to the right way without it? -- Alex Tutubalin Web: http://blog.lexa.ru mailto:lexa@lexa.ru From owner-freebsd-fs@freebsd.org Wed Dec 7 16:49:38 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A074C6CA9F for ; Wed, 7 Dec 2016 16:49:38 +0000 (UTC) (envelope-from george.wilson@delphix.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF88494D for ; Wed, 7 Dec 2016 16:49:37 +0000 (UTC) (envelope-from george.wilson@delphix.com) Received: by mail-qk0-x232.google.com with SMTP id n204so419505274qke.2 for ; Wed, 07 Dec 2016 08:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3SQSLgrd+GqGvRzzqSYea+SrIgiTXE4WOz7wpilMAmw=; b=eXDq3TZSVVWvElFzn236x1pNhUco58WeHOW+GmCixvpLWkAY3JWLKyuE3bX0a3zPOX QOx5iedQ76eDUctBrO7/BpAXyWjEe6sCq3eK7NFumsxbMz2hM/OwtyiuYbyuuEquhF4e AblSJn6E10j2ujkCxQ8QiZODCp0gOtVf82SMM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3SQSLgrd+GqGvRzzqSYea+SrIgiTXE4WOz7wpilMAmw=; b=Tlwo6iCWdzbxWwYlhFETgpu0VLrYCPgFFQ3XMzvVqOfK1u9n8f6pYsONdJX2S3sLgS Ov1beGWYc0aU5lQkWWN3nFoSqesjRAPrbQ+b9Ft2xIJ0MUAKjYUL96P6Y5w5+r1CTSp/ RZcN8VKfsJDJTk62dR3fYRusrAXUGyc1mzWKRJwf9uAdRw/2Gm2V6bWmdssL7sV8Hq9k Nq1Q32MTJWUFwXod2lxTuffu4xV5EgQcPoGkjhzB2bp013ClWbtYQgEs0brXJrPouCdx c4JEem/VEmzeo9JzP57ncf/FAjIbY2wdazbsY0NWcG+KLl2l7xlyYO81fLZuSmT8Wft5 MSBw== X-Gm-Message-State: AKaTC02g9LU/lPh1dUu/p5YWExz46AN5aRALVCIs3jYEeQL/hG2HaR43/yPQGH/Ns3mxYqDfNmXlqfC0t1ZY3rJf X-Received: by 10.55.79.86 with SMTP id d83mr57272490qkb.24.1481129376872; Wed, 07 Dec 2016 08:49:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.46.58 with HTTP; Wed, 7 Dec 2016 08:49:36 -0800 (PST) In-Reply-To: <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> From: George Wilson Date: Wed, 7 Dec 2016 11:49:36 -0500 Message-ID: Subject: Re: 11-STABLE vs 11.0-RELENG test To: Alexander Motin Cc: freebsd-fs@freebsd.org, Alex Tutubalin , Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 16:49:38 -0000 Alexander, Nice find! It's true that io_offset is 0 when we sort but the offset ordering should be implied by the way the way that we issue the I/Os from dbuf_sync_list(). The I/Os are issued in order within the file which is what we want. So having the offset comparison is probably not needed but we could use the bookmark's blkid as a new comparator. Let me know if I can help. Thanks, George On Wed, Dec 7, 2016 at 8:34 AM, Alexander Motin wrote: > On 06.12.2016 22:26, Alexander Motin wrote: > > I've reproduced this issue with quick test on my lab system configured > > with 12-disk RAIDZ2 pool. I've measured write and read back (with and > > without prefetch) speeds for pool recreated on different FreeBSD head > > revisions: > > r309625 r305456 r305330 r305322 > > write 702 701 1115 1120 > > read w/ pref 232 228 518 512 > > read w/o pref 128 126 242 240 > > > > I suspect we could obtain the problem here: > > > > r305331 | mav | 2016-09-03 13:04:37 +0300 (=D1=81=D0=B1, 03 =D1=81=D0= =B5=D0=BD=D1=82. 2016) | 45 lines > > > > MFV r304155: 7090 zfs should improve allocation order and throttle > > allocations > > Closer look shown me the cause. This code sorts I/Os on time, offset > and memory address. But time on FreeBSD (to reduce overhead) returned > with 1ms resolution, so it does not provide reliable ordering. Offset > sorting used by this patch is broken by design, since io_offset field is > always zero there, since it is used only for physical I/Os, not for > logical. As result, I/Os are "sorted" on memory address, that in fact > means complete randomization of all allocations within one millisecond, > predictably killing read performance. > > Switching gethrtime() emulation from getnanouptime() to nanouptime() > fixes the read performance, resulting: > nanouptime() > write 702 > read w/ pref 845 > read w/o pref 272 > > It would be good to make offset sorting really work there rather then > just switching to high resolution time source, but that maybe quite > invasive. Will look more. > > -- > Alexander Motin > From owner-freebsd-fs@freebsd.org Wed Dec 7 19:08:21 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56A30C6C727 for ; Wed, 7 Dec 2016 19:08:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFEEB1A6A for ; Wed, 7 Dec 2016 19:08:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id a197so182772590wmd.0 for ; Wed, 07 Dec 2016 11:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=2K+bOx6D5x3LQAcI+n5YHoIyggM+gDDe9Y6SU1TD2F4=; b=Cp2KDG+lTtz0/mCqPo316CEBR5x3Zev6exPIBCsTEh5EBrPbSb1TOLaEe0FifJFePv LIlSTu0sR0iMhTT+T+/d0MuoRp0xMo3XfbpGuw1lZX4zpvS96m3gp2OLIvgy6XRTxsL0 iDa2jNVrJ1s1SebuPNGe2cmCI54s6aZnAhBsdO5w5vI7/gDjPP1eYh/wsSoL5T+HXltC vDV8QmlYrEonsWX2wrzc7NlFdKQnw4PINdmizf++HIIpyf913nLj3L3kxv3fDxS6V9Jw Drw0EqG+QcssDFp9kor4pzGoNphibqqyrWIHbbza3BBzm3TxGx3kAyNeQNDyX7dZGM8v cw4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2K+bOx6D5x3LQAcI+n5YHoIyggM+gDDe9Y6SU1TD2F4=; b=b3yU/6riJ2AlqZ2ejXmK2Bs1zD9NXCi/l9kdbqlQWPcOWVa4NM1vpadYaQeTDR0bHF 1a3MoEvydFoebOqt0UIJXKvvJLs5d2JP2LBXiJsjNufeUTa4l4H/SesY/I6aOsk3aPqD 5ePTyBDPNtfQ8GKgh3yKSjRlaDllTs/cRhV0LZd+ovfd5MYOgeED0aLEhB+lVbS6QaEk TQJFtJfnUE0h2TI5cggDGNHbpth462NYl347fvN4/vQv7nNb338h4On/lC/dY23xeLzq 9agLoXI2ryuuq2zYM581VdqDGKtI8p2v8PJDo5xDi+zwEJPMhvawi46eA63pkqYLbWZb aZug== X-Gm-Message-State: AKaTC01MG6kX34doNpSLcVdczl4qmzsHuTZz9LiPRcRq/KVgs7aqO27Ctv+BaPAGmV9Msg== X-Received: by 10.25.22.166 with SMTP id 38mr24890770lfw.11.1481137698995; Wed, 07 Dec 2016 11:08:18 -0800 (PST) Received: from spectre.mavhome.dp.ua ([134.249.139.101]) by smtp.gmail.com with ESMTPSA id t15sm4893774lfe.13.2016.12.07.11.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Dec 2016 11:08:18 -0800 (PST) Sender: Alexander Motin Subject: Re: 11-STABLE vs 11.0-RELENG test To: freebsd-fs@FreeBSD.org References: <8b4ba98d-03d3-f671-33b2-ed12d3b4fb7c@FreeBSD.org> <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> From: Alexander Motin Message-ID: <0b0a2d6c-59f2-aa0e-01ca-ca2613ccbe57@FreeBSD.org> Date: Wed, 7 Dec 2016 21:08:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <374b6d16-5cb4-9338-ec1d-65ad93ca29dc@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:08:21 -0000 On 07.12.2016 15:34, Alexander Motin wrote: > Closer look shown me the cause. This code sorts I/Os on time, offset > and memory address. But time on FreeBSD (to reduce overhead) returned > with 1ms resolution, so it does not provide reliable ordering. Offset > sorting used by this patch is broken by design, since io_offset field is > always zero there, since it is used only for physical I/Os, not for > logical. As result, I/Os are "sorted" on memory address, that in fact > means complete randomization of all allocations within one millisecond, > predictably killing read performance. > > Switching gethrtime() emulation from getnanouptime() to nanouptime() > fixes the read performance, resulting: > nanouptime() > write 702 > read w/ pref 845 > read w/o pref 272 > > It would be good to make offset sorting really work there rather then > just switching to high resolution time source, but that maybe quite > invasive. Will look more. PS: If somebody needs quick workaround, this loader tunable restores both read and write speed: vfs.zfs.zio.dva_throttle_enabled=0. -- Alexander Motin From owner-freebsd-fs@freebsd.org Sat Dec 10 03:05:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 125DEC6F419 for ; Sat, 10 Dec 2016 03:05:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 022921FF for ; Sat, 10 Dec 2016 03:05:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA359bd043960 for ; Sat, 10 Dec 2016 03:05:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 215119] gmirror stop not possible when labels present Date: Sat, 10 Dec 2016 03:05:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:05:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215119 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Dec 10 03:18:51 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AB1CC6FB77 for ; Sat, 10 Dec 2016 03:18:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A1E1100F for ; Sat, 10 Dec 2016 03:18:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3Io7V014880 for ; Sat, 10 Dec 2016 03:18:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 215067] [zfs] g_dev_taste: make_dev_p() failed on importing pool with snapshots with long names Date: Sat, 10 Dec 2016 03:18:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:18:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215067 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org CC|freebsd-amd64@FreeBSD.org | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Dec 10 03:28:03 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6276AC6F707 for ; Sat, 10 Dec 2016 03:28:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51F091E2E for ; Sat, 10 Dec 2016 03:28:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3S2BF000979 for ; Sat, 10 Dec 2016 03:28:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 214981] POLA violation: ZFS happily and silently remounts any existing mount on pool import Date: Sat, 10 Dec 2016 03:28:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:28:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214981 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Dec 10 03:28:15 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88D9BC6F761 for ; Sat, 10 Dec 2016 03:28:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70D711EDB for ; Sat, 10 Dec 2016 03:28:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA3SFYm006604 for ; Sat, 10 Dec 2016 03:28:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 214976] SMBFS-mount hangs indefinitely when opening many files at once Date: Sat, 10 Dec 2016 03:28:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 03:28:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214976 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- CC|freebsd-i386@FreeBSD.org | Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Dec 10 05:27:55 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DCE7C70AA4 for ; Sat, 10 Dec 2016 05:27:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AACA696 for ; Sat, 10 Dec 2016 05:27:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBA5Rt7o061083 for ; Sat, 10 Dec 2016 05:27:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 214981] POLA violation: ZFS happily and silently remounts any existing mount on pool import Date: Sat, 10 Dec 2016 05:27:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eborisch+FreeBSD@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 05:27:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214981 --- Comment #1 from eborisch+FreeBSD@gmail.com --- Related: Bug #210222 --=20 You are receiving this mail because: You are the assignee for the bug.=