From nobody Sun Jan 22 18:20:32 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P0M4043RTz3NL3j for ; Sun, 22 Jan 2023 18:20:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P0M401PFpz3RHs for ; Sun, 22 Jan 2023 18:20:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674411645; bh=U3qFjLnd6fkBMy8wgRo7iSst+ituVSv5IQwRnT7/++s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=SXqEZ14P5utS3e7R0Lxn3zFUei2+ItvjrQR57xLOC51DZDoFVzmPK3s3nvhvuuWGZGznrRJc9O4W1G0Aw4UzU1Sorkje0rcg5DsuW/7e8JsFL4yFbFP02S0sTAxXqRmaxfIfJkDaOsGuZylfhQm44jzIvMy6yh3+GTlZomkPBBCttFC0gVZFT3Kq/9YQuqOUM3Ojl2XaqWJCBV7KZCGRQJWBeAc0LehJJLhMGdPyC8E995VSu3oknF2f2VUvwxBdQZhpOlpdWsfOCpINzKyBJn92FXxoqtBTkK4EH9xVcPe+KYa6zvNjEALk0pa1qprxsd6JjPNWw87Bu1J2WkXmDA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674411645; bh=YSzCGf7kQ0KkAcpq7iwMCFi9k7yYxEzw28yF3HcBSra=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=U9QbfF1CLl1pUzbzLqdFKhp3ugaz9Gghvru9jEqTF75+svpL3kSU0fajyLsf63cjrJeRWUlhLCBtaB+vIh6u267OhuSjXfRhYzk4kSq6suGuObqLCDd0dlYboGa325VvCUzL/Kq4qERRUEiWlWiLY/G+klv4kTuO1dIaO0x3yoiRm5MNcwNxBYBJY4Mb2hBCymhD9Pii6azcAMSQdw9WBD2LYbUO6dIbXxEh07D9Dq9KXVlZCLNZZvpR7UpLJ/hFLPsmlvAWXWkbOj9+uJiqjquIIgKoyZ3xlW3tY1Jp0vyzZuTAlP5kxYjNJg2Wh4pKqXwJIXi3BTQ4IjgybU+k9w== X-YMail-OSG: 1TJdnxgVM1m4HwTcZbb24yIgwZUOQix31ThO0RXZ5sQlXgvtCIweisj5K8LfTNo PZ93rdupDEr20gljd7piOJjzOn88Lgir1TjoPbdVZZfjGecgMi.mUYnPcuW0KhLJZm5M2lJKV95n W_YyP6fYjjvw0LRLjG6uXqXq4SP.VUVzlSFLwIJ_orJiZiQmk9FEuCvwzePIUSLqwD6fSe35qrB3 6Io0KM90cg3vUkuFwSqUM6BAzEKDcfvO8VKlksqcKHeMYZZvyuALWxjRYWl46hj.L325Gqc9caBs N1mhTK69JzByoM97P5a.E9C1GbaYUNRr7ILQXm2vI_HdfVUK_KbrNHZ6OBMEPmNwmyMBAxuFc2RV 2V2.HYxiHWxJ6QXvMMdXZv3PVttLclRNaPgZv0QPvadp1Om8UZeX7ew1.G3U4kqH7LdYj2_IuRW. J23pp0YEyxqhSsH30d4C3rhthVXQNX_BUw8h7XfiNH5OuocFuQb7ZhIcbG.4LYeQnyKV6Wria1l3 63lrvF1o4DfNkkJ_PH9a_gQvwpZj60tXearVmiUs5oiabw3ZH6Ctw5HUmb8Et4tctDudz..UoPxX kSr3js.cYlgOGlqV1ezNY31rbkoWIrTjmaPZiNTHR3dVDHH5JBHIOD3JCB.h4I8OvW7JnxS_wKi4 pG1M83vlmnaup9L2Lch_8DHa9h9vFD.n4qJVFGKj3TwByrn4xPyWO2kW49IeKulOMk8D__GsFUj5 ondQyUVb_twLQTjJsMrh5H8.V1HCkpyzA0QI5G3fbZUQYrqWj8SjUr1QWsUBMylME.qeQtHn_d7S zfanXanfSrDDd63bDUwS0tZUZKV9ltagdpIvakn8KXAmrCYfyj2G4UOgi0sblWi4U2Qyyyb4MPk8 fvyXfACZw0ZfuPB5XCwBFrBnmNPlJggc4mv7BMTSy4Ua8kl6LhW9O3ZCABgR3cbtEFz9wwNQhtQs eBW3jATDEPWWBLInXZkSje5P9NfkXfCSOtVA5Cbvm0gsqGiz4Ol9zcUMhCDHxa2ccm6qWHq4Hfkb GS5X_WKxMS49s1gcFxlitVIVD.9yhJczWWq2cSiuMaiKNgYrzqd1f5Ecbq33RQVn7gSrCMg6uNcc KpNRlOJZQCYhHAh7MXSmQMPDcwh5qbyjZnmM2xmoC3T0p6aI_rlE7NkdYRQ5kV2QD4zSqtDckySL gCx6r381xgBWXsLpkpUrdqa9rnI4Nhxc7a8fRg2ippjqmdreoowFhLl3bgKandzGHpex3ud4Ay4K 8SXQTa01hzKeBx1BL2gEG5HOlnoKfjowxw.2XJ7yx1T0GjlKDsjHmfYO8kW6pvBG8QIcb1YqtOFa _anSgrU.Vhf_o6ANXaQkbzUHOBPHSb5W5DNCKyQgQl7qcikzZpNOoMUSohVi5S2WH6tMEZyjF44b 3j9QlRdfehU10luuIEcfbLfZHY6hLAwsOfM8smuEH4pQ4yX6R_OB2gjLD.WgpcvkvRO_LAyzxsRB ceoL6cWsPi4Dnp2SCa8xaTuKkmkeiHW093AvW.A8Tmr10rmIJU990ANf_2ebyVVSmsdRekMmUd_z eq1U1xHM.l6Z0Eyqc03jQ5.c6NTTO77OeWj1ADR1xuA.AtDesXPQ0FH9bLEpFjIGbfgM6qzRmDAO a.QrjJRzG958zdpMU5fZwJ8PizS2e.tBjaZ55kmt4c7.n1EI24gsROe4mhsoyT0rfuLuSBoBgyfn SobFrVtfaT0PGOPPh5bMR4WxuHqBIo9GYJRd.laAueujtAAw0jyBs9Q3aM_FqXBaQRoY1dQLtN2l 1QM8lyk.pgwbIdzM3VA50Cvz.N9T6ppkfHwInrMnOlPQjlSLTFF9yF.5CgvCRE7tTWstz.5tCpJP Tm4wgPU7QgqgS8x8KUpmUACxu0CCpQmFypOhwgNFkSSYDbX5l6lBgpZf4aKlqBJjAaXTBhv.37_. W5dlgvlcIl1qQpnkz1CDmXRtKsanDz_b_GMrCYOQ2xoIkQeuraABNcoGU8E8JB82cMJRAWW0KugC d5uOetKR2VyqbCm4fgSJ_M3Pkh9u9Dlrp16QXt6vabGoiOVhxtMBmxIHwkRqBfBGc5T8e5seVLhg yZHlMs5No.k4jzT88.eJD7d2wqj028J0hWUNw9LwaDorf_8SHyRZs96O1BLWUs7ezJhbwZAMA0SN TNSaynGucwZjUzp6zvt9v.pmO3J5otdiN45nn_RctKs6Mg2E4mw21yoPkxcACUkSE5Ax_N5yLQ7E Kr6DlFjGNPXxCcidn0Ank70xp5HhmWbWBwapCt.nAoO.uAPoniGRtLG2bZ3w4d1AUNQSBrlIwaNI W X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 18:20:45 +0000 Received: by hermes--production-gq1-6597fd5bbd-mr9bp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0c82a48ded9b52dadad77d8de34e1215; Sun, 22 Jan 2023 18:20:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: An idea for swap partition size vs. swap space size in use handling From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: <159467120.7.1674396707299@mailrelay> Date: Sun, 22 Jan 2023 10:20:32 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <05B1F338-6FE8-444F-AF05-55884FDEB8B3@yahoo.com> References: <159467120.7.1674396707299@mailrelay> To: Ronald Klop X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4P0M401PFpz3RHs X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 22, 2023, at 06:11, Ronald Klop wrote: >=20 >=20 > Van: Mark Millard > Datum: zondag, 22 januari 2023 05:41 > Aan: freebsd-current > Onderwerp: An idea for swap partition size vs. swap space size in use = handling > I have boot media that are each set up to boot a variety > of systems that have widely different RAM sizes, from > 1 GiBytes to 64 GiBytes for the aarch64 examples of this. >=20 > This has lead to having multiple swap partitions of > various sizes so that I can have total swap spaces that > are somewhat under the recommended maximum sizes for the > amount of RAM in each of those systems that a given media > can boot. >=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 > If such could be done, I'd no longer use multiple swap > partitions at the same time in order to get to a desired > total for the system at hand at the time. >=20 > Of course, that still leaves what to do when multiple > swap partitions are enabled if such a "ignore what > would be extra" mode was also enabled. As I'd not use > such, I've no specific recommendations to make that > would make any difference to my use. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 > =C3=82=20 >=20 >=20 > Hi Mark, >=20 > Do you mean you would like to be able to add a "size" parameter to the = fstab swap line? >=20 > /dev/da0p1 none swap sw,size=3D1g 0 = 0 No. That would use 1g for even the 64 GiByte RAM system when I move the media to that 64 GiByte system and boot it --and similarly as I move the media from system to system in general. For my style of use, I want the swap to be (a lower bound approximation of) the recommended figure for the amount of RAM for the specific system the media is currently use in. That means that the figure changes when I move the media to a system with a different amount of RAM. > Another option I can think of is using the "gnop" geom provider. It = has a -s parameter to set the size. I classically use a label based path to identify the swap partition, not a device name. This fits with the variations in what system I'm booting and what other devices might be around. (Some of the media involved here are USB media.) Labels go at the end of partitions, as I remember. This would appear to make forms of resizing or subranging the partition also mean adjusting the labeling. That is something I'd like to avoid. I'd also like to avoid needing to provide my own lower bound approximation of the recommended figure for the live amount of RAM. For one, it is platform dependent, for example armv7 and aarch64 are very different for the same amount of RAM. =3D=3D=3D Mark Millard marklmi at yahoo.com