Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Apr 2026 19:38:31 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Alexander Ziaee <ziaee@FreeBSD.org>, dev-commits-src-all <dev-commits-src-all@FreeBSD.org>, dev-commits-src-main <dev-commits-src-main@FreeBSD.org>
Subject:   Re: git: 5ed26c21e4ff - main - bsdinstall: Improve auto-partition message
Message-ID:  <58e18961-431d-447f-85e6-a5d746e9fc7a@yahoo.com>
In-Reply-To: <E1wHtHX-0000gT-ID@rmmprod07.runbox>
References:  <13e05438-16ed-4049-b595-cfb6929aee79@yahoo.com> <E1wHtHX-0000gT-ID@rmmprod07.runbox>

index | next in thread | previous in thread | raw e-mail

On 4/28/26 18:00, Alexander Ziaee wrote:
> On 2026-04-28 19:06 -04:00 EDT, "Mark Millard" <marklmi@yahoo.com> wrote:
>> On 4/28/26 13:53, Alexander Ziaee wrote:
>>>
>>>
>>> On 2026-04-28 16:16 -04:00 EDT, "Mark Millard" <marklmi@yahoo.com> wrote:
>>>> On 4/28/26 10:02, Alexander Ziaee wrote:
>>>>> The branch main has been updated by ziaee:
>>>>>
>>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=5ed26c21e4ff1d478d4611abbf3dc14cc1b77244
>>>>>
>>>>> commit 5ed26c21e4ff1d478d4611abbf3dc14cc1b77244
>>>>> Author:     Alexander Ziaee <ziaee@FreeBSD.org>
>>>>> AuthorDate: 2026-04-28 16:59:19 +0000
>>>>> Commit:     Alexander Ziaee <ziaee@FreeBSD.org>
>>>>> CommitDate: 2026-04-28 16:59:34 +0000
>>>>>
>>>>>     bsdinstall: Improve auto-partition message
>>>>>     
>>>>>     Manually tuning ZFS for systems with <8GB ram hasn't been necessary at
>>>>>     least since the switch to OpenZFS. We have users reporting using 1GB RAM
>>>>>     with no manual tuning/issues.
>>>>
>>>> It is my understanding that FreeBSD 15.1-RELEASE intends on have armv7
>>>> fully supported with normal style distributions, unlike for 15.0 and
>>>> before. (This came up during the 15.0 effort.) That sets some context
>>>> for the below.
>>>>
>>>> Back when I experimented with such contexts for building ports on armv7,
>>>> there were definite memory tradeoffs vs. using UFS and what parallel
>>>> jobs / MAKE_JOBS_NUMBER_LIMIT combinations did. This was in the OpenZFS
>>>> time frame for sure. (I tested both ZFS and UFS types of context doing
>>>> the same builds.) These tests were "headless" (serial console and ssh)
>>>> that avoided also having any other notable competition for RAM+SWAP,
>>>> something that does not necessarily generally apply.
>>>>
>>>> I will note that armv7 no longer gets updating official port-package
>>>> builds via FreeBSD distributions. Some folks do not have/use aarch64
>>>> that is also armv7 user space capable or just do not use aarch64 systems
>>>> to build the port-packages that they want to use.
>>>>
>>>> Compared to 64-bit contexts, 32-bit environments (such as armv7) also
>>>> have smaller multipliers for SWAP=MULTIPLIER*RAM before FreeBSD warns of
>>>> potential mis-tuning. armv7 is tier 2.
>>>>
>>>> In other words, it seems that more needs to be specified about the
>>>> workload context to make a solid claim.
>>>
>>> Yes, that's why I removed the stale claim and the link to stale doc.
>>
>> I was talking about your new claim:
>>
>> QUOTE
>> Manually tuning ZFS for systems with <8GB ram hasn't been necessary at
>> least since the switch to OpenZFS. We have users reporting using 1GB RAM
>> with no manual tuning/issues.
>> END QUOTE
>>
>> not necessarily applying well to armv7 for its likely common context of
>> building port-packages for armv7 on armv7.
> 
> Tuning filesystems for port building on a memory constrained tier 2 architecture is highly specialized knowledge that is likely uncommon.

I'm just worried about setting things up for more support effort being
required.

To avoid more requests for support on the lists and forums, a warning
suggesting to pick UFS for 32-bit architectures would likely be more
effective.

But I'm not sure bsdinstall would have a reasonable way to present such.

> 
> I'm sure it would be appreciated if you put something on the wiki under the arm namespace about port building! Please let me know if you do so I can take a look too!

The experiments that I reported that I did lead to me not normally using
ZFS on such systems after the experiments. I never became literate at
tuning ZFS for low memory, for example.

Another overall system issue for ZFS use is managing disk free disk
space in each pool . . .

QUOTE (from the book's page 548):
Like all nonoverwriting file systems, ZFS operates best when at least a
quarter of its disk pool is free. Write throughput becomes poor when the
pool gets too full. By contrast, UFS can run well to 95 percent full and
acceptably to 99 percent full.
END QUOTE

That would not disappear by tuning for low memory. Also, I was not
likely to meet the 1/4 or more usually free criteria at the time. These
days, for USB media, I likely would be able to deliberately maintain
such a status based on sizes picked for use. But one has to know to do
that, even for small systems. (Again: a source of support requests.)

The book lists some more items in page 548's "[t]he areas in which ZFS
architecture works less well than UFS" material that are less obvious. I
have run into support requests that traced to such issues in the past.

> 
> Best,
> Alex
> 
>>> Thanks for the interest and the additional context!
>>>
>>> Best,
>>> Alex
>>>
>>>> A common case of needing to
>>>> personally build port-packages on such systems at least likely does have
>>>> differing tradeoffs involved from differing RAM usage. (Time to build is
>>>> also part of the tradeoff structure.)
>>>>
>>>> (I'm not claiming that https://wiki.freebsd.org/ZFSTuningGuide should be
>>>> referenced.)
>>>>
>>>> I do not know of Kirk McKusic would fully retract the paragraph that is
>>>> on pages 49 and 549 of the Design and Implementation of the FreeBSD
>>>> Operating System book as a summary of the issues. (Page 547 and 548
>>>> indicate more about what contributes.)
>>>>
>>>> Further, the page this links to is a stale
>>>>>     wiki page, which is causing complaints. Remove this misleading note and
>>>>>     replace it with a similar message for UFS. While here, reword that note
>>>>>     to be a bit clearer.
>>>>>     
>>>>>     PR:                     287719
>>>>>     MFC after:              3 days
>>>>>     Differential Revision:  https://reviews.freebsd.org/D50971
>>>>> ---
>>>>>  usr.sbin/bsdinstall/scripts/auto | 4 ++--
>>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/usr.sbin/bsdinstall/scripts/auto b/usr.sbin/bsdinstall/scripts/auto
>>>>> index e9d6da149a85..ca0561daac1a 100755
>>>>> --- a/usr.sbin/bsdinstall/scripts/auto
>>>>> +++ b/usr.sbin/bsdinstall/scripts/auto
>>>>> @@ -50,10 +50,10 @@ msg_abort="Abort"
>>>>>  msg_an_installation_step_has_been_aborted="An installation step has been aborted. Would you like\nto restart the installation or exit the installer?"
>>>>>  msg_auto_ufs="Auto (UFS)"
>>>>>  msg_auto_ufs_desc="Guided UFS Disk Setup"
>>>>> -msg_auto_ufs_help="Menu options help choose which disk to setup using UFS and standard partitions"
>>>>> +msg_auto_ufs_help="Choose which disk to setup using UFS and standard partition layout"
>>>>>  msg_auto_zfs="Auto (ZFS)"
>>>>>  msg_auto_zfs_desc="Guided Root-on-ZFS"
>>>>> -msg_auto_zfs_help="To use ZFS with less than 8GB RAM, see https://wiki.freebsd.org/ZFSTuningGuide"
>>>>> +msg_auto_zfs_help="Choose which disk to setup using ZFS and standard partition layout"
>>>>>  msg_exit="Exit"
>>>>>  msg_freebsd_installer="$OSNAME Installer"
>>>>>  msg_gpt_active_fix="Your hardware is known to have issues booting in CSM/Legacy/BIOS mode from GPT partitions that are not set active. Would you like the installer to apply this workaround for you?"
>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> ===
>>>> Mark Millard
>>>> marklmi at yahoo.com
>>>>
>>>
>>
>>
>> -- 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>>
> 

-- 
===
Mark Millard
marklmi at yahoo.com



home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58e18961-431d-447f-85e6-a5d746e9fc7a>