From owner-freebsd-fs@freebsd.org Sun Aug 13 00:33:12 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 A29F7DD5C8F for ; Sun, 13 Aug 2017 00:33:12 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 425C77C7EE for ; Sun, 13 Aug 2017 00:33:11 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id v7D03Th2021822 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 13 Aug 2017 10:03:35 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id v7D03NPq013026 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Aug 2017 10:03:23 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id v7D03NIe013025; Sun, 13 Aug 2017 10:03:23 +1000 (AEST) (envelope-from peter) Date: Sun, 13 Aug 2017 10:03:23 +1000 From: Peter Jeremy To: Chris Ross Cc: freebsd-fs@freebsd.org Subject: Re: Oh no, what have I done... Message-ID: <20170813000323.GC95431@server.rulingia.com> References: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.8.3 (2017-05-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: Sun, 13 Aug 2017 00:33:12 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Aug-12 19:36:31 -0400, Chris Ross wrote: > But, I fear I may=E2=80=99ve shot myself. Is there any way to recover m= y raid1z vdev from this situation, and get a working zfs pool back? There's no way to detach the vdev /dev/da2p1 - you need to backup and re-create the pool. You need to re-attach /dev/da2p1 so the pool can be imported, then do a backup, destroy the pool and re-create it. --=20 Peter Jeremy --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJZj5dLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0bu0P/1IPP73kwN7t+8dbo492kQg3 WVmT2eyJCbhOS5INwf+S8lOjkKgW78XySh6fpOAoL480XRCuUGaOqdzjhR39lNBL ycJS1DzGhD97EmptuxYCKj2WGYjp0nnbg0JZmbBywV/qfx0QhjjQ1Vj3dsV4b0rW YgGEEwjY/HqLxXBCuTo+b49U5jZ/2Gwpxg7QQf6giYpqqAyaQHGA5/sWAkwbeXHr KmQGtsBzlAikfdqdTZ/AGt1pOo06e12BIvj4mJvtAwafrKYtEbMvnq+2FB20//G3 YGgVXb3lM/fUUSIgvKZyCf8ShGAEfJi5JhuKgpdOkD8HkICt2G3RUXGvGmTLQuuv 4BLd9cI94OWTOIPRoJXrGUEHv2peW9ThtDjhtOUYXKNh5d/BMlOSANVBpqTwXcuE 5QqGeaZXXzgecb4NbjmO1XLrFVCzLuFVu+D5jWmL8x2ynzX69IGeEqoHwbg4wzmK MpFT7RdpjaZG0krREk3IDFnpbooRMfbvtzjUCQGKXg5NLA2KuR2A4yZpmSqaQXp8 aJaqhP1fDuB7cDLl5jyBSZ60fq9SRmmBQM4gSWuHFJYIeU+uOT3fxVAlE2NlE0tx u4lYCC8yJZJWcUO5HMX64zUN4aCtecPkpIgfGTJJzfw57VdkB1WU7oLVjymreas/ uYQT2HaYasZmv3l0LFim =6t1r -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-fs@freebsd.org Sun Aug 13 01:22:35 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 27286DD8A09 for ; Sun, 13 Aug 2017 01:22:35 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D9CA07DF5A for ; Sun, 13 Aug 2017 01:22:34 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]) (authenticated bits=0) by hydra.pix.net (8.16.0.19/8.15.2) with ESMTPSA id v7D1MOla000766 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 12 Aug 2017 21:22:31 -0400 (EDT) (envelope-from cross+freebsd@distal.com) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.15.2/8.15.2) with ESMTPSA id v7D1ML6s092168 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Aug 2017 21:22:23 -0400 (EDT) (envelope-from cross+freebsd@distal.com) Content-Type: multipart/signed; boundary="Apple-Mail=_15F13A35-E30B-4564-820B-27A5668D2D18"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Oh no, what have I done... From: Chris Ross In-Reply-To: <20170813000323.GC95431@server.rulingia.com> Date: Sat, 12 Aug 2017 21:22:13 -0400 Cc: freebsd-fs@freebsd.org Message-Id: <5B508AED-4DAC-42E4-8C56-4619C0D1A1C6@distal.com> References: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> <20170813000323.GC95431@server.rulingia.com> To: Peter Jeremy X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]); Sat, 12 Aug 2017 21:22:23 -0400 (EDT) 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, 13 Aug 2017 01:22:35 -0000 --Apple-Mail=_15F13A35-E30B-4564-820B-27A5668D2D18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 12, 2017, at 20:03 , Peter Jeremy wrote: >=20 > On 2017-Aug-12 19:36:31 -0400, Chris Ross = wrote: >> But, I fear I may=E2=80=99ve shot myself. Is there any way to = recover my raid1z vdev from this situation, and get a working zfs pool = back? >=20 > There's no way to detach the vdev /dev/da2p1 - you need to backup and > re-create the pool. You need to re-attach /dev/da2p1 so the pool can > be imported, then do a backup, destroy the pool and re-create it. Can I attach a different similar drive as da2p1? Or, does it have to = have the same bits that were put on it when it was in the pool = previously? If the latter, I don=E2=80=99t have those bits any more. I=E2=80=99ll try putting a disk with the same layout in, and see how = that goes. That was a thought I=E2=80=99d had. - Chris --Apple-Mail=_15F13A35-E30B-4564-820B-27A5668D2D18 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZj6nNAAoJEPFBDnXvoNg0zIwQAJ1LDSxcw2aQ3MsRKuP3Pr4n ZAA8JoMLTQviLjwZo8ZnEU0ldU+JQ81fghsnqxKJCmXkyALx6ugWW+FBkOSQNEZf 9Uog6bWUzUpbw35iRsZ/CTxDutGwYLYFCXMlT0SHZIDrf8D3nu31/WD2KY7J5pcz lXb0PoO8FCSxhvyrfCv5w+Pf8ECUhtSp10PWRaCFkUrVjPec4X/EWPTUdpXZtiTd HR0Ql9Q9aVwhk4pQiOKOZnqpurcGQL2hdPBe67o7F9Pa6aMNmtH9EyiMaWM3Bt8z +SLNJqGRp/UXcYkaHTZEJDR2BY2Oq0qwqb1noIT2hh2UpcSxtOAJniedHb1VTajH A7XX1hv/bw99whFzG85+zqQFnuMyWXPQjthj4kk+AkiHWmCgGSCiM+VZVMiMQJBg BU+9U99ALiPpxGPrZ13t+5P59xFiO0oMwsF3kqPPPXmEA9DM7lw0N5EyfzASQwS+ 8TSIgtj8O5vbK+krI3VmTVozMl3pO1eL063Ov9dm1U20EqT0IicJl/s3VXGV/Djf pvqGqUYYxvRnZixpy9El10Aft0KAW7X7W9zhE3k9/GBIxMJdmtTPeVgjjzCJGBAL 5i0auINkTMOR7Vr+GDOwhKKUTYuLd96F0kL/RUVuf/hbxG3nltpcOQYzodiPmvdp MYBqqIJsZdCjfQzvHSfr =Mk0K -----END PGP SIGNATURE----- --Apple-Mail=_15F13A35-E30B-4564-820B-27A5668D2D18-- From owner-freebsd-fs@freebsd.org Sun Aug 13 02:23:24 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 47842DDC41E for ; Sun, 13 Aug 2017 02:23:24 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 082197FB48 for ; Sun, 13 Aug 2017 02:23:23 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qk0-x229.google.com with SMTP id d136so37100265qkg.3 for ; Sat, 12 Aug 2017 19:23:23 -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=yimvu19ZwuwKCwkmmI8+aKYfZT1/F9MsTez1mg6fuh0=; b=hkoGYdGpzzv4HffVDb/wMyxjdiHmMq0yXI0h/6XnH1+fcC1/Ven1d1W7UoGBJWxc+9 xwOrW5ZkpHIjmRD0DMI/RM6MbQsaDU+70ozr23PREsIZthoS6I2PETlwsM8Lf3nUFis0 5F4vJL+aBmEQ6SXb8Gp8072QEh8dkBWp0qlYrm9REC5IIZHHFPlmz6oRq6qC5jUnPUmo qipTmDVBu06Dj61tFNhybweNmW8n6FcRQi2nXMlModQULsGzKE8BnUYzsMvzK3pbPn8d oZ9RxUNg8NEG0ATN6kAYwt9YB6k5+hTJY5GXNa61Zx1sziFVRKB4nxrtf+Org+vqBGdk pILw== 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=yimvu19ZwuwKCwkmmI8+aKYfZT1/F9MsTez1mg6fuh0=; b=rQocgaLfBvJkTLbH3Dk2fdo3HzsmuA0qzip1mZhVPV4o33lel65QqECIgqoLxdbSV+ tnkd85ihr5D3sgBMhEBkmyYFFy4L80exofH9QsxXI5VYAQ5zznwVKJ5f380/e9FNI6Dj MhuSiIiiS8GaH7Pl8t+bp65clgjmwboYgP+919F9y9xhmQ6QW3i/itWxIZfLmIt8DEAt 43icHsJoXlgK9kvPanzyHDCB88PWOXrd9LWHfshGr4PEEVaJIYXfvQuXa/CoeMc6fIWk IGmNxqgY/7aHUdBvNnTikfFG59ti2I9YyvDHVuNJX9M1MlNTEvd1p/6US7Df8kw8dvgc OqAA== X-Gm-Message-State: AHYfb5iy4VqW3/bEzWom1qPL25bL5QLmTwsXcuKEnDcsaFbvWPMcQHKS BFykrpoV+BAodRpb X-Received: by 10.55.103.23 with SMTP id b23mr27419998qkc.55.1502591002322; Sat, 12 Aug 2017 19:23:22 -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 u26sm3115250qtb.34.2017.08.12.19.23.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 12 Aug 2017 19:23:20 -0700 (PDT) Subject: Re: Oh no, what have I done... Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Paul Kraus In-Reply-To: <5B508AED-4DAC-42E4-8C56-4619C0D1A1C6@distal.com> Date: Sat, 12 Aug 2017 22:23:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <035BFBCB-BA43-4568-89E9-8E8DCDFAA8CA@kraus-haus.org> References: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> <20170813000323.GC95431@server.rulingia.com> <5B508AED-4DAC-42E4-8C56-4619C0D1A1C6@distal.com> To: Chris Ross , FreeBSD FS 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: Sun, 13 Aug 2017 02:23:24 -0000 > On Aug 12, 2017, at 9:22 PM, Chris Ross = wrote: >=20 >=20 >> On Aug 12, 2017, at 20:03 , Peter Jeremy wrote: >>=20 >> On 2017-Aug-12 19:36:31 -0400, Chris Ross = wrote: >>> But, I fear I may=E2=80=99ve shot myself. Is there any way to = recover my raid1z vdev from this situation, and get a working zfs pool = back? >>=20 >> There's no way to detach the vdev /dev/da2p1 - you need to backup and >> re-create the pool. You need to re-attach /dev/da2p1 so the pool can >> be imported, then do a backup, destroy the pool and re-create it. >=20 > Can I attach a different similar drive as da2p1? Nope. > Or, does it have to have the same bits that were put on it when it = was in the pool previously? If the latter, I don=E2=80=99t have those = bits any more. The same disk. ZFS is looking for the labels it writes (4x for = redundancy; 2 at the beginning of the disk and 2 at the end; it only = _needs_ to find one of them) to identify the drive to include it in the = zpool. If that disk no longer contains the ZFS labels then you are = probably out of luck. You _may_, and this is a very, very long shot, be able to force an = import to a TXG (transaction group) _before_ you added the lone drive = vdev. > I=E2=80=99ll try putting a disk with the same layout in, and see how = that goes. That was a thought I=E2=80=99d had. Won=E2=80=99t work, without the ZFS labels it will not be seen as the = missing drive. From owner-freebsd-fs@freebsd.org Sun Aug 13 02:48: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 C3FF8DDD9AE for ; Sun, 13 Aug 2017 02:48:31 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67C7B803DF for ; Sun, 13 Aug 2017 02:48:31 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]) (authenticated bits=0) by hydra.pix.net (8.16.0.19/8.15.2) with ESMTPSA id v7D2mK1I003023 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 12 Aug 2017 22:48:29 -0400 (EDT) (envelope-from cross+freebsd@distal.com) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.15.2/8.15.2) with ESMTPSA id v7D2mGjt092605 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Aug 2017 22:48:17 -0400 (EDT) (envelope-from cross+freebsd@distal.com) Content-Type: multipart/signed; boundary="Apple-Mail=_64E1E7EE-A91F-4B8F-B22E-C5713940579A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Oh no, what have I done... From: Chris Ross In-Reply-To: <035BFBCB-BA43-4568-89E9-8E8DCDFAA8CA@kraus-haus.org> Date: Sat, 12 Aug 2017 22:48:01 -0400 Cc: FreeBSD FS , Peter Jeremy Message-Id: <928F1F16-0777-4D66-BD27-8224DF80363C@distal.com> References: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> <20170813000323.GC95431@server.rulingia.com> <5B508AED-4DAC-42E4-8C56-4619C0D1A1C6@distal.com> <035BFBCB-BA43-4568-89E9-8E8DCDFAA8CA@kraus-haus.org> To: Paul Kraus X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]); Sat, 12 Aug 2017 22:48:19 -0400 (EDT) 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, 13 Aug 2017 02:48:31 -0000 --Apple-Mail=_64E1E7EE-A91F-4B8F-B22E-C5713940579A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 12, 2017, at 22:23 , Paul Kraus wrote: >>=20 >> Can I attach a different similar drive as da2p1? >=20 > Nope. >=20 >> Or, does it have to have the same bits that were put on it when it = was in the pool previously? If the latter, I don=E2=80=99t have those = bits any more. >=20 > The same disk. ZFS is looking for the labels it writes (4x for = redundancy; 2 at the beginning of the disk and 2 at the end; it only = _needs_ to find one of them) to identify the drive to include it in the = zpool. If that disk no longer contains the ZFS labels then you are = probably out of luck. Okay. Well, the work I had done on the other disk to =E2=80=9Cwipe=E2=80= =9D it only wiped the beginning. So I appear to have gotten lucky that = ZFS writes labels at the end, and also learned that my intent of wiping = it was insufficient. In this case, to my benefit. I was able to bring = the zpool back online. > You _may_, and this is a very, very long shot, be able to force an = import to a TXG (transaction group) _before_ you added the lone drive = vdev. I=E2=80=99m curious to learn more about this. Had I inserted an = geometrically identical disk, without the labels ZFS was able to find, = and the above was my option. How could I have done that? And, now that = I have it up again, am I moving farther away from that possibility? >=20 >> I=E2=80=99ll try putting a disk with the same layout in, and see how = that goes. That was a thought I=E2=80=99d had. >=20 > Won=E2=80=99t work, without the ZFS labels it will not be seen as the = missing drive. K. What, if it hadn=E2=80=99t found labels I=E2=80=99d fail to clear, = would it have done with it? Just considered it irrelevant, and still = refused to bring the pool in much the same was as I=E2=80=99d been = trying with the disk forcibly removed? Thanks all. I=E2=80=99d like to learn more about what to do in this = situation, but I appear to have at least gotten to the point where I can = create a backup, which should allow me to destroy and create a pool more = to my actual intent. - Chris --Apple-Mail=_64E1E7EE-A91F-4B8F-B22E-C5713940579A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZj73wAAoJEPFBDnXvoNg0ob8QAI91neADQ1NQbkP3QcUj5JE6 pJTLICII7z1Bz39ZNLszwA82bDfiasSTwKP9KdBCTgYiuF7dZhNXYGKA0mJe9qlG gJHssPsdR6DbdtPVh8fcmMVQ5CKIr7zOrWceUbmFzhaPZpuMdeluSa7Cv/8Jqspq RHUebydSKPJlQUQXoj4c88+Q3/CdSyLR8zIhEF78B4/rph+9TIaBlZ+2DtSiGO7Z yIaS7cRgaycawBNjWBRy/bzLvEi8fA0kST2guuzaGaoZSKkafzdHN2SpT1GPDg2c GxJ4//swkWmmnybenubFian11Q8iSFif8E3KhrJRkMWYiPd+V+3GnMcabFzDX/Lb D/Q3MdwcgCvqYuDWV7YHlGYIZDU2Hk2ZGUCGGh98ZkMpoF4F0qbgA/uoLVPRjWEP 0UDhxyndum2/y8WvVdI0qMISwy3u/qY3EvWEl5OJ0iaMZN0a23SvXjVtxDZBz9kh WqyK6u8AtB02jlRX8wkxNq1UUhodqFRUeVkp3F6H3EdgX4mTNnEbdomtPdnanHZv lC515fLXEQz9jL2Yd2XOYCFrHfP2R6sUqpyGxvXSOqJGXLyY6xl3nQZI0LsTQvV4 pUpeusE2RLCsPTxx1BlV5VUbQ8mQS5ZwwHbecEfN1rzE0LmvSoI2UMbYjYGbC+t5 SivKGw8Po7sgxZiEsULC =7W1x -----END PGP SIGNATURE----- --Apple-Mail=_64E1E7EE-A91F-4B8F-B22E-C5713940579A-- From owner-freebsd-fs@freebsd.org Sun Aug 13 03:14:44 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 0DB68DDF383 for ; Sun, 13 Aug 2017 03:14:44 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 B97DF81621 for ; Sun, 13 Aug 2017 03:14:43 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qk0-x229.google.com with SMTP id z18so37041164qka.4 for ; Sat, 12 Aug 2017 20:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kraus-haus-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=A4mg0OXQpf+dnuRYZbbQJqQdNlHjo4/qUkMUh8w2z7o=; b=XSFq3lFpBLtnPs0A3RQJAa+U3PBogqpgobKkBf8n6YvXs5IOgE4aAxlkdWGMK4csiE prXopEDQxnBrp0fJfuseCyQB2PA270F3BEjgMQk59ndlIHLsxiDIwXQrZ8DM3RQkLVSG cY8SaO1dScuiG9tahcGG3VLcdeW9D+y7I1t0/bRUEJly6y1M99Sbp7ohh5u9oAWjBgiH H/QfLEHM7qSXU0UNOmLiLLLz8eWmKa35b6QcRK8o6qMlodiEkHp0Dc65t+b8+lLFBh1i p8JXEvUyzGaX2yw53ztKbd9UyY61L7ZsyVkhGuDQPc4D1+e/xJtccEMpQAqvA+j0JISB CXUg== 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 :content-transfer-encoding:message-id:references:to; bh=A4mg0OXQpf+dnuRYZbbQJqQdNlHjo4/qUkMUh8w2z7o=; b=Pb2yKUEB/Db0PkUcSfhsKtbi0PdPS25BxlWuxT9d7smmCkLdRQZcZtoc3t5OskZudP In51NASitHrnONAjJb6dPIB5UDV+syTV2lC94/gSzXl7I535HvhioRceQHqYDa4FWRpN 5qnf0060xCWraqwZqRA03bjtAaKO50oIABXeQFDncCfu38Kf2bUsyo64d8Lsvnjc/G6h HHpoLbpvZJMcbQ36VUzHkEwGFkk8bTnP7X0N3eUtFRbAcpfTEu4/pooKiJPYs2298Wuw 3zdeHrFy01eiWJreWScM/eZICh/b7CU2GF1MvmyblWhTyqEnU/+IrXGkf0OoMLWsmOTE 1kOA== X-Gm-Message-State: AHYfb5jKTFmC0Rgy/MHl6/FiEWrgoORSlgvabISBxhToX35gWzOIhbvj RsCYDFMubDbV6+uV X-Received: by 10.55.212.2 with SMTP id l2mr19694123qki.3.1502594082930; Sat, 12 Aug 2017 20:14:42 -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 y9sm3159655qkg.36.2017.08.12.20.14.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 12 Aug 2017 20:14:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Oh no, what have I done... From: Paul Kraus In-Reply-To: <928F1F16-0777-4D66-BD27-8224DF80363C@distal.com> Date: Sat, 12 Aug 2017 23:14:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06EEEF86-E466-44EA-86F1-866DA32DD92D@kraus-haus.org> References: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> <20170813000323.GC95431@server.rulingia.com> <5B508AED-4DAC-42E4-8C56-4619C0D1A1C6@distal.com> <035BFBCB-BA43-4568-89E9-8E8DCDFAA8CA@kraus-haus.org> <928F1F16-0777-4D66-BD27-8224DF80363C@distal.com> To: Chris Ross , FreeBSD FS 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: Sun, 13 Aug 2017 03:14:44 -0000 > On Aug 12, 2017, at 10:48 PM, Chris Ross = wrote: >=20 >> On Aug 12, 2017, at 22:23 , Paul Kraus wrote: >> The same disk. ZFS is looking for the labels it writes (4x for = redundancy; 2 at the beginning of the disk and 2 at the end; it only = _needs_ to find one of them) to identify the drive to include it in the = zpool. If that disk no longer contains the ZFS labels then you are = probably out of luck. >=20 > Okay. Well, the work I had done on the other disk to =E2=80=9Cwipe=E2=80= =9D it only wiped the beginning. So I appear to have gotten lucky that = ZFS writes labels at the end, and also learned that my intent of wiping = it was insufficient. In this case, to my benefit. I was able to bring = the zpool back online. You got luck (and in this case you win :-) >=20 >> You _may_, and this is a very, very long shot, be able to force an = import to a TXG (transaction group) _before_ you added the lone drive = vdev. >=20 > I=E2=80=99m curious to learn more about this. Had I inserted an = geometrically identical disk, without the labels ZFS was able to find, = and the above was my option. How could I have done that? And, now that = I have it up again, am I moving farther away from that possibility? Using zdb you can examine the TXGs and there is a way to force an import = to a certain TXG (at least under Illumos there is, I assume the FBSD ZFS = code is the same). I do not remember the specific procedure, but it went = by on one of the ZFS mailing lists a few years ago. The goal at the time = was not to deal with a changed pool configuration but a series of writes = that corrupted something (possibly due to a feature being turned on at a = certain point in time). You would lose all data written after the TXG = you force the import to. Looking at the manpages for zpool and zdb, it looks like doing this has = gotten easier with `zdb -e -F` =E2=80=A6 operate on exported pool and = rollback TXG until the pool is importable =E2=80=A6 but I=E2=80=99m sure = there are limits :-) Spend time with the zdb manpage and remember that many of these = functions were added due to someone needing to do something = =E2=80=9Cinappropriate=E2=80=9D to a pool to recover some data :-) >=20 >>=20 >>> I=E2=80=99ll try putting a disk with the same layout in, and see how = that goes. That was a thought I=E2=80=99d had. >>=20 >> Won=E2=80=99t work, without the ZFS labels it will not be seen as the = missing drive. >=20 > K. What, if it hadn=E2=80=99t found labels I=E2=80=99d fail to = clear, would it have done with it? Just considered it irrelevant, and = still refused to bring the pool in much the same was as I=E2=80=99d been = trying with the disk forcibly removed? ZFS would have considered the new drive as just that and the pool would = still be un-importable due to a missing top level vdev. > Thanks all. I=E2=80=99d like to learn more about what to do in this = situation, but I appear to have at least gotten to the point where I can = create a backup, which should allow me to destroy and create a pool more = to my actual intent. Keep in mind are that you cannot add devices for capacity _within_ a = vdev only to add mirrors, you add capacity to a pool by _adding_ vdevs. = As you learned, all of the top level vdevs do not have to be the same = type (mirror, radizn), but with different types of vdevs it is almost = impossible to predict the performance of the pool. These days I = generally only use raidz2 for backup data or long term storage, I use = mirrors (2 or 3 way) for production data. This gets me better = performance and easier scalability. ZFS is very good at getting you access to your data as long as it can = find enough of each top level vdev to bring them all on line. I once had = a hardware config with limitations, so I designed my pools around that = and _when_ the external disk chassis went offline I lost performance but = no data. When trying to recover a ZFS pool, never overwrite any drives that may = have been part of the pool as you may need them to bring the pool back = online. From owner-freebsd-fs@freebsd.org Sun Aug 13 10:09: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 85A04DD5134; Sun, 13 Aug 2017 10:09:31 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EFD45675B5; Sun, 13 Aug 2017 10:09:30 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from [IPv6:2a02:2698:26:ba6d:b8c2:5ea7:b69b:1849] (dynamic-2a02-2698-26-0-0.perm.ertelecom.ru [IPv6:2a02:2698:26:ba6d:b8c2:5ea7:b69b:1849] (may be forged)) (authenticated bits=0) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPSA id v7DA9Psd036500 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 13 Aug 2017 15:09:25 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1502618965; bh=VySA4zhZ8cIn8iDCAv7T+QPVKuUplKPP7uddFkMqSME=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=GVQIjTlavkVVDMRs5ECS4zaIyDyYO1H23k0y9ZxhMRh8olUlZ14HQ8cIGsTJLDeAi fx5Cycf9RrGGL2hMH5qps1GJwM2nMlvcbEmnF7ZZLEMFWsAoNnTHBpoMm280d9BPj9 N/y1NFgmNDgMKt/Ky/WsEQsOzrk9TiMGW+oipalo= Subject: Re: zfs listing and CPU To: freebsd-fs@freebsd.org Cc: freebsd-stable References: From: "Eugene M. Zheganin" Message-ID: <399c4309-c7a6-a7e9-299f-9675224c090d@norma.perm.ru> Date: Sun, 13 Aug 2017 15:09:23 +0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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, 13 Aug 2017 10:09:31 -0000 Hi, On 12.08.2017 20:50, Paul Kraus wrote: >> On Aug 11, 2017, at 2:28 AM, Eugene M. Zheganin wrote: >> >> Why does the zfs listing eat so much of the CPU ? >> 47114 root 1 20 0 40432K 3840K db->db 4 0:05 26.84% zfs >> 47099 root 1 20 0 40432K 3840K zio->i 17 0:05 26.83% zfs >> 47106 root 1 20 0 40432K 3840K db->db 21 0:05 26.81% zfs >> 47150 root 1 20 0 40432K 3428K db->db 13 0:03 26.31% zfs >> 47141 root 1 20 0 40432K 3428K zio->i 28 0:03 26.31% zfs >> 47135 root 1 20 0 40432K 3312K g_wait 9 0:03 25.51% zfs >> This is from winter 2017 11-STABLE (r310734), one of the 'zfs'es is cloning, and all the others are 'zfs list -t all'. I have like 25 gigs of free RAM, do I have any chance of speeding this up using may be some caching or some sysctl tuning ? We are using a simple ZFS web API that may issue concurrent or sequential listing requests, so as you can see they sometimes do stack. > How many snapshots do you have ? I have only seen this behavior with LOTS (not hundreds, but thousands) of snapshots. [root@san1:~]# zfs list -t snapshot | wc -l 88 > What does your `iostat -x 1` look like ? I expect that you are probably saturating your drives with random I/O. Well, it's really long, and the disks are busy with random i/o indeed, but byst only for 20-30%. As about iostat - it's really long, because I have hundreds (not thousands) of zvols, and they do show up in iostat -x. But nothing unusual besides that. Thanks. Eugene. From owner-freebsd-fs@freebsd.org Sun Aug 13 11:13:24 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 35D0ADD9174; Sun, 13 Aug 2017 11:13:24 +0000 (UTC) (envelope-from tenzin.lhakhang@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 DB08669DCD; Sun, 13 Aug 2017 11:13:23 +0000 (UTC) (envelope-from tenzin.lhakhang@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id k20so11309051wmg.0; Sun, 13 Aug 2017 04:13:23 -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=sb/SJRa2EAKbfvjv+9OyiiuIyzHrgAXqAYd9b/GNhQ4=; b=X+u+ry9ujs4blAdvjWWf63TW9+wYwKYqo2afC1m5OuuFAZQkqwgnTmAcyJjlT5Kj9a gxXzBi1agZjPwUgi0C98cLl6SkmYHN95+VNFTBzwwkMlZ0hX0LzpmzDgJoEtExMeSN6n 0cSI9X8Y/gryhpPi75HVXdTLCe+QwrgW9YqIJbgtT1JIf+STAJNLj6dxiMFHmZURQ9cq NYYksF4BBzXSNh3zyMKLU6plJ2xmutkG2lgrDzA2fMxeOh+jAlWnsZY/Bc25P9QBPBnt Xo0LgWDYlEq5aGYj1pQFFvFE2OK0IV9evLyts2mxgyEYSGEk0flPMnD6JFwAiivFTuE8 shjg== 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=sb/SJRa2EAKbfvjv+9OyiiuIyzHrgAXqAYd9b/GNhQ4=; b=gv+PCBSZWHk0+eAkdvA6WxBphBi93D0j05smp48er/Q1uCh5FV8eJ2v2arFtsDMnIr Z81Fcnsb0v+eSwzNBwDjMSUFKgrp5mHLAHTbryGjej+OmlwXelfAjyYE30DF33yUkFdK VGgzwS3nRVwJ+mCaUO9HKBMdaJgiXLoHBUDPwmiHgSNI1kv7TLemODHHKCNBx/otAYHr jaOggGdmtkOfTpMLiuohHXdH1byLHQbV87oZEMCeONirSFl5cwkTE+vGWjFGW4yYAJgs DOvxuOE/PFRaTwGTEx8Gxtt+BICC31RASrdEdqX9Y5ZigHNAZz91hw6yJZu30sA7xBpL wxqg== X-Gm-Message-State: AHYfb5jwcKtFy8+fPRyCdFeSyudJ+R8FT88fuA0jE72rV4sCYZIDUoO3 nz5CjpX8cUmHNTm/eiSLERAoM26myS+8 X-Received: by 10.28.12.201 with SMTP id 192mr2274527wmm.45.1502622801545; Sun, 13 Aug 2017 04:13:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.167.2 with HTTP; Sun, 13 Aug 2017 04:13:20 -0700 (PDT) In-Reply-To: <399c4309-c7a6-a7e9-299f-9675224c090d@norma.perm.ru> References: <399c4309-c7a6-a7e9-299f-9675224c090d@norma.perm.ru> From: Tenzin Lhakhang Date: Sun, 13 Aug 2017 07:13:20 -0400 Message-ID: Subject: Re: zfs listing and CPU To: "Eugene M. Zheganin" 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: Sun, 13 Aug 2017 11:13:24 -0000 You may want to have an async zfs-get program/script that regularly does a zfs get -Ho and stores then in a local cache (redis or your own program) at a set interval and then the api can hit the cache instead of directly running get or list. - Some silly person will try to benchmark your zfs web-API and overload your server with zfs processes. - Example: let me run [ ab -c 10 -n 10000 http://yourserver/zfs-api/list ] -- Let me run 10 concurrent connection with a total of 10k requests to your api (it's a simple one liner -- people will be tempted to benchmark like this). Example: https://github.com/tlhakhan/ideal-potato/blob/master/zdux/routers/zfs/service.js#L9 - This is a JS example, but you can easily script it or another language (golang) for cache separation and another program for the API. Also, zfs does have a -c property to get cached values -- these values are stored in an internal zfs process cache. The -c doesn't help if you have 1000(0)s of filesystems, a single list can still take minutes. Sending the list is also several megabytes. zfs list -Hrpc -o space zfs get -Hrpc space all - H= no headers - r = recursive - p = machine parseable - c = hit cached entries Fixes: if ok, it may be good to stop the API, kill slowly the zfs list -t all. @ Eugene: - I have seen single zfs list -Ho space -rt all take about 4-5 minutes, on an 8000+ zfs_dataset zpool. --- Notes: my knowledge is from the illumos-zfs man pages but should apply here. On Sun, Aug 13, 2017 at 6:09 AM, Eugene M. Zheganin wrote: > Hi, > > On 12.08.2017 20:50, Paul Kraus wrote: > >> On Aug 11, 2017, at 2:28 AM, Eugene M. Zheganin >>> wrote: >>> >>> Why does the zfs listing eat so much of the CPU ? >>> 47114 root 1 20 0 40432K 3840K db->db 4 0:05 26.84% zfs >>> 47099 root 1 20 0 40432K 3840K zio->i 17 0:05 26.83% zfs >>> 47106 root 1 20 0 40432K 3840K db->db 21 0:05 26.81% zfs >>> 47150 root 1 20 0 40432K 3428K db->db 13 0:03 26.31% zfs >>> 47141 root 1 20 0 40432K 3428K zio->i 28 0:03 26.31% zfs >>> 47135 root 1 20 0 40432K 3312K g_wait 9 0:03 25.51% zfs >>> This is from winter 2017 11-STABLE (r310734), one of the 'zfs'es is >>> cloning, and all the others are 'zfs list -t all'. I have like 25 gigs of >>> free RAM, do I have any chance of speeding this up using may be some >>> caching or some sysctl tuning ? We are using a simple ZFS web API that may >>> issue concurrent or sequential listing requests, so as you can see they >>> sometimes do stack. >>> >> How many snapshots do you have ? I have only seen this behavior with LOTS >> (not hundreds, but thousands) of snapshots. >> > [root@san1:~]# zfs list -t snapshot | wc -l > 88 > >> What does your `iostat -x 1` look like ? I expect that you are probably >> saturating your drives with random I/O. >> > > Well, it's really long, and the disks are busy with random i/o indeed, but > byst only for 20-30%. As about iostat - it's really long, because I have > hundreds (not thousands) of zvols, and they do show up in iostat -x. But > nothing unusual besides that. > > > Thanks. > > Eugene. > > > _______________________________________________ > 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 Sun Aug 13 14:03:58 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 501F0D93F6F for ; Sun, 13 Aug 2017 14:03:58 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from limbo.b1t.name (limbo.b1t.name [78.25.32.206]) (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 E21C86FE0A for ; Sun, 13 Aug 2017 14:03:57 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from [172.29.1.75] (probe.42.lan [172.29.1.75]) by limbo.b1t.name (Postfix) with ESMTPSA id 3189886 for ; Sun, 13 Aug 2017 16:54:23 +0300 (EEST) Subject: Re: Oh no, what have I done... To: freebsd-fs@freebsd.org References: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> <20170813000323.GC95431@server.rulingia.com> <5B508AED-4DAC-42E4-8C56-4619C0D1A1C6@distal.com> <035BFBCB-BA43-4568-89E9-8E8DCDFAA8CA@kraus-haus.org> <928F1F16-0777-4D66-BD27-8224DF80363C@distal.com> <06EEEF86-E466-44EA-86F1-866DA32DD92D@kraus-haus.org> From: Volodymyr Kostyrko Message-ID: <1d3771a3-9c3a-1af9-9c48-032a01629630@b1t.name> Date: Sun, 13 Aug 2017 16:54:21 +0300 User-Agent: Mozilla/5.0 (X11; DragonFly x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: <06EEEF86-E466-44EA-86F1-866DA32DD92D@kraus-haus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=b1t.name; s=dkim; t=1502632464; bh=sDpvZo/OBQW37d3MfrmNPy4ggMKD3QWMhu4HXLmH6X0=; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=G17xad7waaL2ub24Fi6+BfuGU8R3xj/gQqEGbnjP//pHzLiZR3mD14CQB0agMkEigWGLil0DtzQCvdeUq82ZgErdhe1JfysxJZUtmfIuI/LBLo+3kUVX7tclHdqJsWYkrWgOzRWqwJG3Omr+vIGwBVpejcVgPmPyo6T/+WV7sn0= 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, 13 Aug 2017 14:03:58 -0000 Paul Kraus wrote: > Using zdb you can examine the TXGs and there is a way to force an impor= t to a certain TXG (at least under Illumos there is, I assume the FBSD ZF= S code is the same). I do not remember the specific procedure, but it wen= t by on one of the ZFS mailing lists a few years ago. The goal at the tim= e was not to deal with a changed pool configuration but a series of write= s that corrupted something (possibly due to a feature being turned on at = a certain point in time). You would lose all data written after the TXG y= ou force the import to. > > Looking at the manpages for zpool and zdb, it looks like doing this has= gotten easier with `zdb -e -F` =E2=80=A6 operate on exported pool and ro= llback TXG until the pool is importable =E2=80=A6 but I=E2=80=99m sure th= ere are limits :-) That's -T, it was intentionally left undocumented. /usr/src/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c /starting txg --=20 Sphinx of black quartz judge my vow. From owner-freebsd-fs@freebsd.org Sun Aug 13 15:41: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 04F52DC5218 for ; Sun, 13 Aug 2017 15:41: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 E65FB734AB for ; Sun, 13 Aug 2017 15:41:41 +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 v7DFffZD003967 for ; Sun, 13 Aug 2017 15:41:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221075] regression: 11.1 is unable to mount ZFS / on boot Date: Sun, 13 Aug 2017 15:41: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.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marius@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 15:41:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221075 --- Comment #14 from Marius Strobl --- Yeah, I've missed that sdhci_pci(4) actually is attaching, probably due to a typo in the search field. Still, the only explanation I have is that the sheer presence of the geom_flasmap(4) class is triggering a GEOM-related ra= ce. Especially, since you apparently didn't have a SD card inserted, so neither mmc(4) nor mmcsd(4) did attach and, consequently, no additional disk(9) was present. I can't find a GEOM-related change not present in stable/11 which looks like it would fix such a race. Thus, I suspect that the particular race in fact = is also present in head, but due to some differences in timing you don't happen to hit it there. Recently it has been mentioned that geom_label(4) is racy, too: https://lists.freebsd.org/pipermail/svn-src-all/2017-August/149683.html The fact that as mentioned in that e-mail, bsdinstall(8) therefore doesn't use labels - but apparently you do in your ZFS setup - might also explain w= hy not more people are hitting the problem you see. So it could be worthwhile = to try whether using ada[0,1]p1 directly for the zpools instead of DISK-p1 labels reliably gets you rid of the problem. Apart from that I don't have an idea how to further debug the actual cause. Part of the problem is that there are several known GEOM-related races, some even documented in the code of geom(4). So changing something or even fixing one race just might alter the timing enough so that the real culprit is hid= den. Another part is that I only know how geom(4) debugging output differs when hitting the race I mentioned earlier, but I don't know how it would differ for the other races, for example the geom_label(4)-related one. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Aug 13 16:56:03 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 BA97ADCA5AD for ; Sun, 13 Aug 2017 16:56:03 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AC1276566 for ; Sun, 13 Aug 2017 16:56:02 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]) (authenticated bits=0) by hydra.pix.net (8.16.0.19/8.15.2) with ESMTPSA id v7DGtbQS022197 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 13 Aug 2017 12:55:44 -0400 (EDT) (envelope-from cross+freebsd@distal.com) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.15.2/8.15.2) with ESMTPSA id v7DGtZOs097287 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Aug 2017 12:55:36 -0400 (EDT) (envelope-from cross+freebsd@distal.com) Content-Type: multipart/signed; boundary="Apple-Mail=_BDF2A781-B1CF-43FB-9688-07F2EBF6AF76"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Oh no, what have I done... From: Chris Ross In-Reply-To: <1d3771a3-9c3a-1af9-9c48-032a01629630@b1t.name> Date: Sun, 13 Aug 2017 12:55:25 -0400 Cc: freebsd-fs@freebsd.org Message-Id: <8EE368A2-D2BA-4E43-8B84-47E8F50B5B1B@distal.com> References: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> <20170813000323.GC95431@server.rulingia.com> <5B508AED-4DAC-42E4-8C56-4619C0D1A1C6@distal.com> <035BFBCB-BA43-4568-89E9-8E8DCDFAA8CA@kraus-haus.org> <928F1F16-0777-4D66-BD27-8224DF80363C@distal.com> <06EEEF86-E466-44EA-86F1-866DA32DD92D@kraus-haus.org> <1d3771a3-9c3a-1af9-9c48-032a01629630@b1t.name> To: Volodymyr Kostyrko X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]); Sun, 13 Aug 2017 12:55:36 -0400 (EDT) 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, 13 Aug 2017 16:56:03 -0000 --Apple-Mail=_BDF2A781-B1CF-43FB-9688-07F2EBF6AF76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 13, 2017, at 09:54 , Volodymyr Kostyrko = wrote: >=20 > Paul Kraus wrote: >=20 >> Using zdb you can examine the TXGs and there is a way to force an = import to a certain TXG (at least under Illumos there is, I assume the = FBSD ZFS code is the same). I do not remember the specific procedure, = but it went by on one of the ZFS mailing lists a few years ago. The goal = at the time was not to deal with a changed pool configuration but a = series of writes that corrupted something (possibly due to a feature = being turned on at a certain point in time). You would lose all data = written after the TXG you force the import to. >>=20 >> Looking at the manpages for zpool and zdb, it looks like doing this = has gotten easier with `zdb -e -F` =E2=80=A6 operate on exported pool = and rollback TXG until the pool is importable =E2=80=A6 but I=E2=80=99m = sure there are limits :-) >=20 > That's -T, it was intentionally left undocumented. >=20 > /usr/src/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c /starting txg Thanks Peter, Paul, Volodymyr, and all. So I got my pool back online, = just in a way I don=E2=80=99t like it, so I=E2=80=99m trying to find a = place I can export (zfs send) the 5+ TB of data. Disadvantage of having = my largest data-store machine be the problem machine. :-) But, were I in a state as I was earlier in recent days, and I = understand the above, I might=E2=80=99ve been able to =E2=80=9Czfs = import -T=E2=80=9D to a TXG that was before I added the single-drive = vdev, and it would=E2=80=99ve imported just the working raidz1 and been = okay? If any data had been written in the very small time the new vdev = was added, that would be lost, but I would=E2=80=99ve been fine with = that. And, if I understand correctly, I would=E2=80=99ve used =E2=80=9Czdb=E2=80= =9D to find out what the TXG that I wanted to refer to was? Paul, you = mention using zdb against an exported pool, which of course I didn=E2=80=99= t have. Could I have found the old TXG to import from without having an = export? Just that that seems to be the gap I=E2=80=99m missing in the = above. But, all is well. Or at least, 99+% recoverable, it seems. Thank you = all for your time and information. What do rebuild after I find a way = to back the pool up will be this next weeks problem. - Chris --Apple-Mail=_BDF2A781-B1CF-43FB-9688-07F2EBF6AF76 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZkISGAAoJEPFBDnXvoNg0wVwP/jT7fT/cy5SpJAvBIOyQ4SIZ ifaWO8u/lyAVJQGOUpqR4RGmZWSlxmn3IzLhInPFxXV9PGjzRDUJrDSGza2RWV8k Kzj2wSQEJGUmbEYlSY8ssZ51wMsjcFLrfsKAzJgfFztsy6XOdUR+3sGWAZKA/t7M B1lCgr+75rlfQZrX52aZOw3n3+S9c/Z5ggHBoAvw3gT66JOqyKbm2IkjyWj+1A50 QYIpuOB9InjGB22Uk3zk07wUDSxngjby9LBcbBArUl94yQkuBhmwB3TqbGxQiyeV WOpipLycDyaLjrlw+srfYhyiLDXS0vpI7ZGvzTN+dffUGb+skEBjZevfSPxLx1gR SIW2GI1Bw70ChOpeW9tqrCAdOKwYEZnv47XN3PrSc2Ziu2K3XTmHXalXmLPXn04i RYYl1GshEguCGfxJCkWF+dnMoU3g/LSD6OdjMy4n4QbOG/nWuSrFeMDWf9vquL20 zJvYT9gma5saBSvPUS4Ubbtk58yB5Dz5Hl4JSBxh3LWjFCRRNEwMDTe8znyYF30H lV/SrxTXoDyIh+Y2BUeJfgafHcX34vYwh6T+iHNfyIc9tfwDMldyCY5eoY+S5mR7 n02qOlGxV0dEiM6nkl0O99WwcpF8T7fbiaTxfnBlzJXB3X9NDjCn6N4cSFL3qBj9 MEXAmoYugAopC+8L87ZS =g833 -----END PGP SIGNATURE----- --Apple-Mail=_BDF2A781-B1CF-43FB-9688-07F2EBF6AF76-- From owner-freebsd-fs@freebsd.org Sun Aug 13 18:25:45 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 1DF56DD0A34; Sun, 13 Aug 2017 18:25:45 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 89BA27D9E3; Sun, 13 Aug 2017 18:25:43 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from [IPv6:2a02:2698:26:ba6d:b8c2:5ea7:b69b:1849] (dynamic-2a02-2698-26-0-0.perm.ertelecom.ru [IPv6:2a02:2698:26:ba6d:b8c2:5ea7:b69b:1849] (may be forged)) (authenticated bits=0) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPSA id v7DIPcfZ058994 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 13 Aug 2017 23:25:38 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1502648738; bh=EzrOpIoJuONDvA70FFhY/Lidt4qvvxquAR8qPyJRz8I=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=tZr4MHnr7MVvBeCars1wCjh9enj1pEaXhEpN0t3yNkrs+tugfPYAVw1HWnU8fEjks jywUijPPD23lpjEYrN4KHR7RNKySriprN3J/RZ1BMXpURJ5IOvahVBHzOiyW+93ggs VqkQzEnxHGztvCSYPcWsNtAM9f7lO6q3js9/HkCg= Subject: Re: zfs listing and CPU To: "freebsd-fs@FreeBSD.org" Cc: freebsd-stable References: <399c4309-c7a6-a7e9-299f-9675224c090d@norma.perm.ru> From: "Eugene M. Zheganin" Message-ID: Date: Sun, 13 Aug 2017 23:25:36 +0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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, 13 Aug 2017 18:25:45 -0000 On 13.08.2017 16:13, Tenzin Lhakhang wrote: > You may want to have an async zfs-get program/script that regularly > does a zfs get -Ho and stores then in a local cache (redis or your own > program) at a set interval and then the api can hit the cache instead > of directly running get or list. I cannot because the cache will become stale on first new entity creation, which happens all the time. > - Some silly person will try to benchmark your zfs web-API and > overload your server with zfs processes. > - Example: let me run [ ab -c 10 -n 10000 http://yourserver/zfs-api/list ] > -- Let me run 10 concurrent connection with a total of 10k requests to > your api (it's a simple one liner -- people will be tempted to > benchmark like this). > > Example: > https://github.com/tlhakhan/ideal-potato/blob/master/zdux/routers/zfs/service.js#L9 > - This is a JS example, but you can easily script it or another > language (golang) for cache separation and another program for the API. > > Also, zfs does have a -c property to get cached values -- these values > are stored in an internal zfs process cache. The -c doesn't help if > you have 1000(0)s of filesystems, a single list can still take > minutes. Sending the list is also several megabytes. Doesn't have on FreeBSD. Thanks. Eugene. From owner-freebsd-fs@freebsd.org Mon Aug 14 06:14: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 4E94FDD78D3 for ; Mon, 14 Aug 2017 06:14:59 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [46.251.251.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "0x20.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 156316F378; Mon, 14 Aug 2017 06:14:58 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (e-new.0x20.net [217.69.76.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 2B5CD8DA7B; Mon, 14 Aug 2017 08:04:49 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id v7E64uMu028551; Mon, 14 Aug 2017 08:04:56 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id v7E64uAI028255; Mon, 14 Aug 2017 08:04:56 +0200 (CEST) (envelope-from lars) Date: Mon, 14 Aug 2017 08:04:56 +0200 From: Lars Engels To: freebsd-fs@freebsd.org Cc: gnn@FreeBSD.org Subject: Re: Status of FUSE in FreeBSD kernel Message-ID: <20170814060456.GE48929@e-new.0x20.net> References: <878tiqdjtc.fsf@vostro.rath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <878tiqdjtc.fsf@vostro.rath.org> X-Editor: VIM - Vi IMproved 7.4 User-Agent: Mutt/1.5.23 (2014-03-12) 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, 14 Aug 2017 06:14:59 -0000 On Fri, Aug 11, 2017 at 08:46:07PM +0200, Nikolaus Rath wrote: > Hello, > > Is there some resource that gives an overview of the features supported > by the FUSE kernel module in FreeBSD? > > For example, I am wondering if the EINVAL error that I'm getting when > sending FUSE_NOTIFY_INVAL_INODE requests to FUSE is because of an error > on my side, or because the FreeBSD kernel just doesn't support it. > > I expect to encounter the same question for a number of other functions, > e.g. the other FUSE_NOTIFY_* requests. > > Thanks, > -Nikolaus George Neville-Neil (CC'ed) wrote FreeBSD's fuse kernel module. Maybe he can help you. -- Lars From owner-freebsd-fs@freebsd.org Mon Aug 14 06:54:27 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 9C57BDD8EE0 for ; Mon, 14 Aug 2017 06:54:27 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 5FCB070996 for ; Mon, 14 Aug 2017 06:54:26 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.54] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 578469DD407; Mon, 14 Aug 2017 08:47:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: protecting zfs snapshot info From: Borja Marcos In-Reply-To: Date: Mon, 14 Aug 2017 08:47:44 +0200 Cc: "freebsd-fs@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <52984307-2C6C-454C-A69B-15FB4AE01E1B@sarenet.es> References: To: Mike Tancsa X-Mailer: Apple Mail (2.3273) 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, 14 Aug 2017 06:54:27 -0000 > On 12 Aug 2017, at 19:14, Mike Tancsa wrote: >=20 >=20 > Is there a way in zfs to protect non root users from seeing snapshots = ? > lets say a user makes a permissions mistake on a sensitive = homedirectory > on a Monday AM that is not discovered until the next day. If there = are > a whole mess of snapshots created between those two points in time, > there is no way to protect that directory without deleting the = snapshots. Good question and it=E2=80=99s a problem indeed. The .zfs directory is = always created and it can be hidden but it=E2=80=99s still accessible. It=E2=80=99s a = security problem that prevents an effective access revocation for a directory/file, I guess that=E2=80=99= s what you mean. Ideally, datasets should have a property preventing the snapshots to be = auto mounted when the relevant .zfs/snapshot directory was accessed or even = preventing the creation of .zfs. Alternatively there could be a specific zfs permission covering this, = like a =E2=80=9Csnapaccess=E2=80=9D for snapshot access or =E2=80=9Csnapmount=E2=80=9D for automatic mounting of = snapshots, but it=E2=80=99s more complicated to do. Borja. From owner-freebsd-fs@freebsd.org Mon Aug 14 10:49:21 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 2A0A3DE2A39 for ; Mon, 14 Aug 2017 10:49:21 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E13B776F9E for ; Mon, 14 Aug 2017 10:49:20 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd20.aul.t-online.de (fwd20.aul.t-online.de [172.20.26.140]) by mailout06.t-online.de (Postfix) with SMTP id CD40641EA59E; Mon, 14 Aug 2017 12:49:11 +0200 (CEST) Received: from Stefans-MBP-2.fritz.box (Ewt5koZS8hlci+FKuJRJdZ5imEMEXPKPddJxVhqN2BkrgCx1iqGd4JmMfAB27Oqgo2@[84.154.103.210]) by fwd20.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1dhCvk-1NuxQu0; Mon, 14 Aug 2017 12:49:08 +0200 Subject: Re: Oh no, what have I done... To: Chris Ross , Volodymyr Kostyrko Cc: freebsd-fs@freebsd.org References: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> <20170813000323.GC95431@server.rulingia.com> <5B508AED-4DAC-42E4-8C56-4619C0D1A1C6@distal.com> <035BFBCB-BA43-4568-89E9-8E8DCDFAA8CA@kraus-haus.org> <928F1F16-0777-4D66-BD27-8224DF80363C@distal.com> <06EEEF86-E466-44EA-86F1-866DA32DD92D@kraus-haus.org> <1d3771a3-9c3a-1af9-9c48-032a01629630@b1t.name> <8EE368A2-D2BA-4E43-8B84-47E8F50B5B1B@distal.com> From: Stefan Esser Message-ID: <48f99783-ea09-ac43-535c-f5fccda29233@freebsd.org> Date: Mon, 14 Aug 2017 12:49:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8EE368A2-D2BA-4E43-8B84-47E8F50B5B1B@distal.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ID: Ewt5koZS8hlci+FKuJRJdZ5imEMEXPKPddJxVhqN2BkrgCx1iqGd4JmMfAB27Oqgo2 X-TOI-MSGID: 480c71ff-b939-4c08-9ded-bc57438a5243 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, 14 Aug 2017 10:49:21 -0000 Am 13.08.17 um 18:55 schrieb Chris Ross: > And, if I understand correctly, I wouldve used zdb to find out > what the TXG that I wanted to refer to was? Paul, you mention using > zdb against an exported pool, which of course I didnt have. Could I > have found the old TXG to import from without having an export? Just > that that seems to be the gap Im missing in the above. You can display the pool history including TXG numbers with: # zpool history -i The history for all pools is shown, if the pool name is omitted. Regards, STefan From owner-freebsd-fs@freebsd.org Mon Aug 14 11:15:11 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 C0321DE3B24; Mon, 14 Aug 2017 11:15:11 +0000 (UTC) (envelope-from tenzin.lhakhang@gmail.com) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 5C51177DAD; Mon, 14 Aug 2017 11:15:11 +0000 (UTC) (envelope-from tenzin.lhakhang@gmail.com) Received: by mail-wr0-x22e.google.com with SMTP id y41so8774914wrd.3; Mon, 14 Aug 2017 04:15:11 -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=oX3ioggygsDcsNUW6QE0FYMIBCQkF6IxPhYSCCQoaGA=; b=sRmBm5fQn7YGyz+581g3//62tgjCsjH9Fgo4GLgD1QnwxoNQnSssT7bbPGmKsf5StB 1HQd1c6hS9XSWBtr5yIZ1A6f3M5uIeMBtK5ohHRYm+Y/KvCWjX0WchGyv3tGhbYyP8De XsPVP0iLW5sfapxB7HEZsMY3Ev4642qw54twCmxME+BMP+m8fLtTZWSvyJpqx3Xuk8d4 N1pLFMTHWpczxnixoMGhtSQYeiADRsiqz3Q2IclMpK2sV8i8HJAUq7xNIQcDYg8RyK9h bk30igYQHUgfAvF00GxQHeE5LK61sspC8kRVz8T0ZjAjX5NCdsgjioWyf1T8TjjyMcU/ yYbg== 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=oX3ioggygsDcsNUW6QE0FYMIBCQkF6IxPhYSCCQoaGA=; b=g6boV2I/u7pUeUrmUBnVbD2vc8Qz0rfWqf+80lNqP8uddHxxPFWntrsemz5C1Ma/wM Nt4Vyc9nC+/GwNHmGZRXE3moPF4DuZO4ED4ReCdd2CaFns4KC9GRqpflUIiAaFTSGn9l 58to7Butk04T4KgAf2fLU8/+eMcJHpnn5+ZZqfhcadZz3q+Vw1z1ka40s1Lrov+/gjoV Rr2+AZjolEK9t0smtti2wFNNTdizTGwG+uFfaGnhZVGZo99byQJKwcVJH9gtV51zVV2z FMVNEOPwgByTEdl50UUU0rRNF2ejlrpP2iqG3eTAIFxi+Y2qfS9LaQ+dIxdk573QtBLg GheQ== X-Gm-Message-State: AHYfb5jX4i8yN5/EISE063AgxQrl/cMDQoVhVHmq51+qjg3EYhjNQrcl u4R5DemaVBbBseBq1gYsquxZGEpxRND0 X-Received: by 10.223.186.130 with SMTP id p2mr1598413wrg.151.1502709308743; Mon, 14 Aug 2017 04:15:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.167.2 with HTTP; Mon, 14 Aug 2017 04:15:07 -0700 (PDT) In-Reply-To: References: <399c4309-c7a6-a7e9-299f-9675224c090d@norma.perm.ru> From: Tenzin Lhakhang Date: Mon, 14 Aug 2017 07:15:07 -0400 Message-ID: Subject: Re: zfs listing and CPU To: "Eugene M. Zheganin" 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: Mon, 14 Aug 2017 11:15:11 -0000 Interesting, even the illumos man page doesn't have the -c defined. I remember reading about it at one point. I can only get `zfs get -Hrpc all` working, even though -c is not documented. So, I retract my statement on the zfs list with cached. # zfs get -*Hpc* -o property,value name,used,avail zones name zones used 1219313598464 available 761203195904 # I use the above way to create easily parseable zfs_dataset objects. As for needing immediate/latest version of zfs list on entity creation -- you ideally want a way to do cache invalidation or use some sort of message/event driven system between the client that creates the entity and the server. You can perform the cache invalidation by monitoring the 'creation' events that come to your API, or by tailing zpool history [pool] for changes. - I recently read this article and they show a nice way to decouple the storage events and the api, architecture is not entirely new but can be adapted to your case. - https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb Thanks, Tenzin On Sun, Aug 13, 2017 at 2:25 PM, Eugene M. Zheganin wrote: > On 13.08.2017 16:13, Tenzin Lhakhang wrote: > >> You may want to have an async zfs-get program/script that regularly does >> a zfs get -Ho and stores then in a local cache (redis or your own program) >> at a set interval and then the api can hit the cache instead of directly >> running get or list. >> > I cannot because the cache will become stale on first new entity creation, > which happens all the time. > > - Some silly person will try to benchmark your zfs web-API and overload >> your server with zfs processes. >> - Example: let me run [ ab -c 10 -n 10000 http://yourserver/zfs-api/list >> ] >> -- Let me run 10 concurrent connection with a total of 10k requests to >> your api (it's a simple one liner -- people will be tempted to benchmark >> like this). >> >> Example: >> https://github.com/tlhakhan/ideal-potato/blob/master/zdux/ro >> uters/zfs/service.js#L9 >> - This is a JS example, but you can easily script it or another language >> (golang) for cache separation and another program for the API. >> >> Also, zfs does have a -c property to get cached values -- these values >> are stored in an internal zfs process cache. The -c doesn't help if you >> have 1000(0)s of filesystems, a single list can still take minutes. >> Sending the list is also several megabytes. >> > Doesn't have on FreeBSD. > > > > Thanks. > Eugene. > _______________________________________________ > 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 Mon Aug 14 12:58:09 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 E922ADC56BF for ; Mon, 14 Aug 2017 12:58:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 80B5D800B0 for ; Mon, 14 Aug 2017 12:58:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id v7ECvvNt040282 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 Aug 2017 08:57:57 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id v7ECvtjU088996; Mon, 14 Aug 2017 08:57:55 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: protecting zfs snapshot info To: Borja Marcos Cc: "freebsd-fs@freebsd.org" References: <52984307-2C6C-454C-A69B-15FB4AE01E1B@sarenet.es> From: Mike Tancsa Organization: Sentex Communications Message-ID: <5e3145ab-246a-f213-80b0-000dd801fbef@sentex.net> Date: Mon, 14 Aug 2017 08:57:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <52984307-2C6C-454C-A69B-15FB4AE01E1B@sarenet.es> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 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, 14 Aug 2017 12:58:10 -0000 On 8/14/2017 2:47 AM, Borja Marcos wrote: > >> On 12 Aug 2017, at 19:14, Mike Tancsa wrote: >> >> >> Is there a way in zfs to protect non root users from seeing snapshots ? >> lets say a user makes a permissions mistake on a sensitive homedirectory >> on a Monday AM that is not discovered until the next day. If there are >> a whole mess of snapshots created between those two points in time, >> there is no way to protect that directory without deleting the snapshots. > > Good question and it’s a problem indeed. The .zfs directory is always created > and it can be hidden but it’s still accessible. It’s a security problem that prevents > an effective access revocation for a directory/file, I guess that’s what you mean. Yes, something like an extra option hidden | visible | unmounted ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-fs@freebsd.org Tue Aug 15 12:21: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 7BCBFDD0650 for ; Tue, 15 Aug 2017 12:21:00 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F1716D0F5 for ; Tue, 15 Aug 2017 12:20:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id v7FCKqWa071776 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 15 Aug 2017 08:20:52 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id v7FCKoD9095065; Tue, 15 Aug 2017 08:20:50 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: protecting zfs snapshot info From: Mike Tancsa To: Borja Marcos Cc: "freebsd-fs@freebsd.org" References: <52984307-2C6C-454C-A69B-15FB4AE01E1B@sarenet.es> <5e3145ab-246a-f213-80b0-000dd801fbef@sentex.net> Organization: Sentex Communications Message-ID: Date: Tue, 15 Aug 2017 08:20:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5e3145ab-246a-f213-80b0-000dd801fbef@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 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, 15 Aug 2017 12:21:00 -0000 On 8/14/2017 8:57 AM, Mike Tancsa wrote: > On 8/14/2017 2:47 AM, Borja Marcos wrote: >> >>> On 12 Aug 2017, at 19:14, Mike Tancsa wrote: >>> >>> >>> Is there a way in zfs to protect non root users from seeing snapshots ? >> Good question and it’s a problem indeed. The .zfs directory is always created >> and it can be hidden but it’s still accessible. It’s a security problem that prevents >> an effective access revocation for a directory/file, I guess that’s what you mean. > > Yes, something like an extra option > hidden | visible | unmounted I did come across this thread https://github.com/zfsonlinux/zfs/issues/3963 but it seems Linux specific or at least I dont see how its done on FreeBSD. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-fs@freebsd.org Tue Aug 15 19:23: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 01096DC33C4 for ; Tue, 15 Aug 2017 19:23:41 +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 E39FC8065F for ; Tue, 15 Aug 2017 19:23:40 +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 v7FJNeZs070456 for ; Tue, 15 Aug 2017 19:23:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221501] [msdosfs] panic 11.0-RELEASE by mounting a malformed msdosfs image Date: Tue, 15 Aug 2017 19:23:41 +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 Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open 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: Tue, 15 Aug 2017 19:23:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221501 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 Tue Aug 15 19:28: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 107D0DC3C90 for ; Tue, 15 Aug 2017 19:28:13 +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 F2B7D80B7B for ; Tue, 15 Aug 2017 19:28:12 +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 v7FJSCDC078039 for ; Tue, 15 Aug 2017 19:28:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221480] [request] ZFS - Add zpool get ashift POOL function Date: Tue, 15 Aug 2017 19:28:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many 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 short_desc 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, 15 Aug 2017 19:28:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221480 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org Summary|ZFS - Add zpool get ashift |[request] ZFS - Add zpool |POOL function |get ashift POOL function --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Aug 15 19:31:10 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 50FF3DC4535 for ; Tue, 15 Aug 2017 19:31:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E8DD814FB for ; Tue, 15 Aug 2017 19:31:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7FJV93E086207 for ; Tue, 15 Aug 2017 19:31:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221408] "zpool online -e zroot mirror-2" - zpool tool crashes, core dumped Date: Tue, 15 Aug 2017 19:31:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many 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: Tue, 15 Aug 2017 19:31:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221408 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 Wed Aug 16 10:19: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 C6E95DD23B1 for ; Wed, 16 Aug 2017 10:19:38 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (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 8911F7CE92 for ; Wed, 16 Aug 2017 10:19:37 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.54] (unknown [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPA id DF53E9DC48A; Wed, 16 Aug 2017 12:12:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: protecting zfs snapshot info From: Borja Marcos In-Reply-To: Date: Wed, 16 Aug 2017 12:12:18 +0200 Cc: "freebsd-fs@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <003E0B0C-95C5-4D0B-91DB-393877480BDE@sarenet.es> References: <52984307-2C6C-454C-A69B-15FB4AE01E1B@sarenet.es> <5e3145ab-246a-f213-80b0-000dd801fbef@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.3273) 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, 16 Aug 2017 10:19:38 -0000 > On 15 Aug 2017, at 14:20, Mike Tancsa wrote: >=20 > On 8/14/2017 8:57 AM, Mike Tancsa wrote: >> On 8/14/2017 2:47 AM, Borja Marcos wrote: >>>=20 >>>> On 12 Aug 2017, at 19:14, Mike Tancsa wrote: >>>>=20 >>>>=20 >>>> Is there a way in zfs to protect non root users from seeing = snapshots ? >=20 >>> Good question and it=E2=80=99s a problem indeed. The .zfs directory = is always created >>> and it can be hidden but it=E2=80=99s still accessible. It=E2=80=99s = a security problem that prevents >>> an effective access revocation for a directory/file, I guess = that=E2=80=99s what you mean. >>=20 >> Yes, something like an extra option >> hidden | visible | unmounted >=20 > I did come across this thread >=20 > https://github.com/zfsonlinux/zfs/issues/3963 >=20 > but it seems Linux specific or at least I dont see how its done on = FreeBSD. Yes, it seems to be Linux specific and as far as I know there=E2=80=99s = no way to do it on FreeBSD right now. I would vouch for a third state added to the =E2=80=9Csnapdir=E2=80=9D = variable, but I wouldn=E2=80=99t call it =E2=80=9Cdisabled=E2=80=9D. = =E2=80=9Cunmounted=E2=80=9D or maybe =E2=80=9Cnoauto=E2=80=9D is much better in my opinion. The .zfs = directory should still be created (maybe hidden when in =E2=80=9Cnoauto=E2=80=9D state in order to prevent it from being = created by a user. I don=E2=80=99t think a new permission is needed to control that = variable, though. The =E2=80=9Csnapshot=E2=80=9D permission implies that =E2=80=9Cmount=E2=80=9D should be allowed as well at least = in the current versions. So it=E2=80=99s redundant. Or, actually, the =E2=80=9Cnoauto=E2=80=9D value for =E2=80=9Csnapdir=E2=80=9D= would eliminate the requirement for =E2=80=9Cmount=E2=80=9D = permissions.=20 I mean: Right now the =E2=80=9Csnapshot=E2=80=9D permission requires = =E2=80=9Cmount=E2=80=9D because the snapshot is mounted upon creation like it or not. If the snapshot was not automatically mounted thanks to = the =E2=80=9Cnoauto=E2=80=9D value for =E2=80=9Csnapdir=E2=80=9D it = would be possible to have a user authorized to manage snapshots but unable to = mount them. Given the very sensible nature of =E2=80=9Cmount=E2=80=9D in Unix it = makes sense.=20 Borja. From owner-freebsd-fs@freebsd.org Wed Aug 16 13:03: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 9B815DDACB6 for ; Wed, 16 Aug 2017 13:03:50 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F2BA82948; Wed, 16 Aug 2017 13:03:49 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id v7GD3h1Q023713 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Aug 2017 09:03:43 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.ca [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id v7GD3fcH000649; Wed, 16 Aug 2017 09:03:41 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: protecting zfs snapshot info To: Borja Marcos Cc: "freebsd-fs@freebsd.org" , Andriy Gapon References: <52984307-2C6C-454C-A69B-15FB4AE01E1B@sarenet.es> <5e3145ab-246a-f213-80b0-000dd801fbef@sentex.net> <003E0B0C-95C5-4D0B-91DB-393877480BDE@sarenet.es> From: Mike Tancsa Organization: Sentex Communications Message-ID: <2b83528d-55a0-7c40-c11d-d341f8f46e47@sentex.net> Date: Wed, 16 Aug 2017 09:03:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <003E0B0C-95C5-4D0B-91DB-393877480BDE@sarenet.es> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 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, 16 Aug 2017 13:03:50 -0000 cc'ing Andriy who knows a lot of ZFS... Andriy, is there any chance something like this is in the works in ZFS ? ---Mike On 8/16/2017 6:12 AM, Borja Marcos wrote: > >> On 15 Aug 2017, at 14:20, Mike Tancsa wrote: >> >> On 8/14/2017 8:57 AM, Mike Tancsa wrote: >>> On 8/14/2017 2:47 AM, Borja Marcos wrote: >>>> >>>>> On 12 Aug 2017, at 19:14, Mike Tancsa wrote: >>>>> >>>>> >>>>> Is there a way in zfs to protect non root users from seeing snapshots ? >> >>>> Good question and it’s a problem indeed. The .zfs directory is always created >>>> and it can be hidden but it’s still accessible. It’s a security problem that prevents >>>> an effective access revocation for a directory/file, I guess that’s what you mean. >>> >>> Yes, something like an extra option >>> hidden | visible | unmounted >> >> I did come across this thread >> >> https://github.com/zfsonlinux/zfs/issues/3963 >> >> but it seems Linux specific or at least I dont see how its done on FreeBSD. > > Yes, it seems to be Linux specific and as far as I know there’s no way to do it on FreeBSD right now. > > I would vouch for a third state added to the “snapdir” variable, but I wouldn’t call it “disabled”. “unmounted” or > maybe “noauto” is much better in my opinion. The .zfs directory should still be created (maybe hidden when > in “noauto” state in order to prevent it from being created by a user. > > I don’t think a new permission is needed to control that variable, though. The “snapshot” permission > implies that “mount” should be allowed as well at least in the current versions. So it’s redundant. Or, > actually, the “noauto” value for “snapdir” would eliminate the requirement for “mount” permissions. > > I mean: Right now the “snapshot” permission requires “mount” because the snapshot is mounted upon creation > like it or not. If the snapshot was not automatically mounted thanks to the “noauto” value for “snapdir” it would be > possible to have a user authorized to manage snapshots but unable to mount them. > > Given the very sensible nature of “mount” in Unix it makes sense. > > > > > > > > Borja. > > > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-fs@freebsd.org Thu Aug 17 10:24: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 05702DD9915 for ; Thu, 17 Aug 2017 10:24:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7F496B3E7 for ; Thu, 17 Aug 2017 10:24:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7HAO3DK018602 for ; Thu, 17 Aug 2017 10:24:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 164472] [ufs] fsck -B panics on particular data inconsistency Date: Thu, 17 Aug 2017 10:24:04 +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: 8.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: mckusick@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 10:24:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D164472 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |mckusick@FreeBSD.org CC| |eugen@freebsd.org --- Comment #8 from Eugene Grosbein --- It seems Kirk had some thoughts on the problem. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Aug 17 17:49:03 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 D41D1DCC6C3 for ; Thu, 17 Aug 2017 17:49:03 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (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 9671881C23; Thu, 17 Aug 2017 17:49:03 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 84-236-59-104.pool.digikabel.hu ([84.236.59.104] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1diOpA-000Jz7-Gp; Thu, 17 Aug 2017 17:43:16 +0000 To: ume@freebsd.org, freebsd-fs@freebsd.org From: Gergely Czuczy Subject: NFS-mounting directories with colons is tricky and undocumented Message-ID: Date: Thu, 17 Aug 2017 19:43:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 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, 17 Aug 2017 17:49:03 -0000 Hello, The other day I had a failure mounting a package directory to its build VM: mount_nfs: 10.219.14.254:/tank/packages/FreeBSD:12: hostname nor servname provided, or not known Genesys on efnet pointed me to r203490, which said: Introduce '[ipaddr]:path' notation. Since the existing implementation searches ':' backward, a path which includes ':' could not be mounted. You can now mount such path by enclosing an IP address by '[]'. Though we should change to search ':' forward, it will break 'ipv6addr:path' which is currently working. So, it still searches ':' backward, at least for now. Which provides way of doing it, however, I think a couple of improvements could be done: 1. Documentation is missing from mount_nfs(8) 2. Maybe it would worth improving the algorithm to something more effect, resulting in the expected behaviour: * A) Do a colon-forward search, skipping the part in []. With ipv6, that means the colons in the addresses are skipped due to the [] notation, then the first colon breaks the token, and starts the path * B) Stop looking for colons at the first slash. Hostnames and IP addresses are not allowed to contain slashes, and AFAIK the code doesn't have to deal with CIDR ranges. If possible, I would like task, whether the parsing code here could be improved to be more human-friendly, and work as it expected to? AFAIK ipv6 addresses are usually enclosed within [], while ipv4 addresses are not, and people are expecting such behavior from codes as well. And please, whatever happens to the parsing code, update the documentation. FreeBSD has a reputation for its good quality docs, and this corner case is totally not covered. Best regards, Gergely From owner-freebsd-fs@freebsd.org Fri Aug 18 09:11: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 4F67EDD3D8C; Fri, 18 Aug 2017 09:11:29 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 1411D7DB47; Fri, 18 Aug 2017 09:11:29 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-io0-x231.google.com with SMTP id j32so31133065iod.0; Fri, 18 Aug 2017 02:11:29 -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; bh=OCV2yTbK6sEVYZKoxEko+I53FvTkPqhWG6aALBG7Eac=; b=AgKkH6X78DKXXqMhCHvn0kmk4OEPZB64C+NdMC1N9DGYmSUtWL3fph1leb5mSAtBWi BSyNso9NMiEmfOkcvmbvD7W/X8Ch3oz+xA95QMDcjidEmc+DxvGBLsHBr6oLEfINv0Ub 4GbFw5yGjY5PFRYI7H4TECHGinA9SX89XH0HWWmEvD68zj5UfTWHZypxTky4dkahRV4K Ym6lBV01/fHtIOililFErPhL8B5gggnVXQYRv7FLXKPa2S/w9RVcesvCNDYKFxibHUqL G9Y/GvHHpmRdq+1L3o1/aTCtZuaYQt4esjyO+tZYGl3ijwPMiWt1HsO1k/+RhOso/NX3 X7Og== 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; bh=OCV2yTbK6sEVYZKoxEko+I53FvTkPqhWG6aALBG7Eac=; b=JzyAakZ3Zb392+Hj7nJ+++UIavdF23QtaO0MFEVLFCZhskN1EusX5+B4VY8Wwncpgr FZDZ13dsSKsX2his6NOawEdLtdmz6O3Tva0PEvuKkGmP8G8Ga4YrAHIX53mfgg7hn7Jm Qr0x2mkU8x/eW2kNQ/aTP66reZTHBE/hpGELwTas/HoGJOCEwXtv9aUFi3AQHR1Lg9iM ifl9QcGT0+k7Ip4ydBs3qM4lMUfu8nsfRuS4nQRgUqWVX4yuKw5yvHtUcg73gPcRI1hz jJTR7uv4aFPTGsPhV6VIeAjRsX8eoa1PIpOwQ2kK9mIxDNDaOWiwQPJV4OJFL5mRZNte 9PvQ== X-Gm-Message-State: AHYfb5jFPyU4L4AwtfSNN7z6h8kwlOigYjCUW4NtChjC2FNB6DQRvo39 45SQB0Tip4v+sVKj1Q0v+BxiX93TWY9u X-Received: by 10.107.50.77 with SMTP id y74mr7052996ioy.150.1503047488028; Fri, 18 Aug 2017 02:11:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.133.174 with HTTP; Fri, 18 Aug 2017 02:11:27 -0700 (PDT) Received: by 10.2.133.174 with HTTP; Fri, 18 Aug 2017 02:11:27 -0700 (PDT) In-Reply-To: References: From: Sami Halabi Date: Fri, 18 Aug 2017 12:11:27 +0300 Message-ID: Subject: recommendations for file server based zfs appliance To: freebsd-fs@freebsd.org, freebsd-stable@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: Fri, 18 Aug 2017 09:11:29 -0000 Hi all, I am planning to use zfs appliance for backup purposes, do you have reccomenations for small box with 4-16 gb ram ecc, and 4 hard drives sas/sata. Thanks in advance, Sami From owner-freebsd-fs@freebsd.org Fri Aug 18 09:17:07 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 3F75EDD439F for ; Fri, 18 Aug 2017 09:17:07 +0000 (UTC) (envelope-from michael@fuckner.net) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D22D17DFB5 for ; Fri, 18 Aug 2017 09:17:06 +0000 (UTC) (envelope-from michael@fuckner.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1503047824; l=277; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Language:Content-Type:In-Reply-To: MIME-Version:Date:From:References:To:Subject; bh=DsxAGgLfG6WCtNfYvlOq3MSPDUIDxIeiPZzYxUSo2kQ=; b=hAEjb8u1QWkit2V2sfdVPM6jHC3SJO5JmpwHd7/nfphZWOiqEhAO4MXy6dmQKDSmRp DHdux9T+4DbLgjaU8hXgx5SNKlCdMrkb0wa2Z0UQmeRK4U2jiMFtxavlzph5HYco1BtL N2S8ePvoAs1L56v7NI2vsDOJgQPQqAKndYqCU= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgkm8tkNJEfjVsisSlUtpvg== X-RZG-CLASS-ID: mo00 Received: from fuckner.delnet (static-213-209-125-98.business-customer.wtnet.de [213.209.125.98]) by smtp.strato.de (RZmta 41.2 DYNA|AUTH) with ESMTPA id h07bedt7I9H4JKl for ; Fri, 18 Aug 2017 11:17:04 +0200 (CEST) Subject: Re: recommendations for file server based zfs appliance To: freebsd-fs@freebsd.org References: From: Michael Fuckner Message-ID: <3ac05ca0-8460-78a0-9282-4e0d52e296eb@fuckner.net> Date: Fri, 18 Aug 2017 11:17:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 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-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, 18 Aug 2017 09:17:07 -0000 On 08/18/2017 11:11 AM, Sami Halabi wrote: > Hi all, > > I am planning to use zfs appliance for backup purposes, do you have > reccomenations for small box with 4-16 gb ram ecc, and 4 hard drives > sas/sata. HP Microserver Gen8 (G1610T) is quite cheap at the moment From owner-freebsd-fs@freebsd.org Fri Aug 18 09:21: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 9C524DD4689; Fri, 18 Aug 2017 09:21:16 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 509867E33B; Fri, 18 Aug 2017 09:21:16 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-vk0-x230.google.com with SMTP id u133so30391035vke.3; Fri, 18 Aug 2017 02:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gyfa2xal0v20WLLKH0Xc/m8ifPSt61+Knt+sOzxWOWg=; b=A4KoOq9+f/Y8K+YVsVPHm5H30tiQVUp7h0ei4fk6woOlv+CfVWfj1iNMHuO4vsxGh7 TqbWjexLtHMCa/w+8/3E32k2LdmUH8c7lfu46yGBlRp4R0iYiK+DuvJhvu/ygJiZOADH 1OZBpcwPDWDgQfACeJCqvwl3Zn5Lcha0gIHfToFno4LiubxoOIMd9enz+AaobezrCngb DVIDzWh3Kxk1pn29+AqgnhvGiZJfvns36Oqczt+71a/VpkiOhvYz738FlpD3mlA+wkIm PVcmvD7c/7zv5xjr27cDwrkv8wozjwZ+kCHRlOSQBmC4jGzJFwMUj+/meFwp0Y11l0Jy oVYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=gyfa2xal0v20WLLKH0Xc/m8ifPSt61+Knt+sOzxWOWg=; b=h5a+wcLiYhKdkHQGZiaCUTX+hZsDw3empp2TCAuAysXRpz1O2N7R9x/B9epkwzMw8g WUk4AdXy5C9wkE9J+W9xJ0gS5JZZjvPAhPrsqcET/HNqX1enPbqy9DuiH6nEqhi3SeGM /qQjyeOmnfE16DgzeGOet0tn0TC2f33uGLwReFZypl8ZqGLDmaoxiM7Sl3uwMXtZwvF7 xq7aujx/aIRT23+2wW3Tu0ri8Oj6ns9QmBVG7O5ttKLu6QENti266KDrZCcACsvo78BM O9Y4bGX9BEvZahX/3mcbFlx7iF+tl25qwPxt08a9qHg9UyKipfej9WWR9DPp2keud6yc KXRg== X-Gm-Message-State: AHYfb5gaFpxfreWTPGYIq0ZuD6MXkwpKt8icg3NyYtUUKnmYdCA+awxF DAgUgGCLqAMadtKpCJiuA2ouSgOkHA== X-Received: by 10.31.218.133 with SMTP id r127mr5138031vkg.104.1503048075365; Fri, 18 Aug 2017 02:21:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.17.214 with HTTP; Fri, 18 Aug 2017 02:21:14 -0700 (PDT) Reply-To: araujo@freebsd.org In-Reply-To: References: From: Marcelo Araujo Date: Fri, 18 Aug 2017 17:21:14 +0800 Message-ID: Subject: Re: recommendations for file server based zfs appliance To: Sami Halabi Cc: "freebsd-fs@freebsd.org" , FreeBSD-STABLE Mailing List 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: Fri, 18 Aug 2017 09:21:16 -0000 2017-08-18 17:11 GMT+08:00 Sami Halabi : > Hi all, > > I am planning to use zfs appliance for backup purposes, do you have > reccomenations for small box with 4-16 gb ram ecc, and 4 hard drives > sas/sata. > > Thanks in advance, > Sami > Take a look at iXsystems, they have a nice FreeNAS-Mini. Best, -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-fs@freebsd.org Fri Aug 18 14:01:06 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 4CC41DE344B for ; Fri, 18 Aug 2017 14:01:06 +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 3B6CC641DC for ; Fri, 18 Aug 2017 14:01:06 +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 v7IE15BT002328 for ; Fri, 18 Aug 2017 14:01:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221570] lock order reversal fs_mount.c:1271, msdosfs_vfsops.c:928 Date: Fri, 18 Aug 2017 14:01:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects 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: 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: Fri, 18 Aug 2017 14:01:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221570 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 Fri Aug 18 21:52:15 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 34A04DDA207 for ; Fri, 18 Aug 2017 21:52:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670088.outbound.protection.outlook.com [40.107.67.88]) (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 D9643774AE for ; Fri, 18 Aug 2017 21:52:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0223.CANPRD01.PROD.OUTLOOK.COM (10.165.218.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Fri, 18 Aug 2017 21:52:12 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1362.019; Fri, 18 Aug 2017 21:52:12 +0000 From: Rick Macklem To: "freebsd-fs@freebsd.org" Subject: when has a pNFS data server failed? Thread-Topic: when has a pNFS data server failed? Thread-Index: AQHTGGwqSs0WOO4N5Uy/bwL72vYOsA== Date: Fri, 18 Aug 2017 21:52:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0223; 6:UFWqtINnoSqo0GhFMnU9Nnm4WHKOTKHdrDo5Qh/CtVc++9nAvj5FhAQu3FerXQt8dDB792tuDeGuWJNYLVYZ3KCfCo0KjI86QmNW9b1BssnnxELZkPNDmDYh2ik3Yo6K30FeDelqx6J7VPqd3cTsg03j59L9HG+wfDVHPh+HDRutMXuc5b7t+L2GSsrlf7U11Z4vcgvAg4kkp7nmOfbLiWFsxRmUzaYnexSgTH+7oJoGvwEXnkXuJcvvf3YZZ9wcUioSU1N3ATGRn/IcW58oyDpNlQvvz5Fb2VY2869iCiP/pQy15/OvdGpNUJXHODsLWXL9mz89Vx4AofOWnSnduA==; 5:3krAhmBQA5xk5rAIWFvYb8B21QNFhxXzy75L+JqticBiAGH1Yt+H6aa32QD7tcZNQOac4UWkKTVtd7C2atSOc/ZD2GiMZaVvQS1fdX/x7gjjZHcVsuJSq/ysP9/xqlgWQ1SnqRJqucT/HVw0Twjb8w==; 24:GshqcJ+pf0x0T22jnLENxvQzbiCj21xQEmYy5/r/zmb3kE6W1ILjxm5CHIjiBkCJDveBlhuYIbYpM0VaWHFVM8Ex7nXPfqEkyTN1698L47k=; 7:sSxiEyGcrOxZq3h2Jg0e3f0xxR79s9o+OyLizmBtd3JNMBn3zwuxtVHB1ixSYuWSJwebEnAL05EQOjxefMA6ZfbwbH/yaItiEgIYP9x2xhj7MXjZSNvv8O+J3vH2LS0NsnmK4LEeChc4SRjoVKTRF9I/LgcrkLeolVRfAsxtR1ePU+eDsNrghlCn+SGRlTX5RBUjOsFs4wFJy3mL0nvEbyTOTgIujPslfhaN2kdS2M0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 701494ea-b3e8-46ca-747d-08d4e68361ff x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:YTXPR01MB0223; x-ms-traffictypediagnostic: YTXPR01MB0223: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YTXPR01MB0223; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YTXPR01MB0223; x-forefront-prvs: 040359335D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(68736007)(189998001)(5660300001)(74482002)(54356999)(50986999)(2900100001)(478600001)(25786009)(101416001)(7696004)(8936002)(305945005)(8676002)(81156014)(81166006)(966005)(2906002)(74316002)(14454004)(6436002)(102836003)(2351001)(3280700002)(77096006)(6506006)(86362001)(6916009)(97736004)(55016002)(2501003)(53936002)(110136004)(5640700003)(3660700001)(105586002)(106356001)(9686003)(6306002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0223; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2017 21:52:12.4224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0223 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, 18 Aug 2017 21:52:15 -0000 This is kind of a "big picture" question that I thought I 'd throw out. As a brief background, I now have the code for running mirrored pNFS Data S= ervers working for normal operation. You can look at: http://people.freebsd.org/~rmacklem/pnfs-planb-setup.txt if you are interested in details related to the pNFS server code/testing. So, now I am facing the interesting part: 1 - The Metadata Server (MDS) needs to decide that a mirrored DS has failed= at some point. Once that happens, it stops using the DS, etc. --> This brings me to the question of "when should the MDS decide that the = DS has failed and should be taken offline?". - I'm not up to date w.r.t. the TCP stack, so I'm not sure how long i= t will take for the TCP connection to decide that a DS server is no longer working and = fail the TCP connection. I think it takes a fair amount of time, so I'm not sure= if TCP connection loss is a good indicator of DS server failure or not? - It seems to me that the MDS should wait a fairly long time before fai= ling the DS, since this will have a major impact on the pNFS server, requiring rep= air/resilvering by a sysadmin once it happens. So, any comments or thoughts on this? rick From owner-freebsd-fs@freebsd.org Sat Aug 19 00:59:45 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 553F2DE5069 for ; Sat, 19 Aug 2017 00:59:45 +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 4388C810B6 for ; Sat, 19 Aug 2017 00:59:45 +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 v7J0xjNW080588 for ; Sat, 19 Aug 2017 00:59:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204055] [patch] zfs(8) should not yet list sha512, skein and edonr as supported hash algorithms Date: Sat, 19 Aug 2017 00:59:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: allanjude@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 00:59:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204055 --- Comment #1 from Allan Jude --- sha512 and skein are supported. edon-r is not. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Aug 19 01:22:08 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 DA619DE69F5 for ; Sat, 19 Aug 2017 01:22:08 +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 C5BD58225A for ; Sat, 19 Aug 2017 01:22:08 +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 v7J1M8Zi063111 for ; Sat, 19 Aug 2017 01:22:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221188] zfs: bin/chmod/chmod_test:v_flag fails on ZFS, not UFS (ZFS updates mode for files unnecessarily) Date: Sat, 19 Aug 2017 01:22:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:22:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221188 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: ngie Date: Sat Aug 19 01:21:46 UTC 2017 New revision: 322685 URL: https://svnweb.freebsd.org/changeset/base/322685 Log: MFC r321949,r321950,r322101: r321949: Add expected failures for ZFS - :f_flag fails on ZFS because UF_IMMUTABLE isn't supported [1]. - :v_flag fails on ZFS because the mode for foo is [always] updated unnecessarily. get_filesystem(..) (supporting function that was added to the test script) is based on equivalent logic in usr.bin/extattr/tests/extattr_test.sh . PR: 221189 [1], 221188 [2] r321950: Always use first parameter passed to get_filesystem(..) instead of discar= ding it and using `.` instead. MFC with: r321949 PR: 221189 [1], 221188 [2] r322101: Don't check result of chflags in f_flag_cleanup() This will prevent false positives from occurring if the test is run on ZFS since ZFS doesn't support fflags throbbing like UFS. PR: 221189 MFC with: r321949 Changes: _U stable/11/ stable/11/bin/chmod/tests/chmod_test.sh --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Aug 19 01:22:10 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 74903DE69FE for ; Sat, 19 Aug 2017 01:22:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FCB182269 for ; Sat, 19 Aug 2017 01:22:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v7J1MAJs063132 for ; Sat, 19 Aug 2017 01:22:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221189] zfs: bin/chmod/chmod_test:f_flag fails on ZFS, not UFS; UF_IMMUTABLE not supported on ZFS Date: Sat, 19 Aug 2017 01:22:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:22:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221189 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: ngie Date: Sat Aug 19 01:21:47 UTC 2017 New revision: 322685 URL: https://svnweb.freebsd.org/changeset/base/322685 Log: MFC r321949,r321950,r322101: r321949: Add expected failures for ZFS - :f_flag fails on ZFS because UF_IMMUTABLE isn't supported [1]. - :v_flag fails on ZFS because the mode for foo is [always] updated unnecessarily. get_filesystem(..) (supporting function that was added to the test script) is based on equivalent logic in usr.bin/extattr/tests/extattr_test.sh . PR: 221189 [1], 221188 [2] r321950: Always use first parameter passed to get_filesystem(..) instead of discar= ding it and using `.` instead. MFC with: r321949 PR: 221189 [1], 221188 [2] r322101: Don't check result of chflags in f_flag_cleanup() This will prevent false positives from occurring if the test is run on ZFS since ZFS doesn't support fflags throbbing like UFS. PR: 221189 MFC with: r321949 Changes: _U stable/11/ stable/11/bin/chmod/tests/chmod_test.sh --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Aug 19 01:22:14 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 18DA3DE6A0E for ; Sat, 19 Aug 2017 01:22:14 +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 073A882282 for ; Sat, 19 Aug 2017 01:22:14 +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 v7J1MDZI063269 for ; Sat, 19 Aug 2017 01:22:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221189] zfs: bin/chmod/chmod_test:f_flag fails on ZFS, not UFS; UF_IMMUTABLE not supported on ZFS Date: Sat, 19 Aug 2017 01:22:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:22:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221189 --- Comment #8 from commit-hook@freebsd.org --- A commit references this bug: Author: ngie Date: Sat Aug 19 01:21:47 UTC 2017 New revision: 322685 URL: https://svnweb.freebsd.org/changeset/base/322685 Log: MFC r321949,r321950,r322101: r321949: Add expected failures for ZFS - :f_flag fails on ZFS because UF_IMMUTABLE isn't supported [1]. - :v_flag fails on ZFS because the mode for foo is [always] updated unnecessarily. get_filesystem(..) (supporting function that was added to the test script) is based on equivalent logic in usr.bin/extattr/tests/extattr_test.sh . PR: 221189 [1], 221188 [2] r321950: Always use first parameter passed to get_filesystem(..) instead of discar= ding it and using `.` instead. MFC with: r321949 PR: 221189 [1], 221188 [2] r322101: Don't check result of chflags in f_flag_cleanup() This will prevent false positives from occurring if the test is run on ZFS since ZFS doesn't support fflags throbbing like UFS. PR: 221189 MFC with: r321949 Changes: _U stable/11/ stable/11/bin/chmod/tests/chmod_test.sh --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Aug 19 01:22:12 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 4F5E6DE6A0B for ; Sat, 19 Aug 2017 01:22:12 +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 3DD1782276 for ; Sat, 19 Aug 2017 01:22:12 +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 v7J1MBht063168 for ; Sat, 19 Aug 2017 01:22:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221188] zfs: bin/chmod/chmod_test:v_flag fails on ZFS, not UFS (ZFS updates mode for files unnecessarily) Date: Sat, 19 Aug 2017 01:22:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:22:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221188 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: ngie Date: Sat Aug 19 01:21:47 UTC 2017 New revision: 322685 URL: https://svnweb.freebsd.org/changeset/base/322685 Log: MFC r321949,r321950,r322101: r321949: Add expected failures for ZFS - :f_flag fails on ZFS because UF_IMMUTABLE isn't supported [1]. - :v_flag fails on ZFS because the mode for foo is [always] updated unnecessarily. get_filesystem(..) (supporting function that was added to the test script) is based on equivalent logic in usr.bin/extattr/tests/extattr_test.sh . PR: 221189 [1], 221188 [2] r321950: Always use first parameter passed to get_filesystem(..) instead of discar= ding it and using `.` instead. MFC with: r321949 PR: 221189 [1], 221188 [2] r322101: Don't check result of chflags in f_flag_cleanup() This will prevent false positives from occurring if the test is run on ZFS since ZFS doesn't support fflags throbbing like UFS. PR: 221189 MFC with: r321949 Changes: _U stable/11/ stable/11/bin/chmod/tests/chmod_test.sh --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Aug 19 01:22:06 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 ED4FFDE69F0 for ; Sat, 19 Aug 2017 01:22:06 +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 DB54F82246 for ; Sat, 19 Aug 2017 01:22:06 +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 v7J1M6al062351 for ; Sat, 19 Aug 2017 01:22:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221189] zfs: bin/chmod/chmod_test:f_flag fails on ZFS, not UFS; UF_IMMUTABLE not supported on ZFS Date: Sat, 19 Aug 2017 01:22:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:22:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221189 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: ngie Date: Sat Aug 19 01:21:46 UTC 2017 New revision: 322685 URL: https://svnweb.freebsd.org/changeset/base/322685 Log: MFC r321949,r321950,r322101: r321949: Add expected failures for ZFS - :f_flag fails on ZFS because UF_IMMUTABLE isn't supported [1]. - :v_flag fails on ZFS because the mode for foo is [always] updated unnecessarily. get_filesystem(..) (supporting function that was added to the test script) is based on equivalent logic in usr.bin/extattr/tests/extattr_test.sh . PR: 221189 [1], 221188 [2] r321950: Always use first parameter passed to get_filesystem(..) instead of discar= ding it and using `.` instead. MFC with: r321949 PR: 221189 [1], 221188 [2] r322101: Don't check result of chflags in f_flag_cleanup() This will prevent false positives from occurring if the test is run on ZFS since ZFS doesn't support fflags throbbing like UFS. PR: 221189 MFC with: r321949 Changes: _U stable/11/ stable/11/bin/chmod/tests/chmod_test.sh --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Aug 19 03:31:18 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 DED4DDC8FBB for ; Sat, 19 Aug 2017 03:31:18 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CF4E2FF7 for ; Sat, 19 Aug 2017 03:31:18 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]) (authenticated bits=0) by hydra.pix.net (8.16.0.19/8.15.2) with ESMTPSA id v7J3V7lK019037 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 18 Aug 2017 23:31:15 -0400 (EDT) (envelope-from cross+freebsd@distal.com) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.15.2/8.15.2) with ESMTPSA id v7J3V2M7038641 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Aug 2017 23:31:04 -0400 (EDT) (envelope-from cross+freebsd@distal.com) From: Chris Ross Content-Type: multipart/signed; boundary="Apple-Mail=_D603767F-7050-43CF-9222-ECBF7F44304E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: zfs recv went idle after 20+ hours Date: Fri, 18 Aug 2017 23:30:49 -0400 Message-Id: <4BCBA5DE-6AC7-4B0A-BF33-CFFE5A54B2DF@distal.com> To: FreeBSD FS Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]); Fri, 18 Aug 2017 23:31:04 -0400 (EDT) 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, 19 Aug 2017 03:31:19 -0000 --Apple-Mail=_D603767F-7050-43CF-9222-ECBF7F44304E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =46rom earlier posts on this list, many know I was dealing with an = issue on a zfs pool. I eventually got it running in an off way, and = backed it up (via zfs send to a file in UFS). I then destroyed and = recreated the pool as I wanted it. For the last 23 hours or so, I=E2=80=99= ve been running a =E2=80=9Czfs recv=E2=80=9D from the large send output = (~5.2T). It was cooking along, more slowly than I=E2=80=99d expected, = but moving. I looked in on it a short while ago, and the pv I=E2=80=99m using on = the input file was reporting 0.0 B/s, 77% complete. Looking at the = iostat I had running, I could see the raidz disks still seeing activity, = but less than a minute later that stopped. Now, all disks on the system = seem idle. The =E2=80=9Czfs recv=E2=80=9D process is idle according to = ps (STAT I+), and a ktrace on the zfs process shows no activity either. = The window in which I was running the commands look as follows: cross@hyrule[~](511): zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH = ALTROOT tank 18.8T 949K 18.8T - 0% 0% 1.00x ONLINE - zroot 50.5G 34.7G 15.8G - 55% 68% 1.00x ONLINE - cross@hyrule[~](512): pv /mnt/tank@20170815| sudo zfs recv -Fvu tank receiving full stream of tank@20170815 into tank@20170815 received 46.3KB stream in 1 seconds (46.3KB/sec) receiving full stream of tank/deluge@20170815 into tank/deluge@20170815 received 2.87TB stream in 45452 seconds (66.3MB/sec) ] 55% ETA = 10:18:14 receiving full stream of tank/timecapsule@20170815 into = tank/timecapsule@20170815 3.99TiB 22:54:18 [0.00 B/s] [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D> ] 76% ETA 7:04:49 The time-of-day and ETA value keep increasing, but other than that, = it=E2=80=99s just sitting. zfs list shows: hyrule# zfs list -t all | grep tank tank 3.89T 8.28T 73.3K none tank@20170815 0 - 73.3K - tank/deluge 2.86T 8.28T 2.86T /data/deluge tank/deluge@20170815 0 - 2.86T - tank/timecapsule 1024G 8.28T 1024G /data/timecapsule I=E2=80=99m going to leave it this way for a while, but it=E2=80=99s = already been about 10 minutes since it started, so I don=E2=80=99t = expect that it will free itself. Does anyone have a suggestion, or = something I should look at? Did I do something wrong? Thanks=E2=80=A6 - Chris --Apple-Mail=_D603767F-7050-43CF-9222-ECBF7F44304E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZl7D1AAoJEPFBDnXvoNg0As4P/igPoDSY1uGES5wStQFxc8Tx /0hDp0UlIbXruU1CF1j15rFIpu/SVzT8HU8sXF8ie+RCs8ZVzFAqa5p5zpO5LKVb YAFzUiXjXLK+LNDfS4TWMV546ayAy4uYnQZB+xaXQpzg6D+Z6GwdtLAbNtl5Y1vV jiPyqncVecVWHPHumAtkx3jsGKT8TJvoeifR1Z7ARsmS9ry4Lcc8sA6HcpT2azc2 b8pCfF5Uqrpt+EaDi8VSIyZz1ghFwwBTEboeIqYwEOuzSEFoMJppsw8YI5cJjZzZ i9yeUUn0EtGx4UvYOmaUiFaOABxGooa6EIfguFtsyizeUiIcadzW7GhN+b+JHQhk skYwV+pwaC+0HQqsrcv5WA3hkM17OLSeUDn+cMv7X1Sb1kDjd3fmdWlJw0lhS2sN tckVXSXsGuWkjT/942KyB1T7umSRaxyD39wd8c17E+3wyypH/BLHDla07CdxPpen R4NqzLnNLAAJb3+z50ui5427p2dBUVqU+LeoxWiXGvCwYycj1tJC2IMPyY7h30Jc Oatu6Nv74T4u+QmbWKBgpEvvxVwNsQA3YFQUlYTxudio3fzS1bhVCo5LWjOiHdXX 2xgidVBo++0s4HbARuK2ACMP74SLWWTddwXhqye54/pe+hMeMqlSgNjUcKWRO49W qpJ9xARJdg0XWGge/ecT =H4Dg -----END PGP SIGNATURE----- --Apple-Mail=_D603767F-7050-43CF-9222-ECBF7F44304E--