[Bug 209396] ZFS primarycache attribute affects secondary cache as well

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209396

Bryan Drewery <bdrewery@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bdrewery@FreeBSD.org
             Status|New                         |Closed
         Resolution|---                         |Works As Intended

--- Comment #1 from Bryan Drewery <bdrewery@FreeBSD.org> ---
I didn't realize this until today myself but this is working as intended. L2ARC
only takes metadata/data from ARC before it is evicted. So if using
primarycache=metadata then data can never make it to L2ARC since it was not in
the ARC.

https://www.mail-archive.com/zfs-discuss@opensolaris.org/msg45601.html

I can't find a great source for this (in a manpage) but the code spells it out.
sys/contrib/openzfs/module/zfs/arc.c

    * 2. The L2ARC attempts to cache data from the ARC before it is evicted.
    * It does this by periodically scanning buffers from the eviction-end of
    * the MFU and MRU ARC lists, copying them to the L2ARC devices if they are
    * not already there. It scans until a headroom of buffers is satisfied,
    * which itself is a buffer for ARC eviction. [...]

It also won't cache prefetched data by default. Apparently
primarycache=metadata also effectively disables prefetch
(https://github.com/openzfs/zfs/issues/1773)

https://github.com/openzfs/zfs/issues/12028 discusses this primary bug's issue
and the fact that this primary=metadata,secondary=all setup can lead to read
amplification too.


If I've misunderstood and your report is about the fact that
already-cached-in-ARC data is not sent to L2arc and you think it should I think
a better place to report is https://github.com/openzfs/zfs anyway. I doubt they
would handle that as it's quite a hack to set primarycache=all, cache a bunch
of data, and then change to metadata and expect it to fill up L2arc. Eventually
that data would leave the l2arc as well and you would need to manually do the
hack over again.

-- 
You are receiving this mail because:
You are the assignee for the bug.