Date: Sun, 7 Aug 2022 20:06:36 -0300 From: "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com> To: freebsd-arm <freebsd-arm@freebsd.org> Cc: Glen Barber <gjb@freebsd.org>, Warner Losh <imp@bsdimp.com>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Ed Maste <emaste@freebsd.org>, Mark Millard <marklmi@yahoo.com> 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: <71BFB117-151A-4970-A9B3-9BCD14336A64@cyclaero.com> In-Reply-To: <6483BD0C-AFDF-443D-BEA2-9F599C9B8C07@cyclaero.com> References: <A1AA705B-531D-45A2-9A1F-89F759550D3A@yahoo.com> <EA1CDEC5-A29E-43C5-9437-050CDBEC2233@freebsd.org> <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com> <2016951A-BF16-4780-85FF-0B77E91FBBD4@yahoo.com> <6483BD0C-AFDF-443D-BEA2-9F599C9B8C07@cyclaero.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 07.08.2022 um 19:51 schrieb Dr. Rolf Jansen =
<freebsd-rj@cyclaero.com>:
>=20
>> Am 07.08.2022 um 19:16 schrieb Mark Millard <marklmi@yahoo.com>:
>>=20
>>> On 2022-Aug-7, at 14:51, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> =
wrote:
>>>=20
>>>> Am 07.08.2022 um 16:50 schrieb Mark Millard <marklmi@yahoo.com>:
>>>>=20
>>>> On 2022-Aug-7, at 12:32, Glen Barber <gjb@freebsd.org> wrote:
>>>>=20
>>>>> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
>>>>>=20
>>>>> I honestly do not have any idea where the problems you are seeing =
are creeping in.
>>>>>=20
>>>>> Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not =
sure how to proceed otherwise.
>>>>=20
>>>> My guess is that if the release/tools/arm.subr line:
>>>>=20
>>>> chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2
>>>>=20
>>>> was instead (note the added -b use):
>>>>=20
>>>> chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a =
64k ${mddev}s2
>>>>=20
>>>> then the line:
>>>>=20
>>>> chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>>>>=20
>>>> would work as expected and things would still be aligned:
>>>> no aliasing of BSD vs. freebsd-ufs. (In part this is by
>>>> prior steps already having achieved alignment of BSD.)
>>>=20
>>> =46rom a strict mathematical stand point of view, -a is not =
necessary when using -b with an aligned value.
>>=20
>> "-a" controls more than the start offset: also the size.
>>=20
>> QUOTE
>> -a alignment If specified, then the gpart utility tries =
to
>> align start offset and partition size to =
be
>> multiple of alignment value.
>> END QUOTE
>>=20
>> I expect your statement would at most apply to the start offset, not =
to
>> everything "-a" does.
>>=20
>>> Personally I don=E2=80=99t use the -a option of gpart anymore since =
it started to do funny magics in front of face. If I remember correct, =
gpart of the FreeBSD 9.x-RELEASES was still OK (or was it 8?). Nowadays, =
I align all my storage media by employing -b with a reasonable value.
>>>=20
>>=20
>> I've no clue of the specifics that you are referencing and so can not =
check.
>=20
> It started at unexpected offsets and then left unexpected space at the =
end - sorry, I don=E2=80=99t use -a anymore for years, and I don=E2=80=99t=
remember the very details.=20
>=20
> That said, why then would we use -b in addition to -a, if -a would =
show the expected behaviour on its own. That is because either -a adds =
some "funny magic" to the logic, that is stated in the man file, or =
there is a bug in gpart.
>=20
> Anyway, using -a and -b together bears the danger of the equation =
being overestimated, namely in the case base is not a multiple (incl. 1) =
of alignment. Although, that is not the case with your suggestion. -b =
64k -a 64k is OK.
>=20
> Finally, I still wonder what might be the technical reason for =
aligning the size.
PS:
Now I am in nit picking mode - "... the gpart utility tries to ..." =20
Don=E2=80=99t try it, do it! Otherwise, hasta la vista, baby!
Hlv,b is meant to the -a option, and not personally.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71BFB117-151A-4970-A9B3-9BCD14336A64>