Re: Should a UFS machine have an ARC entry in top?

On 2022-Jan-29, at 12:43, bob prohaska <[email protected]> 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