Date: Thu, 11 Aug 2022 12:34:23 -0700 From: Mark Millard <marklmi@yahoo.com> To: "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use Message-ID: <FE1A97C7-B3D5-43CF-9EEA-30A7EF394392@yahoo.com> In-Reply-To: <F466F020-40C8-4983-82CB-02B95A80ADAA@cyclaero.com> References: <A1AA705B-531D-45A2-9A1F-89F759550D3A@yahoo.com> <EA1CDEC5-A29E-43C5-9437-050CDBEC2233@freebsd.org> <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com> <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com> <F466F020-40C8-4983-82CB-02B95A80ADAA@cyclaero.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Aug-11, at 07:22, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> = wrote: >=20 >>>=20 >>> . . . Thanks for the notes about what you do. > My finding support your view. Only it seems now, that we may choose on = how to make the volume distinct from the slice, namely both or either of = offset and size.=20 >=20 >> . . . Good point: The change in offset via the -b in the experiment means the implicit freebsd-ufs size should decrease compared to before. So, both are effectively changed in the test. But the allocation on the media will go out to towards the end of the media when it does the grow activities: there will still be nothing explicit after the freebsd-ufs slice in BSD. Changing just the size but not the offset would be different in that respect. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE1A97C7-B3D5-43CF-9EEA-30A7EF394392>