Date: Mon, 7 Nov 2022 23:05:16 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Mike Karels <mike@karels.net>, freebsd-arm@freebsd.org Subject: Re: adding swap when expanding root filesystem Message-ID: <9BF0BEB8-6074-4607-BA1B-B3462C5CEA66@yahoo.com> In-Reply-To: <20221108043817.GA55121@www.zefox.net> References: <202211071610.2A7GAcHl090048@mail.karels.net> <20221107175206.GA49113@www.zefox.net> <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net> <20221107205150.GA53784@www.zefox.net> <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com> <20221108043817.GA55121@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>>=20
>>> . . .
>=20
>> 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.=20
>=20
> 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=20
U-Boot loader and related files for the Pine64 Rock64.
To install this bootloader on an sdcard just do:
dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync
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=3D and bs=3D 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=3D1184, boot CPU=3D0, string block size=3D131, DT =
structure block size=3D992
# 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:
=3D> 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)
=3D> 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=20
> swap partition during a microSD card setup? A trio of self-
> hosted armv7 Pi2's with swap on microSD have been running=20
> happily for over two years as name, mail and webservers on=20
> 64 GB cards. Admittely, aarch64 is a lot more swap-intensive,=20
> but a Pi3 ran for about a year on a 128 GB card before things=20
> 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?
> . . .
>=20
> 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=20
> 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]
>=20
> It might be worth mentioning the /boot/loader.conf and=20
> /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..=20
>=20
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.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9BF0BEB8-6074-4607-BA1B-B3462C5CEA66>