From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 25 04:49:53 2021 Received: (at submit) by debbugs.gnu.org; 25 Mar 2021 08:49:53 +0000 Received: from localhost ([127.0.0.1]:37092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPLgf-00044h-1g for submit@debbugs.gnu.org; Thu, 25 Mar 2021 04:49:53 -0400 Received: from lists.gnu.org ([209.51.188.17]:49442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPLgd-00044Z-7M for submit@debbugs.gnu.org; Thu, 25 Mar 2021 04:49:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54496) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPLga-00071Q-ST for bug-guix@gnu.org; Thu, 25 Mar 2021 04:49:48 -0400 Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]:49492) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lPLgO-0005fB-IA for bug-guix@gnu.org; Thu, 25 Mar 2021 04:49:48 -0400 Received: from ptr-bvsjgyjmffd7q9timvx.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:aaf1:9810:a0b8:a55d]) by laurent.telenet-ops.be with bizsmtp id kYpU2400B0mfAB401YpUF5; Thu, 25 Mar 2021 09:49:28 +0100 Message-ID: Subject: "statfs" test in tests/syscall.scm fails with BTRFS file systems. From: Maxime Devos To: bug-guix@gnu.org Date: Thu, 25 Mar 2021 09:49:08 +0100 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-/Z7w7HBDKVLRbO9DQiY1" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1616662168; bh=y9qFR8o4ZuVsZ7PTOQ2wAvK9r5QpLWc7HfdW1pyvkIM=; h=Subject:From:To:Date; b=GK4JZMaszVd1yYNYtxHeVQas6ui34Oh4xEGFbEXhQgUEEOYDap0oaw+1lvlCp2YB4 UU/pD280zbo5CMshf5t7Jf+HR6fbCpc19Ng+UCyDLUtaRi8WdU4JSdolNgdzTLoceM c1afpL8LGjoxQPIiiGKdOLbHDn1ErxXJbhd4Ba5hTpq7RRRLbE3vgd2KlfowkNnD/l FPix3L5RieQcDf0Idg0JSj8iPEDYMernfK/bZ1US4IjpVyZ8bWR5xbQWTQxwxRnCMN d91742rv0d8xABmFdOPTPByiNQ7D3E9P0gJtgVpx3aWZ3hRBdlOQ2yrZqnpDv4hnpL CXWSXrkP7zydQ== Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-/Z7w7HBDKVLRbO9DQiY1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Guix, Version: guix (GNU Guix) 1155a88308df7649fe74bd5bb8279a4d103ce386 The following test fails: (start snip) test-name: statfs location: $HOME/guix/git/guix/tests/syscalls.scm:123 source: + (test-assert + "statfs" + (let ((fs (statfs "/"))) + (and (file-system? fs) + (> (file-system-block-size fs) 0) + (>=3D (file-system-blocks-available fs) 0) + (>=3D (file-system-blocks-free fs) + (file-system-blocks-available fs))))) actual-value: #f result: FAIL (end snip) Evaluating (statfs "/") from a REPL gives: scheme@(guix-user)> ((@ (guix build syscalls) statfs) "/") $2 =3D #< type: 2435016766 block-size: 4096 blocks: 244189696 = blocks-free: 178549974 blocks-available: 178571318 files: 0 free- files: 0 identifier: (1111009624 2088757363) name-length: 255 fragment-size= : 4096 mount-flags: 1056 spare: (0 0 0 0)> It seems the following does not hold on my system: + (>=3D (file-system-blocks-free fs) + (file-system-blocks-available fs)) Greetings, Maxime --=-/Z7w7HBDKVLRbO9DQiY1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYFxOhRccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7q3jAP9t1MfAlsfVdokHsacdWRJ8/sHI 1T7pLiABPG/0BlVuzgEAwfwRx/EgRSaW7vSBWVhlkD6CF0KexGBhpw1BTk7EJQQ= =BvGb -----END PGP SIGNATURE----- --=-/Z7w7HBDKVLRbO9DQiY1-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 25 06:05:08 2021 Received: (at 47379) by debbugs.gnu.org; 25 Mar 2021 10:05:08 +0000 Received: from localhost ([127.0.0.1]:37189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPMrU-0008D4-0o for submit@debbugs.gnu.org; Thu, 25 Mar 2021 06:05:08 -0400 Received: from flashner.co.il ([178.62.234.194]:41266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPMrS-0008CW-CM for 47379@debbugs.gnu.org; Thu, 25 Mar 2021 06:05:06 -0400 Received: from localhost (unknown [31.210.177.71]) by flashner.co.il (Postfix) with ESMTPSA id E186A40311; Thu, 25 Mar 2021 10:04:59 +0000 (UTC) Date: Thu, 25 Mar 2021 12:04:10 +0200 From: Efraim Flashner To: Maxime Devos Subject: Re: bug#47379: "statfs" test in tests/syscall.scm fails with BTRFS file systems. Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wjR5p3rYDWoO9f6z" Content-Disposition: inline In-Reply-To: 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-Debbugs-Envelope-To: 47379 Cc: 47379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --wjR5p3rYDWoO9f6z Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 25, 2021 at 09:49:08AM +0100, Maxime Devos wrote: > Hi Guix, >=20 > Version: > guix (GNU Guix) 1155a88308df7649fe74bd5bb8279a4d103ce386 >=20 > The following test fails: >=20 > (start snip) > test-name: statfs > location: $HOME/guix/git/guix/tests/syscalls.scm:123 > source: > + (test-assert > + "statfs" > + (let ((fs (statfs "/"))) > + (and (file-system? fs) > + (> (file-system-block-size fs) 0) > + (>=3D (file-system-blocks-available fs) 0) > + (>=3D (file-system-blocks-free fs) > + (file-system-blocks-available fs))))) > actual-value: #f > result: FAIL > (end snip) >=20 > Evaluating (statfs "/") from a REPL gives: >=20 > scheme@(guix-user)> ((@ (guix build syscalls) statfs) "/") > $2 =3D #< type: 2435016766 block-size: 4096 blocks: 24418969= 6 blocks-free: 178549974 blocks-available: 178571318 files: 0 free- > files: 0 identifier: (1111009624 2088757363) name-length: 255 fragment-si= ze: 4096 mount-flags: 1056 spare: (0 0 0 0)> >=20 > It seems the following does not hold on my system: > + (>=3D (file-system-blocks-free fs) > + (file-system-blocks-available fs)) >=20 I'm also running on btrfs (ins)scheme@(guile-user)> (statfs "/") $1 =3D #< type: 2435016766 block-size: 4096 blocks: 244049664 = blocks-free: 165299045 blocks-available: 165178857 files: 0 free-files: 0 i= dentifier: (2930232877 3283401406) name-length: 255 fragment-size: 4096 mount-flags: 4= 128 spare: (0 0 0 0)> (cmd)scheme@(guile-user)> (>=3D (file-system-blocks-free (statfs "/")) (fil= e-system-blocks-available (statfs "/"))) $5 =3D #t (ins)efraim@3900XT ~$ btrfs filesystem df / Data, single: total=3D289.00GiB, used=3D287.83GiB System, single: total=3D32.00MiB, used=3D48.00KiB Metadata, single: total=3D13.00GiB, used=3D12.07GiB GlobalReserve, single: total=3D512.00MiB, used=3D0.00B When was the last time you ran btrfs balance? Regardless, we still want this test to pass on btrfs. --=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 --wjR5p3rYDWoO9f6z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmBcYBgACgkQQarn3Mo9 g1GMLA/8CfhXkwVDCGKDoQtLtHSxhLRKrqhobOx63wfhExAGQo/QYPryl2BkuUmC Q1Wn+M5MNGOS2kkobD/ViN/8Cl01omg6y53FttWV5oxvWeh4/NufZCq0yEGoHxNj T7bHuRm3r0/fqS5dDiZS/vJE1sFeFiDtrDLfO6GUyLG5q8xw8MU3RqRSdiZlKXXk 5tXEJt2QP646XoydefW/8bv2yzEH4TYjyyhO+/ptM1NYh7ddcy8PvP0jiJPX4WCJ 1PNFyIsmdJ5ZPGLGBbuWL8OwGVtK+KY/nw/CEgajHUGo8tSOOG0dFDAYgAD9VF2U qgS70KkCxQ1dG5HXrlLCiosUGwnHBasbgrme/h0OnPQXNd5jnVetgXx0EcqbW5GQ eAGjkrMfqj+p2X5NINazK8T/V12O0OH64gy5XOXnq41gn6KChMaIvcLXTJVkD1FO D663kv4QOa+Zcybze1KZYiLZE4R8Ml6XqGfKkDuEFChAa0HyET7usj1A+BlqvQH/ JZpClrdKFbaf9H7A7X3a3fD/kSq6LzQPXnFmo2xA5acywSvS1vR7Y6ynulX5ZiLR oAdPJ3lSNXcPvEDB5AnhZNYrZHA5wBSDSOAAO9wIBTkLSdF4E1lYXwqstR4aU+Zn DBIbH8WCw/2U+I+CBrniM/mNOPWnu2zwC3gHvDIweOY3ZdPPPM0= =nU7F -----END PGP SIGNATURE----- --wjR5p3rYDWoO9f6z-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 25 06:16:36 2021 Received: (at 47379) by debbugs.gnu.org; 25 Mar 2021 10:16:36 +0000 Received: from localhost ([127.0.0.1]:37207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPN2Z-0008UC-OD for submit@debbugs.gnu.org; Thu, 25 Mar 2021 06:16:36 -0400 Received: from laurent.telenet-ops.be ([195.130.137.89]:51398) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPN2X-0008U2-HB for 47379@debbugs.gnu.org; Thu, 25 Mar 2021 06:16:34 -0400 Received: from ptr-bvsjgyjmffd7q9timvx.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:aaf1:9810:a0b8:a55d]) by laurent.telenet-ops.be with bizsmtp id kaGX240050mfAB401aGXSj; Thu, 25 Mar 2021 11:16:31 +0100 Message-ID: <2cca61a298fd7481859a7268fbe98fc046fff736.camel@telenet.be> Subject: Re: bug#47379: "statfs" test in tests/syscall.scm fails with BTRFS file systems. From: Maxime Devos To: Efraim Flashner Date: Thu, 25 Mar 2021 11:16:25 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-ora2awaYVyoNeDcKlOLH" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1616667391; bh=6pMfd7N8LHb7/gnfQ8kp6/IYbuz1gZC/aaw2JcHUHF0=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=lFT8kLQuYU6BJh9ys9WBxcIkTAs8o3yh624j7i8jaA+7k1qUaYZw5xeJJ5HG+kZYF mPo+F+NvxnJe0V6FdK8kgBpkS7xUzwTgA8/PjzuneieL647b1P2VQJmPwdGJm8dCkK ORxiuMRM5mk4W1hceCSJNBOuxSofaiPYOZLEYFE/QtqZO6wKVSXzNFQU3kw7sYGN7s ruCIkfRv9rh5Ypf3IkhnnRQX79sCIJcMZSUUgquuC85k4y5SEXlYJy5iND9UbuBmxW iGuCc7ncUFCcXNCZK9wGQ9wxf5WXF/M4e2493zK1V+32hUGrxPb3YqSoCGT7YfAB1i f/tS44if+3cwQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47379 Cc: 47379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-ora2awaYVyoNeDcKlOLH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2021-03-25 at 12:04 +0200, Efraim Flashner wrote: > [...] > I'm also running on btrfs > (ins)scheme@(guile-user)> (statfs "/") > [...] >=20 > (ins)efraim@3900XT ~$ btrfs filesystem df / > Data, single: total=3D289.00GiB, used=3D287.83GiB > System, single: total=3D32.00MiB, used=3D48.00KiB > Metadata, single: total=3D13.00GiB, used=3D12.07GiB > GlobalReserve, single: total=3D512.00MiB, used=3D0.00B >=20 > When was the last time you ran btrfs balance? ... never? My output of "btrfs filesystem df" FWIW: $ btrfs filesystem df / Data, single: total=3D224.01GiB, used=3D223.14GiB System, DUP: total=3D8.00MiB, used=3D48.00KiB Metadata, DUP: total=3D14.00GiB, used=3D13.81GiB GlobalReserve, single: total=3D512.00MiB, used=3D0.00B Are there any reasons for running "btrfs balance"? If so, what command do you recommend (I assume something only touching meta data?) Greetings, Maxime. --=-ora2awaYVyoNeDcKlOLH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYFxi+RccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7noTAP4mIW6gnjRq6y99QH79FcKsdJtC cpwpJJfBzvVRp5UKkAD+IIqvUsM/J87bn5bk03vrr7226CBU0a8K7+JBorkqegM= =70lX -----END PGP SIGNATURE----- --=-ora2awaYVyoNeDcKlOLH-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 25 06:26:12 2021 Received: (at 47379) by debbugs.gnu.org; 25 Mar 2021 10:26:12 +0000 Received: from localhost ([127.0.0.1]:37219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPNBr-0000Q1-ML for submit@debbugs.gnu.org; Thu, 25 Mar 2021 06:26:11 -0400 Received: from flashner.co.il ([178.62.234.194]:41320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPNBp-0000Ph-Q8 for 47379@debbugs.gnu.org; Thu, 25 Mar 2021 06:26:10 -0400 Received: from localhost (unknown [31.210.177.71]) by flashner.co.il (Postfix) with ESMTPSA id 61EA140304; Thu, 25 Mar 2021 10:26:03 +0000 (UTC) Date: Thu, 25 Mar 2021 12:25:14 +0200 From: Efraim Flashner To: Maxime Devos Subject: Re: bug#47379: "statfs" test in tests/syscall.scm fails with BTRFS file systems. Message-ID: References: <2cca61a298fd7481859a7268fbe98fc046fff736.camel@telenet.be> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2Km2JiEhS9VOfFpb" Content-Disposition: inline In-Reply-To: <2cca61a298fd7481859a7268fbe98fc046fff736.camel@telenet.be> 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-Debbugs-Envelope-To: 47379 Cc: 47379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --2Km2JiEhS9VOfFpb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 25, 2021 at 11:16:25AM +0100, Maxime Devos wrote: > On Thu, 2021-03-25 at 12:04 +0200, Efraim Flashner wrote: > > [...] > > I'm also running on btrfs > > (ins)scheme@(guile-user)> (statfs "/") > > [...] > >=20 > > (ins)efraim@3900XT ~$ btrfs filesystem df / > > Data, single: total=3D289.00GiB, used=3D287.83GiB > > System, single: total=3D32.00MiB, used=3D48.00KiB > > Metadata, single: total=3D13.00GiB, used=3D12.07GiB > > GlobalReserve, single: total=3D512.00MiB, used=3D0.00B > >=20 > > When was the last time you ran btrfs balance? >=20 > ... never? My output of "btrfs filesystem df" FWIW: >=20 > $ btrfs filesystem df / > Data, single: total=3D224.01GiB, used=3D223.14GiB > System, DUP: total=3D8.00MiB, used=3D48.00KiB > Metadata, DUP: total=3D14.00GiB, used=3D13.81GiB > GlobalReserve, single: total=3D512.00MiB, used=3D0.00B >=20 > Are there any reasons for running "btrfs balance"? > If so, what command do you recommend (I assume something > only touching meta data?) >=20 btrfs balance moves the free space around so that you have fewer blocks with extra freed space. I normally run 'btrfs balance start -dusage=3D70 -musage=3D80 $mountpoint'. (unless I have it backwards) this takes any blocks with data which are less than 70% used and metadata blocks with less than 80% used and re-arranges them to effectively make the total space allocated closer to the actual space used. Running it with 50 is normally plenty. --=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 --2Km2JiEhS9VOfFpb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmBcZQcACgkQQarn3Mo9 g1ExwxAAisGXY3bhvJiEkpZ0n9yiwUDGw8MuinoRtiMq4H1deGsyoDrqjvNsBdYX /fZ7K0I/JpqFAmYgc8bHpkEnSF2SuMV9pJC9d8J2RcDSIOcNGFRQcbw9rohVez1M hSyCROSpc90WqErjiajoqJh5Za1fedJIP5ONFQxMdsK4vWphdSN1CKKR4GcBWbRs TlBYKqF2qk4+z8si7MIlj2P255QtZWdLlhwt6KuvOHh86fETmhAFSb2teD5fugHM 5+YVhwRwDP7tkKZeSgPyk7LOQTh7zotuvNoi0NQ8bjy4oV7A+QzAuzWPQTrjZ2Fd 6LAHXoMMtGJrl/Dgp8Tb0SsQ5Hxu3TI8jFM8ltaLX+P9WyXIcj/LGwmLJN8sxThQ eeik9OuiultuypK6s6lFHIWxF6wnQ4vxU4/+7aNlf8SScjx4inE0pvut9KvLo3ix 33aNXJl4HYlqGnn+bFuYhUapB+SKNIqM46/C5BIxB187ES+quYz2t7b3lEpgdBXD Eu7A7b9lC/mAJb6jS/Am/TBNZukpZwuMezlj31DS9Eo+RjbA+ooSUfYAzsMm2SH8 ABkmK184gJnnc9gxWroO+lY98wRKZDwvqRDgJM3OeeFozy3sJwqbnm84mdLYYWlt tHSIdVJV5KCThQMakuWq2ymDeLBpscdnmVx/q8Jm6N0H1CUhLDU= =cLKD -----END PGP SIGNATURE----- --2Km2JiEhS9VOfFpb-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 26 08:22:31 2021 Received: (at 47379) by debbugs.gnu.org; 26 Mar 2021 12:22:31 +0000 Received: from localhost ([127.0.0.1]:40603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPlTz-0002Fq-9A for submit@debbugs.gnu.org; Fri, 26 Mar 2021 08:22:31 -0400 Received: from mail-40137.protonmail.ch ([185.70.40.137]:27997) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lPlTw-0002FY-HW for 47379@debbugs.gnu.org; Fri, 26 Mar 2021 08:22:29 -0400 Date: Fri, 26 Mar 2021 12:22:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1616761341; bh=ygw74iDn6yzjQhqi9qzbGKLdCiyGHr226S33RUWL96c=; h=Date:To:From:Reply-To:Subject:From; b=JCNA/ZcWS567HOJoAczJ/MkdmbPhrn7LR+rjiUktC9eI/IYu27OWXb329pGATxawH iiAXQl4KnTEVcDpiD603FbN/BdkWtGo5Agq+VoDJibrZXVT/uAmYekgjyRY5YZgxX3 IMufsFzClpQn9qFhYlC9mmn25sK7lXCK3QNuDNew= To: "47379@debbugs.gnu.org" <47379@debbugs.gnu.org>, Efraim Flashner , Maxime Devos From: raid5atemyhomework Subject: "statfs" test in tests/syscall.scm fails with BTRFS file systems. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47379 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: raid5atemyhomework Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > btrfs balance moves the free space around so that you have fewer blocks > with extra freed space. I normally run 'btrfs balance start -dusage=3D70 > -musage=3D80 $mountpoint'. (unless I have it backwards) I think you do? Usually the numbers for `musage` are smaller I think. There is some old advice that you should only balance data and never balanc= e metadata, i.e. `btrfs balance start -dusage=3D70 $mountpoint`. This is b= ecause 1Gb blocks are assigned to either data or metadata, and it's possibl= e for excessive balances to result in a situation where the metadata gets o= nly a single 1Gb block and the rest of storage is assigned to data. Then t= he single metadata 1Gb block gets filled, and when new metadata is needed -= -- such as to rebalance the large number of data blocks so they take up few= er 1Gb blocks and more blocks can be assigned to metadata --- the filesyste= m is unable to continue operating due to the lack of metadata space and you= are stuck in a condition where you cannot delete data, delete snapshots, a= nd rebalance data. This is old advice since the new "GlobalReserve" (not so new I think, it wa= s added way back in 4.x? 3.x?) should provide space for temporary metadata = operations in such a case. Personally I'd rather just let metadata be "loo= se" and unbalanced to avoid the situation altogether; metadata is fairly ti= ny so it taking up more than one 1Gb block usually means it has two 1Gb blo= cks, maybe three at a stretch if you've been doing a lot of file creation a= nd deletion events. Another piece of old advice is to regularly balance. For example, have a d= aily `btrfs balance start -dusage=3D50 -dlimit=3D2 $mountpoint` --- the `dl= imit` makes it so that balancing stops when two 1Gb blocks of data have bee= n merged into some other half-filled 1Gb blocks of data. If you have never= balanced your BTRFS system, you might want to wait for some low-utilizatio= n time period, do a full `btrfs balance start -dusage=3D90 $mountpoint` wit= hout a `dlimit`, then schedule a daily balance of `-dusage=3D50 -dlimit=3D2= ` afterwards. On the other hand, if you're using SSDs, be aware that balan= cing leads to writing, which lowers your drive's longevity (but the point o= f `dlimit` is to prevent excessive amounts of daily work, and if you're reg= ularly writing to your disk (almost) everyday anyway, a small `dusage` and = `dlimit` would be within the noise of your daily-work-activity writes). You also want to do regular `btrfs scrub start $mountpoint`. Once a week f= or consumer-quality drives, once a month for enterprise-quality drives, if = you're not sure which one you have, go weekly. This is advice typical from= ZFS but should still apply to BTRFS. On SSD (or other storage with TRIM commands) you might want to do scheduled= trim regularly once a week or once every two weeks, in order to take alloc= ation pressure off the SSD and let it get better wear-levelling. This is g= enerally done via `fstrim` without any BTRFS-specific commands. Old advice= is to avoid the `discard` mount option (in some cases it can trim so often= that the SSD lifetime is significantly reduced) but that's supposed to be = fixed so maybe with a recent version you can mount `-o discard`, maybe. P= ersonally I'd use explicit scheduled trim still. Do try to schedule this a= t low-activity times, though; unless you've got SATA 3.1 (hard to check, mo= st drives/controllers just say "SATA 3" or "SATA III" which may or may not = mean including SATA 3.1 support), or SAS, or real SCSI, trim commands are s= low. Finally you might also want to do explicit defragmentation (which is a sepa= rate issue from balancing --- balancing ensures you don't have lots of half= -used blocks, defragging means files try to have as much of their data in t= he same 1Gb block) periodically, like once a week or two weeks. See also https://github.com/kdave/btrfsmaintenance for a package that does = btrfs maintenance for you, including balance, scrubbing, trimming, and defr= agging, and schedules those in "recommended" times as well. I think it mig= ht also have auto-snapshotting, though that is a bit more fraught as snapsh= ots are fairly heavyweight on BTRFS. Do note that it's crontab/SystemD-bas= ed though, so needs a good amount of glue code if you want to use it in Gui= x. It's available on Debian as `btrfsmaintenance` package. It's also got = a lot of settings, so you'd be up for a fairly comprehensive configuration = system to adapt it for Guix. Going back on topic... It looks like the test assumes "free" should equal "= available", but that is something that is likely not to work on ***all*** c= opy-on-write filesystems --- including ZFS and bcachefs, not just BTRFS. I= n particular, most copy-on-write filesystems (BTRFS, ZFS, and bcachefs) sup= port transparent compression, meaning "available" is often an estimated mul= tiple of "free". Probably the test should either explicitly use a specific= filesystem (maybe `tmpfs` would work? Or create a 1Gb "dd if=3D/dev/zero` = file in `/tmp` and bind-mount `ext4` onto it) that is simple enough that "f= ree" =3D=3D "available" most of the time, or it should just remove that par= ticular test. Thanks raid5atemyhomework