From nobody Sat Jan 29 23:30:35 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 652011986C08 for ; Sat, 29 Jan 2022 23:30:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4JmVtx4C80z4XZ1 for ; Sat, 29 Jan 2022 23:30:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643499041; bh=tLem2j6G8Dbm3ZCt8M5/J9hkBJXBcclJSYanw9MfFSw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BGOFDIwb5djSmJKt9JSXMrQ8XiEjQa6NYbJ6boI/Z3bpz5s0pndEkQwGq2lq+hTFfuqPYQPx/Wov2DhX9lpX0LADHxXpUpkmVl90GrMmGkeGipbCSvqE0lbnpO1bpLeg/LwwY0aLmDr9YRNrL5DyByWzX77H0MWR9PK7eLqgluz4jnZylfE2XotE20GVRzaMmwf4XBOjFjBlXSxgsbVCnahFcxIbvYgswj2UVoXUwBVERD7Rq5utmLnAxH1YglEWPsdZ5EECO/emb/k9Lc+hBY09hsAth2VTQj6eqSp7m8ZxU+G5vMvWRRzsapCBcHk9dtLNDZylAnTtG0e2h8pokw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643499041; bh=1kVrT0Tj9xqUIHO5Zs3vP4AmG6nQ/dIVmQlnlUOWHgP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BKCXaSMdnIKUwIkgK1FYfW3DR92Z6F1Eurt6KtXaArhGXtY3qyMxGQNVcxg3hN6M6KXq9ty+PFpLrw5UPd1U7KyldvxjwL96pjlTz3N9HMbWRQ0i9r54rbjQATFzfgT2AOej59DeHLp6eVbE89PMTAoy8ager9W+ZWvLpOm973MfxM5DYagaZ2QgBZiUrrE/ewpD8lAG1ug+xb5aUMN8dlZE3KWdW59FyW8YnlURzFLDO4WOoIE9vNdqB2YYfQb3Z8+9jBNSRexxv5LvX9lYpUdrUlsTqnntZG48oFOdWXdiqgxmQlwSeaIxv/DyxmI00tQlb5mhbCwZTSrFkeDyZg== X-YMail-OSG: Ni6EWVwVM1lWwaQ1mZkgdE.GtBDGRsX4gxQZKBLwJiEhd899uWThO21GrWzq8bP k9hNuDpPViN9DrG_QlD6uJQxE8eZVLtmrqh6PULTjd752H82y5hs7hkWor7L4H3GgVi93AV2I3rG .KDef3xfYdYUw0cF5Emlsx4AfXX9mJnqjEAc0HUKKGA05XogOLbf7L.bqwZYwcnryCl3cFCqKruH szb_WUJIr3XjzMG24h2W5o85uNLuhN2vbR4JvIwXh2FS9bAEBN74mnay0ep9nZN3ZP5WsP9v5j5O .E8Ufdoy3zAMSPdfD7stGqy56YWj_c6Hu_JQph9tOO4gG0z8fSmw.xjAtXdKQnXAZI6DxOSjetPQ qPyrRJ4abdv9e7ZFSFSFmF.Uq69BKAyd2q2Uwsx.In265f1lm_VPPLfiO8jZdbf6dWsuNMT6VDGM r0KLeDiBHNnQJP0PTSE5HAEF9AeOQIGsufZZlBRGT9GW9BAATBuoWgewOkmK3LNgWATTaKswd_LS YKJmyIC2rU777vAlDK8xs3Xzi55qmsRGxQZINT2c7uOhRj.53Qq5p0eqmrDGYO3jTMTaagPqo5Zm BExaY_QpCFVejn2fkdleXjZra58l5JdG75o1.FvPbjXfE6tVGeg9TN3l7l06M.TBiaaaHtb4fXR8 XdNkXpWhzCVWq.1hglrrLBgr5n40QAVnFaDbg_xOJ3wnL3rzbxwbN_dc.foqxiYSvx1ALxhAs0UT HJ8Y5xS7Kb3Va1s6.jOgI8ZPpFsJqYio3fgGGd.GDysGHIQXbQFNAYALXeYULN37ycPqbwX7MRA2 ms1KigBijB2qvzO8erte0z_XHnn2F_dwzbIj9OYTXGpcer3jEP7FaCiw2uJ0Qpi3n0ThG7fSbAbd 4pBV3IMf0qsAgkEQHobjUFMpY_VXgPDC.vVq.bL4jgLDok7WbDWkYUBCNfOQP3sxJKhO_aVggzoR 78Zymn7ZPSE9a6n849EhYss5lncRR__vFWaTuv5whuWJDNratBSSbP3YPZhRQtTr7o05Iy8d10X. AmLcKam6a27.QTklPwl.9zEKZSA8M.ZmV3fkbDL7WweL6STdDp3740_SJkGr5M.VpbovodssSDmj S81zhJLJ.wQS2xL9zZh18m0VKGRSpju2SfeYbMZ6KKJusGoFLZN8Hnz108AggfbTf2RACsuQ7V2p ctXQrXHFuGgnd5KQbDgRO_cVTvh.Jr_l93.NSpFlDYk3122WKAAKeiTyi4ui2u8nGfF3tIO3YD3n Z_C6sLkWA6aVwVTx_lmJ9jNpvONB8LLe5Ro6cWjtVxJybxaZnYemAYCw7pDVimOAKskSFEDLwQmB WB9h7HhGW.Xqbz4gFJ_AmuGdSmSdQ2QDKkBVxAsHA3l5sEqtoHfl4GXT9evF48MTka8tJ4LtNoCk DElJlmUfrqmKLWTk_KJxlDmPVhOSqDW8dNgn6O.6TlNVhmjJngLxdNIL80ZG.XGxZ90NH5n36BBA 4OuwxDkXhG_TodwCZt3an3Vyt2GQOQqYwM7xd9Y7B.M84qHVhyOClsdy4gFimMIeW5PsX22pnH0h G3Dz2HE4RARPQ9A32wcJvrkKD2V_RIddH.W7aiVAwjGZx5vptJf41HAGOwtRwQaQvjtxF6ctw9j9 trL9uq01R_xhVxz_hC7A4auttDqme0aLxwLIt6ITMKM2U7zVE9yjG2.b3uIMIDey.KdQOVFk8V0M 35MffU4SsXQKVG8E0ZZ2lS2flycXwdDrCLZBDjJxLfvjNpSxV2KGNpcFwt4JwJztTm9G6fgGE_WA AWAJi6.867_s.oulrHkLhCv2W5jm5z9bV5nCWbiAODjTm8uYkPTzsFIzgCb214jE8JzawcCKpRI4 x5kG7BA.zQsF_st0lTN5Me7bltTUailJmGQgIVDCOQUOMZOGoSeZVRxx4P1LnNP.ajoLFDsMTWrR zzkS.re3dq4PV07wdcH8gu2Om0trPzkLrn2lkndAuQuyf7n_robiuIHr61Sqd0asW7.kwD6DoLd7 DRNYmjP4RkZta3MQmyDT.8vAjrisLVUak0RQCnnM63p_PR72DX0Wy0KSOvWard5jjkgFmh9pcFzs 8VIPaU9n7kDTabJIB1LmRQwJHkZt.jr93oGvDt0eMu4YIPL3q8nge_MosYBk8fVMA5_1Gzwr8wk9 HQqN8Ag0K8du_v7h9B9LJyB742Go4nNpec6KNpCbNaoqjTB1IaWdPqwz.nlqz5Di4AJdZp0Zqdgs 9XCDh8RQo_kyfGXFm5mqKo0e2KgWpU4bYFCPQK6.gMpR5nroV9nvnZIP.2P6qjNjWnliLMpG07gp BEDYxNKsfXBR3bFxC X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Jan 2022 23:30:41 +0000 Received: by kubenode505.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 01560994b95d37a55ad48dede05eb6fb; Sat, 29 Jan 2022 23:30:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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: <20220129204313.GA63030@www.zefox.net> Date: Sat, 29 Jan 2022 15:30:35 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4D29091D-AC99-4D8D-AC3C-646A05529E26@yahoo.com> References: <20220128182701.GA57479@www.zefox.net> <20220129204313.GA63030@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmVtx4C80z4XZ1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BGOFDIwb; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 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)[]; BLOCKLISTDE_FAIL(0.00)[98.137.69.83:query timed out]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4087 Lines: 135 On 2022-Jan-29, at 12:43, bob prohaska wrote: > 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 > The system was last updated in mid January.=20 >=20 A system can have multiple types of file systems, even on the same media (e.g., separate partitions). It can boot from either and have the other in use. Note: zpools (and ZFS) do not require partitioned drives. But my example context only uses partitioned drives to hold an zpool. ARC is for ZFS and its being in use suggests a ZFS file system is (or was?) at least slightly accessed at some point. What does: # gpart show -p show? For example, with 2 USB3 NVMe SSD drives plugged in, one being the boot drive, I get: # gpart show -p =3D> 40 1953525088 da0 GPT (932G) 40 532480 da0p1 efi (260M) 532520 2008 - free - (1.0M) 534528 29360128 da0p2 freebsd-swap (14G) 29894656 4194304 - free - (2.0G) 34088960 33554432 da0p6 freebsd-swap (16G) 67643392 58720256 da0p3 freebsd-swap (28G) 126363648 8388608 - free - (4.0G) 134752256 394264576 da0p4 freebsd-swap (188G) 529016832 8388608 - free - (4.0G) 537405440 1405091840 da0p5 freebsd-ufs (670G) 1942497280 11027848 - free - (5.3G) =3D> 40 1953525088 da1 GPT (932G) 40 532480 da1p1 efi (260M) 532520 2008 - free - (1.0M) 534528 515899392 da1p2 freebsd-swap (246G) 516433920 20971520 - free - (10G) 537405440 1342177280 da1p3 freebsd-zfs (640G) 1879582720 73942408 - free - (35G) Notice the freebsd-ufs at da0p5 (boot context) and the freebsd-zfs at da1p3 (just plugged in). Merely having plugged in da1 does not lead to ARC showing up in a new, temporary instance of top. But merely doing a: # zpool import to show what pools can be imported was enough for ARC to show up in yet another new instance top. For reference: # zpool import pool: zextu id: 7086474838335519206 state: ONLINE status: Some supported features are not enabled on the pool. (Note that they may be intentionally disabled if the 'compatibility' property is set.) action: The pool can be imported using its name or numeric identifier, = though some features will not be available without an explicit 'zpool = upgrade'. config: zextu ONLINE gpt/CA72zfs64GU ONLINE Having done the zpool import command, zfs.ko shows up in the kldstat output: # kldstat Id Refs Address Size Name 1 18 0xffff000000000000 12c5ee8 kernel 2 1 0xffff0000012c7000 423b70 zfs.ko 3 1 0xffff0000016eb000 256e0 cryptodev.ko 4 1 0xffff0000ffc00000 27000 nullfs.ko 5 1 0xffff0000ffc27000 24000 fdescfs.ko Merely unplugging da1 will not make zfs.ko go away. A new, temporary instance of top still shows the ARC at this point. Since the pool had not been imported, I unplugged da1 and then did the following: # kldunload zfs.ko # kldstat Id Refs Address Size Name 1 9 0xffff000000000000 12c5ee8 kernel 3 1 0xffff0000016eb000 256e0 cryptodev.ko 4 1 0xffff0000ffc00000 27000 nullfs.ko 5 1 0xffff0000ffc27000 24000 fdescfs.ko Starting another new, temporary instance of top no longer shows the ARC at this point. Booting with a freebsd-zfs partition present, for example, would likely lead to zfs.ko loading and the ARC showing up in a new, temporary instance of top. So a reboot's result is dependent on what the boot finds, so far as I know. Another relevant command if one or more pools have been imported is: # zpool list For reference for when no zpool has been imported: # zpool list no pools available =3D=3D=3D Mark Millard marklmi at yahoo.com