From owner-freebsd-fs@freebsd.org Sun Jul 19 08:11: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 8C814358288 for ; Sun, 19 Jul 2020 08:11:52 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B8cyb4mXQz4HRh; Sun, 19 Jul 2020 08:11:51 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (m.cksoft.de [195.88.109.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTPSA id 8FBB61EA988; Sun, 19 Jul 2020 10:11:43 +0200 (CEST) Received: from amavisfra1.cksoft.de (unknown [IPv6:2001:67c:24f8:2003::25:a1]) by m.cksoft.de (Postfix) with ESMTP id 332BA63026; Sun, 19 Jul 2020 10:11:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([IPv6:2001:67c:24f8:2003::25:3]) by amavisfra1.cksoft.de (amavisfra1.cksoft.de [IPv6:2001:67c:24f8:2003::25:a1]) (amavisd-new, port 10051) with ESMTP id hgDIE-eq2V1b; Sun, 19 Jul 2020 10:11:40 +0200 (CEST) Received: from nocfra1.cksoft.de (nocfra1.cksoft.de [IPv6:2001:67c:24f8:2001::53:1]) by m.cksoft.de (Postfix) with ESMTP id 67C026302A; Sun, 19 Jul 2020 10:11:42 +0200 (CEST) Received: by nocfra1.cksoft.de (Postfix, from userid 1000) id 78D7714040; Sun, 19 Jul 2020 10:11:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by nocfra1.cksoft.de (Postfix) with ESMTP id 737B213EB6; Sun, 19 Jul 2020 10:11:42 +0200 (CEST) Date: Sun, 19 Jul 2020 10:11:42 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@nocfra1.cksoft.de Reply-To: Christian Kratzer To: Andriy Gapon cc: Allan Jude , freebsd-fs@freebsd.org, Toomas Soome Subject: Re: gptzfsboot targeting wrong vdev In-Reply-To: Message-ID: References: <9400f5f0-e267-932c-b1ce-8436748cf2c0@FreeBSD.org> <78024f0d-4889-713e-15a5-56ec6d8d82b3@freebsd.org> User-Agent: Alpine 2.22 (BSF 395 2020-01-19) X-NCC-RegID: de.cksoft X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 X-Rspamd-Queue-Id: 4B8cyb4mXQz4HRh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ck-lists@cksoft.de designates 2001:67c:24f8:1::25:1 as permitted sender) smtp.mailfrom=ck-lists@cksoft.de X-Spamd-Result: default: False [-1.46 / 15.00]; HAS_REPLYTO(0.00)[ck@cksoft.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[cksoft.de]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.922]; NEURAL_HAM_MEDIUM(-0.97)[-0.973]; R_SPF_ALLOW(-0.20)[+a:mx1.cksoft.de]; NEURAL_HAM_SHORT(-0.26)[-0.264]; CTYPE_MIXED_BOGUS(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:57407, ipnet:2001:67c:24f8::/48, country:DE]; RCVD_TLS_LAST(0.00)[] Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Sun, 19 Jul 2020 08:11:52 -0000 Hi, On Tue, 14 Jul 2020, Andriy Gapon wrote: > On 13/07/2020 21:02, Christian Kratzer wrote: >> In the future I will ensure  to have the first partition after boot to be the >> zroot. > > By the way, I've been considering changing our ZFS boot code so that it does not > treat a pool as a candidate unless it has bootfs explicitly set (non-default value). > I think that that would be a reasonable change. And not hard to do. > But never got around to doing it. that would actually be most welcome. I have just finished changeing all my non boot freebsd-zfs partition types to freebsd-vinum so as not to confuse the boot loader. I also disabled my sas controllers exposing the drives in the arrays to the bios as that was also bloating the initial set of potential targets to boot from. So having an explicit way of targeting the boot devices would really be cool. You would propably still need to keep the current default logic when there is no bootme property set on any bios visible partition. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-fs@freebsd.org Sun Jul 19 08:15:27 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 9C66E37FED1 for ; Sun, 19 Jul 2020 08:15:27 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B8d2k1181z4HbP; Sun, 19 Jul 2020 08:15:25 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (m.cksoft.de [195.88.109.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTPSA id 3057E1EA988; Sun, 19 Jul 2020 10:15:24 +0200 (CEST) Received: from amavisfra1.cksoft.de (unknown [IPv6:2001:67c:24f8:2003::25:a1]) by m.cksoft.de (Postfix) with ESMTP id C81BC63028; Sun, 19 Jul 2020 10:15:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([IPv6:2001:67c:24f8:2003::25:3]) by amavisfra1.cksoft.de (amavisfra1.cksoft.de [IPv6:2001:67c:24f8:2003::25:a1]) (amavisd-new, port 10051) with ESMTP id 8-rObDelrcby; Sun, 19 Jul 2020 10:15:20 +0200 (CEST) Received: from nocfra1.cksoft.de (nocfra1.cksoft.de [IPv6:2001:67c:24f8:2001::53:1]) by m.cksoft.de (Postfix) with ESMTP id 7D50B63026; Sun, 19 Jul 2020 10:15:21 +0200 (CEST) Received: by nocfra1.cksoft.de (Postfix, from userid 1000) id 84B0913E9E; Sun, 19 Jul 2020 10:15:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by nocfra1.cksoft.de (Postfix) with ESMTP id 7FF6A13D6F; Sun, 19 Jul 2020 10:15:21 +0200 (CEST) Date: Sun, 19 Jul 2020 10:15:21 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@nocfra1.cksoft.de Reply-To: Christian Kratzer To: "Kevin P. Neal" cc: Andriy Gapon , freebsd-fs@freebsd.org, Toomas Soome Subject: Re: gptzfsboot targeting wrong vdev In-Reply-To: <20200718220657.GA99649@neutralgood.org> Message-ID: References: <9400f5f0-e267-932c-b1ce-8436748cf2c0@FreeBSD.org> <78024f0d-4889-713e-15a5-56ec6d8d82b3@freebsd.org> <20200718220657.GA99649@neutralgood.org> User-Agent: Alpine 2.22 (BSF 395 2020-01-19) X-NCC-RegID: de.cksoft X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 X-Rspamd-Queue-Id: 4B8d2k1181z4HbP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ck-lists@cksoft.de designates 2001:67c:24f8:1::25:1 as permitted sender) smtp.mailfrom=ck-lists@cksoft.de X-Spamd-Result: default: False [-1.56 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[ck@cksoft.de]; RCVD_COUNT_FIVE(0.00)[6]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a:mx1.cksoft.de:c]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[cksoft.de]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.968]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.29)[-0.294]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.001]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:57407, ipnet:2001:67c:24f8::/48, country:DE]; RCVD_TLS_LAST(0.00)[] Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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: Sun, 19 Jul 2020 08:15:27 -0000 Hi, On Sat, 18 Jul 2020, Kevin P. Neal wrote: > On Tue, Jul 14, 2020 at 08:34:30AM +0300, Andriy Gapon wrote: >> On 13/07/2020 21:02, Christian Kratzer wrote: >>> In the future I will ensure  to have the first partition after boot to be the >>> zroot. >> >> By the way, I've been considering changing our ZFS boot code so that it does not >> treat a pool as a candidate unless it has bootfs explicitly set (non-default value). >> I think that that would be a reasonable change. And not hard to do. >> But never got around to doing it. > > Would that include full dataset paths in vfs.root.mountfrom? Because I > load the kernel from one ufs filesystem and then boot from a zfs pool > with the full dataset path/name (which term?) specified. It'd be a shame > to lose that. is that not what load vfs.root.mountfrom in loader.conf is for vfs.root.mountfrom="zfs:zroot/ROOT/default" Once the first stage has located the drive to boot from it will be in the loader and will have consumed /boot/loader.conf The bootme property is just there to point the first stage at the correct device from where to get the loader from. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-fs@freebsd.org Mon Jul 20 09:41:38 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 97A48376663 for ; Mon, 20 Jul 2020 09:41:38 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from mail.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9Gvj3JZZz3TWg; Mon, 20 Jul 2020 09:41:37 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.15.2/8.15.2) with ESMTP id 06K9fWNL094344; Mon, 20 Jul 2020 10:41:32 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id 06K9fVUx017026; Mon, 20 Jul 2020 10:41:31 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id 06K9fVRr017022; Mon, 20 Jul 2020 10:41:31 +0100 Date: Mon, 20 Jul 2020 10:41:31 +0100 Message-Id: <202007200941.06K9fVRr017022@higson.cam.lispworks.com> From: Martin Simmons To: Christian Kratzer CC: kpn@neutralgood.org, avg@freebsd.org, freebsd-fs@freebsd.org, tsoome@freebsd.org In-reply-to: (message from Christian Kratzer on Sun, 19 Jul 2020 10:15:21 +0200 (CEST)) Subject: Re: gptzfsboot targeting wrong vdev References: <9400f5f0-e267-932c-b1ce-8436748cf2c0@FreeBSD.org> <78024f0d-4889-713e-15a5-56ec6d8d82b3@freebsd.org> <20200718220657.GA99649@neutralgood.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4B9Gvj3JZZz3TWg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of martin@lispworks.com has no SPF policy when checking 46.17.166.21) smtp.mailfrom=martin@lispworks.com X-Spamd-Result: default: False [0.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.23)[-0.233]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lispworks.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.10)[-0.095]; NEURAL_SPAM_LONG(0.12)[0.119]; RCVD_IN_DNSWL_NONE(0.00)[46.17.166.21:from]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:51055, ipnet:46.17.166.0/24, country:GB] 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, 20 Jul 2020 09:41:38 -0000 >>>>> On Sun, 19 Jul 2020 10:15:21 +0200 (CEST), Christian Kratzer said: > > Hi, > > On Sat, 18 Jul 2020, Kevin P. Neal wrote: > > > On Tue, Jul 14, 2020 at 08:34:30AM +0300, Andriy Gapon wrote: > >> On 13/07/2020 21:02, Christian Kratzer wrote: > >>> In the future I will ensure  to have the first partition after boot to be the > >>> zroot. > >> > >> By the way, I've been considering changing our ZFS boot code so that it does not > >> treat a pool as a candidate unless it has bootfs explicitly set (non-default value). > >> I think that that would be a reasonable change. And not hard to do. > >> But never got around to doing it. > > > > Would that include full dataset paths in vfs.root.mountfrom? Because I > > load the kernel from one ufs filesystem and then boot from a zfs pool > > with the full dataset path/name (which term?) specified. It'd be a shame > > to lose that. > > is that not what load vfs.root.mountfrom in loader.conf is for > > vfs.root.mountfrom="zfs:zroot/ROOT/default" > > Once the first stage has located the drive to boot from it will be in the loader > and will have consumed /boot/loader.conf > > The bootme property is just there to point the first stage at the correct > device from where to get the loader from. Also, don't confuse bootme and bootfs. bootme is a GPT attribute used by gptboot, for booting from UFS. bootfs is a zpool property used by gptzfsboot, for booting from ZFS. __Martin From owner-freebsd-fs@freebsd.org Mon Jul 20 22:56:34 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 C2F0336C216; Mon, 20 Jul 2020 22:56:34 +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 4B9cXy3VGVz4g3M; Mon, 20 Jul 2020 22:56:34 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (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 565E01D9E2; Mon, 20 Jul 2020 22:56:34 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lf1-f51.google.com with SMTP id u12so10598371lff.2; Mon, 20 Jul 2020 15:56:34 -0700 (PDT) X-Gm-Message-State: AOAM5326c6IZFEwxjVGV26lAo7xLdUdlT9pL56aoDI7UfoIhJ/u6ya5e ptmhcE/TyEeVVJ3IS5emfBAapc2/dK/3iwoRzJ8= X-Google-Smtp-Source: ABdhPJyybhoOwXo3KGOOm6PHWsvpvL+V4+z3eHcXTkIWSCzyU+SOXXYfEufND/xd+h77Y1nHHWkLhFJoQx684BSM4ok= X-Received: by 2002:ac2:51a1:: with SMTP id f1mr11992204lfk.173.1595285792273; Mon, 20 Jul 2020 15:56:32 -0700 (PDT) MIME-Version: 1.0 From: Matthew Macy Date: Mon, 20 Jul 2020 15:56:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: CFT for vendor openzfs - week 3 reminder To: freebsd-current , freebsd-fs , 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: Mon, 20 Jul 2020 22:56:34 -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. 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. ========================================================== 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 Tue Jul 21 03:40:26 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 1835C375E02 for ; Tue, 21 Jul 2020 03:40:26 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [IPv6:2001:470:1:474::25]) (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 4B9krT52qpz43Z7 for ; Tue, 21 Jul 2020 03:40:25 +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 95223189B5; Tue, 21 Jul 2020 03:40:18 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 95223189B5 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> 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: <9d77cb73-c8e8-cca0-b4b8-28e6790268d6@freebsd.org> Date: Mon, 20 Jul 2020 23:40:14 -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: <528ca743-7889-d1fd-ca95-a17cd430725b@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BzphuFD49KUoqTjS8pR7SJVV9MAdN0UlC" X-Rspamd-Queue-Id: 4B9krT52qpz43Z7 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:2001:470::/32, 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: Tue, 21 Jul 2020 03:40:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BzphuFD49KUoqTjS8pR7SJVV9MAdN0UlC Content-Type: multipart/mixed; boundary="7UCzvkUxDyNlbe9CvgYPdX9ObTi9Pk87U"; protected-headers="v1" From: Allan Jude To: status-updates@freebsdfoundation.org, freebsd-fs , openzfs-developer Message-ID: <9d77cb73-c8e8-cca0-b4b8-28e6790268d6@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> In-Reply-To: <528ca743-7889-d1fd-ca95-a17cd430725b@freebsd.org> --7UCzvkUxDyNlbe9CvgYPdX9ObTi9Pk87U Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable This is the fifth weekly status report on the project to integrate ZSTD into OpenZFS. https://github.com/c0d3z3r0/zfs/pull/14/commits/9807c99169e5931a754bb0df6= 8267ffa2f289474 - 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. https://github.com/c0d3z3r0/zfs/pull/14/commits/94bef464fc304e9d6f5850391= e41720c3955af11 - 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. https://github.com/c0d3z3r0/zfs/pull/14/commits/3d48243b77e6c8c3bf562c7a2= 315dd6cc571f28c - 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). I am still working on a solution for zfs send stream compatibility. I am 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 warning 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. 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: >=20 > https://github.com/allanjude/zfs/commit/b0b1270d4e7835ecff413208301375e= 3de2a4153 > - 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 verif= y > that the level matches. It uses a random level between 1 and 19 and the= n > verifies with zdb that the block was compressed with that level. >=20 > 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. A= s > well as fixing up compatibility around zfs send/recv with the embedded > block points flag. >=20 > This project is sponsored by the FreeBSD Foundation. >=20 >=20 --=20 Allan Jude --7UCzvkUxDyNlbe9CvgYPdX9ObTi9Pk87U-- --BzphuFD49KUoqTjS8pR7SJVV9MAdN0UlC 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) iQIcBAEBAgAGBQJfFmOhAAoJEBmVNT4SmAt+aoMP/A5oJmKyp7lEkG7yFf+glHb3 IYKF2eWjVcCogLGMlQKdFlxXq+D6osHHpUacAsN2W/E8/3fXWPka9ybdKRfXN6Km v40PvpixAHN0GrOT4bnspUj/SrwVPiglj/nwy/K0Nv7vZdLq6Xw9/dQoElYWapKd Ht3zYH3zBTJQlxVEyvmvdaQAwzuVSJ4RtyHG2F07A0+ojQmpmrS3ZwlqiWRov2/w rLVemzC9iL7GkCsL6L6qCQddTcmYoZoIhk5UzmI4eN4jXCJZ3jWUfWYG1u3W7qPv PtHEyPBdEvafzyEfojKXhNccoHmY0L7kE8zq2URIpcWc51tsfyvEcXHv4XT1aPBF 7Pm1DVGO3uf6uQkwyFcNUAFz1jggnXD+F6FiFhRHdzplQICeJlSGvtUvIu/jdmHM NReTuOiF8DvnB2RE67V4gHpXfx6DuDaCIvoakiO7FmFdU7LufrmEtXDoivhsRR0M wr7O4JWWDZnJ+fibRTIuPaLTXUfMmOKUX9om7idjiY5cyU43QzKieLcspkoIrBKB xGo5QLwK5NSMgJF8vkW7Rt565cGzteEPbqv6ik4aDwjMnLMQhqg8kVnHpNVS4QC1 ZerihdbyNdnBw5nLW547bAJwIW6PGAi92IsfqZXCi0Hi1IZ9+QjncMqm2Lje77nG 0uNVQcvCJv9xUJV1c+wT =kdXF -----END PGP SIGNATURE----- --BzphuFD49KUoqTjS8pR7SJVV9MAdN0UlC--