Date: Sun, 22 Jan 2023 10:37:00 -0800 From: Mark Millard <marklmi@yahoo.com> To: Mike Karels <mike@karels.net> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: An idea for swap partition size vs. swap space size in use handling Message-ID: <F0BCD913-9C82-4122-90FF-86772B844E85@yahoo.com> In-Reply-To: <C8B52E43-9E1F-4226-8E31-EB43BD63C9C2@yahoo.com> References: <E187AA6B-6832-4A75-81BC-21E0A999154D.ref@yahoo.com> <E187AA6B-6832-4A75-81BC-21E0A999154D@yahoo.com> <202301220717.30M7H7wC022099@critter.freebsd.dk> <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> <960C016C-9D43-4F24-8913-363676B5E202@yahoo.com> <83FEEEDC-1880-4A7A-B5C9-312FB86D5826@karels.net> <C8B52E43-9E1F-4226-8E31-EB43BD63C9C2@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 22, 2023, at 09:46, Mark Millard <marklmi@yahoo.com> wrote: >=20 >> On Jan 22, 2023, at 05:15, Mike Karels <mike@karels.net> wrote: >>=20 >>> On 22 Jan 2023, at 2:42, Mark Millard wrote: >>>=20 >>>> On Jan 22, 2023, at 00:21, Mark Millard <marklmi@yahoo.com> wrote: >>>>=20 >>>>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp <phk@phk.freebsd.dk> = wrote: >>>>>=20 >>>>>> -------- >>>>>> Mark Millard writes: >>>>>>=20 >>>>>>> It would be nice if I could have just one swap partition >>>>>>> on a given boot media, one that is more than sufficient >>>>>>> in size for all but the biggest RAM system --but to then >>>>>>> be able to tell the system to just use up to the >>>>>>> recommended swap space size and to ignore any extra swap >>>>>>> space in the swap partition. >>>=20 >>> Why not just reduce the size of the swap partition to the desired = size >>> with =E2=80=9Cgpart resize=E2=80=9D? Granted, that requires manual = intervention. >=20 > On Jan 22, 2023, at 05:15, Mike Karels <mike@karels.net> wrote: >=20 >> On 22 Jan 2023, at 2:42, Mark Millard wrote: >>=20 >>> On Jan 22, 2023, at 00:21, Mark Millard <marklmi@yahoo.com> wrote: >>>=20 >>>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp <phk@phk.freebsd.dk> = wrote: >>>>=20 >>>>> -------- >>>>> Mark Millard writes: >>>>>=20 >>>>>> It would be nice if I could have just one swap partition >>>>>> on a given boot media, one that is more than sufficient >>>>>> in size for all but the biggest RAM system --but to then >>>>>> be able to tell the system to just use up to the >>>>>> recommended swap space size and to ignore any extra swap >>>>>> space in the swap partition. >>=20 >> Why not just reduce the size of the swap partition to the desired = size >> with =E2=80=9Cgpart resize=E2=80=9D? Granted, that requires manual = intervention. >=20 > Why would I use the size for a 1 GiByte aarch64 system > (prior boot) when I'm using the media to boot the 64 > GiByte system? So increases too. Manual intervention > every time I move the media between systems, going in > both directions over time? >=20 > That gets me into the business of independently > calculating a reasonable lower bound for the recommended > swap space every time I move the media between systems > with differing amounts of RAM. I've noticed that the > recommendation varies some across the OS updates. (My > guess is variations in the kernel space use is involved > in the recommendation.) I'm looking for something > avoiding such a redundant calculation, something that > just works given the variability across OS updates. (And across platforms: armv7 and aarch64 have very different recommendations for the same amount of RAM. And across differing amounts of RAM from system to system.) Took a while for me to think of it, but there is also that I use paths based on labels to identify the swap partition independent of the system it is plugged into and what other devices are present in that system. (Some of the media here are USB media.) Resizing (or subranging) partitions invalidates labeling because the labeling information goes at the end of the (logical) partition, if I understand right. So labeling would have to be re-established for the new size as well. =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?F0BCD913-9C82-4122-90FF-86772B844E85>