From nobody Sun Jan 30 01:34:37 2022 X-Original-To: freebsd-arm@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 1A8881985244 for ; Sun, 30 Jan 2022 01:34:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmYf55SXtz3s0n for ; Sun, 30 Jan 2022 01:34:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643506486; bh=ZSjwINergdKWPLnSbVax330jJDdVWTaMTmLeEXe2zJI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FCvtUMTid96EpTNeCrhb+EpfedSFQ1CXlVI5KZxs/leGF5uFl/169Bu5PCCaf3IehvWqeujuhVQ+PbKZQGSodNGP0i8yzV1A/peEXGYxeljJEx4q7pq/EuCnEMQ6M7eGCljrlVwUJS3L6Wa6ocUUn5w/My226IrXG/nhLBd3abwlogYMYMghEPbGjnK7xHeFXrWuqy6Lo1CGbtwW264a5TWpYJtr/LgupqoEQIn2rxrggZXKWPKxUalne4o9xshzaedeWJZeqXJYDyIIOIe3lD5Ue3ONC4ZwhiqmvPZn6mzvtD7kYF1DpRiPf3ENAJVanldaxdZKS2QyUN7P0N+v/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643506486; bh=giwtskccE3+7MM0LAV4rIN10fbOvrcrkDDucGYQe0jg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GkhhyAGrDNNuXKcg71zdOUrb1nlxJ5jEpBPjGa9jJSUT8cMrzYQ5nKg8iyRTpuD8lwqdwhysxm7u6Zva2wbpwZrsJeijoPTs1k/1eU/kMSyw1B7R/N44YlLlo8KSrmlM5TyCZdK8C2jk1TK+YqInnLwOgIdANo+g86inG/CcvRVVBaqBNkc1NeIff7h2eiI6UULThpDP3jQ+6H7BvTykCX9BldykN4b0TcbgDUiqn/ajssMN6BYX6EvCbrOZmQx14oGbfp2buVU9ANrx9z9kNNdQmyBM0+nItKOUsqY5nKSWfEpiI/jfNg/z8y/xDtIDl9gRXiRMkOnK7EnBTDTyRQ== X-YMail-OSG: iTfkrTAVM1lQ_2dq0TmChIWavkeCjUY3WWux1BXDr0u4CR0VxZE2quZBmKDGpYb cFE6Oy5XWbX2iEZyqaX0JboLAY9xx_Y2eJUEwVCafr_LsjvW3igOJiD.AzKtN25PrLl62_Yl0xqU z52M22WEEd36qFlm2QIAHUmYIh8LylX5biWsqW2oaZ_DgLI0nGW3jRg6LmJJp63lKQZF1XmKSjvk 3VwLrCjsG.gOuuZ.jo1B_.5cVgVq4ELcll_S_1SE7i0QUFCp5VE0fwXMBZyISLOBcfz_y8FzI9FY 090HJCWv4OVIsQYv1HXWX9wIVm3MYmA0C3XhppNWucINO.kj8qOkvsYSKIdcexQNzVq6Q6JqITFH 4NzgR9GrgmIitRBAUydGWotLWJK4eQhzxLvdRgyCdqDCrmii0lsYNj9aTZ6T._9dCZydBDp0gmai weyjuRTKqY3PGlUXol_EcUTXw_5FhJtnf6qF9yIkk1KTX5s.UbDp6ZMl9TxsW1wAaNHfPFDeBSG2 URgUHoS_FW8N5rhus_eRLsC0e3n8wGIXWxXXuDzIdwCUM8MWCie_RS3fjzgzxn1dt2aSfVDmDatz mHiCTeVj4og2rwJeTq3RvpNe8mRP7AprX0j56YfbwgGGL5_DwNRL0vU_nL55dRMA_vi6uz7_TsIW 5agMxFMYoD_QJJdABLRPQpminp9aw3clNuIlpHZFT9vkwO.yUkeWyOKYA9SgvVYV8lCMDuATkbgQ MFuvv0hjEpXro7XCrTKEZ6Hfg5yhob1o43oFkrc130zbQpPfNup0tsLXVm0mfifyJ6PWejd7ArYR zTmG_Z13ZOIuPM5CCp2JTKslm2ykjY9Sju2OaDCkXUXWSsHO2SgztXyLDBxJ5VAK3RII.c1T.EQj 2ZzZyqvCnUhwS6DWEl0Oqw0ZFSgzvgDFL00uuyqo17ltgLlPZ7iEUqLBm_.wdTws.xdXZTZzJEZl 3lekgMLczTfuScQ7MCs6mdPwKM94ZBuiB.TLswsvT8enFN9DcBDyxF7HaAx97Rk.uER9bvQV2ZWs 4qUOg7k2gLbu0vLLLSe47juBD.fSkrUpq935G7y.Zg5rrUAWCC_QQLro2cE_zI4TNBRiFWSfLtOs YLUw9PIsh2B0aVoCcYEE7i9QpnRBQhBnRQy42C_UyL5SvJrS6JFb7IkdkihYVLCWWreQfKNsnnoa Eq2uPO3pT4L0M3cKy_nTgC0p_jAcBtL2YSbe3UM5O5mlp3Wr55YqjUGNq9vLRSGbWCa8az81xEAI pEXptUoP3oaefvEdRk9PH2Px7Pj8A9PyVMVRzkrnyEnO_3QiDQzwxOfqTEn8MXCLeA5TC87QW7LZ B4Uw4v4isCxFJ7ePeDrBih3uOKNX3TbbpNu3VCA2HNb2wUU0enapV_qKXhtttFCEAmKlul0QEBMr Ooqpc7GzEbKlyXE7pNj170ZjBxgxkjMG7kwZwRxIsZIlDscu0zoia_s.ZMRu208CXT96Wjlv4C2c N0UH8sxak4TDoC_JkP5nuZEIylmRR7GL4S2cW_6i9Hab8BKMZWMaC2DPnIpFjSjcdIVUN2sacMy7 5s9GGXRc.St2AIYZV84pFe.FdxBRL3QcPl4UBRwFrZ0jCt9GY4HJ1zlLN7ByUq_BLxqCpx1CXowC 4Eqn5rQzT47dZxwzzOQ59hC1ki4jqAO4EeI2K8juNun_swZQs.cRbIqs2NEFfTqJpzQQS10CFmiI hEy_ow5VVHXJRoUXKEBs7XjofqPHRM0IYv_yq8SUU4Fgo8qVjjugk89B7qk5ltYClWIIlhTErPu6 mwezgiakXYm5ObfNIbOZc4SRjAZ.SfZVMrxdqjh0IsPa35fqalnKY.oL1Ja59Vkxasb1FsCP4djA ECXsjad2Zl82qWjmZIQOHCjEcv1AmPx8a4.NOFcgAa1Dpi6V7uTK0TNPMYCr.WNvc41MQWP7mPeo JNVbT.n9b19rFawDS_Qye3EipCFlRhSFLvEiVYSS6vNKd_CvKniFCheljciYrvr4leSXRYp5av9Y 7qGR3s6LX4uSFq988hhT4CiYeDilRQuadpzUuqZsRAqosHEPNG7uSCsZFc23M47EnJVNyQyHX8dz nEnFExUR74cyYwC.viTZ3Qr0SKCN8sR.GBskxo6NTEIB843HwMAkrzoQsa64svJGPDaK8qLT2vfL V.mEN_HUXTacCxbHWy096REbU8rY8L3UB5tgw5ViB.p6LdHJFh8Vb7mbtG7xZwBDu4fKJTwkQZCT oFNpFypdhPmHytEdFU2ueX2svYmNfKI.1uqotzMaw5_.2XwoqzZO1_ykx7Do4QtzcbLzA7_Gmwmv ye8ETYYkSYPXniQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Jan 2022 01:34:46 +0000 Received: by kubenode549.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2679683ce30c5c44dcc66be4e6716f2f; Sun, 30 Jan 2022 01:34:40 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Should a UFS machine have an ARC entry in top? From: Mark Millard In-Reply-To: <20220130001829.GA63427@www.zefox.net> Date: Sat, 29 Jan 2022 17:34:37 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220128182701.GA57479@www.zefox.net> <20220129204313.GA63030@www.zefox.net> <4D29091D-AC99-4D8D-AC3C-646A05529E26@yahoo.com> <20220130001829.GA63427@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmYf55SXtz3s0n X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=FCvtUMTi; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-29, at 16:18, bob prohaska wrote: > On Sat, Jan 29, 2022 at 03:30:35PM -0800, Mark Millard wrote: >> On 2022-Jan-29, at 12:43, bob prohaska wrote: >>=20 >>> I just noticed a new line in top's output on a Pi3 running = 13/stable: >>>=20 >>> ARC: 3072B Total, 2048B MRU, 1024B Header >>> 2048B Compressed, 20K Uncompressed, 10.00:1 Ratio >>>=20 >>> This is on a Pi3 with a UFS filesystem, near as I can >>> tell ARC is something to do with ZFS; have I got something >>> misconfigured? >>=20 >> ARC is for ZFS and its being in use suggests a ZFS >> file system is (or was?) at least slightly accessed >> at some point. >=20 > Not knowingly, just ufs and fat32.=20 >=20 >=20 >> What does: >>=20 >> # gpart show -p >>=20 >> show?=20 >=20 > root@pelorus:/usr/src # gpart show -p > =3D> 63 62333889 mmcsd0 MBR (30G) > 63 2016 - free - (1.0M) > 2079 102312 mmcsd0s1 fat32lba [active] (50M) > 104391 62229561 - free - (30G) >=20 > =3D> 63 62333889 diskid/DISK-29ED3EF6 MBR (30G) > 63 2016 - free - (1.0M) > 2079 102312 diskid/DISK-29ED3EF6s1 fat32lba [active] (50M) > 104391 62229561 - free - (30G) >=20 > =3D> 63 1953525105 da0 MBR (932G) > 63 2016 - free - (1.0M) > 2079 102312 da0s1 fat32lba [active] (50M) > 104391 1953420777 da0s2 freebsd (931G) >=20 > =3D> 0 1953420777 da0s2 BSD (931G) > 0 57 - free - (29K) > 57 6186880 da0s2a freebsd-ufs (2.9G) > 6186937 4194304 da0s2b freebsd-swap (2.0G) > 10381241 1943039536 da0s2d freebsd-ufs (927G) >=20 > It turns out kldstat reports=20 > 6 1 0xffff0000c9a00000 3ba000 zfs.ko >=20 > but /etc/defaults/rc.conf contains: >=20 > # ZFS support > zfs_enable=3D"NO" # Set to YES to automatically mount ZFS file = systems > zfs_bootonce_activate=3D"NO" # Set YES to make successful bootonce BE = permanent >=20 > # ZFSD support > zfsd_enable=3D"NO" # Set to YES to automatically start the ZFS = fault > # management daemon. >=20 > There's nothing related to zfs in /etc/rc.conf, either.=20 > Any other places to look? /boot/loader.conf The FreeBSD loader supports zfs and will detect zpools as well. That is part of why booting can initiate a zfs.ko load. > The GENERIC kernel config doesn't contain it, could it be included = from elsewhere?=20 zfs is not normally built into the kernel but loaded from a external zfs.ko file as needed. > Perhaps more to the point, does it matter? I've read some claims that > ZFS is a memory hog, consistent with the trouble seen on this machine, > but the extent to which the claims apply in this case is unclear since > ZFS isn't in use, only the module is loaded. =20 The ARC is present and active and using memory. How well behaved that is with a default configuration but only 1 GiByte of RAM I do not know. You may well want to avoid any extra use of more RAM. I suggest you do a reboot of the RPi3* and see if it automatically ends up with zfs.ko loaded by the time you can log in. If it does, then we need to figure out why and fix it. (But you might want to read the notes towards the end of this reply first.) >> For reference for when no zpool has been imported: >>=20 >> # zpool list >> no pools available >=20 > Same result here. I'll not unload the module just yet, > for sake of finishing what's been started. =20 >=20 > Maybe this is another red herring, but I do wonder=20 > how zfs.ko got loaded. "How" but also "when" is important. What else was going on at the time that lead to zfs.ko loading? > I did use Windows 10 diskpart > to format one of the fat32 usb flash drives used,=20 > but it seems a stretch to think that's the cause. Agreed. There is a command that might have to be used on some device that at one time had a zpool on it but now does not. . . # man zpool-labelclear ZPOOL-LABELCLEAR(8) FreeBSD System Manager's Manual = ZPOOL-LABELCLEAR(8) NAME zpool-labelclear =E2=80=93 remove ZFS label information from device SYNOPSIS zpool labelclear [-f] device DESCRIPTION Removes ZFS label information from the specified device. If the = device is a cache device, it also removes the L2ARC header (persistent = L2ARC). The device must not be part of an active pool configuration. -f Treat exported or foreign devices as inactive. SEE ALSO zpool-destroy(8), zpool-detach(8), zpool-remove(8), = zpool-replace(8) FreeBSD 14.0-CURRENT May 31, 2021 FreeBSD = 14.0-CURRENT There are also places like: # ls -Tld /etc/zfs/* drwxr-xr-x 2 root wheel 2 Apr 28 01:41:23 2021 = /etc/zfs/compatibility.d -rw------- 1 root wheel 3736 Jan 27 13:42:23 2022 /etc/zfs/exports -rw------- 1 root wheel 0 Apr 30 06:31:09 2021 = /etc/zfs/exports.lock -rw-r--r-- 1 root wheel 1416 Dec 14 16:03:49 2021 = /etc/zfs/zpool.cache Another directory that can look similar is (as I remember): # ls -Tld /boot/zfs/ drwxr-xr-x 2 root wheel 2 May 20 20:57:00 2021 /boot/zfs/ (But mine is empty.) There may be things to delete from such places on the RPi3* if the directories are not basically empty. =3D=3D=3D Mark Millard marklmi at yahoo.com