From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id kGVFM4DCHl99QQAA0tVLHw (envelope-from ) for ; Mon, 27 Jul 2020 12:03:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id YLEoL4DCHl9yXQAA1q6Kng (envelope-from ) for ; Mon, 27 Jul 2020 12:03:12 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D19DB9403E7 for ; Mon, 27 Jul 2020 12:03:11 +0000 (UTC) Received: from localhost ([::1]:58006 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k01qX-000131-IM for larch@yhetil.org; Mon, 27 Jul 2020 08:03:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60884) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k01qQ-00011k-Rw for guix-patches@gnu.org; Mon, 27 Jul 2020 08:03:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:42709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k01qQ-0003xc-II for guix-patches@gnu.org; Mon, 27 Jul 2020 08:03:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k01qQ-0008Ga-FD for guix-patches@gnu.org; Mon, 27 Jul 2020 08:03:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#42478] [PATCH] services: Add zram-device-service. Resent-From: Efraim Flashner Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 27 Jul 2020 12:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42478 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Marius Bakke Cc: 42478@debbugs.gnu.org Received: via spool by 42478-submit@debbugs.gnu.org id=B42478.159585133031710 (code B ref 42478); Mon, 27 Jul 2020 12:03:02 +0000 Received: (at 42478) by debbugs.gnu.org; 27 Jul 2020 12:02:10 +0000 Received: from localhost ([127.0.0.1]:54255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k01pZ-0008FN-Ki for submit@debbugs.gnu.org; Mon, 27 Jul 2020 08:02:09 -0400 Received: from flashner.co.il ([178.62.234.194]:39360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k01pX-0008F3-Rr for 42478@debbugs.gnu.org; Mon, 27 Jul 2020 08:02:08 -0400 Received: from localhost (unknown [141.226.9.208]) by flashner.co.il (Postfix) with ESMTPSA id A8CB3401A4; Mon, 27 Jul 2020 12:02:01 +0000 (UTC) Date: Mon, 27 Jul 2020 15:01:29 +0300 From: Efraim Flashner Message-ID: <20200727120129.GE9269@E5400> References: <20200722181025.29413-1-efraim@flashner.co.il> <87eeozsf5l.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J4XPiPrVK1ev6Sgr" Content-Disposition: inline In-Reply-To: <87eeozsf5l.fsf@gnu.org> X-PGP-Key-ID: 0x41AAE7DCCA3D8351 X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc X-PGP-Fingerprint: A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: -2.61 X-TUID: OZ6j7DSIPVd5 --J4XPiPrVK1ev6Sgr Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 25, 2020 at 07:00:54PM +0200, Marius Bakke wrote: > Efraim Flashner writes: >=20 > > * gnu/services/linux.scm (): New record. > > (zram-device-service-type): New variable. > > * doc/guix.texi (Linux Services): Document it. > > * tests/services/linux.scm (zram-device-configuration->udev-string): New > > test. >=20 > [...] >=20 > > diff --git a/doc/guix.texi b/doc/guix.texi > > index 8696a9b554..f656c31fab 100644 > > --- a/doc/guix.texi > > +++ b/doc/guix.texi > > @@ -27127,6 +27127,51 @@ parameters, can be done as follow: > > @end lisp > > @end deffn > > =20 > > +@cindex zram > > +@cindex compressed swap > > +@cindex Compressed RAM-based block devices > > +@subsubheading Zram Device Service > > + > > +The Zram device service provides a compressed swap device in system > > +memory. The Linux Kernel documentation has more information about > > +@uref{https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram= =2Ehtml,zram} > > +devices. > > + > > +@deffn {Scheme Variable} zram-device-service-type > > +This service creates the zram block device, formats it as swap and > > +enables it as a swap device. The service's value is a > > +@code{zram-device-configuration} record. > > + > > +@deftp {Data Type} zram-device-configuration > > +This is the data type representing the configuration for the zram-devi= ce > > +service. > > + > > +@table @asis > > +@item @code{disksize} (default @var{"0"}) > > +This is the amount of space you wish to provide for the zram device. = It > > +accepts a string and can be a number of bytes or use a suffix, eg.: > > +@var{2G}. >=20 > Perhaps this could accept both an integer and a string? What does a > size 0 device do, would it make sense to not have a default here? An integer or a string would certainly be more convenient for users, it just needs a bit more logic to add in number->string as needed. A size 0 device is pretty useless. It still creates the zram device but with a size of 0. I put in 0 as the default because that's the default if you don't choose anything when creating it. I suppose it would be better to make the default 1G or 1024**3 >=20 > Also, would it make sense to name it "size" instad of "disksize"? That's the internal name but I'm not opposed to changing it to 'size'. >=20 > > +@item @code{comp_algorithm} (default @var{"lzo"}) > > +This is the compression algorithm you wish to use. It is difficult to > > +list all the possible compression options, but common ones supported by > > +Guix's Linux Libre Kernel include @var{lzo}, @var{lz4} and @var{zstd}. >=20 > "comp_algorithm" is not very idiomatic :-) >=20 > Either "compression-algorithm" or just "compression" IMO. I'd also > prefer a symbol instead of a string (or both!), but no strong opinion. compression-algorithm does seem better. I'll change it to a symbol. >=20 > > +@item @code{mem_limit} (default @var{"0"}) >=20 > "mem_limit" should instead be "memory-limit" or just "limit". I like memory-limit, limit would make me wonder what the difference is between this an size. >=20 > Accepting an integer here too would be nice! :-) Noted :) >=20 > > +This is the maximum amount of memory which the zram device can use. > > +Setting it to '0' disables the limit. While it is generally expected > > +that compression will be 2:1, it is possible that uncompressable data > > +can be written to swap and this is a method to limit how much memory c= an > > +be used. It accepts a string and can be a number of bytes or use a > > +suffix, eg.: @var{2G}. > > +@item @code{priority} (default @var{"-1"}) >=20 > Just an integer I suppose? It would make more sense than a string. > =20 > > + > > +;;; > > +;;; Zram swap device. > > +;;; > > + > > +(define zram-device-configuration->udev-string > > + (@@ (gnu services linux) zram-device-configuration->udev-string)) >=20 > Would it make sense to export this, or is it strictly for internal use? I'm not opposed to exporting it but I'm not really sure what else you'd do with it. I think it would be nice to not hardcode zram0 so there can be more than one or to make it so it can be mounted as /tmp but there's nothing currently exposed as a variable to change how it works. >=20 > Great that you were able to add unit tests for the functionality. I > think in this case we could also have a system test that checks that a > zram device was created? But it can come later. I think it'd be good to add a system test to make sure there's actually 42 MB of swap or something. I'll have to think about how to do that. >=20 > Other than the cosmetic/idiomatic issues looks great to me! Thanks --=20 Efraim Flashner =D7=90=D7=A4=D7=A8=D7=99=D7=9D = =D7=A4=D7=9C=D7=A9=D7=A0=D7=A8 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --J4XPiPrVK1ev6Sgr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAl8ewhYACgkQQarn3Mo9 g1GfwQ//USTQmnfU0NBAedRrlQXoC5nzap6iGwTEu2vDofkXVJyfKU8HhBktjVj/ cW2ap9dCzcdvCR+s1qyYrwmYBkSmD+iZg0xY9toQBYgENHZLqcx4DjvPz6aIHv4O wTEoiqTXcOmtqfSvFfvshJb913FU84JJ3w2SlD0lYLNWQ9cB+fkbpGpRw03P9FNz a/J2xFXLF29U+VUkfJtOzsp6jqJArJZ6a1fK7wM7j8Fy19JkG/Z8SPmvzB8y4b+p MqMkOWG4ZGJ4OmJ0mFY1IEkdzZogpks4WlqgQpuzZSWzfmbWprukfkicMzYW2DHy xuwRaiEc6gfwVx5e2BTYerg3tP56doSn93SNmx5b24lR8TYCfrFN4YO/VPmWt+XL htK1eZODuQVICGwN5qw+dmocfo4N+OZ3GxpjNiTfLep8mMyBBxDKgyyfd3pljwSV /d1zk4heDU7aSA/U4K5kmMbhdzF4tsRro/8ajEZe66Y9SNJbf83EfikqdbMMx/qe joZRMc34xVnB9H+YcVnnkRFa8NNFxq4L9iOcdq3esjddzgngm4ognC46I6AU8pjk PFu7H4kN6hQoSKiWB2SjIL6KkScSKVwxaI742wjgXyhcr9QQKnsI7OLRGjfoLi10 V9t1zA1bhky2rRk6xLNu62LWQWiQKWRfCj7uuJ0eTNYgP+8QgVs= =PQLu -----END PGP SIGNATURE----- --J4XPiPrVK1ev6Sgr--