Re: Should a UFS machine have an ARC entry in top?
- In reply to: bob prohaska : "Should a UFS machine have an ARC entry in top?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 29 Jan 2022 23:30:35 UTC
On 2022-Jan-29, at 12:43, bob prohaska <fbsd@www.zefox.net> wrote:
> I just noticed a new line in top's output on a Pi3 running 13/stable:
>
> ARC: 3072B Total, 2048B MRU, 1024B Header
> 2048B Compressed, 20K Uncompressed, 10.00:1 Ratio
>
> 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?
>
> The system was last updated in mid January.
>
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
=> 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)
=> 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
===
Mark Millard
marklmi at yahoo.com