Re: adding swap when expanding root filesystem

[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?
 
> > 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.

> # 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.

> > 
> > 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.

> 
> > 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. 

> > 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.

> 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.  

> 
> > [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.

Thanks for reading, and your insights!

bob prohaska