From owner-freebsd-fs@freebsd.org Mon Jul 27 13:47:18 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B23BE3626DC for ; Mon, 27 Jul 2020 13:47:18 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail1.yamagi.org (mail1.yamagi.org [IPv6:2001:19f0:b001:853::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BFh1x6C3kz3VRc; Mon, 27 Jul 2020 13:47:17 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from [212.48.125.108] (helo=aka.server.knhmn.de) by mail1.yamagi.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1k03T7-0004y1-VO; Mon, 27 Jul 2020 15:47:11 +0200 Date: Mon, 27 Jul 2020 15:46:51 +0200 From: Yamagi To: mmacy@freebsd.org Cc: freebsd-fs@freebsd.org Subject: Re: CFT for vendor openzfs - week 3 reminder Message-Id: <20200727154651.37a7c23e711da9218cee61dd@yamagi.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Mon__27_Jul_2020_15_46_51_+0200_yqgiOGuJ8.4PycJZ" X-Rspamd-Queue-Id: 4BFh1x6C3kz3VRc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@yamagi.org designates 2001:19f0:b001:853::3 as permitted sender) smtp.mailfrom=lists@yamagi.org X-Spamd-Result: default: False [-1.59 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[yamagi.org]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.96)[-0.963]; NEURAL_HAM_MEDIUM(-0.87)[-0.866]; NEURAL_SPAM_SHORT(0.14)[0.142]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:b000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 13:47:18 -0000 --Signature=_Mon__27_Jul_2020_15_46_51_+0200_yqgiOGuJ8.4PycJZ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've tested the merge candidate for some days on our PostgreSQL and MariaDB servers. But only on replication followers (slaves), not the leaders (masters). I haven't seen any problems, on the opposite: The problems with scattered ARC buffers are finally gone. See [0] for details. One small nit, though. I'm unable to delegate datasets to jails: % zfs create system/data/test % jls JID IP Address Hostname Path 1 10.42.11.5 portaldb-test.XXX.de /data/jails/portaldb-test % zfs jail 1 system/data/test internal error: Inappropriate ioctl for device zsh: abort (core dumped) zfs jail 1 system/data/test Regards, Yamagi 0: https://lists.freebsd.org/pipermail/freebsd-fs/2018-August/026612.html On Mon, 20 Jul 2020 15:56:20 -0700 Matthew Macy wrote: > On Wednesday, July 8th I issued the initial call for testing for the > update to HEAD to vendored openzfs. We'd like to give users roughly a > month to test before merging. I'm pushing the tentative merge date out > by a week to August 17th as I wasn't able to spend any time working on > this myself last week. >=20 > Again, I hope it's not terribly controversial to point out that > it really rests with users of non amd64 platforms to test to avoid any > unpleasant surprises the next time they update their trees following > the merge. --=20 Homepage: https://www.yamagi.org Github: https://github.com/yamagi GPG: 0x1D502515 --Signature=_Mon__27_Jul_2020_15_46_51_+0200_yqgiOGuJ8.4PycJZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEOXu/lxyufwz0gC5x6xRy5x1QJRUFAl8e2ssACgkQ6xRy5x1Q JRX0tg/+PVVC+b+nWIwz8m2o/Nsrf7Ocp6grasmlLStEEV3HMAvFwYpNjaJkrc/v RvRrxoi6g0GoZkRr/GS/aolxPzfzz2feSksFILPzMFFg4a6LNWB3nOOb3t86tmTR KfSAVynu0inlq6Hb8Rc3vjKpwBRkn5T65Gp/2BDVhxjkXi8G63DTylDZ5vLUfL3x avi10ex1xFGysXXGSAJTxdtHn27YSsEgBe38iA6r3pdwEfYBm/mMIlytXGFAH3sT cfUCkQowHGAQaW9t23ayOc02Hlxwz0g/jcEbmfaimmP86YBaIqHXsHXZxwOKhDWK q8rO+JDYdYW3N4ZN8Fiq8bjOV45UU9tNpistrPNs4wHSUWg9Eh8qCQKxIJRaBpdp l7eI4UUayaHD8g3H5rFMeRZijOafc5JO3S8OIVWqPQkfsX/EUBfaYPXwABsb2aTV pQ8TxlZ4DAT40FfV4ktUfgz2oY4tYkXmBNEaoQK4qoLk/5rtIvRgguP1qV6M4/QD AaF1IeY18PHOtGXeGcmoqvcIeYyBvFbZ3CljnHE2d0x2BF/kwjL8UwPYXKsH45gC JcvdpX5lsfAfq0TszCPVyDgXfVDLLKDtUwW6ktwVfrTsLsRR9z+bBDJzBMoxdjqU 35jGc+4yisMPXX8AFlmzg2g3A/sJaQZSChncv0m46F8pTTW62q4= =Uk9u -----END PGP SIGNATURE----- --Signature=_Mon__27_Jul_2020_15_46_51_+0200_yqgiOGuJ8.4PycJZ-- From owner-freebsd-fs@freebsd.org Wed Jul 29 01:33:52 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B6A36379A80 for ; Wed, 29 Jul 2020 01:33:52 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BGbfm4V3cz473N for ; Wed, 29 Jul 2020 01:33:52 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 7633E2ED8D for ; Wed, 29 Jul 2020 01:33:52 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lf1-f44.google.com with SMTP id h8so12062789lfp.9 for ; Tue, 28 Jul 2020 18:33:52 -0700 (PDT) X-Gm-Message-State: AOAM533Nx3ivLwmcHqJcawfORg6NQgNRUMvgTOHVqx+0kKnw2EtOU4eV 7HTK8OC6lT1kgg3lDbCQmjNBEbooXt1rxYJYJz4= X-Google-Smtp-Source: ABdhPJyVFk1v7DQVKheqJJw6Rtf/bfRRLwsXm3QbPPdqAZMZTw5jkNGKd6PG+FlqwxQ8bXHdSq2LWWE4gIa0EYZ/AXo= X-Received: by 2002:a05:6512:5c5:: with SMTP id o5mr16010943lfo.26.1595986431084; Tue, 28 Jul 2020 18:33:51 -0700 (PDT) MIME-Version: 1.0 References: <20200727154651.37a7c23e711da9218cee61dd@yamagi.org> In-Reply-To: <20200727154651.37a7c23e711da9218cee61dd@yamagi.org> From: Matthew Macy Date: Tue, 28 Jul 2020 18:33:39 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CFT for vendor openzfs - week 3 reminder To: Yamagi Cc: freebsd-fs Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 01:33:52 -0000 > % zfs create system/data/test > % jls > JID IP Address Hostname Path > 1 10.42.11.5 portaldb-test.XXX.de /data/jails/portaldb-test > % zfs jail 1 system/data/test > internal error: Inappropriate ioctl for device > zsh: abort (core dumped) zfs jail 1 system/data/test > My guess is that this is the same problem I was seeing with the DTRACEIOC_PROVIDER ioctl that was causing dtrace to fail. I had defined zoneid_t to be 8 bytes in openzfs - but it was defined as 4 bytes in userland which was causing the switch statement to fall through. I fixed this on Tuesday or Wednesday last week. If it's still an issue I will fix. -M > Regards, > Yamagi > > 0: > https://lists.freebsd.org/pipermail/freebsd-fs/2018-August/026612.html > > On Mon, 20 Jul 2020 15:56:20 -0700 > Matthew Macy wrote: > > > On Wednesday, July 8th I issued the initial call for testing for the > > update to HEAD to vendored openzfs. We'd like to give users roughly a > > month to test before merging. I'm pushing the tentative merge date out > > by a week to August 17th as I wasn't able to spend any time working on > > this myself last week. > > > > Again, I hope it's not terribly controversial to point out that > > it really rests with users of non amd64 platforms to test to avoid any > > unpleasant surprises the next time they update their trees following > > the merge. > > -- > Homepage: https://www.yamagi.org > Github: https://github.com/yamagi > GPG: 0x1D502515 From owner-freebsd-fs@freebsd.org Wed Jul 29 02:10:48 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 23AB8379AD3; Wed, 29 Jul 2020 02:10:48 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BGcTN08dXz48J2; Wed, 29 Jul 2020 02:10:48 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id DC3A62F193; Wed, 29 Jul 2020 02:10:47 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lf1-f54.google.com with SMTP id k13so12147050lfo.0; Tue, 28 Jul 2020 19:10:47 -0700 (PDT) X-Gm-Message-State: AOAM530Wa5MbpiJ7n0IVhrPQo9LShY/yyoForlAnch7MXXPqIGv3EPdx nxkSNYBKY7Uo+aLqPVpBnpIAQKJorIbGMIIr6CA= X-Google-Smtp-Source: ABdhPJyWhvSSSw2xQUXvTbic0iYkMxzoa1Spvhmervj0vxambAont5ojg82/jZ/ztPncgQwxHYJGjrVNiZwDkTSVK+8= X-Received: by 2002:a05:6512:14d:: with SMTP id m13mr15980129lfo.173.1595988646167; Tue, 28 Jul 2020 19:10:46 -0700 (PDT) MIME-Version: 1.0 From: Matthew Macy Date: Tue, 28 Jul 2020 19:10:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: CFT for vendor openzfs - week 4 reminder + memdisk images To: freebsd-fs , freebsd-current , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 02:10:48 -0000 On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The tentative merge date is August 17th. Again, I hope it's not terribly controversial to point out that it really rests with users of non amd64 platforms to test to avoid any unpleasant surprises the next time they update their trees following the merge. amd64, i386, and aarch64 memdisk images can be found at: https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ If you're using a platform not listed above and would be inclined to test if you had an image to work with, let us know. Alternatively, you can still build following the instructions below. The review for merging in to base can be found at: https://reviews.freebsd.org/D25872 ========================================================== NB: Do NOT zpool upgrade unless you are willing to live without the ability to ever rollback to the legacy zfs kmod. Checkout updated HEAD: % git clone https://github.com/mattmacy/networking.git -b projects/openzfs_vendor freebsd Checkout updated openzfs in to sys/contrib: % git clone https://github.com/zfsonfreebsd/ZoF.git -b projects/openzfs_vendor freebsd/sys/contrib/openzfs Build world and kernel with whatever your usual configuration is. Where possible the openzfs kmod is backward compatible with the cmd utils in HEAD so common operations work with existing tools and the new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries are backward compatible with the zfs kmod in HEAD. Although ideally one would test this in a separate boot environment, the interoperability should allow one to rollback without too much difficulty. Thanks in advance for your time. From owner-freebsd-fs@freebsd.org Wed Jul 29 03:08:45 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3384637BBA0; Wed, 29 Jul 2020 03:08:45 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BGdmF0gSBz4CZW; Wed, 29 Jul 2020 03:08:45 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id E963E2ED56; Wed, 29 Jul 2020 03:08:44 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-qt1-f181.google.com with SMTP id d27so16605656qtg.4; Tue, 28 Jul 2020 20:08:44 -0700 (PDT) X-Gm-Message-State: AOAM532appHFWlzm9fls+DEQl+IjLLsBLPiQD/lhrpCrelldlr6fY8WE 7rf/8bvuiqRi1ZLi7qGEoJlHV67MlFCRfWcI0HU= X-Google-Smtp-Source: ABdhPJzhgzPM8eDBGtFbKHawwqrAnFnrPPp29R36kruD/J4i07zmbwCrFeD/vKeeykXp7r7F0Mp3qWOgRvyvfk4U884= X-Received: by 2002:aed:2a82:: with SMTP id t2mr10286898qtd.280.1595992124412; Tue, 28 Jul 2020 20:08:44 -0700 (PDT) MIME-Version: 1.0 References: <69527ad8d7b98fe2fa58edaafb09c03c@udns.ultimatedns.net> In-Reply-To: <69527ad8d7b98fe2fa58edaafb09c03c@udns.ultimatedns.net> From: Matthew Macy Date: Tue, 28 Jul 2020 20:08:33 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CFT for vendor openzfs - week 4 reminder + memdisk images To: freebsd-fs , freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 03:08:45 -0000 On Tue, Jul 28, 2020 at 8:03 PM Chris wrote: > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mmacy@freebsd.org said > > > On Wednesday, July 8th I issued the initial call for testing for the > > update to HEAD to vendored openzfs. We'd like to give users roughly a > > month to test before merging. The tentative merge date is August > > 17th. > > > > Again, I hope it's not terribly controversial to point out that > > it really rests with users of non amd64 platforms to test to avoid any > > unpleasant surprises the next time they update their trees following > > the merge. > > > > amd64, i386, and aarch64 memdisk images can be found at: > > https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ > > Is this in an attempt to replace the opensolaris version used now? The word "attempt" is a misnomer. If you search the mail archives this has been the PoR for some time. > > Thanks. > > --Chris > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Thu Jul 30 01:10:12 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9277B371626 for ; Thu, 30 Jul 2020 01:10:12 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BHC50154Vz4VJv for ; Thu, 30 Jul 2020 01:10:11 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id C17811DF91; Thu, 30 Jul 2020 01:10:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net C17811DF91 From: Allan Jude To: status-updates@freebsdfoundation.org, freebsd-fs , openzfs-developer References: <7b8842ad-d520-c575-22ee-2cd77244f2c6@freebsd.org> <708ec9f2-3c5c-6452-f6e6-bfb11a7f7eb2@freebsd.org> <528ca743-7889-d1fd-ca95-a17cd430725b@freebsd.org> <9d77cb73-c8e8-cca0-b4b8-28e6790268d6@freebsd.org> Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Subject: Re: ZSTD Project Weekly Status Update Message-ID: <327f4b10-9727-331e-2dc9-641dad96dd2a@freebsd.org> Date: Wed, 29 Jul 2020 21:10:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9d77cb73-c8e8-cca0-b4b8-28e6790268d6@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HXdgsR2rk3L8d56jpFJrIXbETIpRJKU9d" X-Rspamd-Queue-Id: 4BHC50154Vz4VJv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:6939, ipnet:209.51.160.0/19, country:US] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 01:10:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HXdgsR2rk3L8d56jpFJrIXbETIpRJKU9d Content-Type: multipart/mixed; boundary="lJuBT4HZrTb0Dn1o8XsoeLb5B1bLWBKWv"; protected-headers="v1" From: Allan Jude To: status-updates@freebsdfoundation.org, freebsd-fs , openzfs-developer Message-ID: <327f4b10-9727-331e-2dc9-641dad96dd2a@freebsd.org> Subject: Re: ZSTD Project Weekly Status Update References: <7b8842ad-d520-c575-22ee-2cd77244f2c6@freebsd.org> <708ec9f2-3c5c-6452-f6e6-bfb11a7f7eb2@freebsd.org> <528ca743-7889-d1fd-ca95-a17cd430725b@freebsd.org> <9d77cb73-c8e8-cca0-b4b8-28e6790268d6@freebsd.org> In-Reply-To: <9d77cb73-c8e8-cca0-b4b8-28e6790268d6@freebsd.org> --lJuBT4HZrTb0Dn1o8XsoeLb5B1bLWBKWv Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable This is the sixth weekly status report on the project to integrate ZSTD into OpenZFS. https://github.com/openzfs/zfs/pull/10631 - Improved the `zfs recv` error handling when it receives an out-of-bounds property value. Specifically, if a zfs send stream is created that supports a newer compression or checksum type, the property will fail to be set on the receiving system. This is fine, but `zfs recv` would abort() and create a core file, rather than reporting the error, because it did not understand the EINVAL being returned for that property. In the case where the property is outside the accepted range, we now return the new ZFS_ERR_BADPROP value, and the correct message is displayed to the user. I opted not to use ERANGE because that is used for 'this property value should not be used on a root pool'. The idea is to get this fix merged into the 0.8.x branch for the next point release, to improve compatibility with streams generated by OpenZFS 2.0 https://github.com/openzfs/zfs/pull/10632 - General improvement to error handling when the error code is EZFS_UNKNOWN. https://github.com/allanjude/zfs/commit/8f37c1ad8edaff20a550b3df07995dab8= 0c06492 - ZFS replication compatibility improvements. As discussed on the leadership call earlier this month, keep the compatibility simple. If the -c flag is given, send blocks compressed with any compression algorithm. The improved error handling will let the user know if their system can't handle ZSTD. https://github.com/allanjude/zfs/commit/0ffd80e281f79652973378599cd033217= 2f365bd - per-dataset feature activation. This switches the ZSTD feature flag from 'enabled' to 'active' as soon as the property is set, instead of when the first block is written. This ensures that the pool can't be imported on a system that does not support ZSTD that will cause the ZFS cli tools to panic. I will be working on adding some tests for the feature activation. I've been looking at ways to add tests for the replication changes, but it doesn't seem to be easy to test the results of a 'zfs recv' that does not know about ZSTD (where the values are outside of the valid range for the enum). If anyone has any ideas here, I'd be very interested. On 2020-07-20 23:40, Allan Jude wrote: > This is the fifth weekly status report on the project to integrate ZSTD= > into OpenZFS. >=20 > https://github.com/c0d3z3r0/zfs/pull/14/commits/9807c99169e5931a754bb0d= f68267ffa2f289474 > - Created a new test case to ensure that ZSTD compressed blocks survive= > replication with the -c flag. We wanted to make sure the on-disk > compression header survived the trip. >=20 > https://github.com/c0d3z3r0/zfs/pull/14/commits/94bef464fc304e9d6f58503= 91e41720c3955af11 > - I split the zstd.c file into OS specific bits > (module/os/{linux,freebsd}/zstd_os.c) and also split the .h file into > zstd.h and zstd_impl.h. This was done so that FreeBSD can use the > existing kmem_cache mechanism, while Linux can use the vmem_alloc pool > created in the earlier versions of this patch. I significantly changed > the FreeBSD implementation from my earlier work, to reuse the power of = 2 > zio_data_buf_cache[]'s that already exist, only adding a few additional= > kmem_caches for large blocks with high compression levels. This should > avoid creating as many unnecessary kmem caches. >=20 > https://github.com/c0d3z3r0/zfs/pull/14/commits/3d48243b77e6c8c3bf562c7= a2315dd6cc571f28c > - Lastly, in my testing I was seeing a lot of hits on the new > compression failure kstat I added. This was caused by the ZFS "early > abort" feature, where we give the compressor an output buffer that is > smaller than the input, so it will fail if the block will not compress > enough to be worth it. This helps avoid wasting CPU on uncompressible > blocks. However, it seems the 'one-file' version of zstd we are using > does not expose the ZSTD_ErrorCode enum. This needs to be investigated > further to avoid issues if the value changes (although it is apparently= > stable after version 1.3.1). >=20 > I am still working on a solution for zfs send stream compatibility. I a= m > leaning towards creating a new flag, --zstd, to enable ZSTD compressed > output. If the -e or -c flag are used without the --zstd flag, and the > dataset has the zstd feature active, the idea would be to emit a warnin= g > but send the blocks uncompressed, so that the stream remains compatible= > with older versions of ZFS. I will be discussing this on the OpenZFS > Leadership call tomorrow, and am open to suggestions on how to best > handle this. >=20 >=20 > On 2020-07-14 22:26, Allan Jude wrote: >> In my continuing effort to complete the integration of ZSTD into >> OpenZFS, here is my fourth weekly status report: >> >> https://github.com/allanjude/zfs/commit/b0b1270d4e7835ecff413208301375= e3de2a4153 >> - Create a new test case to make sure that the ZSTD header we write >> along with the data is correct. Verify that the physical size of the >> compressed data is less than the psize for the block pointer, and veri= fy >> that the level matches. It uses a random level between 1 and 19 and th= en >> verifies with zdb that the block was compressed with that level. >> >> I am still working on a solution for setting the zstd feature flag to >> 'active' as soon as it is set, rather than only once a block is born. = As >> well as fixing up compatibility around zfs send/recv with the embedded= >> block points flag. >> >> This project is sponsored by the FreeBSD Foundation. >> >> >=20 --=20 Allan Jude --lJuBT4HZrTb0Dn1o8XsoeLb5B1bLWBKWv-- --HXdgsR2rk3L8d56jpFJrIXbETIpRJKU9d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJfIh3sAAoJEBmVNT4SmAt+8M0QAJ/QeFAM/SHC8FGC15biQwTr vxdFQhwGtjykCbUyJ4ccgnUmWkdPq0xsTw1Qg/z88KTBb5D1+0a/KgAD83IIyLav apcC8ksxKGISrGznGHv2YNk122Js8ss/W8RxlV7PKbX7chenOrg7SnozBFXwr9VK i0AwctTDk+ryHt63gm+eBunLB3D7+RWvdaS9P2ahTYFWkM9usyUUyS5ujO/z8LxX V/nqkIOvsTuJYVuwbSsa18Z9NiYhd2MtL+crEAfIXyF+PYNNb0lsxCGCe7HmGJYT fV6QBNSkLpIx5QHLSE0Ha7XmygmkNSws8xcoVwBcVdkqRfI/nU5/Klo1WoSsbOMV u30QqNUbIPhWOXVutkSQhss7JLwyDnkaxsbTBRnKdlW3DFCbV9Vv0LHNvnlDDV59 3Qz5o3OYCDUO/twD8cIHj04n6v6Ud3xOdpOHsfSUiJChKvqK39sXHwzqn6fSlo+f I2UpO7xBLumPOlS08ci7Oqp0kMabVCFhFRU/ww8OC7Mu3HZ4AmYbGGWRswAWXO8W mEtKiQgp/03wxQO6XUJ7n5g3JdJI0G2AQ7u2nb2H8Ikk02DgPt5AdVvwgwL7Wf9Z 2TUFE+4AclO3EK0gxHA2JJp4UW6em/GRZs5Y5j78CdzXC01LY+xBYq2kfT1RZBQL xfN5grWkBc+5+CQBQ9W0 =qJ7j -----END PGP SIGNATURE----- --HXdgsR2rk3L8d56jpFJrIXbETIpRJKU9d-- From owner-freebsd-fs@freebsd.org Thu Jul 30 13:28:45 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B23C83A5C9E for ; Thu, 30 Jul 2020 13:28:45 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail1.yamagi.org (mail1.yamagi.org [IPv6:2001:19f0:b001:853::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BHWT85D4Gz4Myb; Thu, 30 Jul 2020 13:28:44 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from [212.48.125.108] (helo=aka.server.knhmn.de) by mail1.yamagi.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1k18bt-0001nT-6t; Thu, 30 Jul 2020 15:28:38 +0200 Date: Thu, 30 Jul 2020 15:28:25 +0200 From: Yamagi To: mmacy@freebsd.org Cc: freebsd-fs@freebsd.org Subject: Re: CFT for vendor openzfs - week 3 reminder Message-Id: <20200730152825.c246a854a1763883b2f165d4@yamagi.org> In-Reply-To: References: <20200727154651.37a7c23e711da9218cee61dd@yamagi.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Thu__30_Jul_2020_15_28_25_+0200_=dBoGSDe32osBgPj" X-Rspamd-Queue-Id: 4BHWT85D4Gz4Myb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@yamagi.org designates 2001:19f0:b001:853::3 as permitted sender) smtp.mailfrom=lists@yamagi.org X-Spamd-Result: default: False [-2.05 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[yamagi.org]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.99)[-0.992]; NEURAL_HAM_MEDIUM(-0.93)[-0.935]; NEURAL_HAM_SHORT(-0.22)[-0.224]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:b000::/38, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 13:28:45 -0000 --Signature=_Thu__30_Jul_2020_15_28_25_+0200_=dBoGSDe32osBgPj Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 28 Jul 2020 18:33:39 -0700 Matthew Macy wrote: > > % zfs create system/data/test > > % jls > > JID IP Address Hostname Path > > 1 10.42.11.5 portaldb-test.XXX.de /data/jails/portaldb-test > > % zfs jail 1 system/data/test > > internal error: Inappropriate ioctl for device > > zsh: abort (core dumped) zfs jail 1 system/data/test > > >=20 > My guess is that this is the same problem I was seeing with the > DTRACEIOC_PROVIDER ioctl that was causing dtrace to fail. I had > defined zoneid_t to be 8 bytes in openzfs - but it was defined as 4 > bytes in userland which was causing the switch statement to fall > through. I fixed this on Tuesday or Wednesday last week. >=20 > If it's still an issue I will fix. Hi, I just gave it a try. I'm still hitting the error with both branches rebuild this morning. FreeBSD is at 3d833be and OpenZFS is at=20 f10f94a. It looks like there's still something missing. Regards, Yamagi --=20 Homepage: https://www.yamagi.org Github: https://github.com/yamagi GPG: 0x1D502515 --Signature=_Thu__30_Jul_2020_15_28_25_+0200_=dBoGSDe32osBgPj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEOXu/lxyufwz0gC5x6xRy5x1QJRUFAl8iyvoACgkQ6xRy5x1Q JRVw+w/+NFjAqB0udmM+rbD9STFS/AgcZCVDdIsKqj8YbGaVKUmtgExOCiOy8Zn1 wbFCM+0bMD+rri0fR1/t0PPScuE1pap1aTzyf2W5GeIvIEE5YMb5gIUB/tqFGIWr jReEnZeSSSN4h8EaamCLAjMm/8zZmNWPJdNl0uLfQk6ZIvYyYSuD2qBAqW+/Q3D6 F63JyglVzrqAKOT/pYJ2iIknvuF1PiEq03Hm5GWSRQCt9sBTGvDFDcquQX1wwB+Y NsfEkEKUkRCstN107YaLnXMbzkaEsRtmiBQpJljWO07O+6qh/NjS56NgAYuGdeFD 4INkaD23c9yJGa476sIk/n6GT1yOklhNSixvGaKBUUes8YDKhUdXq/z2tyxA6ohp Pj2o/rreNGGiWChRdzdq34Xr0lBSj98JrpmwCAU6ZAqIBxK1QZ8sXk4wnEhRP+q1 n18RdKwkIYJvpkbm9WUzZ67kO9Q12PSN5vIwFuduOlDLVSdvLd0KrQB96x1pZ7Cl Tpnz0pGLoXJcKU+li9n+umQkeZdRKQ7zQRF7Nd6Zyk/Wz/J8gBVncr5TkDZii7Qc 42YtNtRYb4VXQDwF6irGooCMbdidvxXx/QlYyebHXQvIoAA+u5kubkgyC6i5W571 rV9PgyWDH2D072kD7aSqAi7lrjOD9pyfYUBtYeoOmjkbBZJpFI4= =IgUf -----END PGP SIGNATURE----- --Signature=_Thu__30_Jul_2020_15_28_25_+0200_=dBoGSDe32osBgPj-- From owner-freebsd-fs@freebsd.org Fri Jul 31 20:35:57 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 07E783A2765 for ; Fri, 31 Jul 2020 20:35:57 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BJJvc6SC2z3g8Q for ; Fri, 31 Jul 2020 20:35:56 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id BD09C2CB70 for ; Fri, 31 Jul 2020 20:35:56 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lf1-f44.google.com with SMTP id c15so200045lfi.3 for ; Fri, 31 Jul 2020 13:35:56 -0700 (PDT) X-Gm-Message-State: AOAM531qTO+LIKUURe6/aX/f0r9LZvixKAsnISDsLJQGdiEGJXL6kVz8 zeAXyEnCP8x0yN1G3x9wQwUNE7hIvNsj7Bpigmk= X-Google-Smtp-Source: ABdhPJyD+eVYZfRM+HEn5jgNkG/JlWsAFxoFpJ0NY2lsGOxDpeY/x+CbrReu8ZMFTbl9Fgr2usCntFKpAgIxUelUaws= X-Received: by 2002:a05:6512:14d:: with SMTP id m13mr2803409lfo.173.1596227755365; Fri, 31 Jul 2020 13:35:55 -0700 (PDT) MIME-Version: 1.0 References: <20200727154651.37a7c23e711da9218cee61dd@yamagi.org> <20200730152825.c246a854a1763883b2f165d4@yamagi.org> In-Reply-To: <20200730152825.c246a854a1763883b2f165d4@yamagi.org> From: Matthew Macy Date: Fri, 31 Jul 2020 13:35:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CFT for vendor openzfs - week 3 reminder To: Yamagi Cc: freebsd-fs Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 20:35:57 -0000 On Thu, Jul 30, 2020 at 6:28 AM Yamagi wrote: > > On Tue, 28 Jul 2020 18:33:39 -0700 > Matthew Macy wrote: > > > > % zfs create system/data/test > > > % jls > > > JID IP Address Hostname Path > > > 1 10.42.11.5 portaldb-test.XXX.de /data/jails/portaldb-test > > > % zfs jail 1 system/data/test > > > internal error: Inappropriate ioctl for device > > > zsh: abort (core dumped) zfs jail 1 system/data/test > > > > > > > My guess is that this is the same problem I was seeing with the > > DTRACEIOC_PROVIDER ioctl that was causing dtrace to fail. I had > > defined zoneid_t to be 8 bytes in openzfs - but it was defined as 4 > > bytes in userland which was causing the switch statement to fall > > through. I fixed this on Tuesday or Wednesday last week. > > > > If it's still an issue I will fix. > > Hi, > I just gave it a try. I'm still hitting the error with both branches > rebuild this morning. FreeBSD is at 3d833be and OpenZFS is at > f10f94a. It looks like there's still something missing. I'll rebase the OpenZFS projects/openzfs_vendor when the fix is merged: https://github.com/openzfs/zfs/pull/10658 Cheers. -M