Re: adding swap when expanding root filesystem

On Nov 8, 2022, at 09:41, bob prohaska <fbsd@www.zefox.net> wrote:

> [much snippage ensues, hope I've preserved enough context]
> 
> On Mon, Nov 07, 2022 at 11:05:16PM -0800, Mark Millard wrote:
>> On Nov 7, 2022, at 20:38, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>>> On Mon, Nov 07, 2022 at 04:07:08PM -0800, Mark Millard wrote:
>>>> On Nov 7, 2022, at 12:51, bob prohaska <fbsd@www.zefox.net> wrote:
>>>> 
>>>>> . . .
>>> 
>>>> Also the amount of space
>>>> U-Boot and the like takes varies. The Rock64 images
>>>> use a 16 MiByte space for its U-Boot and the like,
>>>> which are stored outside any file system. 
>>> 
>>> I'm not sure how anything can be stored "outside any
>>> filesystem". Might it be better to say "in a private filesystem",
>>> as in not known to the running kernel?
>> 
> 
>> 
>> The 2 dd commands above put the content of idbloader.img
>> and of u-boot.itb into the so-called "free" space
>> indicated, at very particular positions.
>> 
> 
> If there's no guide to what's free vs in-use, there's no filesystem?
> I see your point, but then the msdos partition is a filesystem. Thus,
> at least on a Pi, nothing is outside the filesystem. The Rock64 case
> resembles the boot blocks of a DOS boot disk. Am I reading right?

The older RPi*'s are unusual in being just file system based.
(RPi4B's and the like have the EEPROM updatable as well but
are otherwise just file system based.)

DOS boot blocks were more standardized, if I understand right.

>>> Is there any basic problem with automatically establishing a 
>>> swap partition during a microSD card setup?  A trio of self-
>>> hosted armv7 Pi2's with swap on microSD have been running 
>>> happily for over two years as name, mail and webservers on 
>>> 64 GB cards. Admittely, aarch64 is a lot more swap-intensive, 
>>> but a Pi3 ran for about a year on a 128 GB card before things 
>>> started going wrong. That Pi3 was running buildworld
>>> most of the time.
>> 
>> Are you asking for someone to give such support
>> to each of the following contexts (ignoring
>> u-boot-master and u-boot-tools and the like
>> that also show up in the list)?
>> 
> I'm a bit confused here, as the connection between 
> u-boot and swap availability isn't obvious to me.

Are you after media that boots without being adjusted?
That would make the U-Boot issues (and more) part of
the overall activity of making media images available
for whatever range of devices you are after. One image
does not cover all those cases, possibly even if
U-Boot or such has to be manually added (presuming some
support of GPT anyway).

>> # ls -dC1 /usr/ports/sysutils/u-boot-*
>> /usr/ports/sysutils/u-boot-a13-olinuxino
>> /usr/ports/sysutils/u-boot-a64-olinuxino
>> /usr/ports/sysutils/u-boot-bananapi
>> /usr/ports/sysutils/u-boot-bananapim2
>> /usr/ports/sysutils/u-boot-beaglebone
> [many more examples snipped]
>> 
>> What fraction of what size user base actually does large
>> port builds and buildworld buildkernel or the like on
>> each of these [or otherwise needs swap space in order to
>> have enough memory space (not just RAM)]. If the
>> volunteer(s) that provide this context have no interest
>> in doing such activities on such hardware, how likely is
>> it that they are going to provide the more involved setup?
>> 
> 
> I simply don't know. Those with a loftier viewpoint probably do.
> Projects like FreeBSD have to pick and choose what they support
> and not all platforms are equal. I suppose one would seek to 
> balance benefits, burdens and breakage. For something like
> Raspberry Pi the benefits are obvious, breakage looks small.
> Burden on the project is un-gaugeable by me. As one of the
> cheapest SBCs the potential user base looks large, perhaps
> the largest among the many competitors.

You are already seeing the judgments in the support that is
available now vs. not. Part of this is the overall difficulty
of supporting the RPi*'s, making efforts in other areas for
them less likely. (And, are you really only asking for the
RPi*'s?)

Do not confuse the RPi* general market and the realtively tiny
RPi* with FreeBSD on it subset. Or, going the other way, the
size of the FreeBSD installation base overall vs. how much of
it is on RPi*'s. (It is less obvious to me for aarch64 RPi*
vs. other aarch64, for example.)

And then: The size of the set of those doing large builds
or other needs-swap-space activity on RPi3B class aarch64?

At some point, FreeBSD ends up with "beyond here is self
support".

>>> Configuring swap manually on a RPi microSD system is a very
>>> considerable amount of work.
>> 
>> That might contribute to what the volunteer(s) choose to do
>> or not do.
> 
> Perhaps that is what motivated the automatic swap creation idea.

But volunteers would be biased to avoiding dealing with
complication of providing the automatic swap creation
unless they had other reasons for doing so. Your
motivation to hope that someone implements such for you
and others and the implementor's motivations need not be
the same.

You can likely infer that the folks that would do such
activity have not found that it is a big deal for their
own activities. If it was, they likely would have
already provided such to support their own activities.

>> 
>>> Having it happen by default 
>>> wastes at most a few percent of the card capacity.
>> 
>> Presuming large enough capacities. 3.5 GiBytes would be
>> more than 10% of 32 GiBytes, for example. What is the
>> distribution of media sizes for folks that do not do
>> large port builds or buildworld buildkernel on such
>> systems --but do use such systems in some way? What
>> fraction of the overall use of such systems is that
>> set of folks?
>> 
> 
> The original proposal set a minimum amount of free space
> on the card before attempting swap creation. That would 
> seem to solve the problem, unless I'm missing something.  
> As a practical matter 32GB is a small card, 128 readily
> available and cheap, 1TB expensive and available. 

So growfs to less than the space available, then add a
swap slice/paritition, but with checks for "would not
fit well" and handling such cases?

>>> At this
>>> point I can't see any reason to say it's a bad idea and
>>> have some personal experience to suggest it's a good idea.
>> 
>> Getting someone else to be interested in doing what
>> you would find useful can be a challenge. Nothing
>> about that requires that the idea be a bad idea.
> 
> Did you mean "good idea"? If so I agree. "Good ideas"
> for one are mere distractions for most.

Just because you might not get someone interested does not
mean an idea is bad. That was the intention of the wording.

>> There are far too many good ideas for various context(s)
>> to implement them all for all the spanned contexts.
> 
> Very true. That's why I suggest looking at benefits, breakage
> and burden of support. Knowing that balance one can decide
> if the user base is big enough to warrant adoption.  

I think you are already seeing the relative priorities
people have judged in what has and has not been done.
Some of it is just "working in this area overall is too
painful compared to other things I can work on".

>>> [bsdinstall limitations snipped]
>>> 
>>> It might be worth mentioning the /boot/loader.conf and 
>>> /etc/sysctl.conf additions you've mentioned in other threads,
>>> as adjuncts to having autoconfigured swap on microSD. They've
>>> all been helpful in my experiments on RPi2 and RPi3. I think
>>> they'd be constructive additions to the RPi images and perhaps
>>> others.. 
>>> 
>> 
>> Mostly, these things go back to what we learned from markj
>> primarily (vm.pageout_oom_seq) and kib primarily
>> (vm.pfault_oom_attempts and vm.pfault_oom_wait), presuming
>> that I remember which-for-what accurately. Using
>> vm.swap_enabled and vm.swap_idle_enabled to avoid a form
>> of losing communication with the system(s) when they are
>> using the swap/paging space is more recent.
>> 
> 
> I didn't catch on until you made the importance explcit. 
> All apply to the constrained-memory situations in which 
> automatic swap creation is likely to be important. It
> might make sense to bundle the settings if practical.

So you are really after pre-supplied images configured
for "constrained-memory situations", at least on RPi*'s
with 1 GiByte of RAM, with updates as releng/*.* ,
stable/* , and main progress?

I'll remind that, as far as I know, no one is actively
working on RPi* support in the FreeBSD code. That is
why FreeBSD requires versions of RPi* firmware that are
over a year out of date, for example. So far as I know,
any new RPi* type of device requiring more recent
firmware would just not be supported at all. (I'm
not aware of important reasons for firmware updates
for what the firmware required now if new devices are
not considered. But others may be aware of reasons
for such.)

===
Mark Millard
marklmi at yahoo.com