Date: Tue, 9 Feb 2021 20:10:34 +0100 From: Michael Schuster <michaelsprivate@gmail.com> To: Mike Clarke <jmc-freebsd2@milibyte.co.uk> Cc: freeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Bootenv containing several filesystems [Re: "make" in ports tells me "requires kernel source files in SRC_BASE=/usr/src." despite an up-to-date /usr/src] Message-ID: <CADqw_gLg8uG8jXTTFe=ZODwyxDSov6os44_P7No%2BQOtuwbapQg@mail.gmail.com> In-Reply-To: <2476830.FrFBg55ix7@curlew> References: <CADqw_gKG6ovTuN7bZvYy7PCydfCXH4M2fw68YLmLvZhxi-g2xw@mail.gmail.com> <CADqw_gL=9hY77i%2BnG6YCsVEFEzce0PngfrY9U_RYC2rrwD1MeQ@mail.gmail.com> <a71737ff-39f6-21ec-a4aa-a542aa70ce49@FreeBSD.org> <2476830.FrFBg55ix7@curlew>
next in thread | previous in thread | raw e-mail | index | archive | help
(changing the subject because we changed the subject :-)) On Tue, Feb 9, 2021 at 5:30 PM Mike Clarke <jmc-freebsd2@milibyte.co.uk> wrote: > 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 > strangely, I don't see such a difference: bectl: BE_20210205_121021_CURRENT14 - - 81.6M 2021-02-05 12:10 BE_20210205_181224_CURRENT14 - - 49.9M 2021-02-05 18:12 BE_20210206_102540_CURRENT14 - - 153M 2021-02-06 10:25 BE_20210206_175312_CURRENT14 NR / 30.9G 2021-02-06 17:53 BE_20210208_204901_CURRENT_14 - - 31.9M 2021-02-08 20:49 beadm: BE_20210205_121021_CURRENT14 - - 81.6M 2021-02-05 12:10 BE_20210205_181224_CURRENT14 - - 49.9M 2021-02-05 18:12 BE_20210206_102540_CURRENT14 - - 152.3M 2021-02-06 10:25 BE_20210206_175312_CURRENT14 NR / 30.9G 2021-02-06 17:53 BE_20210208_204901_CURRENT_14 - - 31.9M 2021-02-08 20:49 as you can see, the difference is negligable ... is there some zpool or zfs property I need to set so that be(ctl|adm) (with appropriate options if need be) will create a recursive boot environment? Thx Michael > 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 > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADqw_gLg8uG8jXTTFe=ZODwyxDSov6os44_P7No%2BQOtuwbapQg>