Re: adding swap when expanding root filesystem

On Nov 7, 2022, at 20:38, bob prohaska <[email protected]> wrote:

> On Mon, Nov 07, 2022 at 04:07:08PM -0800, Mark Millard wrote:
>> On Nov 7, 2022, at 12:51, bob prohaska <[email protected]> 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?

Here are the instructions for putting U-Boot (and such)
on a Rick64:

# more /usr/local/share/u-boot/u-boot-rock64/README 
U-Boot loader and related files for the Pine64 Rock64.

To install this bootloader on an sdcard just do:
dd if=/usr/local/share/u-boot/u-boot-rock64/idbloader.img of=/path/to/sdcarddevice seek=64 bs=512 conv=sync
dd if=/usr/local/share/u-boot/u-boot-rock64/u-boot.itb of=/path/to/sdcarddevice seek=16384 bs=512 conv=sync

idbloader.img and u-boot.itb are not file systems.
They are found by the exact position that they must
be put at, thus the seek= and bs= usage in the dd
commands above.

# file /usr/local/share/u-boot/u-boot-rock64/u-boot.itb
/usr/local/share/u-boot/u-boot-rock64/u-boot.itb: Device Tree Blob version 17, size=1184, boot CPU=0, string block size=131, DT structure block size=992

# file /usr/local/share/u-boot/u-boot-rock64/idbloader.img
/usr/local/share/u-boot/u-boot-rock64/idbloader.img: data

The content in those files are not representations of
file systems.

Here is what a gpart show -p indicates for an example
Rock64 media with idblooader and U-Boot on it via those
dd commands:

=>       63  244277185    da4  MBR  (116G)
         63      32705         - free -  (16M)
      32768     102312  da4s1  fat32lba  [active]  (50M)
     135080      28760         - free -  (14M)
     163840  241172480  da4s2  freebsd  (115G)
  241336320    2940928         - free -  (1.4G)

=>        0  241172480   da4s2  BSD  (115G)
          0  230686720  da4s2a  freebsd-ufs  (110G)
  230686720   10485760          - free -  (5.0G)

Note the:

         63      32705         - free -  (16M)

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.

> 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)?

# 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
/usr/ports/sysutils/u-boot-chip
/usr/ports/sysutils/u-boot-clearfog
/usr/ports/sysutils/u-boot-cubieboard
/usr/ports/sysutils/u-boot-cubieboard2
/usr/ports/sysutils/u-boot-cubox-hummingboard
/usr/ports/sysutils/u-boot-firefly-rk3399
/usr/ports/sysutils/u-boot-imx-serial-loader
/usr/ports/sysutils/u-boot-master
/usr/ports/sysutils/u-boot-nanopi-a64
/usr/ports/sysutils/u-boot-nanopi-m1plus
/usr/ports/sysutils/u-boot-nanopi-neo
/usr/ports/sysutils/u-boot-nanopi-neo-air
/usr/ports/sysutils/u-boot-nanopi-neo2
/usr/ports/sysutils/u-boot-nanopi-r4s
/usr/ports/sysutils/u-boot-olimex-a20-som-evb
/usr/ports/sysutils/u-boot-olinuxino-lime
/usr/ports/sysutils/u-boot-olinuxino-lime2
/usr/ports/sysutils/u-boot-olinuxino-lime2-emmc
/usr/ports/sysutils/u-boot-orangepi-one
/usr/ports/sysutils/u-boot-orangepi-pc
/usr/ports/sysutils/u-boot-orangepi-pc-plus
/usr/ports/sysutils/u-boot-orangepi-pc2
/usr/ports/sysutils/u-boot-orangepi-plus-2e
/usr/ports/sysutils/u-boot-orangepi-r1
/usr/ports/sysutils/u-boot-orangepi-zero
/usr/ports/sysutils/u-boot-orangepi-zero-plus
/usr/ports/sysutils/u-boot-pandaboard
/usr/ports/sysutils/u-boot-pcduino3
/usr/ports/sysutils/u-boot-pine-h64
/usr/ports/sysutils/u-boot-pine64
/usr/ports/sysutils/u-boot-pine64-lts
/usr/ports/sysutils/u-boot-pinebook
/usr/ports/sysutils/u-boot-pinebookpro
/usr/ports/sysutils/u-boot-qemu-arm
/usr/ports/sysutils/u-boot-qemu-arm64
/usr/ports/sysutils/u-boot-qemu-riscv64
/usr/ports/sysutils/u-boot-riotboard
/usr/ports/sysutils/u-boot-rock-pi-4
/usr/ports/sysutils/u-boot-rock64
/usr/ports/sysutils/u-boot-rockpro64
/usr/ports/sysutils/u-boot-rpi
/usr/ports/sysutils/u-boot-rpi-0-w
/usr/ports/sysutils/u-boot-rpi-arm64
/usr/ports/sysutils/u-boot-rpi2
/usr/ports/sysutils/u-boot-rpi3
/usr/ports/sysutils/u-boot-rpi3-32
/usr/ports/sysutils/u-boot-rpi4
/usr/ports/sysutils/u-boot-sifive-fu540
/usr/ports/sysutils/u-boot-sifive-fu740
/usr/ports/sysutils/u-boot-sinovoip-bpi-m3
/usr/ports/sysutils/u-boot-sopine
/usr/ports/sysutils/u-boot-sopine-spi
/usr/ports/sysutils/u-boot-tools
/usr/ports/sysutils/u-boot-utilite
/usr/ports/sysutils/u-boot-wandboard

Just all those that happen to have snapshots made these
days?:

13.1+ and 14.0:
armv6 RPI-B
armv7 GENERICSD
aarch64 GENERIC
aarch64 RPI
aarch64 PINE64
aarch64 PINE64-LTS
aarch64 PINEBOOK
aarch64 ROCK64
aarch64 ROCKPRO64
riscv64 GENERIC
riscv64 GENERICSD

12.4 (in process) :
armv6 RPI-B
armv7 BANANAPI
armv7 CUBIEBOARD
armv7 CUBIEBOARD2
armv7 CUBOX-HUMMINGBOARD
armv7 RPI2
armv7 WANDBOARD
armv7 GENERICSD
aarch64 GENERIC
aarch64 PINE64
aarch64 PINE64-LTS

A subset of those?

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?

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

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

> 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.
There are far too many good ideas for various context(s)
to implement them all for all the spanned contexts.

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

===
Mark Millard
marklmi at yahoo.com