From owner-freebsd-questions@freebsd.org Tue Feb 9 16:29:55 2021 Return-Path: Delivered-To: freebsd-questions@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 1A525543F6E for ; Tue, 9 Feb 2021 16:29:55 +0000 (UTC) (envelope-from jmc-freebsd2@milibyte.co.uk) Received: from cp160176.hpdns.net (cp160176.hpdns.net [91.238.160.176]) (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 4DZpJf13qBz3Fvd for ; Tue, 9 Feb 2021 16:29:53 +0000 (UTC) (envelope-from jmc-freebsd2@milibyte.co.uk) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=milibyte.co.uk; s=default; h=Content-Type:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9hRpHfnAU9kqFe0TQfIKv4tBsQctY0jZ+YpFQTRHcsk=; b=K8fGK1/T42T9Tcz+Qs/sihwURs 7Pj+rYqD11ca4Dggd0jlfdaFgMlOatk/GFs8vA/RjIAd+y8A7T7gjCDmgire7zIQWuLzya+MJHP/y K30J8cRAnnTeGeWjw4OJ/JKuZVjlujz5msyGGv9rb2Ii3nlEHst+wuNIQ+gursS9abSyHJWcg5DM+ FU3dRU91Utp6fCrXlhBeehMkjl/B2sMvzdkPCiPLHDuAQheOxD7JyiLywwJlzaObNOQBjtw9SRusB JCS1AAHmnMM3BryMSFu6bKaSlKVyxONl61+UWqkbtNKqOrFap+1xM54VMpIugyZS8Cyit51iXgzIQ VDuTvX6w==; Received: from 82-71-56-121.dsl.in-addr.zen.co.uk ([82.71.56.121]:39996 helo=curlew.milibyte.co.uk) by cp160176.hpdns.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l9VtW-001fMx-Gn for freebsd-questions@freebsd.org; Tue, 09 Feb 2021 16:29:42 +0000 Received: from [127.0.0.1] (helo=curlew.localnet) by curlew.milibyte.co.uk with esmtp (Exim 4.94) (envelope-from ) id 1l9VtW-0003TF-Ex for freebsd-questions@freebsd.org; Tue, 09 Feb 2021 16:29:42 +0000 From: Mike Clarke To: freebsd-questions@freebsd.org Subject: Re: "make" in ports tells me "requires kernel source files in SRC_BASE=/usr/src." despite an up-to-date /usr/src Date: Tue, 09 Feb 2021 16:29:42 +0000 Message-ID: <2476830.FrFBg55ix7@curlew> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: jmc-freebsd2@milibyte.co.uk X-SA-Exim-Scanned: No (on curlew.milibyte.co.uk); SAEximRunCond expanded to false X-YourOrg-MailScanner-Information: Please contact the ISP for more information X-YourOrg-MailScanner-ID: 1l9VtW-001fMx-Gn X-YourOrg-MailScanner: Found to be clean X-YourOrg-MailScanner-SpamCheck: X-YourOrg-MailScanner-From: jmc-freebsd2@milibyte.co.uk X-Spam-Status: No X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp160176.hpdns.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - milibyte.co.uk X-Get-Message-Sender-Via: cp160176.hpdns.net: authenticated_id: mailpool@milibyte.co.uk X-Authenticated-Sender: cp160176.hpdns.net: mailpool@milibyte.co.uk X-Source: X-Source-Args: X-Source-Dir: X-Rspamd-Queue-Id: 4DZpJf13qBz3Fvd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=milibyte.co.uk header.s=default header.b=K8fGK1/T; dmarc=none; spf=pass (mx1.freebsd.org: domain of jmc-freebsd2@milibyte.co.uk designates 91.238.160.176 as permitted sender) smtp.mailfrom=jmc-freebsd2@milibyte.co.uk X-Spamd-Result: default: False [-2.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; HAS_X_SOURCE(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[milibyte.co.uk:+]; NEURAL_HAM_SHORT(-0.52)[-0.520]; HAS_X_ANTIABUSE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[91.238.160.176:from]; CTE_CASE(0.50)[]; ASN(0.00)[asn:12703, ipnet:91.238.160.0/22, country:GB]; HAS_X_AS(0.00)[mailpool@milibyte.co.uk]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[milibyte.co.uk:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[milibyte.co.uk]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[91.238.160.176:from:127.0.2.255]; HAS_X_GMSV(0.00)[mailpool@milibyte.co.uk]; MID_RHS_NOT_FQDN(0.50)[]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 16:29:55 -0000 On Tuesday, 9 February 2021 09:53:27 GMT Matthew Seaman wrote: > There's an important difference between beadm and bectl which seems > relevant here. beadm defaults to accepting a tree of ZFSes as a boot > environment, whereas bectl only applies to the ZFS at the top level of > the boot environment unless you use the -r flag. That probably accounts for a discrepancy that I always see between beadm list and bectl list for my BE which has child datasets: curlew:/tmp% beadm list BE Active Mountpoint Space Created fbsd12.1y - - 1.9G 2020-12-20 20:52 fbsd12.2a - - 133.0M 2020-12-24 11:20 fbsd12.2b - - 18.5M 2021-01-02 09:50 fbsd12.2c - - 11.7M 2021-01-12 09:55 fbsd12.2d NR / 39.4G 2021-02-05 10:46 curlew:/tmp% bectl list BE Active Mountpoint Space Created fbsd12.1y - - 61.3M 2020-12-20 20:52 fbsd12.2a - - 6.97M 2020-12-24 11:20 fbsd12.2b - - 2.80M 2021-01-02 09:50 fbsd12.2c - - 5.91M 2021-01-12 09:55 fbsd12.2d NR / 39.5G 2021-02-05 10:46 For inactive BEs the output from beadm shows the total space for all the child datasets and their snapshots but bectl only includes the space for the top level dataset and its snapshot. For example: curlew:/tmp% zfs list -H -o name,used,origin ssd/ROOT/fbsd12.1y ssd/ROOT/fbsd12.1y 6.02M ssd/ROOT/fbsd12.2d@2020-12-24-11:20:04 curlew:/tmp% zfs list -t snap -H -o name,used ssd/ROOT/ fbsd12.2d@2020-12-24-11:20:04 ssd/ROOT/fbsd12.2d@2020-12-24-11:20:04 55.3M This gives a total of 61.3M matching the result for bectl but does not include the space used by all the children. >From past experience I know that when I destroy fbsd12.1y it will free up about 1.9G but there's no way to get this information using bectl Since bectl doesn't have an -r option for the list command it's not possible for me to make it look for child datasets. Perhaps it should be updated to check for and include child datasets by default when calculating the size, this shouldn't have any adverse affect the result if there is only a top level dataset in the BE. -- Mike Clarke