From owner-freebsd-fs@freebsd.org Sun May 14 21:00:30 2017 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 96563D6C247 for ; Sun, 14 May 2017 21:00: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 8D2D316AD for ; Sun, 14 May 2017 21:00: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 v4EL01vt029899 for ; Sun, 14 May 2017 21:00:30 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201705142100.v4EL01vt029899@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, 14 May 2017 21:00:30 +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, 14 May 2017 21:00:30 -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 New | 217062 | for file systems mounted with -o noexec, exec=off 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 | 211491 | System hangs after "Uptime" on reboot with ZFS 7 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Mon May 15 03:03:52 2017 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 B66D2D6CCC5 for ; Mon, 15 May 2017 03:03:52 +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 A6179B1 for ; Mon, 15 May 2017 03:03:52 +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 v4F33qWX046155 for ; Mon, 15 May 2017 03:03:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219224] [zfs] sync hanging in _cv_wait zil_commit zfs_sync sys_sync Date: Mon, 15 May 2017 03:03:52 +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 Only Me 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: short_desc 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: Mon, 15 May 2017 03:03:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219224 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|sync hanging in _cv_wait |[zfs] sync hanging in |zil_commit zfs_sync |_cv_wait zil_commit |sys_sync |zfs_sync sys_sync 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 Mon May 15 18:10:04 2017 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 7DD3DD6EF97; Mon, 15 May 2017 18:10:04 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF49E10BC; Mon, 15 May 2017 18:10:03 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from iris.berlin.strato.de ([192.166.200.216]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MY4Ls-1dWEzr2d3g-00UuOJ; Mon, 15 May 2017 20:09:55 +0200 Subject: Fwd: ZFS References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> From: Nikos Vassiliadis To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-Forwarded-Message-Id: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> Message-ID: Date: Mon, 15 May 2017 20:09:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7VR/Pgmwc3gTksbhU74jS5SdNM6kPtbxWELlcBY0tBXE2z/hris rBDR3Zne7pzagP9MtRkwkIAPQWGek3AtuuKdM1VtV9SC5E1jT54on/JlDAWrQtN5hGgW0R8 eAKitMdVz8xgep3x/yhIJWU9zahwXIkk1WSGjCCUwfWBxH31lnhrDxT0DuK1PU1To/wBcoT wxTaYpkj44fGz764kOgOg== X-UI-Out-Filterresults: notjunk:1;V01:K0:vkMzPZ071pQ=:7gY66TLUldXwdAv6jrp3O+ bYJR4X9LkfWom7BFbrSDueQFNIgOP+F8nupAM7x0GCAAnMjENBeAcrXz4c8X+wyKVsWc3GZTa 8eLcfGjnbupOmOeFaWWiq5EoQsh8w2K0bvvSsbfajlW7Qe9MUcRWxMWlaD91ZoSft48CsozUZ 5owIcy2Um5bb0aiyZbdz72cu0VZCencRXM/PgJT7ERn+Qlr4szv+t+80f9erkC3vdQ6vk1aza C74eeUgwZQi7nqLnS8e6l5TB+6eqFGYJBahRe4KYNBMePjYRVm7e92SYr0ucGX8CEImU6KOHj fOtlE1KiM5yLjDd5eQgFM68lsvOCv8mKfjICXh7+iTnObFOcuuPyvEDgSlOwtz+ylhUeSOxVq SgXDx2LHBbMCoTyoPF6KACo1+GCrlOFS6WLZ4kssJRx6DuR1d2k4j01iFStpd6ccDfQzD3FSt Z3t/LkrhKeMAzd30LRwmiabWtgjmb1uJWIVyLujJb7PGA3jBi7fPDUNlU/BKZaFl5QvGT82h1 lJbZtIJ6sQzxUVn/iSISpkAeR5QMBBcnkngSaqVZV9y9+QEnPQ3J66vedzLtUe6BSrxkUqUg0 gko3DCG0hm7O9nQWhPpTK7oZbhCVjmRp4SznmjCTV1UGykIrUEUwHs6JvbYlyT9atL+LrFune IViCXNV6Iyi7kVRpnNImdeBtB/AAnTdAUdZ7tZxuo5h7WmBNc2E9lGLs9e/m7O4KULfWKDvkP N68fn2tYawD0TAhBq+4iXN9RRYb5DzNlxD5In/sbS3Vj6wWylOuYSyImkpzFbusEhmETq0ldd niFmif5 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, 15 May 2017 18:10:04 -0000 Hi everybody, While trying to rename a zpool from zroot to vega, I ended up in this strange situation: nik@vega:~ % zfs list -t all NAME USED AVAIL REFER MOUNTPOINT vega 1.83G 34.7G 96K /zroot vega/ROOT 1.24G 34.7G 96K none vega/ROOT/default 1.24G 34.7G 1.24G / vega/tmp 120K 34.7G 120K /tmp vega/usr 608M 34.7G 96K /usr vega/usr/home 136K 34.7G 136K /usr/home vega/usr/ports 96K 34.7G 96K /usr/ports vega/usr/src 607M 34.7G 607M /usr/src vega/var 720K 34.7G 96K /var vega/var/audit 96K 34.7G 96K /var/audit vega/var/crash 96K 34.7G 96K /var/crash vega/var/log 236K 34.7G 236K /var/log vega/var/mail 100K 34.7G 100K /var/mail vega/var/tmp 96K 34.7G 96K /var/tmp zroot 1.83G 34.7G 96K /zroot zroot/ROOT 1.24G 34.7G 96K none zroot/ROOT/default 1.24G 34.7G 1.24G / zroot/tmp 120K 34.7G 120K /tmp zroot/usr 608M 34.7G 96K /usr zroot/usr/home 136K 34.7G 136K /usr/home zroot/usr/ports 96K 34.7G 96K /usr/ports zroot/usr/src 607M 34.7G 607M /usr/src zroot/var 724K 34.7G 96K /var zroot/var/audit 96K 34.7G 96K /var/audit zroot/var/crash 96K 34.7G 96K /var/crash zroot/var/log 240K 34.7G 240K /var/log zroot/var/mail 100K 34.7G 100K /var/mail zroot/var/tmp 96K 34.7G 96K /var/tmp nik@vega:~ % zpool status pool: vega state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 config: NAME STATE READ WRITE CKSUM vega ONLINE 0 0 0 vtbd0p3 ONLINE 0 0 0 errors: No known data errors pool: zroot state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 vtbd0p3 ONLINE 0 0 0 errors: No known data errors nik@vega:~ % ------------------------------------------- It seems like there are two pools, sharing the same vdev... After running a few commands in this state, like doing a scrub, the pool was (most probably) destroyed. It couldn't boot anymore and I didn't research further. Is this a known bug? Steps to reproduce: install FreeBSD-11.0 in a pool named zroot reboot into a live-CD zpool import -f zroot vega reboot again Thanks, Nikos PS: Sorry for the cross-posting, I am doing this to share to more people because it is a rather easy way to destroy a ZFS pool. From owner-freebsd-fs@freebsd.org Mon May 15 18:11:41 2017 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 8A77FD6E25A; Mon, 15 May 2017 18:11:41 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B0AF1580; Mon, 15 May 2017 18:11:40 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from iris.berlin.strato.de ([192.166.200.216]) by mail.gmx.com (mrgmx103 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MdK8t-1dS8AT3Ebj-00IV1p; Mon, 15 May 2017 20:11:38 +0200 Subject: zpool imported twice with different names (was Re: Fwd: ZFS) From: Nikos Vassiliadis To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> Message-ID: Date: Mon, 15 May 2017 20:11:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uLu4BIUWtdJ0ahoKpW3EEJSRvJQccXKvHLT3RdCAMbuDayOh7uf iralYDcwSiyjy7/zpuydwSKHO4cQdC99VxY+hY8dRV8lMAF57REOfnwQMfRrkJe5WWfEl7h QFJCv+eDEKe2pgyNKnkCt2aaqjjz0fEAauQtfi4RP1Yt52h1i4ZdQM8H3Kq2zgr8c+hfsOq fmsfiptoRVHA9RXrkKQQg== X-UI-Out-Filterresults: notjunk:1;V01:K0:8KRWvFFTzcE=:S0+rVJV1sfmAzdUvB6I2Ai p5MpV+or3wVdGdW7EjTO+5ieijzyHwpUhcfYKJRHrmRS3G4z43YyMKLsCIQYF7ha1eJbbjBkm 1M5x5qJXFlWSbeYYzchWJmERTVtMHTpnAxA+HJ/8TluXKVSuEb9ltjloK5iuBoadjICxJs+vT LGNRFBoAt3taga6Y7SZDCE7WIaxTwd04MKWJsPpCzNd4sazjZXkCA3u7U4fpdWhuSGR5ZqByd S2obvxs0gEiK5AbGxHMlKi8mO4P+wYkt4yDl5rChQO1WZaOPA1n8bUHhobmKacyHbyk0i52y/ wZ6rT785eY4y9et6LlktXXZKAVkDfMQgHh9gc4EEyaR6aShyVbWfzm6KftURKRkcOrLaxNEd1 dmQiFG1WMtxCbmrQwlK2rDyXBqsWbK/NmWaqLPcL4b8rHOw2ZmDpOORx8QH90BXEXy3eiykgP pdIRwhdkoIhQIFQFg7Q0b8HWbamWHkIYY0AVhvsehLHzGcvpjcIsPWOz6rAaB877lVpCVCp5S S2iKubvvzMd4x9+eorEOnLkuOKZTCm04bnjCTk83ouf6RNu2H0xUBhcfTc1kramSjkx+2GSzs sexiN7aJ1HGkkGIMjBY1WNSTTeQTPyFYUDqII0tiZDj7WkHEw8PKCq5ZHFG6hObdPkzgC3Kd4 fG8DC+iQ2NPhwm8u+E5zpH+6Tqzf0cQ4H5Y+UFDeT4AmsIZ+cHhg6+oaarTU/f5MERLjd1fTW OBeIVplx9A9RIsJofOGhq7xDWIbRgnXLDjL/ftX2g+6o9N6zFMr3ZIFd5ROV2tIE5IhqFmcFx ZO664zc 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, 15 May 2017 18:11:41 -0000 Fix the e-mail subject On 05/15/2017 08:09 PM, Nikos Vassiliadis wrote: > Hi everybody, > > While trying to rename a zpool from zroot to vega, > I ended up in this strange situation: > nik@vega:~ % zfs list -t all > NAME USED AVAIL REFER MOUNTPOINT > vega 1.83G 34.7G 96K /zroot > vega/ROOT 1.24G 34.7G 96K none > vega/ROOT/default 1.24G 34.7G 1.24G / > vega/tmp 120K 34.7G 120K /tmp > vega/usr 608M 34.7G 96K /usr > vega/usr/home 136K 34.7G 136K /usr/home > vega/usr/ports 96K 34.7G 96K /usr/ports > vega/usr/src 607M 34.7G 607M /usr/src > vega/var 720K 34.7G 96K /var > vega/var/audit 96K 34.7G 96K /var/audit > vega/var/crash 96K 34.7G 96K /var/crash > vega/var/log 236K 34.7G 236K /var/log > vega/var/mail 100K 34.7G 100K /var/mail > vega/var/tmp 96K 34.7G 96K /var/tmp > zroot 1.83G 34.7G 96K /zroot > zroot/ROOT 1.24G 34.7G 96K none > zroot/ROOT/default 1.24G 34.7G 1.24G / > zroot/tmp 120K 34.7G 120K /tmp > zroot/usr 608M 34.7G 96K /usr > zroot/usr/home 136K 34.7G 136K /usr/home > zroot/usr/ports 96K 34.7G 96K /usr/ports > zroot/usr/src 607M 34.7G 607M /usr/src > zroot/var 724K 34.7G 96K /var > zroot/var/audit 96K 34.7G 96K /var/audit > zroot/var/crash 96K 34.7G 96K /var/crash > zroot/var/log 240K 34.7G 240K /var/log > zroot/var/mail 100K 34.7G 100K /var/mail > zroot/var/tmp 96K 34.7G 96K /var/tmp > nik@vega:~ % zpool status > pool: vega > state: ONLINE > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > config: > > NAME STATE READ WRITE CKSUM > vega ONLINE 0 0 0 > vtbd0p3 ONLINE 0 0 0 > > errors: No known data errors > > pool: zroot > state: ONLINE > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > vtbd0p3 ONLINE 0 0 0 > > errors: No known data errors > nik@vega:~ % > ------------------------------------------- > > It seems like there are two pools, sharing the same vdev... > > After running a few commands in this state, like doing a scrub, > the pool was (most probably) destroyed. It couldn't boot anymore > and I didn't research further. Is this a known bug? > > Steps to reproduce: > install FreeBSD-11.0 in a pool named zroot > reboot into a live-CD > zpool import -f zroot vega > reboot again > > Thanks, > Nikos > > PS: > Sorry for the cross-posting, I am doing this to share to more people > because it is a rather easy way to destroy a ZFS pool. > From owner-freebsd-fs@freebsd.org Mon May 15 19:41:49 2017 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 6DC1ED6EF2D for ; Mon, 15 May 2017 19:41:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 23A1324D for ; Mon, 15 May 2017 19:41:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x229.google.com with SMTP id f55so57434407qta.3 for ; Mon, 15 May 2017 12:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kk6YmktLZ90EXUODxct/GBFagHVIXuQphNj950k2Y0U=; b=nJ4WfrbUvgRSsL+7lg/9V4MAh/l+X2hsY/p6rb7pPxLytDuyxjCTImO96rb9pqKz+X DcbLZrANVbLNJUdPMKeMUJ3YgDsGkL7EvHoFsPUGbzagWgNb9bPOXMhDCcZ/k8aQxJDS ZJspjBQPRmDNY4qH4JSYWnbH5PrOXBuy/Vcrz1htXRruWYCEHLpWKTc76ATpAUMIYPP1 xGTySKtwOnQ6rZk/upIShc86A71AGrRnXaMyR20aBE9FeCtrqR9c0O4R4duq/b4jIAnG oqaMxeglPagocAB+QLxkxi5DDRUXm3Hcc+co//3Xqzfsf1Sv47HE+/Pz52yS1VcPpeyY 1arA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kk6YmktLZ90EXUODxct/GBFagHVIXuQphNj950k2Y0U=; b=R46jzr2/kgyndlw1k1sIaiYHun2Y53tYy398qEHAlnSc5e17bM5h877q/y2/UFxH+5 ysTFGjWM/G1LhctbH5KKZxaFULtNufd2xHD4RXe1O9hRY9NBJWRFrdQWi/Tlk8E5Ccn3 /0TYLtU3i4+ZWJHIAqFeD27vUjOKNMrtCF9NGC5wA/83+fJgcCbAap4L289p3m2ABvxo EsYXlEtzK1I/+i6JW996ih6jFiWcfoQtVbQo0DIk2l+r7iHzTGXhfohcuYV3yEa720nX fgOEqpB6CZGFS92qG025lKD4pTanoC/tikKUncb1sir56HfYuovqdY/GJiDcp4sHwWXA BShA== X-Gm-Message-State: AODbwcDpa51v4fO4QH5ncbdqwW6HvFGORS3bx1vk5p2EfZBRqc8uKQte 8c3kA71vpTFnGR1l X-Received: by 10.200.34.242 with SMTP id g47mr6901497qta.109.1494877308112; Mon, 15 May 2017 12:41:48 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id t35sm9134628qta.62.2017.05.15.12.41.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 May 2017 12:41:47 -0700 (PDT) Date: Mon, 15 May 2017 15:41:45 -0400 From: Shawn Webb To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170515194145.tx2mp6gxjxbcpbng@mutt-hbsd> References: <20170420194314.GI1788@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="meq5xjd7oh4cv4tt" Content-Disposition: inline In-Reply-To: <20170420194314.GI1788@kib.kiev.ua> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170306 (1.8.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, 15 May 2017 19:41:49 -0000 --meq5xjd7oh4cv4tt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > Inodes are data structures corresponding to objects in a file system, > such as files and directories. FreeBSD has historically used 32-bit > values to identify inodes, which limits file systems to somewhat under > 2^32 objects. Many modern file systems internally use 64-bit identifiers > and FreeBSD needs to follow suit to properly and fully support these > file systems. >=20 > The 64-bit inode project, also known as ino64, started life many years > ago as a project by Gleb Kurtsou (gleb@). After that time several > people have had a hand in updating it and addressing regressions, after > mckusick@ picked up and updated the patch, and acted as a flag-waver. >=20 > Sponsored by the FreeBSD Foundation I have spent a significant effort > on outstanding issues and integration -- fixing compat32 ABI, NFS and > ZFS, addressing ABI compat issues and investigating and fixing ports > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > jhb@ provided feedback and review on the ABI transition support. pho@ > performed extensive testing and identified a number of issues that > have now been fixed. kris@ performed an initial ports investigation > followed by an exp-run by antoine@. emaste@ helped with organization > of the process. >=20 > This note explains how to perform useful testing of the ino64 branch, > beyond typical smoke tests. >=20 > 1. Overview. >=20 > The ino64 branch extends the basic system types ino_t and dev_t from > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > layout is modified due to the larger size of ino_t, and also gains a > d_off (directory offset) member. As ino64 implies an ABI change anyway > the struct statfs f_mntfromname[] and f_mntonname[] array length > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > names. >=20 > ABI breakage is mitigated by providing compatibility using versioned > symbols, ingenious use of the existing padding in structures, and by > employing other tricks. Unfortunately, not everything can be fixed, > especially outside the base system. For instance, third-party APIs > which pass struct stat around are broken in backward and forward- > incompatible way. >=20 > 2. Motivation. >=20 > The main risk of the ino64 change is the uncontrolled ABI breakage. > Due to expansion of the basic types dev_t, ino_t and struct dirent, > the impact is not limited to one part of the system, but affects: > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo > and more) > - libc interface (mostly related to the readdir(3), FTS(3)) > - collateral damage in other libraries that happens to use changed types > in the interfaces. See, for instance, libprocstat, for which compat > was provided using symbol versioning, and libutil, which shlib version > was bumped. >=20 > 3. Quirks. >=20 > We handled kinfo sysctl MIBs, but other MIBs which report structures > depended on the changed type, are not handled in general. It was > considered that the breakage is either in the management interfaces, > where we usually allow ABI slip, or is not important. >=20 > Struct xvnode changed layout, no compat shims are provided. >=20 > For struct xtty, dev_t tty device member was reduced to uint32_t. It > was decided that keeping ABI compat in this case is more useful than > reporting 64bit dev_t, for the sake of pstat. >=20 > 4. Testing procedure. >=20 > The ino64 project can be tested by cloning the project branch from > GitHub or by applying the patch at URL | attached> to a working tree. The authorative source is the > GitHub, I do not promise to update the review for each update. >=20 > To clone from GitHub: > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino= 64 >=20 > To fetch the patch from Phabricator: > - Visit https://reviews.freebsd.org/D10439 > - Click "Download Raw Diff" at the upper right of the page >=20 > Or > % arc patch D10439 >=20 > After that, in the checkout directory do > % (cd sys/kern && touch syscalls.master && make sysent) > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) > If you use custom kernel configuration, ensure that > options COMPAT_FREEBSD11 > is included into the config. Then build world and kernel in the > usual way, install kernel, reboot, install new world. Do not make > shortcuts in the update procedure. Hey Kostik, On my HardenedBSD system, world compiled fine with the patch, but the kernel didn't compile. I've uploaded the log to: https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log This was from importing the patch from Phabricator into hardened/current/master in HardenedBSD. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --meq5xjd7oh4cv4tt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlkaBHYACgkQaoRlj1JF bu7DVQ//dkA0Nm4bCMZ0B4Iv3TwZAoWP+EyzLwUAW3ywzM3KhMJyLuGnOIcb+UZ3 szb7jAQEbnOQN3IYsKxKIGmMr0/XFJsdeTGPo29yQ5WFfEpQPZRVkWtC162YrFiE fH9Xuizw3puetGAxlzE3JNM6rBmlJUq0GB1FhUoKlMYD22p6/HTQ3Rn+tJp8oR5R xr0v3F18JcyIbean0RhzXwQZtdTcHpuCL1kgdz+RdrVspY8cw48baJhzburX6ITg XnaU1JSTwWYE58HBfWd6/S5g2/nW9xYfQMNHjuq7vOLPVpy3PWIwelYtcfKMULtt KF/tIsWqPEbPmHhh2BbtzKW95oRruY0M9V8y04cSGFGRaGixXSBJCQ4yQTS0yegy zBpEgY/zZ21MQCrzPIdp7CzfRqWrpIjVS94gska5uER9xI3bq28nWnGwPjeoca4D 5SmNMM6TMWBU2occWwFkaXIURXY+sBxLDbPlBcLGEMkkfm/BajUOrk8YJydCMZeq 73s4b7dKQKWS5Aa18V6Y9/rWMbSQqx/FD7Dvc8rqc49jwv9nRKO6AteEGMvBvKUs NHj1PdeExdtMnuSZd3CFDdTfU0RRy0gqqfISw9ns5aPz0Ofdo9xAjGSEpUGF2Tpu LyX+6X/DlSApPZyC8QsSItKBicuOScXHIQs8AYxX3q7TF8wAbXE= =gxsk -----END PGP SIGNATURE----- --meq5xjd7oh4cv4tt-- From owner-freebsd-fs@freebsd.org Mon May 15 22:01:37 2017 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 4354FD6E86F for ; Mon, 15 May 2017 22:01:37 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 ECB3A1334 for ; Mon, 15 May 2017 22:01:36 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22c.google.com with SMTP id a72so111608817qkj.2 for ; Mon, 15 May 2017 15:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PKAVcDKkyQx9ntzPsSXWZAMOkhBQFpfaAyy7s7oIdSM=; b=L1mYS0CsICQjW9gkwvmDteLkabuDMQEJz4f8spMVSEIyVT1ZB4iKxmGtaGW339WWk4 kEdl9UYpqbGCoXUHmJgSZXRFCc8uIprGBa9K1L6kltJ4g0pnn+gpMh9pQmu/GyKNn3oC fAu2lEkNMjeFWQOXCbBwt3zd3+BOsK9DGUrc6sIubuzSx61Y8tbyWIuU6TwfPcmLAm21 ydjOlIUrVF/BQ5kOuVBQHvfYe+RORgi1I5TO5qKFxREFglU8np2n/weO9mCHmTMteKWu 3IlM/ddgP3urinElSausp2kHmVDAnAuURPF+XxJYxVszsMaBYK/3w68BBkl5M1dwLVof FGTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PKAVcDKkyQx9ntzPsSXWZAMOkhBQFpfaAyy7s7oIdSM=; b=HZ4lKQtt9xcr/ARZyyeA5uoOVhwxD+rMmYqcDX8UbCpDpipvFEAaLLmyDNsKjQjQdY K95sYfZpbb2MkVFciloG4L0PYUMdtt4KHIDt2SBIs4mhyR/T/EKGq4DeO2LUYV4MUdQM r77oYFiElJ3cpOY/WO3d4vm8sP4dVKu6H7Cllm4jweN7l8n7IaNFxJY1oEJs4blHgI+Y mi47qtTZ7lWF5h1rsGjxAtjC3PuSRv2s6CO/8+HtdUA7Spo8jbG5gMOoQkfjSPLEz458 35thghY46PZeh14700wNwFIsgVWclGU16PKcP2s4u8+3IjvniCWYXty1js+hpQrahkiL jOEQ== X-Gm-Message-State: AODbwcC1scDcPcF6P4P35suThzo2IjZD45pBvK5RMMgINsNTaNtt8eeZ yi4Zzz8Ef2PraPQT X-Received: by 10.233.237.72 with SMTP id c69mr8068210qkg.201.1494885695903; Mon, 15 May 2017 15:01:35 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id t35sm9400920qta.62.2017.05.15.15.01.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 May 2017 15:01:35 -0700 (PDT) Date: Mon, 15 May 2017 18:01:33 -0400 From: Shawn Webb To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170515220133.hxp6x2zvlfdilsiq@mutt-hbsd> References: <20170420194314.GI1788@kib.kiev.ua> <20170515194145.tx2mp6gxjxbcpbng@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h36hr3agvrxrlxsc" Content-Disposition: inline In-Reply-To: <20170515194145.tx2mp6gxjxbcpbng@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170306 (1.8.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, 15 May 2017 22:01:37 -0000 --h36hr3agvrxrlxsc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 15, 2017 at 03:41:45PM -0400, Shawn Webb wrote: > On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > > Inodes are data structures corresponding to objects in a file system, > > such as files and directories. FreeBSD has historically used 32-bit > > values to identify inodes, which limits file systems to somewhat under > > 2^32 objects. Many modern file systems internally use 64-bit identifiers > > and FreeBSD needs to follow suit to properly and fully support these > > file systems. > >=20 > > The 64-bit inode project, also known as ino64, started life many years > > ago as a project by Gleb Kurtsou (gleb@). After that time several > > people have had a hand in updating it and addressing regressions, after > > mckusick@ picked up and updated the patch, and acted as a flag-waver. > >=20 > > Sponsored by the FreeBSD Foundation I have spent a significant effort > > on outstanding issues and integration -- fixing compat32 ABI, NFS and > > ZFS, addressing ABI compat issues and investigating and fixing ports > > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > > jhb@ provided feedback and review on the ABI transition support. pho@ > > performed extensive testing and identified a number of issues that > > have now been fixed. kris@ performed an initial ports investigation > > followed by an exp-run by antoine@. emaste@ helped with organization > > of the process. > >=20 > > This note explains how to perform useful testing of the ino64 branch, > > beyond typical smoke tests. > >=20 > > 1. Overview. > >=20 > > The ino64 branch extends the basic system types ino_t and dev_t from > > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > > layout is modified due to the larger size of ino_t, and also gains a > > d_off (directory offset) member. As ino64 implies an ABI change anyway > > the struct statfs f_mntfromname[] and f_mntonname[] array length > > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > > names. > >=20 > > ABI breakage is mitigated by providing compatibility using versioned > > symbols, ingenious use of the existing padding in structures, and by > > employing other tricks. Unfortunately, not everything can be fixed, > > especially outside the base system. For instance, third-party APIs > > which pass struct stat around are broken in backward and forward- > > incompatible way. > >=20 > > 2. Motivation. > >=20 > > The main risk of the ino64 change is the uncontrolled ABI breakage. > > Due to expansion of the basic types dev_t, ino_t and struct dirent, > > the impact is not limited to one part of the system, but affects: > > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo > > and more) > > - libc interface (mostly related to the readdir(3), FTS(3)) > > - collateral damage in other libraries that happens to use changed types > > in the interfaces. See, for instance, libprocstat, for which compat > > was provided using symbol versioning, and libutil, which shlib version > > was bumped. > >=20 > > 3. Quirks. > >=20 > > We handled kinfo sysctl MIBs, but other MIBs which report structures > > depended on the changed type, are not handled in general. It was > > considered that the breakage is either in the management interfaces, > > where we usually allow ABI slip, or is not important. > >=20 > > Struct xvnode changed layout, no compat shims are provided. > >=20 > > For struct xtty, dev_t tty device member was reduced to uint32_t. It > > was decided that keeping ABI compat in this case is more useful than > > reporting 64bit dev_t, for the sake of pstat. > >=20 > > 4. Testing procedure. > >=20 > > The ino64 project can be tested by cloning the project branch from > > GitHub or by applying the patch > at URL | attached> to a working tree. The authorative source is the > > GitHub, I do not promise to update the review for each update. > >=20 > > To clone from GitHub: > > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git i= no64 > >=20 > > To fetch the patch from Phabricator: > > - Visit https://reviews.freebsd.org/D10439 > > - Click "Download Raw Diff" at the upper right of the page > >=20 > > Or > > % arc patch D10439 > >=20 > > After that, in the checkout directory do > > % (cd sys/kern && touch syscalls.master && make sysent) > > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) > > If you use custom kernel configuration, ensure that > > options COMPAT_FREEBSD11 > > is included into the config. Then build world and kernel in the > > usual way, install kernel, reboot, install new world. Do not make > > shortcuts in the update procedure. >=20 > Hey Kostik, >=20 > On my HardenedBSD system, world compiled fine with the patch, but the > kernel didn't compile. I've uploaded the log to: >=20 > https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log >=20 > This was from importing the patch from Phabricator into > hardened/current/master in HardenedBSD. Update: I missed a step. Kernel and world built fine. It seems the patch is working fine for me in a limited test. I'll do a more involved test tomorrow. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --h36hr3agvrxrlxsc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlkaJToACgkQaoRlj1JF bu5Q8A//UjtI66Dxx4vNYviBvrqUXZf+cpY+FsGWUnCiIsNYpmZoLmkNjGqyW5PF OBlq7wpC6R5gUlKLsaV4/7Qe6biGKv8JIr1CujjQKX/gGfHZ7ILrVWyQE6uHFM/a YvFQ3GX4j45fOZGx5Fh7IjzfUaCeBMj0+apdbUyeUZr8h3uqtVy6qY0n0g4i5X0L P6bS57cNXWhSin2lXA98/b89p2DCOOH6TjqvAjB9gbwFs5mzujkS7KgZruaOFWnT csnfgoaqqdzLQDLXrLqURnL50rAE6ALvzUb/+C+TYnNnXTMCzbvRNOJOqhuZ2WiH USbn0IH9bB87cIWTaeYce171dTbBuAAyoAiGSaYEAMhJC+QRirl4M6L1VrJdFLVd VKGkWrtXGJ28u8UlEB+yOp9e/t11DnvVLuU6kqiGlQFlPPP9cu2Kmqcq7bcKwPE1 3Rl4jJjbCiD7LPMKgs3u3IEoSiM90yFUsXf7UByyGpE2ViGMqUH7i+pPQxFYTWQ1 sKiimmCvOxAz0h93lFS3CC5Vti3Gc+rY2tpuCwbyuctBGbJ5VzzVwjinKgOVHVj3 4Mb/1EEId99LWRIt7OVvvmuzs4lWn9MZnK0G/Trpa0lJmHpSFiGN9lZ8Xk7j1B8m DqL9fh8ZCnGhtWiicwWcSOgYpHOF0WpbvXEuuEOpued6GSDezXc= =SIYn -----END PGP SIGNATURE----- --h36hr3agvrxrlxsc-- From owner-freebsd-fs@freebsd.org Tue May 16 00:21:20 2017 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 E9DD8D6C6B0 for ; Tue, 16 May 2017 00:21:20 +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 D87AAC10 for ; Tue, 16 May 2017 00:21:20 +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 v4G0LK11069783 for ; Tue, 16 May 2017 00:21:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 211491] System hangs after "Uptime" on reboot with ZFS Date: Tue, 16 May 2017 00:21:20 +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-BETA3 X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? 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, 16 May 2017 00:21:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211491 --- Comment #20 from g_amanakis@yahoo.com --- This bug seems to be the same as "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D167685" Setting hw.usb.no_shutdown_wait=3D1 resolves it.=20 Strangely though if I manually export the zpool with 6 SATA drives I can re= boot it, even with hw.usb.no_shutdown_wait=3D0 (the default value).=20 It is unclear to me how the 6 SATA-drive zpool is connected with hw.usb.no_shutdown_wait. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue May 16 00:21:34 2017 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 38081D6C705 for ; Tue, 16 May 2017 00:21:34 +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 275B7D19 for ; Tue, 16 May 2017 00:21:34 +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 v4G0LXra070826 for ; Tue, 16 May 2017 00:21:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 211491] System hangs after "Uptime" on reboot with ZFS Date: Tue, 16 May 2017 00:21:34 +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: needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: version 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, 16 May 2017 00:21:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211491 g_amanakis@yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|11.0-BETA3 |11.0-STABLE --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue May 16 00:21:42 2017 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 CFE57D6C73E for ; Tue, 16 May 2017 00:21:42 +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 BE26DDB8 for ; Tue, 16 May 2017 00:21:42 +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 v4G0Lgms072350 for ; Tue, 16 May 2017 00:21:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 211491] System hangs after "Uptime" on reboot with ZFS Date: Tue, 16 May 2017 00:21:42 +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: needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: g_amanakis@yahoo.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: rep_platform 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, 16 May 2017 00:21:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211491 g_amanakis@yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|Any |amd64 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue May 16 06:31:50 2017 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 284E8D6FA5B; Tue, 16 May 2017 06:31:50 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8D8F1954; Tue, 16 May 2017 06:31:49 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v4G6VMSk076391 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 08:31:22 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v4G6VLvX076388; Tue, 16 May 2017 08:31:21 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 16 May 2017 08:31:21 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Nikos Vassiliadis cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) In-Reply-To: Message-ID: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 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, 16 May 2017 06:31:50 -0000 On Mon, 15 May 2017 20:11+0200, Nikos Vassiliadis wrote: > Fix the e-mail subject > > On 05/15/2017 08:09 PM, Nikos Vassiliadis wrote: > > Hi everybody, > > > > While trying to rename a zpool from zroot to vega, > > I ended up in this strange situation: > > nik@vega:~ % zfs list -t all > > NAME USED AVAIL REFER MOUNTPOINT > > vega 1.83G 34.7G 96K /zroot > > vega/ROOT 1.24G 34.7G 96K none > > vega/ROOT/default 1.24G 34.7G 1.24G / > > vega/tmp 120K 34.7G 120K /tmp > > vega/usr 608M 34.7G 96K /usr > > vega/usr/home 136K 34.7G 136K /usr/home > > vega/usr/ports 96K 34.7G 96K /usr/ports > > vega/usr/src 607M 34.7G 607M /usr/src > > vega/var 720K 34.7G 96K /var > > vega/var/audit 96K 34.7G 96K /var/audit > > vega/var/crash 96K 34.7G 96K /var/crash > > vega/var/log 236K 34.7G 236K /var/log > > vega/var/mail 100K 34.7G 100K /var/mail > > vega/var/tmp 96K 34.7G 96K /var/tmp > > zroot 1.83G 34.7G 96K /zroot > > zroot/ROOT 1.24G 34.7G 96K none > > zroot/ROOT/default 1.24G 34.7G 1.24G / > > zroot/tmp 120K 34.7G 120K /tmp > > zroot/usr 608M 34.7G 96K /usr > > zroot/usr/home 136K 34.7G 136K /usr/home > > zroot/usr/ports 96K 34.7G 96K /usr/ports > > zroot/usr/src 607M 34.7G 607M /usr/src > > zroot/var 724K 34.7G 96K /var > > zroot/var/audit 96K 34.7G 96K /var/audit > > zroot/var/crash 96K 34.7G 96K /var/crash > > zroot/var/log 240K 34.7G 240K /var/log > > zroot/var/mail 100K 34.7G 100K /var/mail > > zroot/var/tmp 96K 34.7G 96K /var/tmp > > nik@vega:~ % zpool status > > pool: vega > > state: ONLINE > > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > > config: > > > > NAME STATE READ WRITE CKSUM > > vega ONLINE 0 0 0 > > vtbd0p3 ONLINE 0 0 0 > > > > errors: No known data errors > > > > pool: zroot > > state: ONLINE > > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > > config: > > > > NAME STATE READ WRITE CKSUM > > zroot ONLINE 0 0 0 > > vtbd0p3 ONLINE 0 0 0 > > > > errors: No known data errors > > nik@vega:~ % > > ------------------------------------------- > > > > It seems like there are two pools, sharing the same vdev... > > > > After running a few commands in this state, like doing a scrub, > > the pool was (most probably) destroyed. It couldn't boot anymore > > and I didn't research further. Is this a known bug? > > I guess you had a /boot/zfs/zpool.cache file referring to the original zroot pool. Next, the kernel found the vega pool and didn't realise these two pools are the very same. > > Steps to reproduce: > > install FreeBSD-11.0 in a pool named zroot > > reboot into a live-CD Redo the above steps. > > zpool import -f zroot vega Do these four commands instead of a regular import: mkdir /tmp/vega zpool import -N -f -o cachefile=/tmp/zpool.cache vega mount -t zfs vega/ROOT/default /tmp/vega cp -p /tmp/zpool.cache /tmp/vega/boot/zfs/zpool.cache > > reboot again Reboot again. > > > > Thanks, > > Nikos > > > > PS: > > Sorry for the cross-posting, I am doing this to share to more people > > because it is a rather easy way to destroy a ZFS pool. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-fs@freebsd.org Tue May 16 10:13:02 2017 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 D4155D6E8FB; Tue, 16 May 2017 10:13:02 +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 08FA21221; Tue, 16 May 2017 10:13:01 +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 NAA04494; Tue, 16 May 2017 13:12:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dAZTJ-0005IB-SI; Tue, 16 May 2017 13:12:53 +0300 Subject: Re: zfs recv panic To: Kristof Provost , Freebsd current , freebsd-fs@FreeBSD.org References: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> From: Andriy Gapon Message-ID: <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> Date: Tue, 16 May 2017 13:11:32 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 16 May 2017 10:13:02 -0000 On 10/05/2017 12:37, Kristof Provost wrote: > Hi, > > I have a reproducible panic on CURRENT (r318136) doing > (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 > (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var > > For clarity, the receiving machine is CURRENT r318136, the sending machine is > running a somewhat older CURRENT version. > > The receiving machine panics a few seconds in: > > receiving full stream of zroot/var@before-kernel-2017-04-03 into > tank/jupiter/var@before-kernel-2017-04-03 > panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) (0x0 == > 0x1), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, > line: 2007 Kristof, could you please try to revert commits related to the compressed send and see if that helps? I assume that the sending machine does not have (does not use) the feature while the target machine is capable of the feature. The commits are: r317648 and r317414. Mot that I really suspect that change, but just to eliminate the possibility. Thank you. > cpuid = 0 > time = 1494408122 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0120cad930 > vpanic() at vpanic+0x19c/frame 0xfffffe0120cad9b0 > panic() at panic+0x43/frame 0xfffffe0120cada10 > assfail3() at assfail3+0x2c/frame 0xfffffe0120cada30 > dbuf_assign_arcbuf() at dbuf_assign_arcbuf+0xf2/frame 0xfffffe0120cada80 > dmu_assign_arcbuf() at dmu_assign_arcbuf+0x170/frame 0xfffffe0120cadad0 > receive_writer_thread() at receive_writer_thread+0x6ac/frame 0xfffffe0120cadb70 > fork_exit() at fork_exit+0x84/frame 0xfffffe0120cadbb0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0120cadbb0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 7 tid 100672 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why > db> > > > kgdb backtrace: > #0 doadump (textdump=0) at pcpu.h:232 > #1 0xffffffff803a208b in db_dump (dummy=, dummy2= optimized out>, dummy3=, dummy4=) at > /usr/src/sys/ddb/db_command.c:546 > #2 0xffffffff803a1e7f in db_command (cmd_table=) at > /usr/src/sys/ddb/db_command.c:453 > #3 0xffffffff803a1bb4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:506 > #4 0xffffffff803a4c7f in db_trap (type=, code= optimized out>) at /usr/src/sys/ddb/db_main.c:248 > #5 0xffffffff80a93cb3 in kdb_trap (type=3, code=-61456, tf= out>) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80ed3de6 in trap (frame=0xfffffe0120cad860) at > /usr/src/sys/amd64/amd64/trap.c:537 > #7 0xffffffff80eb62f1 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 > #8 0xffffffff80a933eb in kdb_enter (why=0xffffffff8143d8f5 "panic", msg= optimized out>) at cpufunc.h:63 > #9 0xffffffff80a51cf9 in vpanic (fmt=, > ap=0xfffffe0120cad9f0) at /usr/src/sys/kern/kern_shutdown.c:772 > #10 0xffffffff80a51d63 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:710 > #11 0xffffffff8262b26c in assfail3 (a=, lv= out>, op=, rv=, f= out>, l=) > at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 > #12 0xffffffff822ad892 in dbuf_assign_arcbuf (db=0xfffff8008f23e560, > buf=0xfffff8008f09fcc0, tx=0xfffff8008a8d5200) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:2007 > #13 0xffffffff822b87f0 in dmu_assign_arcbuf (handle=, > offset=0, buf=0xfffff8008f09fcc0, tx=0xfffff8008a8d5200) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:1542 > #14 0xffffffff822bf7fc in receive_writer_thread (arg=0xfffffe0120a1d168) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:2284 > #15 0xffffffff80a13704 in fork_exit (callout=0xffffffff822bf150 > , arg=0xfffffe0120a1d168, frame=0xfffffe0120cadbc0) at > /usr/src/sys/kern/kern_fork.c:1038 > #16 0xffffffff80eb682e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:611 > #17 0x0000000000000000 in ?? () > > Let me know if there’s any other information I can provide, or things I can test. > Fortunately the target machine is not a production machine, so I can panic it as > often as required. -- Andriy Gapon From owner-freebsd-fs@freebsd.org Tue May 16 13:49:22 2017 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 284FFD6E3A6; Tue, 16 May 2017 13:49:22 +0000 (UTC) (envelope-from srs0=fzxa=4w=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E790019FC; Tue, 16 May 2017 13:49:21 +0000 (UTC) (envelope-from srs0=fzxa=4w=sigsegv.be=kristof@codepro.be) Received: from [172.16.32.137] (unknown [103.210.33.250]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 77B0F9B97; Tue, 16 May 2017 15:49:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1494942559; bh=RxHjyppW7+6vB8x0AhdWEGMLnLkVHQvK9G2ERfdkCKA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=EkrR0fKwJWQhApXo10EwfkPFMknYt5gAPdiNOHMxfDD0FKhiQFfy26u5pvlzBtuG4 Ysv5WPu0UWcUl1HG+1RvByQp9aMNS+u26xrJQX8LsgJfUgkjWXIVwu0TjUHTw0H66U vsYvvG+1vMr/BUs5H2/oi+C/47JVGUx3KXZapZ7Q= From: "Kristof Provost" To: "Andriy Gapon" Cc: "Freebsd current" , freebsd-fs@FreeBSD.org Subject: Re: zfs recv panic Date: Tue, 16 May 2017 19:19:16 +0530 Message-ID: In-Reply-To: <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> References: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6082) 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, 16 May 2017 13:49:22 -0000 On 16 May 2017, at 15:41, Andriy Gapon wrote: > On 10/05/2017 12:37, Kristof Provost wrote: >> I have a reproducible panic on CURRENT (r318136) doing >> (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc >> dual 1234 >> (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var >> >> For clarity, the receiving machine is CURRENT r318136, the sending >> machine is >> running a somewhat older CURRENT version. >> >> The receiving machine panics a few seconds in: >> >> receiving full stream of zroot/var@before-kernel-2017-04-03 into >> tank/jupiter/var@before-kernel-2017-04-03 >> panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) >> (0x0 == >> 0x1), file: >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, >> line: 2007 > > could you please try to revert commits related to the compressed send > and see if > that helps? I assume that the sending machine does not have (does not > use) the > feature while the target machine is capable of the feature. > > The commits are: r317648 and r317414. Mot that I really suspect that > change, > but just to eliminate the possibility. Those commits appear to be the trigger. I’ve not changed the sender, but with those reverted I don’t see the panic any more. Regards, Kristof From owner-freebsd-fs@freebsd.org Tue May 16 14:26:47 2017 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 E31B9D6ED06; Tue, 16 May 2017 14:26:47 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 B2A15E3C; Tue, 16 May 2017 14:26:47 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x232.google.com with SMTP id u187so77188828pgb.0; Tue, 16 May 2017 07:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uAUpgAqnd1stsFvHEgHFbGeINeqKRDeEgnKaZRwCuME=; b=GOrTZvNP9MMjvWeDgKa44gRXxxNWRtWn8uvZnSlMcRXWkHasjHzAHHC7Aus9bqcUvs toNNxtG295qxEetlSLAYn9UZfI9sn35rZrg7ba+0CpSBMJSGwGhafuV8SzA+gulgcf0M EM5iAZfv8n6uvVQ+ix8MbOoupXj6xCxR8erQR5eWAnriZJgBk7BjKx4h59DipQBn4rsY HJaKw0eq0HfcJivbib/x5/8qodH2sRwhq8jUJiaUphONomuLKX+Ucd7nDJPzOgp0Si8f XYii9lU9jL1XAUugRZiPjeanHYL4gH+k7M7caM+Q1YwiuqLtFSCBvIUed1akfoI7kDYR tMEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uAUpgAqnd1stsFvHEgHFbGeINeqKRDeEgnKaZRwCuME=; b=EzwQbg3iKeqTV+GAMoXzpE6gbT2ViRpTlA48jxx+Y5Swx2D/ZghjBr/jqUF1LY+bGa 8MYrXaJHhPKTsXdcW9q9UQzsAWmhfSC8C+5YTsH7vp2CN7O6q6lN0gMgtU+akSZQxJsy a0C2HIFZk8agCzqIjmqBweWnHYi8GzzOKHPp/X0Tn9/SrM7ZRL5+Dcnnq/fbjszrlz8k Q2V5/jR8/D12UznuErun8AENgymJDAzKcnsEkI8WYBsKXAc/lcTRXFljZKSE2A+GppaL N22uawb0rA5e3lNfO+YFFvz7ekj7aOTdve5WrZTdr2L6C9v9fnx5oRx4t7uzQYY9Fvrt KWSg== X-Gm-Message-State: AODbwcAvBXOL0HekyoT13KndLd4mdSKUwtnhfkxFFGfR3br4pR1WYRLp HJYA10TZh0ukMFliFIZp5PTIQPwmvQ== X-Received: by 10.84.193.129 with SMTP id f1mr16469574pld.129.1494944807258; Tue, 16 May 2017 07:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Tue, 16 May 2017 07:26:46 -0700 (PDT) In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> From: "Eric A. Borisch" Date: Tue, 16 May 2017 09:26:46 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: Nikos Vassiliadis , "freebsd-fs@freebsd.org" , FreeBSD Stable 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: Tue, 16 May 2017 14:26:48 -0000 On Tue, May 16, 2017 at 1:31 AM, Trond Endrest=C3=B8l < Trond.Endrestol@fagskolen.gjovik.no> wrote: > I guess you had a /boot/zfs/zpool.cache file referring to the original > zroot pool. Next, the kernel found the vega pool and didn't realise > these two pools are the very same. > Assuming this is the case, shouldn't it be fixed? A check while importing that the guid of the pool targeted for import is not in the set of currently active guids would be worthwhile, but it -- apparently, if this is reproducible -- doesn't exist? Again, assuming this is reproducible. - Eric From owner-freebsd-fs@freebsd.org Tue May 16 14:29:59 2017 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 9E089D6EEB6; Tue, 16 May 2017 14:29:59 +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 B982D106D; Tue, 16 May 2017 14:29:58 +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 RAA05221; Tue, 16 May 2017 17:29:56 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dAdU4-0005UF-4V; Tue, 16 May 2017 17:29:56 +0300 Subject: Re: zfs recv panic To: Kristof Provost Cc: Freebsd current , freebsd-fs@FreeBSD.org References: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> From: Andriy Gapon Message-ID: <51bbf691-a8e2-2d16-6a95-c37a474c1dfe@FreeBSD.org> Date: Tue, 16 May 2017 17:28:35 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 16 May 2017 14:29:59 -0000 On 16/05/2017 16:49, Kristof Provost wrote: > On 16 May 2017, at 15:41, Andriy Gapon wrote: >> On 10/05/2017 12:37, Kristof Provost wrote: >>> I have a reproducible panic on CURRENT (r318136) doing >>> (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 >>> (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var >>> >>> For clarity, the receiving machine is CURRENT r318136, the sending machine is >>> running a somewhat older CURRENT version. >>> >>> The receiving machine panics a few seconds in: >>> >>> receiving full stream of zroot/var@before-kernel-2017-04-03 into >>> tank/jupiter/var@before-kernel-2017-04-03 >>> panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) (0x0 == >>> 0x1), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, >>> line: 2007 >> >> could you please try to revert commits related to the compressed send and see if >> that helps? I assume that the sending machine does not have (does not use) the >> feature while the target machine is capable of the feature. >> >> The commits are: r317648 and r317414. Mot that I really suspect that change, >> but just to eliminate the possibility. > > Those commits appear to be the trigger. > I’ve not changed the sender, but with those reverted I don’t see the panic any > more. Thank you for testing. Do you still have the old kernel / module and the crash dump? It would interesting to poke around in frame 14. -- Andriy Gapon From owner-freebsd-fs@freebsd.org Tue May 16 15:41:16 2017 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 6E0EED70A7A; Tue, 16 May 2017 15:41:16 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (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 35A4924B; Tue, 16 May 2017 15:41:15 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.158.117] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1dAeC5-0007rb-OD; Tue, 16 May 2017 17:15:25 +0200 Date: Tue, 16 May 2017 17:08:02 +0200 From: Fabian Keil Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) Message-ID: <20170516170802.71c2a470@fabiankeil.de> In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> Reply-To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Ux+_Pdaq.tM_nalOv235In9"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 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, 16 May 2017 15:41:16 -0000 --Sig_/Ux+_Pdaq.tM_nalOv235In9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Nikos Vassiliadis wrote: > On 05/15/2017 08:09 PM, Nikos Vassiliadis wrote: > > Hi everybody, > >=20 > > While trying to rename a zpool from zroot to vega, > > I ended up in this strange situation: > > nik@vega:~ % zfs list -t all > > NAME USED AVAIL REFER MOUNTPOINT > > vega 1.83G 34.7G 96K /zroot > > vega/ROOT 1.24G 34.7G 96K none > > vega/ROOT/default 1.24G 34.7G 1.24G / > > vega/tmp 120K 34.7G 120K /tmp > > vega/usr 608M 34.7G 96K /usr > > vega/usr/home 136K 34.7G 136K /usr/home > > vega/usr/ports 96K 34.7G 96K /usr/ports > > vega/usr/src 607M 34.7G 607M /usr/src > > vega/var 720K 34.7G 96K /var > > vega/var/audit 96K 34.7G 96K /var/audit > > vega/var/crash 96K 34.7G 96K /var/crash > > vega/var/log 236K 34.7G 236K /var/log > > vega/var/mail 100K 34.7G 100K /var/mail > > vega/var/tmp 96K 34.7G 96K /var/tmp > > zroot 1.83G 34.7G 96K /zroot > > zroot/ROOT 1.24G 34.7G 96K none > > zroot/ROOT/default 1.24G 34.7G 1.24G / > > zroot/tmp 120K 34.7G 120K /tmp > > zroot/usr 608M 34.7G 96K /usr > > zroot/usr/home 136K 34.7G 136K /usr/home > > zroot/usr/ports 96K 34.7G 96K /usr/ports > > zroot/usr/src 607M 34.7G 607M /usr/src > > zroot/var 724K 34.7G 96K /var > > zroot/var/audit 96K 34.7G 96K /var/audit > > zroot/var/crash 96K 34.7G 96K /var/crash > > zroot/var/log 240K 34.7G 240K /var/log > > zroot/var/mail 100K 34.7G 100K /var/mail > > zroot/var/tmp 96K 34.7G 96K /var/tmp > > nik@vega:~ % zpool status > > pool: vega > > state: ONLINE > > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 > > 2017 config: > >=20 > > NAME STATE READ WRITE CKSUM > > vega ONLINE 0 0 0 > > vtbd0p3 ONLINE 0 0 0 > >=20 > > errors: No known data errors > >=20 > > pool: zroot > > state: ONLINE > > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 > > 2017 config: > >=20 > > NAME STATE READ WRITE CKSUM > > zroot ONLINE 0 0 0 > > vtbd0p3 ONLINE 0 0 0 > >=20 > > errors: No known data errors > > nik@vega:~ % > > ------------------------------------------- > >=20 > > It seems like there are two pools, sharing the same vdev... > >=20 > > After running a few commands in this state, like doing a scrub, > > the pool was (most probably) destroyed. It couldn't boot anymore > > and I didn't research further. Is this a known bug? > >=20 > > Steps to reproduce: > > install FreeBSD-11.0 in a pool named zroot > > reboot into a live-CD > > zpool import -f zroot vega Why did you use the -f flag? Unless you can reproduce the problem without it, it's not obvious to me that this is a bug. Fabian --Sig_/Ux+_Pdaq.tM_nalOv235In9 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCWRsV0wAKCRAFiohV/3dU nU8JAKC5MOZFsHNKd0Ry4lkGNtpmLqimEwCgu28OsdQ1UNF+ft4TJZFd0VFneLc= =Qj7V -----END PGP SIGNATURE----- --Sig_/Ux+_Pdaq.tM_nalOv235In9-- From owner-freebsd-fs@freebsd.org Tue May 16 18:53:30 2017 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 299FED70F06; Tue, 16 May 2017 18:53:30 +0000 (UTC) (envelope-from srs0=fzxa=4w=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD6A8E39; Tue, 16 May 2017 18:53:29 +0000 (UTC) (envelope-from srs0=fzxa=4w=sigsegv.be=kristof@codepro.be) Received: from [172.16.32.137] (unknown [103.210.33.250]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id C68059033; Tue, 16 May 2017 20:53:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1494960807; bh=r5MlwkYi2hUMbdIHRH6Bn+5pm2QMc6BxZZ8lhLDGe8M=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=2vGoSeqc6IyFSqD4jU15sIi+gwDwpnTeBuCpOjW31soQpZUCd4E9YXbluGk6Id3bZ vk5FVdQAexje7if2PcSyw+3+XZZF10fDvWmrxEZPh9JfKmpf3HodGmmXuGFfM6hZsg mkiDC2g/x6vcVZSgr7ZUpPEIYSBDCJt5JdeHaSzg= From: "Kristof Provost" To: "Andriy Gapon" Cc: "Freebsd current" , freebsd-fs@FreeBSD.org Subject: Re: zfs recv panic Date: Wed, 17 May 2017 00:23:24 +0530 Message-ID: <96BF657D-34A8-4044-BC73-E0BCD1E98E52@sigsegv.be> In-Reply-To: <51bbf691-a8e2-2d16-6a95-c37a474c1dfe@FreeBSD.org> References: <18A74EE1-3358-4276-88EA-C13E28D8563A@sigsegv.be> <98df7d70-4ecb-34f2-7db2-d11a4b0c854a@FreeBSD.org> <51bbf691-a8e2-2d16-6a95-c37a474c1dfe@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6082) 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, 16 May 2017 18:53:30 -0000 On 16 May 2017, at 19:58, Andriy Gapon wrote: > On 16/05/2017 16:49, Kristof Provost wrote: >> On 16 May 2017, at 15:41, Andriy Gapon wrote: >>> On 10/05/2017 12:37, Kristof Provost wrote: >>>> I have a reproducible panic on CURRENT (r318136) doing >>>> (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc >>>> dual 1234 >>>> (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var >>>> >>>> For clarity, the receiving machine is CURRENT r318136, the sending >>>> machine is >>>> running a somewhat older CURRENT version. >>>> >>>> The receiving machine panics a few seconds in: >>>> >>>> receiving full stream of zroot/var@before-kernel-2017-04-03 into >>>> tank/jupiter/var@before-kernel-2017-04-03 >>>> panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) >>>> (0x0 == >>>> 0x1), file: >>>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, >>>> line: 2007 >>> >>> could you please try to revert commits related to the compressed >>> send and see if >>> that helps? I assume that the sending machine does not have (does >>> not use) the >>> feature while the target machine is capable of the feature. >>> >>> The commits are: r317648 and r317414. Mot that I really suspect >>> that change, >>> but just to eliminate the possibility. >> >> Those commits appear to be the trigger. >> I’ve not changed the sender, but with those reverted I don’t see >> the panic any >> more. > > Thank you for testing. > Do you still have the old kernel / module and the crash dump? > It would interesting to poke around in frame 14. > > This contains the kernel and crash files: https://www.sigsegv.be/files/zfs_recv_kernel_crash.tar.bz2 I was running r318356 at the time of this panic. Regards, Kristof From owner-freebsd-fs@freebsd.org Wed May 17 01:53:20 2017 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 27C8DD70E7E for ; Wed, 17 May 2017 01:53:20 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 DA81F70 for ; Wed, 17 May 2017 01:53:19 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qk0-x22d.google.com with SMTP id k74so145635609qke.1 for ; Tue, 16 May 2017 18:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kraus-haus-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GlC4JnHfrxhB3lQjx8DxInRgZvb1VWgaojDPo2L7yZc=; b=Yr/UBJPUb5yEGRXvCoYntmsPmRwoTYjVnL6lvaBzbi6cArynQSb+z3PqUTX7xK0ko6 Qs+JAR8cytpqlV45au2V2IV4WoPBuPnvDx7dCOtk7tHFPxptqhlh+6pD3A8sjC2Naa0a Z+Fv5YR23VYyB4tLahL8NmbYyW/mhNeoqE6LvtUEXmEDuqoWqcD68lIdNYpZftnmbtPy vbVmTIq+rPvGP3QU+45ccCn1b4x4wRkQBlBn11M+cyswfanYR5cRs6IiaXXXeiXpKnhx ZJivw8uhaZuJ2sKKB/HukkUKvq4kmSeE7O5TQNCsUFtN5lvSd3ozA77dFcyTeiNKAJYr JmeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GlC4JnHfrxhB3lQjx8DxInRgZvb1VWgaojDPo2L7yZc=; b=r6Sx8VwpKCNpWKCbXsqk4EdY8y42MAWuBYhNw+XcHJWGGlpFeYatUjznJ0sfYElqSN SxNsvzlUafo3RMWQTQjD4WnvoLdtTUEybRGcVtNcbn84t9x2UCq5FqmML0WfxSx9BCoK cwUWXgiotQqG8RfCzEGO/HZdcKi0tAXAnIRK729oRMFp402tQcCS5U012ftxIaQoupGF QjTf1cTAt7O0+N5HUm7r9XxhvG51ApzpFz4J7YvfEiLrAleIVQ7H0L8DeeSh8Mym8klq gU4eZmQ/4Szi9WCuOisfZdpx3tIFq6ST5QFK1RA5BM7EbS7OJsYGqMR536tDVE/WsiD1 sj/w== X-Gm-Message-State: AODbwcDCsPcPJctJghqerSqUsm+ofT7OHIcrUCdwUBQLVA9oA6JZhDQs CRzntJRtubm31RiF X-Received: by 10.55.215.219 with SMTP id t88mr834946qkt.45.1494985998916; Tue, 16 May 2017 18:53:18 -0700 (PDT) Received: from [192.168.2.65] (pool-74-109-188-83.albyny.fios.verizon.net. [74.109.188.83]) by smtp.gmail.com with ESMTPSA id j4sm429128qkd.19.2017.05.16.18.53.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 May 2017 18:53:18 -0700 (PDT) Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Paul Kraus In-Reply-To: Date: Tue, 16 May 2017 21:53:17 -0400 Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Stable Content-Transfer-Encoding: quoted-printable Message-Id: <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> To: "Eric A. Borisch" , "freebsd-fs@freebsd.org" X-Mailer: Apple Mail (2.3124) 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, 17 May 2017 01:53:20 -0000 > On May 16, 2017, at 10:26 AM, Eric A. Borisch = wrote: >=20 > On Tue, May 16, 2017 at 1:31 AM, Trond Endrest=C3=B8l < > Trond.Endrestol@fagskolen.gjovik.no> wrote: >=20 >> I guess you had a /boot/zfs/zpool.cache file referring to the = original >> zroot pool. Next, the kernel found the vega pool and didn't realise >> these two pools are the very same. >>=20 >=20 > Assuming this is the case, shouldn't it be fixed? A check while = importing > that the guid of the pool targeted for import is not in the set of > currently active guids would be worthwhile, but it -- apparently, if = this > is reproducible -- doesn't exist? When you use the -f (force) flag all bets are off. The assumption is = that you _know_ it is safe to import the zpool as commanded. In this = case, it was not. Many sysadmins I know have gotten into the sloppy (in my opinion) habit = of using the force option (for various things) all the time. The force = flag, whether it be on a zpool import or a kill -9 should be the last = resort when the non-forced command fails.= From owner-freebsd-fs@freebsd.org Wed May 17 18:04:51 2017 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 99C74D7123F; Wed, 17 May 2017 18:04:51 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00ABF1152; Wed, 17 May 2017 18:04:50 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from iris.berlin.strato.de ([192.166.200.216]) by mail.gmx.com (mrgmx002 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MSdz2-1daSTu2pRU-00RZGI; Wed, 17 May 2017 20:04:42 +0200 Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: freebsd-fs@freebsd.org Cc: freebsd-stable@freebsd.org References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <20170516170802.71c2a470@fabiankeil.de> From: Nikos Vassiliadis Message-ID: Date: Wed, 17 May 2017 20:04:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170516170802.71c2a470@fabiankeil.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:6Rd0kPg9czQyeXeXZ2jF/uGJOkXUj70mrDlNMedt8G+8LCwuQs1 vVveoV5bQh+1X1rpRPLBKKGDbRx1icgJe44jOBqstKNmR5Wz3r2mJ4XGMC+saoS4TU2n0YK lPg3N3uac4qYTJ/7AHAxwmNwheq/q8zcxdr6dXCqZ/bgrA1jqBrkP5mnLNoeupKPNX8PU1J CP2b3VAJypzIJfE8euPXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:BdwiEojxuvU=:lmUH/4TrjS6leaks0TnLnX Am3V5MGGsvXoj2BbnlG4oFmQqr7XGFaeJ17iki/iRi1DbsrdLDEYhZwpytEihzDmoOFvhRauG j6SfUCK+ncO8ojmfyVZjzBXS9gleTbvo3lxtk+IN+mazTeU2vxet+rd+h/NcuBW/2vOBiLxXT HSPz9Yda0oPbmyb86ks1hz0cdCVkmnR01yn7k5yDKn9Ck5d1KawJ0c63ws0K3HFp1cL5GZ0Yr kumPV7iMAiHNCTPVu785/N8FMVN2CUjSw+YTroMZshruEP+DfODMic8JG2Gk2PSCHUUaX+RgA ATdzw77Fe1/eVkH7oIJF0atLGFZ2JDDjgCgS0ihZU3YOZ3WcHWUS8w/Gr9BAjVOcslk9N/z8q Dd910kF8CRgE+AbWIODfZgH1tKI1CqUqKg1/R+jJI8HMjjWVfO2csl3z/5rEWvcC/znScqmVp JMO2eX6usBVptJI/Z8//sEPdERz4esFg8/EdCziQ265kyumKBMg0kV2PjtPQtj+2gBicfgzex pS5m6iUnwe1MprFm4uSxsRVtbht7aNFKPdqQnaAfBA5/T6WduN3sRv3416Z47Cud6a3l/NbPW 90rSMqEsmMhR9rdohocet34m937D879kLkSLC+O5G7KG9RX4MGd3IdLD/kqvQYcPPeWowUWI9 99c/+QvdsQMNYveKXY56ML7YJ7HfOIzA3LkwHA48ErKzp0u3ajLwREEU+Dr0NHg5SJ591fjDe Op55DTIILt2Gj7dzw5iAPRH5vjnjFdrDMhIAaXpVLjMh6HeIM02667DdlpLgdkmI3acjVyEBi t7mfHy9 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, 17 May 2017 18:04:51 -0000 On 05/16/2017 05:08 PM, Fabian Keil wrote: > Why did you use the -f flag? Unless you can reproduce the > problem without it, it's not obvious to me that this is a > bug. If you boot from another system, there is no other way to import a pool than using "import -f". So, I guess it is part of normal administrative tasks. You can read more here: > http://docs.oracle.com/cd/E19253-01/819-5461/gazuf/index.html This works and always have worked as documented. Renaming a pool also works as documented, that is, doing "zpool import oldnamepool newnamepool". Except for this corner-case. IMHO this is a very serious bug. Best, Nikos From owner-freebsd-fs@freebsd.org Wed May 17 18:13:13 2017 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 4571FD7150D; Wed, 17 May 2017 18:13:13 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 F1D781965; Wed, 17 May 2017 18:13:12 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: by mail-vk0-x22b.google.com with SMTP id x71so11328761vkd.0; Wed, 17 May 2017 11:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hYUUuMPJBB2gudUqoGc2lMp+p9y8838zDdhxLOvEDfs=; b=nSzD+EWdCvGB4MsVCiFsp5k9rDq8qNlDijNLqkC7E0looUs0APwj80K0YEHGN3rAuM JeryQRhU40aayalIDRUQ+facUoXiEdKPZ3CSMr+e/1DGbYYCTKQtk3DCLcbp14GcKrf/ xdqP4EBlpToSxreQNbWS26qrcfhSKGWfM7HAYXuP9Z/AT5d6ssYXdI0flTS+RqNWCUOr 5A693BelBA1NJcI2AgncIZSjqvYTX7tAXwtI7lhI+LRoYZqRaF0mHr2umo7UyJb+ZU1W 0m4xQUF5SEX01A3Ve5Sg0XR+uHORRxYE9dtlsPql3FkXKqHOWP6hu/k2JQ5xj9FGH5y5 zUfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hYUUuMPJBB2gudUqoGc2lMp+p9y8838zDdhxLOvEDfs=; b=qPvDhgOwWWr7hbwJVUFcokqjqKCMF5xfhwZA9LEMJ2gZV1EWbiFlVF1FofCPgVvew6 jqbqpWbdbHVMmX1gMnu+IdIzXfBfv1A4c6jNPthVpUJTHj63Gq2aX/nHliOmdEEOUA5+ Gw96A+HQdviijEjChNNONtUJw8jj4dz7oIr6mLzEXfkZHZFn+1KYbcodzSTWqpOreIOj 6AWf5+cvAgZJYsCTYjA/cqXKj2WrH5VQm15irFUNnFW1jpkxakndScn9HFicLY6T/Qo0 Xs6UWyZ9zfxaaU1zk4yPLBHsrSnCOxZzfcUdTbgwkF8PuiENInZwFb1v+nOAafLd7tL3 AgwQ== X-Gm-Message-State: AODbwcCSpHcRpeWTuG5XRGxR/bHi/+ck4EoQk++yrIGayGihdB2glosZ ZoUs2Mj1LoesEkQ6gi6muRBxHsmWsg== X-Received: by 10.31.197.5 with SMTP id v5mr28020vkf.119.1495044791867; Wed, 17 May 2017 11:13:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.169.135 with HTTP; Wed, 17 May 2017 11:13:11 -0700 (PDT) In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <20170516170802.71c2a470@fabiankeil.de> From: Brandon Allbery Date: Wed, 17 May 2017 14:13:11 -0400 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Nikos Vassiliadis Cc: freebsd-fs@freebsd.org, freebsd-stable 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: Wed, 17 May 2017 18:13:13 -0000 On Wed, May 17, 2017 at 2:04 PM, Nikos Vassiliadis wrote: > If you boot from another system, there is no other way to > import a pool than using "import -f". So, I guess it is > part of normal administrative tasks. You can read more here: > > http://docs.oracle.com/cd/E19253-01/819-5461/gazuf/index.html >> > > This works and always have worked as documented. > Renaming a pool also works as documented, that is, > doing "zpool import oldnamepool newnamepool". Except > for this corner-case. IMHO this is a very serious bug. > Sorry, no, that's not a bug. The bug is that, if importing on another system is a common administrative operation, it should not require you to disable *all* checking. I'd rather prefer specific support for that, e.g. "import -F expectedhostname" to import a zpool on a different host from expectedhostname --- now you have sanity checking for a potentially dangerous operation as well as not turning off *all* error/sanity checking. Sadly, this seems to not have occurred to either Sun or Oracle, despite having documented it. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-fs@freebsd.org Wed May 17 18:17:38 2017 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 BAE01D71655; Wed, 17 May 2017 18:17:38 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1906B1B9C; Wed, 17 May 2017 18:17:37 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from iris.berlin.strato.de ([192.166.200.216]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MRSeC-1dZMhJ1L4a-00SiiA; Wed, 17 May 2017 20:16:05 +0200 Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: "Eric A. Borisch" , =?UTF-8?Q?Trond_Endrest=c3=b8l?= Cc: "freebsd-fs@freebsd.org" , FreeBSD Stable References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> From: Nikos Vassiliadis Message-ID: <2bab15ae-9683-d9f3-9d5e-d8f66bc14cac@gmx.com> Date: Wed, 17 May 2017 20:15:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:G/hBLmD7MgVNB+aIa2NU9Xa494eigFoI3QCYrdY0VtYuO7dgP30 9nZ+fiqvQv4Z2cXA874fv0M/GF10GPoKKDvPPQ7CpIvhUyNlM3ZH5qlqlFDp5qxuMfEZcKn Oe65odg6RO+JB65mE/1waARtCNVnLlcABWhtrOfUF/W8LILkBaUMb2EqPglZCgywb82nv1A YrEBFyILMQRZFtlHsbZxg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Y5ymDjdWGY4=:t90FUQQ28kydicGzgKNw83 l0GxYaXYLBDhFCrdsdwDfEabwvGkiWFO+/6sRkYRTaYW8aPbxU9fM/xmqUuH3aVSt7HHBRt6Q 6cTcX+BY2Hxv6OeZiocdkzn6Myf4Ea0uEdLxm5GeRHOdzc9AIyg+rDl+HdZaGWK5mpvirYhZ9 HWB4xnOqJZVgNWu/zagMD1X38HVTVOkMmAT5crpjelRiaRgVXWVp01kvakrwEstHkVmojsgo4 WJ5h5hXBsWEDoLUYcaFSV/KFOKXzuNIiKaIVsBNEj/Nd9YI2IDUh3WJsZwlOLdU3HzdEpC4to cjX79c00A2fb9iS0vO4rw8b8sTRpShmsAI80gVSofml/XJXj33Htue9SQpM/m8HpLuL6xgwZW xlTShB8VilYRFQA0IvjccRVqeIoMtwWJb/Zf1jhF4tIGBGRaKfkcWFRUDQdcVCs5Z8Xs5bZ0p RisnaBHu6rU1Xc+xg2UHKXcMxtfaoVOGc6PVygoEfd9BO0E1KUxyxj3r6gXe3Gjwu4N+OSt9K 9u8k3WQHB2ltgqrS5tdtcfqcSFC2W9HWVNeJB2NT4gX/9h6pv91gFArjxHIMUWBWJX7X50J1J rIV9LDPJ/mU/BcmhcQMFycI26WH2OyMOb3+5yKLLpPnKMKI8yhxoUTspXB/E8zDnt17GdYoUK oYfFhe5L8AXWmsfCZ4SVKTr9N8Tho61U5/qZqjDznGdkNWlnsm22+PEnr9jo/g3icgcV/Amjp 950vzeNayhz/YKTy5bBfEgjfqwXInKigN/9RljqWByWGMybIAnmr/a+iPgvdg9/WHqVVUT9r5 m2rewvp 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, 17 May 2017 18:17:38 -0000 On 05/16/2017 04:26 PM, Eric A. Borisch wrote: > On Tue, May 16, 2017 at 1:31 AM, Trond Endrestøl < > Trond.Endrestol@fagskolen.gjovik.no> wrote: > >> I guess you had a /boot/zfs/zpool.cache file referring to the original >> zroot pool. Next, the kernel found the vega pool and didn't realise >> these two pools are the very same. >> > > Assuming this is the case, shouldn't it be fixed? A check while importing > that the guid of the pool targeted for import is not in the set of > currently active guids would be worthwhile, but it -- apparently, if this > is reproducible -- doesn't exist? > > Again, assuming this is reproducible. > It is reproducible. Except for a check in ZFS, I would also expect that the device cannot be opened twice for writing, that is, protected by GEOM. Nikos From owner-freebsd-fs@freebsd.org Wed May 17 21:12:16 2017 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 6508BD7138B; Wed, 17 May 2017 21:12:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 2E915650; Wed, 17 May 2017 21:12:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x22e.google.com with SMTP id q125so12600787pgq.2; Wed, 17 May 2017 14:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OWTKa7DOCMNQJXoDaOTRCgp716stR6ne//pxm3BAUiA=; b=G7S/54A309lIuMENoOMrz0KsHgt8SqGTDN3M1VDj1c4Ywq2QekJ1pOiGa+qdigrckV qw6QQt1NSpGPnVmW/RHqr1Qrf8xCJJpWXe9XPhc2HRiLzCrV5OdHKmdE/cPabW9NQnUB 9uAWgw6ba5NWc7G4VKHG+et7udGfrJu2FZbqD6x9Gvnu9siLx8FveBUbd24dk4FevNXe uSbGg2YSs5EN9Eb/fj08CEDEPHo2bQMk3g8oUNAhghr2cxp0OxmfNp0lXPHMwTSMNJ92 ToSKka6NLtr1I2/no8F1MvtngzV/t3JJ3DRuaftl+OGrKHZxBYQ57QHENPYAO6LgveKG CHnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OWTKa7DOCMNQJXoDaOTRCgp716stR6ne//pxm3BAUiA=; b=AzoSwkG9GW8bzqQ6g/TmwUGA3u9APPK7mwtoHAXgq+uCQ54crMDpVut8hlZH9IZBVZ q+SjlZVaUPDgYgP8XSDgvwzRj4z+V9mDeMs0QIcVxHvTQKBovrJdCcqaBJWcBhlAOAtn Dph42AUMfvi7TmPFKgcxXg+GiXcCC1OE621t5gZERuVISamjFm0Y3LBoP81Yd6fOM2PS zMe0bbsqt+BaQXKhzvVr777RtrSEaqhvLtrrfERCR0vE5RXMn7D+ugYdIXRGznar3G3v rElFnZfbBGBx7IhOfZkNDyO41l5NH6lCsBtLMCssOZ3uyKLA7rxz0kdUlPGLlCk+4FKA 5PKw== X-Gm-Message-State: AODbwcDR/0GsB70j993C19Z5EtgV/lVq/4kmP/0Yf5pDCBBA2cwVDiEJ Xz170B7Jc+PwftO6zqEvgm5VNDHGWA== X-Received: by 10.98.21.17 with SMTP id 17mr776347pfv.71.1495055535672; Wed, 17 May 2017 14:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Wed, 17 May 2017 14:12:15 -0700 (PDT) In-Reply-To: <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> From: "Eric A. Borisch" Date: Wed, 17 May 2017 16:12:15 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Paul Kraus Cc: "freebsd-fs@freebsd.org" , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Stable 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, 17 May 2017 21:12:16 -0000 On Tue, May 16, 2017 at 8:53 PM, Paul Kraus wrote: > > > > On May 16, 2017, at 10:26 AM, Eric A. Borisch wrote: > > > > On Tue, May 16, 2017 at 1:31 AM, Trond Endrest=C3=B8l < > > Trond.Endrestol@fagskolen.gjovik.no> wrote: > > > >> I guess you had a /boot/zfs/zpool.cache file referring to the original > >> zroot pool. Next, the kernel found the vega pool and didn't realise > >> these two pools are the very same. > >> > > > > Assuming this is the case, shouldn't it be fixed? A check while importing > > that the guid of the pool targeted for import is not in the set of > > currently active guids would be worthwhile, but it -- apparently, if this > > is reproducible -- doesn't exist? > > When you use the -f (force) flag all bets are off. The assumption is that you _know_ it is safe to import the zpool as commanded. In this case, it was not. > > Many sysadmins I know have gotten into the sloppy (in my opinion) habit of using the force option (for various things) all the time. The force flag, whether it be on a zpool import or a kill -9 should be the last resort when the non-forced command fails. Short version: It's not the -f causing the problem, it's the parsing and (double) importing via /boot/zfs/zpool.cache that is. Longer story: I've been able to reproduce the issue, and if I delete the /boot/zpool.cache file from the (alt rooted during live CD session) renamed pool before rebooting into it, everything is fine. So it is not the import with -f that is causing the problem here, it is the following reboot when the zpool.cache file is parsed and ensuing double-import. (As an aside, using the -f is required to import a pool last used and not exported by another system, and is a common and documented use case. If you look at the code, it turns on a the ZFS_IMPORT_ANY_HOST flag, not an 'ignore all errors' state. There is a separate -F which is more 'force'-ish (turns on rewinding).) This points to error checking while importing pools via the cache as one immediate place to look, specifically to exclude processing of any GUIDs already active on the system. A more general change to prevent importing two pools with the same GUID is also worthwhile (IMHO) and would prevent it the problem, too. - Eric From owner-freebsd-fs@freebsd.org Thu May 18 01:27:54 2017 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 EBC50D71E4E for ; Thu, 18 May 2017 01:27:54 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 AA147192A for ; Thu, 18 May 2017 01:27:54 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qt0-x22d.google.com with SMTP id t26so23691898qtg.0 for ; Wed, 17 May 2017 18:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kraus-haus-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NgvmcpnkSUZQzeEjpwZPTn7fjfwhuF2cS04IbRKQ5EE=; b=XsZi1o76VVz6p2yyrwuH4G90gqtOKtD7CyXRZT/yMRkGFZ68ub933e7LhcbLwZutrP cartnpU5qb3QIusB5BuNWd7y6lnb1PkVgp1WcOcQCaPRJSP3/PvEpFg1TupFdn0Q0Usd NZshKouVf1GWUlNci6X7c+zo1RpgfdcsTrsW76aBfZ1K1q+Fs4u5TjfetM83SZpHcR+h w4HIuEj65D/lOqDHqtFlG8ARCPT6KIC2oMr5bLloKqG7b2YxwvZROgMib6+cAShkAf50 egoQP49x7MnbcuyC7A4OxigBLEEF+ARvOOqRUXe2jmlIY44ukWaSzT7vwdJG15FsLRJu 7Jeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NgvmcpnkSUZQzeEjpwZPTn7fjfwhuF2cS04IbRKQ5EE=; b=LpWISaNNipafx536Lrk7O8YFfeYFrZFNhYSnuSAjNpYDAEfIIU0+WNY1wPF5pECPMC cCZO8kUJPsAw3h+Mas1y8P11pqmCctEwA4Y9ESQBsGXJAcoXTBbRRn7ejv750ofo19nO glAFqDB3plgNX57jst9vBBG3rpDFxVwYIFR2RL1X4KHWUwss8p7wZf51Kpd4ZzRYdiIv UrHJjZObYM9qM/RPS0eX7o+eZHfH7BklOH2VUyw/ulkTZyqX1C7Ep7ucsOftumk4Agi9 khpwEN6XmrGiA7Qzhwsa2+vE1r61QlzXQFx7QKNJ52xFPDxiW05tMc2CcwqLOsVdeXwB 7IGg== X-Gm-Message-State: AODbwcD/pZxBkpztmBfq/h2SzEABNIJfttnFJywAeT2NBSGNN4b8/+6v jSE7O0nmzoRmmlvQ X-Received: by 10.200.55.124 with SMTP id p57mr1559084qtb.258.1495070873603; Wed, 17 May 2017 18:27:53 -0700 (PDT) Received: from [192.168.2.65] (pool-74-109-188-83.albyny.fios.verizon.net. [74.109.188.83]) by smtp.gmail.com with ESMTPSA id b23sm2740056qkb.31.2017.05.17.18.27.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 May 2017 18:27:53 -0700 (PDT) Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Paul Kraus In-Reply-To: Date: Wed, 17 May 2017 21:27:56 -0400 Cc: "freebsd-fs@freebsd.org" , FreeBSD Stable , =?utf-8?Q?Trond_Endrest=C3=B8l?= Content-Transfer-Encoding: quoted-printable Message-Id: <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> To: "Eric A. Borisch" X-Mailer: Apple Mail (2.3124) 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: Thu, 18 May 2017 01:27:55 -0000 > On May 17, 2017, at 5:12 PM, Eric A. Borisch = wrote: >=20 > Short version: >=20 > It's not the -f causing the problem, it's the parsing and (double) > importing via /boot/zfs/zpool.cache that is. I was unclear=E2=80=A6 _how_ do you get the double entry in zpool.cache = _except_ by using the -f option with a zpool that is already imported ? > Longer story: > So it is not the import with -f that is causing the problem here, it = is the > following reboot when the zpool.cache file is parsed and ensuing > double-import. I would maintain that it is the combination of the import of an already = imported zpool which causes the double entry in the zpool.cache in = combination with a recent rename of the zpool. Would (did) the import without the force fail ? The last host this zpool = was imported on was _this_ host, so the =E2=80=9Cis this zpool used by = another host=E2=80=9D check would not stop such an import. Or, is the zpool rename not updating the name in the zpool.cache file ? I don=E2=80=99t currently have a test system available or I would = experiment...=20 > (As an aside, using the -f is required to import a pool last > used and not exported by another system, and is a common and = documented use > case. If you look at the code, it turns on a the ZFS_IMPORT_ANY_HOST = flag, > not an 'ignore all errors' state. There is a separate -F which is more > 'force'-ish (turns on rewinding).) There are times when it is necessary to force an operation. One of the = underlying assumptions is that the person using the force option _knows_ = with a very high degree of certainty that the zpool is not in use, = either by another system or the same system. From owner-freebsd-fs@freebsd.org Thu May 18 02:38:39 2017 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 24EDDD723D2; Thu, 18 May 2017 02:38:39 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 E5F961D7E; Thu, 18 May 2017 02:38:38 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x231.google.com with SMTP id u28so15660524pgn.1; Wed, 17 May 2017 19:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fb817rkaPmR7yPis4e72q48e7yP4C00HB6jBQE5/w60=; b=hoVz6ChGvAM9FEDJU+0tpHWtV8cZ51wyPX434Imyp+Be9EU+wMJoO/BgiqTHlhgyHV ZgtU8p8fdBpWxWJpzNNtExoKrH+L24SiYxPDthcuo1DdT5padZNey9n6wD/jpI+DGaxK G9OW6CN8xYo8S0AarmuSp1TiOHX4r94yaXy89XLZhRR1WdIUDyq6kDOqhzUr5qsaD64D qDyE4+SiyYiVIj23gj52L3+xRp8rjPN2l6IfklQlC2f55nR+ZaGXBNvY77bsPMW4khAu Jy3ZnaxAM4op3qpjkbBtI1gR/ZKODexRY6RN+6tBS4qMnnr40KzH/bHok2ehSasyMCUW vzcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fb817rkaPmR7yPis4e72q48e7yP4C00HB6jBQE5/w60=; b=jkCQ6X0MMock6S9ey5liK0bYGjxNf7LBVXe9oqq5ENFzHXFgLkxNaHxujqAFoxQD1L BT/tNqhTCDd+Xb9tNMXdth6QueZ5UTqltPVMn2NlP/RHx3Ik2D4OpjRvcYnTPdoVlflt NKE1ScbJmHiNg9vuiTRWQJIgQrUpx7M9kHa/TncEmzCGQBbFeloK3NNONcAgU49lc31/ GhurwUGQHbh7xo7EM4Es6KT6/O5CHNIsVXdqMlij0NFQQ15/rQznZFZ5ARP6qkFejy6z erQ1d4L9PopEVdpwbanY4gZLeNyY0m9CGS8VjC7k/d0+vmV2h1c4a6JaDR+x1ziA1cPb RlTw== X-Gm-Message-State: AODbwcAEJW5lfBdSJy0VNMnUSK0idKhhJQONiIOD1CmPa4LRr1a/dHXH pe8tnzp8U2n0rhC0qc1Lfx4PffCANSttDo0= X-Received: by 10.84.193.129 with SMTP id f1mr2043238pld.129.1495075118396; Wed, 17 May 2017 19:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Wed, 17 May 2017 19:38:37 -0700 (PDT) In-Reply-To: <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> From: "Eric A. Borisch" Date: Wed, 17 May 2017 21:38:37 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Paul Kraus Cc: FreeBSD Stable , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , "freebsd-fs@freebsd.org" 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: Thu, 18 May 2017 02:38:39 -0000 On Wed, May 17, 2017 at 8:27 PM Paul Kraus wrote: > > > On May 17, 2017, at 5:12 PM, Eric A. Borisch wrote= : > > > > Short version: > > > > It's not the -f causing the problem, it's the parsing and (double) > > importing via /boot/zfs/zpool.cache that is. > > I was unclear=E2=80=A6 _how_ do you get the double entry in zpool.cache _= except_ > by using the -f option with a zpool that is already imported ? > To be clear, I'm using "already imported" to me =3D=3D shows up in 'zpool l= ist' of some running OS, not described in a config file somewhere. The Oracle description [1] that goes along with 'import -f' is: "Do not attempt to import a pool that is active on one system to another system. ZFS is not a native cluster, distributed, or parallel file system and cannot provide concurrent access from multiple, different hosts." This sounds much more like like my description (shows in a running zpool list) than described by a config/cache file. Steps to recreate: (I did it in < 5 minutes in a VM.) Arabic numerals are user actions, Roman numerals are zpool state. 1) Install FreeBSD root-on-zfs onto 'Alpha' I. Alpha exists on disk, and is active whenever your computer is running 1a) Decide at some point later you would like to rename your root pool... so you 2) Boot off live CD II. Alpha exists on disk, but is not active (imported) 3) zpool import alpha beta (because that's how you rename pools) 3a) zpool helpfully points out that it *may be in use* on another system, and use -f to import it anyway. Realize you are at the system that was using it, but in a completely different environment, and decide that it is safe to import. III. Alpha still exists on disk, and is still not active 4) zpool import -f alpha beta succeeds without any complaints. IV. Alpha no longer exists, Beta exists (with the same GUID as Alpha) AND is active. This is an 'atomic' operation from user's point of view, and at no point does zpool list show more than one pool 5) zpool list shows only beta; scrubs fine, life is good.. V. Beta exists on disk and is active and healthy. Alpha is no more. (Except as a ghost in a cache file) 6) Reboot into OS. Kernel messages mention booting off of beta/. Good, good... VI. Beta exists at this point certainly, as boot progresses. The ghost of Alpha is still lurking, however. Before we drop to a prompt, the zpool.cache is parsed, and Alpha springs back into existence beside Beta. NOTE: This is where I'm suggesting a cache file shouldn't trump the on-disk metadata (name mismatch) and running state (GUID collision) and lead to corruption. VII. Alpha and Beta exist together violating the Pauli exclusion principle as it applies to zpools. 7) Despair. Try to export one or the other. No good. Errors start to show up in zpool status. Rebooting fails in various colorful ways. Trying to import the pool again via Live CD is equally fruitless. VIII. Your zpool is cooked. By a config file. Hope you weren't using ZFS for integrity. I would maintain that it is the combination of the import of an already > imported zpool which causes the double entry in the zpool.cache in > combination with a recent rename of the zpool. > > Would (did) the import without the force fail ? The last host this zpool > was imported on was _this_ host, so the =E2=80=9Cis this zpool used by an= other > host=E2=80=9D check would not stop such an import. Yes, it fails without the -f, and helpfully suggests using the -f to import it. I don't think it's already imported in a way that most people (including Oracle) describe it. Or, is the zpool rename not updating the name in the zpool.cache file ? As the zpool rename is occurring in the live cd system; the cache file (living on the filesystems of the pool to be renamed) isn't accessible during the import/rename step, and isn't known about by the active OS. I suspect using a temporary and updating the cache file post-rename pre-reboot would work, just like deleting the cache file before reboot worked. I still, however, maintain an errant cache file shouldn't trump both on-disk state (my name... is Beta) and in-memory state (but I already have that GUID) and bring down a pool. - Eric [1] http://docs.oracle.com/cd/E19253-01/819-5461/gazuf/index.html > From owner-freebsd-fs@freebsd.org Thu May 18 03:42:55 2017 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 35243D716E0 for ; Thu, 18 May 2017 03:42:55 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 E2C141FFD for ; Thu, 18 May 2017 03:42:54 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qk0-x231.google.com with SMTP id u75so26287487qka.3 for ; Wed, 17 May 2017 20:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kraus-haus-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rRuiv0UMmsKXc6sLWxRBps3uE0ATm9YCKhbN2tZaT18=; b=ig7hl1yw+beA31TLcXiZQWzvMQTg1W8ojgFBJsYjKIs7GxlKa26DmOOAgNu/UkuXi/ tqvsohreC5RHpWjDGpZwusaIEaKcuwbUzstaYYI1QAge+a2p/KUUjp9JB2XpTbKfPXjC UkVi7WsOIS6JyhqfJpi1gAn+O8qNjfE8QtMcutmrywA9mUCPsG7FrzknQ7f0TqKZIufx h3FkHxUSOSLJY6NPDoLmlduCtMWuv8x/B/AiTKbO4tB0/aM2Iugqdo6VzNKpujHiDgAo 3+nagrBVhzFEjFqMO8gHVqlu47SWzOiaLfZvBhmui8/AypcGSYC4uz6uDSYIjIy83LjE /5LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rRuiv0UMmsKXc6sLWxRBps3uE0ATm9YCKhbN2tZaT18=; b=KR8JguJ4KROyk+rsvXe6dFp5bPVA7lUsfyV0kwImNBfu2+7p2j+qHsIvJcrIBCSdej /rTp10dXPAkdGcV2EjQTZ3fZa1xnEatYKXs9FMUzSKwKqlIAg3ep+4S5aicz00bZSUhU qRZoj+Z+XHE9GVUy2Aga8nlTpR8SHUV+N+rH3No5XBkH/g+G5BbgsrGXbepjJPBEtelg kqmr1f3Oj5V+wXLpaVg5CCQivIv0Subi0MT/X/w1cLnvATsPKWUCmVojbxWA7Y+V/cza KJEr/D8DR5reEB2uZ1joL+IheKgRd5rFjerYza/r1RfnHKmLuuKRW98jHMHW3v/4ztH/ PcUw== X-Gm-Message-State: AODbwcDeuIYUKDUZbZ0GDLs04R2Zt0VtAaLng/A2wooBKUIFNltqePen kxfIU8tFBJToW0ax X-Received: by 10.55.129.65 with SMTP id c62mr1894367qkd.229.1495078973857; Wed, 17 May 2017 20:42:53 -0700 (PDT) Received: from [192.168.2.65] (pool-74-109-188-83.albyny.fios.verizon.net. [74.109.188.83]) by smtp.gmail.com with ESMTPSA id l10sm2690871qte.15.2017.05.17.20.42.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 May 2017 20:42:53 -0700 (PDT) Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Paul Kraus In-Reply-To: Date: Wed, 17 May 2017 23:42:52 -0400 Cc: Nikos Vassiliadis , FreeBSD FS , freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <20170516170802.71c2a470@fabiankeil.de> To: Brandon Allbery X-Mailer: Apple Mail (2.3124) 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: Thu, 18 May 2017 03:42:55 -0000 > On May 17, 2017, at 2:13 PM, Brandon Allbery = wrote: >=20 > Sorry, no, that's not a bug. The bug is that, if importing on another > system is a common administrative operation, it should not require you = to > disable *all* checking. I'd rather prefer specific support for that, = e.g. > "import -F expectedhostname" to import a zpool on a different host = from > expectedhostname --- now you have sanity checking for a potentially > dangerous operation as well as not turning off *all* error/sanity = checking. The assumption at work here is that you have exported the zpool from the = system that was using it. At that point, zpool import with no = -f will work fine. It is only the special case of a zpool that was NOT = exported that requires the use of the -f option. I don=E2=80=99t see this as an unreasonable expectation. You unmount = non-ZFS (and under the covers ZFS) filesystems before moving them to = other systems. Why should we not be expected to export a zpool before = moving it ? Note that in the case of a crashed or failed or otherwise _unexpected_ = move of a zpool from one system to another you still need to force the = import. Just as you are forced to either fsck or replay journals on = non-ZFS filesystems before you can mount them.= From owner-freebsd-fs@freebsd.org Thu May 18 14:18:04 2017 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 11204D73EDB; Thu, 18 May 2017 14:18:04 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 C682E13E6; Thu, 18 May 2017 14:18:03 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id 9so24591390pfj.1; Thu, 18 May 2017 07:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uyiJiCu4ojy7hTBs2BmORXpW3VGO/WrzmJwDIv3Rd4A=; b=PGubdnf1QNCJxrmbXdrdx944WQLfaem2/gOm+IN+ubD6Ke9F+Evc7PoS51TlsqVol1 6+2dcWz9v0eJy8tNOFCllgfjdzTtz13f3q2kOHzKsAIZufqac+BQcPgzMPw3fQszzgDB Yw31KWKndq1WdT0xCBr0wJYRGT+OhJ/39wLyVkD9Q91vblr5uhutJepwAh4vguVbqnyg OtdZRNNUT3gSf9b5DvEdq0wsqEw8GyK9JzNfRWVw50A72hxF6NJh1HuKjeJKTFDypXtJ SQFx6lbPzCAiSRXE7KIwWiP9fuwKQMJr+9RBvCpPS2pYWm4Lu0Upp+8HzbdF2lVLSZGP HZew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uyiJiCu4ojy7hTBs2BmORXpW3VGO/WrzmJwDIv3Rd4A=; b=AmPOgwVJmy8mEMf3geZIe3VF4+XUHuukYTqK6/xX6N07JFWoFCm5NTOedmAND4BaJm p5TeN7DRm1oMr3o1VTtsOk5zd6WVpkT3qOFqWZv/0vvObFJXp6UkLH4X+2lGz0njUQwH HTNPXALr47wRyaVREeaE/4dDfreGFNdXyQQabfQn6GZ11kyP4fZFErLD30OGQKQ1c1iS VNtGCz7OBFPUbvt973eHhUsRCMRHhrNeeSahH3tZHCaGPKTMtgFQwpWiatQOPVK046wQ X+hWqE5pgJyhDH3stm8cku7bMTfvY3zTMtahQaqgZM4jbou7Q3oDpPRRsNUgS3ybN8ZN U4qA== X-Gm-Message-State: AODbwcDVy+4SbWUCMr4qb4L4e7H9ad8m6c16hxLvcr/eVQWH5supYLch lfWHz3TLwKFOY0UDRbOg86aVrAQN0pjy X-Received: by 10.99.186.78 with SMTP id l14mr4775984pgu.182.1495117083279; Thu, 18 May 2017 07:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Thu, 18 May 2017 07:18:02 -0700 (PDT) In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> From: "Eric A. Borisch" Date: Thu, 18 May 2017 09:18:02 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Paul Kraus Cc: FreeBSD Stable , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , "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: Thu, 18 May 2017 14:18:04 -0000 On Wed, May 17, 2017 at 9:38 PM, Eric A. Borisch wrote: > 4) zpool import -f alpha beta succeeds without any complaints. > > IV. Alpha no longer exists, Beta exists (with the same GUID as Alpha) AND > is active. This is an 'atomic' operation from user's point of view, and at > no point does zpool list show more than one pool > > 5) zpool list shows only beta; scrubs fine, life is good.. > > V. Beta exists on disk and is active and healthy. Alpha is no more. > (Except as a ghost in a cache file) > A quick test revealed one other tidbit this morning; if I 'zpool export beta' at this point in the process (still in live CD OS), everything is OK on reboot into the installed OS. For whoever wants to investigate handling/hand-off between bootloader/kernel/fully booted, the problem appears when a: 1) root pool is renamed, but not 'zpool export'-ed after rename via an 'external' OS (live CD) ** and ** 2) A stale zpool.cache file exists on the pool referring to the original name. - Eric From owner-freebsd-fs@freebsd.org Thu May 18 19:36:57 2017 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 C5A36D737CC for ; Thu, 18 May 2017 19:36:57 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068052.outbound.protection.outlook.com [40.92.68.52]) (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 4727CFD1 for ; Thu, 18 May 2017 19:36:56 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) Received: from HE1EUR02FT033.eop-EUR02.prod.protection.outlook.com (10.152.10.54) by HE1EUR02HT062.eop-EUR02.prod.protection.outlook.com (10.152.11.230) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1075.5; Thu, 18 May 2017 19:36:54 +0000 Received: from DBXPR05MB157.eurprd05.prod.outlook.com (10.152.10.59) by HE1EUR02FT033.mail.protection.outlook.com (10.152.10.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.5 via Frontend Transport; Thu, 18 May 2017 19:36:53 +0000 Received: from DBXPR05MB157.eurprd05.prod.outlook.com ([fe80::2c4a:20f8:b3dd:6a2d]) by DBXPR05MB157.eurprd05.prod.outlook.com ([fe80::2c4a:20f8:b3dd:6a2d%27]) with mapi id 15.01.1075.014; Thu, 18 May 2017 19:36:55 +0000 From: kc atgb To: "freebsd-fs@freebsd.org" Subject: Different size after zfs send receive Thread-Topic: Different size after zfs send receive Thread-Index: AQHS0A4bB1aDgtJ4x0WmR87yTfeQcg== Date: Thu, 18 May 2017 19:36:55 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=hotmail.fr; x-incomingtopheadermarker: OriginalChecksum:D55B19F29969BB1F6133241BF63760C9DAC1E8CC43DC9189C7C759887749937C; UpperCasedChecksum:4BE0A3E5EE4AFB19E1AF5D3BADA65796E553198EDD6DD5622B89D6BB22B0BBA1; SizeAsReceived:7922; Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR02HT062; 5:Mp6+fV53TILk5X7m5kdU62lKrIGGS/qjbaStjYl9yAx0qPhsHDnfFC/OOj72kHe8Lh6OK0Ro/UJivpog+7WduUKvIo7tOuJcAk43W+B0jfGnBeGrd9wf66JgRByzdgg803k7RS2PX9eLOcGffhFndg==; 24:/rQUHmQoMTVrReKlMcZfAmHyGXEn3axNYQeE47hf6C+8B3cZG3egQGSxGxDsV6ecXKF0WNdw1I6MAZ8Dhixyea1AAh0KREo3UdM2++NUOQ8=; 7:r0iLbpecxii/+QXemM7J/qQHs1Ye54w0Oi2if34VjeQNrwytIFAcxi73CB7lPnaOS4REM61t32+SXJKH3vnUy4GpS2OMXHVtKwydhyRMsNA+tWN14N3cFK1IMRFLXKNqnSDoKlgMoe3ONJh4Uloiy8vtpLnDrCSdrbAXyrWhfcIXyZTNx+4sZqlSW7gK2G5LJeuoyA7MYv0kNL/5/YMuZZabpZVmK86MXXi0pKqvfkYHHlrV/kXT5QlpOkDAaXA45js98ewtb7vNefEnK13jPDpx+qRpA8qsPQngFHonRvt9a0crhx0tGROrIIbqdmGo x-incomingheadercount: 40 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR02HT062; H:DBXPR05MB157.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 348a0488-ccb4-43fb-8754-08d49e253d39 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:HE1EUR02HT062; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HE1EUR02HT062; BCL:0; PCL:0; RULEID:; SRVR:HE1EUR02HT062; x-forefront-prvs: 0311124FA9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 19:36:55.3112 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR02HT062 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: Thu, 18 May 2017 19:36:57 -0000 Hi, Some days ago I had a need to backup my current pool and restore it after p= ool destroy and create.=20 The pool in my home server is a raidz1 with 4 disks. To backup this pool I = grabbed two 4TB disks (single disk pools) to have a double backup (I have j= ust one sata port left I can use to plug a disk).=20 The whole process of backup and restore went well as I can say. But looking= at the size reported by zfs list make me a little bit curious.=20 storage/datas/ISO 35= 420869824 381747995136 35420726976 /datas/ISO storage/datas/ISO@backup_send = 142848 - 35420726976 - storage/datas/ISO@backup_sync = 0 - 35420726976 - b1/datas/ISO 3543930= 8800 2176300351488 35439210496 /datas/ISO b1/datas/ISO@backup_send 9= 8304 - 35439210496 - b1/datas/ISO@backup_sync = 0 - 35439210496 - b2/datas/ISO 3543930= 8800 2176298991616 35439210496 /datas/ISO b2/datas/ISO@backup_send 9= 8304 - 35439210496 - b2/datas/ISO@backup_sync = 0 - 35439210496 - storage/datas/ISO 35= 421024576 381303470016 35420715072 /datas/ISO storage/datas/ISO@backup_send = 142848 - 35420715072 - storage/datas/ISO@backup_sync = 11904 - 35420715072 - storage/usrobj 5= 819085888 381747995136 5816276544 legacy storage/usrobj@create = 166656 - 214272 - storage/usrobj@backup_send = 2642688 - 5816228928 - storage/usrobj@backup_sync = 0 - 5816276544 - b1/usrobj 567508= 1728 2176300351488 5673222144 legacy b1/usrobj@create 11= 4688 - 147456 - b1/usrobj@backup_send 174= 4896 - 5673222144 - b1/usrobj@backup_sync = 0 - 5673222144 - b2/usrobj 567518= 8224 2176298991616 5673328640 legacy b2/usrobj@create 11= 4688 - 147456 - b2/usrobj@backup_send 174= 4896 - 5673328640 - b2/usrobj@backup_sync = 0 - 5673328640 - storage/usrobj 5= 820359616 381303470016 5815098048 legacy storage/usrobj@create = 166656 - 214272 - storage/usrobj@backup_send = 2535552 - 5815098048 - storage/usrobj@backup_sync = 11904 - 5815098048 - As you can see the numbers are different for each pool (the initial raidz1,= backup1 disk, backup2 disk and new raidz1). I mean in the USED column. I h= ave nearly all my datasets in the same situation (those with fixed data that ha= ve not changed between the beginning of the process and now). backup1 and b= ackup2 are identical disks with exactly the same configurations and have different= numbers. I used the same commands for all my transfers except the name of = the destination pool.=20 So, I wonder what can cause these differences ? Is it something I have to w= orry about ? Can I consider this as a normal behavior ?=20 Thanks for your enlightments, K. From owner-freebsd-fs@freebsd.org Thu May 18 21:17:52 2017 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 3E6F8D73E21 for ; Thu, 18 May 2017 21:17:52 +0000 (UTC) (envelope-from rde@tavi.co.uk) Received: from kipling.tavi.co.uk (kipling.tavi.co.uk [81.187.145.130]) by mx1.freebsd.org (Postfix) with ESMTP id 005C81D14 for ; Thu, 18 May 2017 21:17:51 +0000 (UTC) (envelope-from rde@tavi.co.uk) Received: from kipling.tavi.co.uk (localhost [127.0.0.1]) by kipling.tavi.co.uk (Postfix) with ESMTP id 260EC7592C for ; Thu, 18 May 2017 22:17:41 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tavi.co.uk; h=date:from:to :subject:message-id:mime-version:content-type :content-transfer-encoding; s=selector1; bh=3FE4liR8cGuquAEmkPEa 0UAEGyU=; b=OSoZ3XKPks4YGaJ/rSTBmDDRV8d34PKpLp/Elpa2xLsi9xH3XL2M W3lJZlwaOV7ChaUHUKhyvY6+mOJiVmhJp4zl9nUXO3r7qxxb+qwSSAdzpdFHPN6r X0MOPpuJE40T+2WVme6JARiIu15FmayPexAeA/07u87OaZpixouMGvo= Received: from raksha.tavi.co.uk (raksha.tavi.co.uk [81.187.145.139]) (Authenticated sender: rde@tavi.co.uk) by kipling.tavi.co.uk (Postfix) with ESMTPA id 91A7475927 for ; Thu, 18 May 2017 22:17:40 +0100 (BST) Date: Thu, 18 May 2017 22:17:40 +0100 From: Bob Eager To: freebsd-fs@freebsd.org Subject: smbfs and SMB1 Message-ID: <20170518221740.6cedb453@raksha.tavi.co.uk> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; i386-portbld-freebsd10.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEUwXjFLc0vD0cS7y7zw9PDZ4tkWSRaVrZZ+m39qi2tXfVj////7+/utwK4IPggAOAAJUUA7AAABKklEQVQ4jWPYjQMwDFYJp0NKEKCNJmEf9h8CsimXiL2e33s3/e7F7K2Cs3f3dCMkQkMKj4YuCY3K3iR+e7fMaiSjvkX0/5cFGrWpe2uLzOpaExUVqMS/8PX/Re5ey960OLBTZpFA8+IlSBKPQ92zNyUUBsosN58uIY0k8f+/ONCoYytkVuhWzVwNkYiYbqk5M3NmOVBi41YZ8RsGF7shEtFb5KJ3r969CyixM7OTPeFUxG2IxLO8/9/SvqXlc+/x3h295YzLlj2nIRJQj//nRvc5TEIal8RsXBLVuCQwIgoq/u80DomP6HEOk/iOS+IJLonZOCT+ReOQ+Lkbh0QKLonbOCR+7MYhsRqHBJrVcIl/1TgklqKLQyQ+tGKIgyQOqXpjig94diZRAgAXmDX6jyWafAAAAABJRU5ErkJggg====== MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Thu, 18 May 2017 21:17:52 -0000 I have just disabled SMB1 on some Windows machines on the network. I find that (as far as I can see) I can no longer mount shares on the machines from FreeBSD, using smbfs. Is it the case that smbfs supports ONLY SMB1? Or is there a workround? Someone will probably mention Samba. Yes, I use Samba as a server on some machines, but the ones in question are clients and do not have Samba installed (and I don't quite see how to use it as a transparent client anyway). Help, please! From owner-freebsd-fs@freebsd.org Thu May 18 21:53:29 2017 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 D19ACD6FEE1 for ; Thu, 18 May 2017 21:53:29 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 8E028C for ; Thu, 18 May 2017 21:53:29 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk0-x22c.google.com with SMTP id y201so47835566qka.0 for ; Thu, 18 May 2017 14:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xgVicuEo9LZrd02+g68tdQ5+zgr0w/P0wqczQ1C+yt0=; b=tGXwKwh3VMGp3tO2LRd7xWTzGK5F0UUXt+o5TI3RU8x7GJhSpsPUUczBlCl+b0jlBK d5924kXwOP/j+IMTdJfhr20PvjnUrTetBvbIAvK7L27Z+GHqt3t/ll2zAnJgwRu/8RHh p9Cbrs8RhBdkVHtaDlk1vs4c9vB0sbCIlxzSRtsW6vrQdDN/BNbLER8O4xMkP/ITHVmv AMBtFY2jY30p4WxNRK56DHc3R6QFfz3L4lUqGn3IJ82/7xkUJZJwdtDDY0+AWiMC14Ph SU9OzYN8V7TYsP6QgmLQ3L6b3/XZXiyvBlz0LzAPxl/dCmUB2inCjOelKnec+dk893iT 6M4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xgVicuEo9LZrd02+g68tdQ5+zgr0w/P0wqczQ1C+yt0=; b=Ycq4rLg2A0TuSoRmnPWdK0aiq8jVjT9Uq+VR3gJj06cG3w2GZqne5YzV1oeZ+BCDt/ zxKZgutJ5e6yI9snkqQz8KSM0B/GK4rKDfSQRiIoZEoinOESCUeuQrt/wSgtLaJ3dqY0 eIFkUJs8zWvhWTAZtkS45jsAUhgY4AAKwskNW01VhNs3+T92gPyL9yXeANsGSacB+4n3 NZ1vFl9bNTChIq7+1ImmKDHBKG3ho32ejJV2YFMElSxcb1NrWawLETycgXYMtfQ10Tx9 LRYer+iuuRZfPY2C4REqYxQ/mlfmINx++z8MsZjdhf7g3PVnnBZPewNIZ/FYj+VkAYwr /cnQ== X-Gm-Message-State: AODbwcD+5IfyIYSSlrqAG5uTZ8JWsf790FC1wLFKtiBW1GDravHBtwvO ZlCtWd0Nem87Ic9lKjct2w== X-Received: by 10.55.167.6 with SMTP id q6mr5646504qke.134.1495144408199; Thu, 18 May 2017 14:53:28 -0700 (PDT) Received: from ?IPv6:2600:1017:b82c:11a0:9c2f:5f39:87d1:8ec9? ([2600:1017:b82c:11a0:9c2f:5f39:87d1:8ec9]) by smtp.gmail.com with ESMTPSA id n35sm4617712qtc.55.2017.05.18.14.53.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 14:53:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Different size after zfs send receive From: Mark Saad X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Thu, 18 May 2017 17:53:23 -0400 Cc: "freebsd-fs@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <58A6B47B-2992-4BB8-A80E-44F74EAE93B2@longcount.org> References: To: kc atgb 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: Thu, 18 May 2017 21:53:29 -0000 Hi kc=20 This has to do with how data blocks are replicated when stored on a raidzN= . Moving them to a mirror removes replicated blocks . This is way over simp= lified but imagine you store a file of 10gb on a raidz1 . The system splits t= he file into smaller chunks; of say 1mb , and stores one extra chunk for eac= h chunk that us striped around the raidz1 . Storing on a mirror is just writ= e the chunk once on each disk . However with a mirror since you only see 1/2= the number of disks you never see the extra chunks in the used field .=20 Hope this helps .=20 --- Mark Saad | nonesuch@longcount.org > On May 18, 2017, at 3:36 PM, kc atgb w= rote: >=20 > Hi, >=20 > Some days ago I had a need to backup my current pool and restore it after p= ool destroy and create.=20 >=20 > The pool in my home server is a raidz1 with 4 disks. To backup this pool I= grabbed two 4TB disks (single disk pools) to have a double backup (I have j= ust one > sata port left I can use to plug a disk).=20 >=20 > The whole process of backup and restore went well as I can say. But lookin= g at the size reported by zfs list make me a little bit curious.=20 >=20 > storage/datas/ISO 3= 5420869824 381747995136 35420726976 /datas/ISO > storage/datas/ISO@backup_send = 142848 - 35420726976 - > storage/datas/ISO@backup_sync = 0 - 35420726976 - >=20 > b1/datas/ISO 354393= 08800 2176300351488 35439210496 /datas/ISO > b1/datas/ISO@backup_send 9= 8304 - 35439210496 - > b1/datas/ISO@backup_sync = 0 - 35439210496 - >=20 > b2/datas/ISO 354393= 08800 2176298991616 35439210496 /datas/ISO > b2/datas/ISO@backup_send 9= 8304 - 35439210496 - > b2/datas/ISO@backup_sync = 0 - 35439210496 - >=20 > storage/datas/ISO 3= 5421024576 381303470016 35420715072 /datas/ISO > storage/datas/ISO@backup_send = 142848 - 35420715072 - > storage/datas/ISO@backup_sync = 11904 - 35420715072 - >=20 >=20 > storage/usrobj 5= 819085888 381747995136 5816276544 legacy > storage/usrobj@create = 166656 - 214272 - > storage/usrobj@backup_send = 2642688 - 5816228928 - > storage/usrobj@backup_sync = 0 - 5816276544 - >=20 > b1/usrobj 56750= 81728 2176300351488 5673222144 legacy > b1/usrobj@create 1= 14688 - 147456 - > b1/usrobj@backup_send 17= 44896 - 5673222144 - > b1/usrobj@backup_sync = 0 - 5673222144 - >=20 > b2/usrobj 56751= 88224 2176298991616 5673328640 legacy > b2/usrobj@create 1= 14688 - 147456 - > b2/usrobj@backup_send 17= 44896 - 5673328640 - > b2/usrobj@backup_sync = 0 - 5673328640 - >=20 > storage/usrobj 5= 820359616 381303470016 5815098048 legacy > storage/usrobj@create = 166656 - 214272 - > storage/usrobj@backup_send = 2535552 - 5815098048 - > storage/usrobj@backup_sync = 11904 - 5815098048 - >=20 > As you can see the numbers are different for each pool (the initial raidz1= , backup1 disk, backup2 disk and new raidz1). I mean in the USED column. I h= ave > nearly all my datasets in the same situation (those with fixed data that h= ave not changed between the beginning of the process and now). backup1 and b= ackup2 > are identical disks with exactly the same configurations and have differen= t numbers. I used the same commands for all my transfers except the name of t= he > destination pool.=20 >=20 > So, I wonder what can cause these differences ? Is it something I have to w= orry about ? Can I consider this as a normal behavior ?=20 >=20 > Thanks for your enlightments, > K. > _______________________________________________ > 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 Thu May 18 23:22:42 2017 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 2956AD73455 for ; Thu, 18 May 2017 23:22:42 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm25-vm2.bullet.mail.ne1.yahoo.com (nm25-vm2.bullet.mail.ne1.yahoo.com [98.138.91.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA3911A62 for ; Thu, 18 May 2017 23:22:41 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1495149755; bh=wbmw/lpmmhoGpdKRODGA34/Wu0ZpPYZQu4hrQ+Ja6qI=; h=From:Subject:To:Date:From:Subject; b=dMXJVIVMow2zN27gUPM4/yC5y2haxUurb/FVhkY5r+Ippn5UiI3+6gjp5LHDEs71eHw/fElg50Ra3KyDGLaHyAzC+QZ04fLtn9ISqfMy3WClTaHCD24tdmJHnkPAuC1QcsJbwDTBHs+5esCiZZYV5Vv/tm9+5wB9JyvUVtVzM9y5BXC8R4L+wrogaMZpEPlawkeyQU/vFgTZgCyppwsZTUbw8m2HM1bIJD8yQsphK1t3c/cFuudKJQuYmxRxeNOWwThm5cXjh7W4Q/45ezfkbBBK87JRw+ihqRCzCugFNca7A5upJfBviN3hJOVqZoo6LfjliSZELF92x0aVPuiKrQ== Received: from [98.138.100.115] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 18 May 2017 23:22:35 -0000 Received: from [98.138.84.39] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 18 May 2017 23:22:35 -0000 Received: from [127.0.0.1] by smtp107.mail.ne1.yahoo.com with NNFMP; 18 May 2017 23:22:35 -0000 X-Yahoo-Newman-Id: 6201.71631.bm@smtp107.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IfZs3tkVM1n0qEBeKCxtieqrHQsE9TreGYK2bpGYkiVhQqt CWpAmNXAq.EblrYM4kGWYBOtO31l8WsN7SsdTHaK9Q6lCOXK3z8yDNcbVn.B 7dxyfQm5HrpM9rG7BAGtbPKGwgfFBVmp_gDGtCvyJOzRfmZWka0CJM6puYHe Dm8P_rjC28OnfiHMBYMQJ4.l0LG.wU18ovpPi1JNLI0Zcu13cQXo4ONlDDWQ WRGsIMcXhTtD1sttrA07rN03tsqzgpvR3pOBTgxvamQPi2D4zsvqOiLPLBvQ 5_33lpdSN53v0UHSa9cpxgrnjaZsi0FscAsANsYvDRUiEW0ctNX9hBCN.y2J kLOAGHd6CMHxbLQgvNbLUHPnnqh4Dfr42g3pHC.6aUUThbVrGHicKJxCwNU7 qAq5_0UDEzrZyJZwbP.WnSPAdyfcCiVn3K40PL68_X9p.sB1rFWJwpEjQ7bD WG.Onuf9Qr.asqrbCF1N1z82mc.CoFPlTh20PnQPJdTVw_W4BtwO8Z9bJdAj 0O_leLKyGd6LQ_8Zr0nMnwKzqS8R3XPp9PpYAu_Ze6eV3 X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf From: Pedro Giffuni Subject: Re: smbfs and SMB1 Organization: FreeBSD To: freebsd-fs@freeBSD.org, Bob Eager Message-ID: <665caabc-cf2d-7f6a-2187-465907ea6ae7@FreeBSD.org> Date: Thu, 18 May 2017 18:22:35 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Content-Language: en-US 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: Thu, 18 May 2017 23:22:42 -0000 Hi Bob; > I have just disabled SMB1 on some Windows machines on the network. > > I find that (as far as I can see) I can no longer mount shares on the > machines from FreeBSD, using smbfs. > > Is it the case that smbfs supports ONLY SMB1? Or is there a workround? > > Someone will probably mention Samba. Yes, I use Samba as a server on > some machines, but the ones in question are clients and do not have > Samba installed (and I don't quite see how to use it as a transparent > client anyway). > > Help, please! Sadly smbfs in contrib/ only supports the old version of the protocol (SMB1). I understand Microsoft recommends disabling SMB1 due to the ransomware attacks. I haven't used samba but indeed that should be the solution. Pedro. From owner-freebsd-fs@freebsd.org Thu May 18 23:40:17 2017 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 B0E0CD73934 for ; Thu, 18 May 2017 23:40:17 +0000 (UTC) (envelope-from rde@tavi.co.uk) Received: from kipling.tavi.co.uk (kipling.tavi.co.uk [81.187.145.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6982B10A4 for ; Thu, 18 May 2017 23:40:16 +0000 (UTC) (envelope-from rde@tavi.co.uk) Received: from kipling.tavi.co.uk (localhost [127.0.0.1]) by kipling.tavi.co.uk (Postfix) with ESMTP id 4802E7592C for ; Fri, 19 May 2017 00:40:14 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tavi.co.uk; h=date:from:to :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=qcfiqgq EO8g87NtwhGsFB4KwQr8=; b=EcXyV32pn8B1hPqSoMK+6QCfdfg0eDuq/CXxGzG 0rOo7vLyyFLMc65R1wlGlmh5GKUOcSUyRb5WVjZ8fqQD4DxgKWE18fPpTRrO03ju os2ZMrSKrdwUmUusw1DUyoXdr14fp1XIC9dGmWblANzi5qQ6sY9HlWJ+sWIHoD8L mnE4= Received: from raksha.tavi.co.uk (raksha.tavi.co.uk [81.187.145.139]) (Authenticated sender: rde@tavi.co.uk) by kipling.tavi.co.uk (Postfix) with ESMTPA id BE1A775927 for ; Fri, 19 May 2017 00:40:13 +0100 (BST) Date: Fri, 19 May 2017 00:40:13 +0100 From: Bob Eager To: freebsd-fs@freebsd.org Subject: Re: smbfs and SMB1 Message-ID: <20170519004013.0d332b9e@raksha.tavi.co.uk> In-Reply-To: <665caabc-cf2d-7f6a-2187-465907ea6ae7@FreeBSD.org> References: <665caabc-cf2d-7f6a-2187-465907ea6ae7@FreeBSD.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; i386-portbld-freebsd10.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEUwXjFLc0vD0cS7y7zw9PDZ4tkWSRaVrZZ+m39qi2tXfVj////7+/utwK4IPggAOAAJUUA7AAABKklEQVQ4jWPYjQMwDFYJp0NKEKCNJmEf9h8CsimXiL2e33s3/e7F7K2Cs3f3dCMkQkMKj4YuCY3K3iR+e7fMaiSjvkX0/5cFGrWpe2uLzOpaExUVqMS/8PX/Re5ey960OLBTZpFA8+IlSBKPQ92zNyUUBsosN58uIY0k8f+/ONCoYytkVuhWzVwNkYiYbqk5M3NmOVBi41YZ8RsGF7shEtFb5KJ3r969CyixM7OTPeFUxG2IxLO8/9/SvqXlc+/x3h295YzLlj2nIRJQj//nRvc5TEIal8RsXBLVuCQwIgoq/u80DomP6HEOk/iOS+IJLonZOCT+ReOQ+Lkbh0QKLonbOCR+7MYhsRqHBJrVcIl/1TgklqKLQyQ+tGKIgyQOqXpjig94diZRAgAXmDX6jyWafAAAAABJRU5ErkJggg====== MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Thu, 18 May 2017 23:40:17 -0000 On Thu, 18 May 2017 18:22:35 -0500 Pedro Giffuni wrote: > Hi Bob; > > > I have just disabled SMB1 on some Windows machines on the network. > > > > I find that (as far as I can see) I can no longer mount shares on > > the machines from FreeBSD, using smbfs. > > > > Is it the case that smbfs supports ONLY SMB1? Or is there a > > workround? > > > > Someone will probably mention Samba. Yes, I use Samba as a server on > > some machines, but the ones in question are clients and do not have > > Samba installed (and I don't quite see how to use it as a > > transparent client anyway). > > > > Help, please! > > Sadly smbfs in contrib/ only supports the old version of the protocol > (SMB1). > > I understand Microsoft recommends disabling SMB1 due to the > ransomware attacks. > > I haven't used samba but indeed that should be the solution. > > Pedro. Yes, I understand that, and that was the impetus for asking. I need the functionality of smbfs. If I disable SMB1 on the Windows machines, I can't access them from FreeBSD any more. From owner-freebsd-fs@freebsd.org Fri May 19 01:40:30 2017 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 BFA45D741FC for ; Fri, 19 May 2017 01:40:30 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 85C7E15A5; Fri, 19 May 2017 01:40:26 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 73A8D28412; Fri, 19 May 2017 03:40:18 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id AAC8228411; Fri, 19 May 2017 03:40:17 +0200 (CEST) Subject: Re: smbfs and SMB1 To: Pedro Giffuni , freebsd-fs@freeBSD.org, Bob Eager References: <665caabc-cf2d-7f6a-2187-465907ea6ae7@FreeBSD.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <591E4D01.9080600@quip.cz> Date: Fri, 19 May 2017 03:40:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <665caabc-cf2d-7f6a-2187-465907ea6ae7@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 01:40:30 -0000 Pedro Giffuni wrote on 2017/05/19 01:22: > Hi Bob; > >> I have just disabled SMB1 on some Windows machines on the network. >> >> I find that (as far as I can see) I can no longer mount shares on the >> machines from FreeBSD, using smbfs. >> >> Is it the case that smbfs supports ONLY SMB1? Or is there a workround? >> >> Someone will probably mention Samba. Yes, I use Samba as a server on >> some machines, but the ones in question are clients and do not have >> Samba installed (and I don't quite see how to use it as a transparent >> client anyway). >> >> Help, please! > > Sadly smbfs in contrib/ only supports the old version of the protocol > (SMB1). > > I understand Microsoft recommends disabling SMB1 due to the ransomware > attacks. > > I haven't used samba but indeed that should be the solution. I am not suru but I think Samba does not provide CIFS/SMBFS mount binaries. There is just ftp-like client. FreeBSD is used in networks for filesharing, storage etc. and I feel SMB mount is very vital feature. Miroslav Lachman From owner-freebsd-fs@freebsd.org Fri May 19 06:35:51 2017 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 340FDD74A5A for ; Fri, 19 May 2017 06:35:51 +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 7103C91C for ; Fri, 19 May 2017 06:35:50 +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 JAA14049; Fri, 19 May 2017 09:35:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dBbVr-0008l6-P1; Fri, 19 May 2017 09:35:47 +0300 Subject: Re: smbfs and SMB1 To: Bob Eager , freebsd-fs@FreeBSD.org References: <665caabc-cf2d-7f6a-2187-465907ea6ae7@FreeBSD.org> <20170519004013.0d332b9e@raksha.tavi.co.uk> From: Andriy Gapon Message-ID: <1544e153-c2a7-5bcd-ec25-0a19a1d5d792@FreeBSD.org> Date: Fri, 19 May 2017 09:34:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170519004013.0d332b9e@raksha.tavi.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: Fri, 19 May 2017 06:35:51 -0000 On 19/05/2017 02:40, Bob Eager wrote: > I need the functionality of smbfs. If I disable SMB1 on the Windows > machines, I can't access them from FreeBSD any more. Perhaps smbnetfs (or something like that) from ports would work for you... -- Andriy Gapon From owner-freebsd-fs@freebsd.org Fri May 19 06:45:39 2017 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 3ED6AD74D7A for ; Fri, 19 May 2017 06:45:39 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id 7F40F1015; Fri, 19 May 2017 06:45:38 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Fri, 19 May 2017 08:45:31 +0200 Authentication-Results: connect.ultra-secure.de; auth=pass (login); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 127.0.0.10 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=127.0.0.10; helo=connect.ultra-secure.de; envelope-from= Received: from connect.ultra-secure.de (webmail [127.0.0.10]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id 61818624-283D-4392-9634-17489D1421E4.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO); Fri, 19 May 2017 08:45:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 May 2017 08:45:27 +0200 From: rainer@ultra-secure.de To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Pedro Giffuni , freebsd-fs@freebsd.org, Bob Eager Subject: Re: smbfs and SMB1 In-Reply-To: <591E4D01.9080600@quip.cz> References: <665caabc-cf2d-7f6a-2187-465907ea6ae7@FreeBSD.org> <591E4D01.9080600@quip.cz> Message-ID: <0705de1f8af4602661ed1d7bc801e9a4@ultra-secure.de> X-Sender: rainer@ultra-secure.de User-Agent: Roundcube Webmail/1.2.0 X-Haraka-GeoIP: --, , NaNkm X-Haraka-GeoIP-Received: X-Haraka-p0f: os="undefined undefined" link_type="undefined" distance=undefined total_conn=undefined shared_ip=Y X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 153, bad: 0, connections: 153, history: 153, pass:all_good, relaying 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: Fri, 19 May 2017 06:45:39 -0000 Am 2017-05-19 03:40, schrieb Miroslav Lachman: > I am not suru but I think Samba does not provide CIFS/SMBFS mount > binaries. There is just ftp-like client. > FreeBSD is used in networks for filesharing, storage etc. and I feel > SMB mount is very vital feature. Microsoft hat advocated for disabling SMBv1 for a long time. I'm not a Windows expert at all - but I've seen what can be achieved (from a security point of view) in a network with only Server 2016 and Windows 10. I'm not sure even Linux would be much use in such an environment. But the SMBv1-less world is here - and vendors of Linux-based appliances are scrambling for solutions. Like here: https://community.sophos.com/kb/en-us/126757 (We opened a ticket with them, too) Apparently, having SMBv1 enabled violates PCI (DSS) compliance. From owner-freebsd-fs@freebsd.org Fri May 19 07:34:40 2017 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 8C50BD73ECC for ; Fri, 19 May 2017 07:34:40 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-oln040092064032.outbound.protection.outlook.com [40.92.64.32]) (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 F198D907 for ; Fri, 19 May 2017 07:34:39 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) Received: from DB5EUR01FT023.eop-EUR01.prod.protection.outlook.com (10.152.4.59) by DB5EUR01HT079.eop-EUR01.prod.protection.outlook.com (10.152.4.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1075.5; Fri, 19 May 2017 07:34:37 +0000 Received: from AMSPR05MB148.eurprd05.prod.outlook.com (10.152.4.51) by DB5EUR01FT023.mail.protection.outlook.com (10.152.4.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.5 via Frontend Transport; Fri, 19 May 2017 07:34:37 +0000 Received: from AMSPR05MB148.eurprd05.prod.outlook.com ([fe80::c083:5c72:5c2c:fb06]) by AMSPR05MB148.eurprd05.prod.outlook.com ([fe80::c083:5c72:5c2c:fb06%27]) with mapi id 15.01.1084.022; Fri, 19 May 2017 07:34:37 +0000 From: kc atgb To: "freebsd-fs@freebsd.org" Subject: Re: Different size after zfs send receive Thread-Topic: Different size after zfs send receive Thread-Index: AQHS0A4bB1aDgtJ4x0WmR87yTfeQcqH6ojqAgACiToA= Date: Fri, 19 May 2017 07:34:36 +0000 Message-ID: References: <58A6B47B-2992-4BB8-A80E-44F74EAE93B2@longcount.org> In-Reply-To: <58A6B47B-2992-4BB8-A80E-44F74EAE93B2@longcount.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=hotmail.fr; x-incomingtopheadermarker: OriginalChecksum:74D0A6E1945EC113801581F03104AD52E119E921192FBC85A483102376175AE2; UpperCasedChecksum:C7FB2D1C75FF6EAF7BE8E0F939E3F47C9CB928BDD8D271A4A485FD02C7C0324D; SizeAsReceived:8151; Count:42 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5EUR01HT079; 5:+XwgGiZBOfvl1zu2o/5VwsVlMwzq+/XbqzSCymO9aAiOACjHa/WXmOfdEk4mynAS8z/9zdmO79rRDMO4lpOraKZh7vtY3fDuxl0f6Q53e3gOWgjqjhCBJvgm8QrLGaVD9YJjARVCnDn856kuh4X17DQe5ON81qEYnqIJke/Yge0=; 24:VKjYTlMViyHhRQ0gcKhJogZSwz0sN1g7P0sy91ADF27kYFOnvDrUjajeGf8LdUcHP0/LwELno5njy2FvSHLSW74T/21KyowQ4RVc7cQLVA4=; 7:PUThJ27z7GfyoJ7vdul8dRPqqBQxcCMx8PraDPPCRzt/NXXjTHLy6O+frt5jC4Dde4kXILBPXnSADVcRh/spXKGf6SubFGHwElxK4h6sQGv7ITlG/DzVgAhG07l8/3o2sGf7eKtjQoZF97uid5t76/R9sDVPFS0uPKeFp/gD5hQYbSL/BPeJftw8KEOglrNSf/mZxnvhOz5o1HVYPe1WvW0sEb4NTJ/OljSDtVtD60Ukn/0J9lG90B3XcO4ozl9ny2p6MnASw6xthX5urko7GDOHMuAjGVfZOeWPbimJy9DTsxOYg1F9HMnufbvgsmZN x-incomingheadercount: 42 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:DB5EUR01HT079; H:AMSPR05MB148.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: cdd16c15-ee89-4958-43dd-08d49e897fcf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:DB5EUR01HT079; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:DB5EUR01HT079; BCL:0; PCL:0; RULEID:; SRVR:DB5EUR01HT079; x-forefront-prvs: 031257FE13 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2017 07:34:36.9980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT079 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: Fri, 19 May 2017 07:34:40 -0000 Le Thu, 18 May 2017 21:53:23 +0000, Mark Saad a =E9crit : Hi, I see what you are talking about I thing. You refer to "raid" splitting, ri= ght ? In this case this is something in the "internals" of the raid system.= Isn't zfs list suppose to report raw data sizes (without metadata, checksums, ...= ) ?=20 I don't really think it is related to what I'm refering.=20 Look, for the same pool configuration (one 4 disks raidz1 vdev) with the sa= me disks and the same data, it reports for storage/usrobj 5819085888 before backup and 5820359616 after restore to the recreated pool.=20 Even for pools with one single disk vdev (again same disks, same configurat= ion, same data as above...) for the same dataset 5675081728 in backup1 disk and 5675188224 in backup2 The difference isn't so big but the numbers differ and I would imagine numb= ers to be the same.=20 K. > Hi kc=20 > This has to do with how data blocks are replicated when stored on a rai= dzN . Moving them to a mirror removes replicated blocks . This is way over > simplified but imagine you store a file of 10gb on a raidz1 . The system = splits the file into smaller chunks; of say 1mb , and stores one extra chun= k for > each chunk that us striped around the raidz1 . Storing on a mirror is jus= t write the chunk once on each disk . However with a mirror since you only = see 1/2 > the number of disks you never see the extra chunks in the used field .=20 >=20 > Hope this helps .=20 >=20 > --- > Mark Saad | nonesuch@longcount.org >=20 > > On May 18, 2017, at 3:36 PM, kc atgb wrote: > >=20 > > Hi, > >=20 > > Some days ago I had a need to backup my current pool and restore it aft= er pool destroy and create.=20 > >=20 > > The pool in my home server is a raidz1 with 4 disks. To backup this poo= l I grabbed two 4TB disks (single disk pools) to have a double backup (I ha= ve just > > one sata port left I can use to plug a disk).=20 > >=20 > > The whole process of backup and restore went well as I can say. But loo= king at the size reported by zfs list make me a little bit curious.=20 > >=20 > > storage/datas/ISO = 35420869824 381747995136 35420726976 /datas/ISO > > storage/datas/ISO@backup_send = 142848 - 35420726976 - > > storage/datas/ISO@backup_sync = 0 - 35420726976 - > >=20 > > b1/datas/ISO 354= 39308800 2176300351488 35439210496 /datas/ISO > > b1/datas/ISO@backup_send = 98304 - 35439210496 - > > b1/datas/ISO@backup_sync = 0 - 35439210496 - > >=20 > > b2/datas/ISO 354= 39308800 2176298991616 35439210496 /datas/ISO > > b2/datas/ISO@backup_send = 98304 - 35439210496 - > > b2/datas/ISO@backup_sync = 0 - 35439210496 - > >=20 > > storage/datas/ISO = 35421024576 381303470016 35420715072 /datas/ISO > > storage/datas/ISO@backup_send = 142848 - 35420715072 - > > storage/datas/ISO@backup_sync = 11904 - 35420715072 - > >=20 > >=20 > > storage/usrobj = 5819085888 381747995136 5816276544 legacy > > storage/usrobj@create = 166656 - 214272 - > > storage/usrobj@backup_send = 2642688 - 5816228928 - > > storage/usrobj@backup_sync = 0 - 5816276544 - > >=20 > > b1/usrobj 56= 75081728 2176300351488 5673222144 legacy > > b1/usrobj@create = 114688 - 147456 - > > b1/usrobj@backup_send = 1744896 - 5673222144 - > > b1/usrobj@backup_sync = 0 - 5673222144 - > >=20 > > b2/usrobj 56= 75188224 2176298991616 5673328640 legacy > > b2/usrobj@create = 114688 - 147456 - > > b2/usrobj@backup_send = 1744896 - 5673328640 - > > b2/usrobj@backup_sync = 0 - 5673328640 - > >=20 > > storage/usrobj = 5820359616 381303470016 5815098048 legacy > > storage/usrobj@create = 166656 - 214272 - > > storage/usrobj@backup_send = 2535552 - 5815098048 - > > storage/usrobj@backup_sync = 11904 - 5815098048 - > >=20 > > As you can see the numbers are different for each pool (the initial rai= dz1, backup1 disk, backup2 disk and new raidz1). I mean in the USED column.= I have > > nearly all my datasets in the same situation (those with fixed data tha= t have not changed between the beginning of the process and now). backup1 a= nd backup2 > > are identical disks with exactly the same configurations and have diffe= rent numbers. I used the same commands for all my transfers except the name= of the > > destination pool.=20 > >=20 > > So, I wonder what can cause these differences ? Is it something I have = to worry about ? Can I consider this as a normal behavior ?=20 > >=20 > > Thanks for your enlightments, > > K. > > _______________________________________________ > > 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" >=20 From owner-freebsd-fs@freebsd.org Sat May 20 03:57:16 2017 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 83EFCD737D2; Sat, 20 May 2017 03:57:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 50A3F1EDF; Sat, 20 May 2017 03:57:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x232.google.com with SMTP id q125so45957016pgq.2; Fri, 19 May 2017 20:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a8HugRkNVhu8TZDJKzEycTrdIK2ZIJE0bSPCn1yzX70=; b=tGx/JQhRrCcK8CAO53ZtXIEtxxY7WA/Q8WdnercY7u/JmD+FBn3bAPstu4KEHiwLqb iuR8/SEsxDVVuLx3FLYBBniYjAYmJSbUUJZOpejR1g2FlNfG1xDw5Q6MkSeXtO04pXXo 345vMmg0QKv+Bra19QQ3uq8TL3gcXHQ5/r9yIECI4+RcHmKL6Pj2hqSEkcdwwKYfyCt7 mRTFUPCAMCGZ6QW1VcVw3DMeIN6IVzaqmfr2UnhMpbD0JBVHEHu5/clZ9thv4T205YAO gRerkWYwSlZVzVa1YefHR84GkYmvXZVtbAD+PyNKDirtMgBxXz2ibjhLvhjjDLlxvzXg jtaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a8HugRkNVhu8TZDJKzEycTrdIK2ZIJE0bSPCn1yzX70=; b=PcbX2TYDSv4ow+vvKTG7ME+Lnf4uGqAHy+ly1ukyq8oUqGYPrgsqGozuKcyozBx8MM gOVta4Z5HFaBNOQUbWZfXpYYpmU3OaXDALUPeOCTo77YkpQXnJ1Svj2ZxdXN4oGG596q Ty9zwhDKHYA7f+E4133UdiUNlPiovFZPiCRQvhTdzgQk+kL+XnCe4nhOk/cBusndEccT aL1Zr+mdBxjzuaRL3DwIoUF1XLxAefIE1A6ELoej90XbqHguFNXIkr0rVk5oby1ZzOnC nQzbIoYkFy5Yth5hDqWJoFgx04W3tmgW5sLjo4vV28jwMOs/fJghdFPkwuGlUyxzGgMM 5Elg== X-Gm-Message-State: AODbwcBlgFfb/KZwoLmtR0bkbSH0exom+hD+A9UQybm5MQMDGnFe1eCW MkrGeE0CwILOhNEwYAU6epduIXuPyRQFXHQ= X-Received: by 10.99.181.11 with SMTP id y11mr13420912pge.54.1495252635882; Fri, 19 May 2017 20:57:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Fri, 19 May 2017 20:57:15 -0700 (PDT) In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> From: "Eric A. Borisch" Date: Fri, 19 May 2017 22:57:15 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Paul Kraus Cc: FreeBSD Stable , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , "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: Sat, 20 May 2017 03:57:16 -0000 On Thu, May 18, 2017 at 9:18 AM, Eric A. Borisch wrote: > On Wed, May 17, 2017 at 9:38 PM, Eric A. Borisch > wrote: > >> 4) zpool import -f alpha beta succeeds without any complaints. >> >> IV. Alpha no longer exists, Beta exists (with the same GUID as Alpha) AND >> is active. This is an 'atomic' operation from user's point of view, and at >> no point does zpool list show more than one pool >> >> 5) zpool list shows only beta; scrubs fine, life is good.. >> >> V. Beta exists on disk and is active and healthy. Alpha is no more. >> (Except as a ghost in a cache file) >> > > A quick test revealed one other tidbit this morning; if I 'zpool export > beta' at this point in the process (still in live CD OS), everything is OK > on reboot into the installed OS. > > For whoever wants to investigate handling/hand-off between > bootloader/kernel/fully booted, the problem appears when a: > > 1) root pool is renamed, but not 'zpool export'-ed after rename via an > 'external' OS (live CD) > ** and ** > 2) A stale zpool.cache file exists on the pool referring to the original > name. > bug report created: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219411 From owner-freebsd-fs@freebsd.org Sat May 20 14:32:31 2017 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 611D2D753BD for ; Sat, 20 May 2017 14:32:31 +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 50A9F1056 for ; Sat, 20 May 2017 14:32:31 +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 v4KEWVnC083415 for ; Sat, 20 May 2017 14:32:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219411] [zfs] Stale zpool.cache corrupts renamed (but not exported) root zpool on boot Date: Sat, 20 May 2017 14:32:31 +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, 20 May 2017 14:32:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219411 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 May 20 21:48:00 2017 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 C9A0FD76DFF for ; Sat, 20 May 2017 21:48:00 +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 B92A21C2D for ; Sat, 20 May 2017 21:48:00 +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 v4KLlxhU013990 for ; Sat, 20 May 2017 21:48:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 214265] zfs is broken in stable/11 Date: Sat, 20 May 2017 21:47:59 +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: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Works As Intended X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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, 20 May 2017 21:48:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214265 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Works As Intended Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.=