dohertj2
db35cffd8d
Assessed whether the TrueNAS VM can drop from 128 GB to 64 GB of RAM. It can, but zfs_arc_max is pinned by an explicit tunable (id 8, 96 GiB) rather than derived from RAM, so it does not follow the VM down. Left alone on a 64 GiB VM, ZFS would target an ARC larger than the whole machine - ARC grows until the kernel shrinker forces it back, giving continuous reclaim pressure and real OOM risk for smbd/nfsd/middlewared under a write burst. zfs_dirty_data_max (id 15) is pinned at 16 GiB and has the same problem at 25% of a 64 GiB box. The sizing evidence is the ARC ghost lists, which count blocks evicted and then re-requested - the direct measure of whether a larger cache would help. mru_ghost_hits was 4 and mfu_ghost_hits 0 against 70M hits, so nothing being evicted is being re-read. The working set is ~22 GiB (MFU 20.7 GiB serving 94% of hits, plus 1.3 GiB metadata); the other ~75 GiB of ARC is MRU holding streaming media and Veeam backup data read once. No dedup, no L2ARC, no apps or VMs, 1.78 GiB total process RSS. Also corrects two stale facts found while looking: mypool is ONLINE with no known data errors at 96.4T/55%, not DEGRADED at 83.5T - the scary zpool status banner is a latched historical flag clearable with zpool clear - and /etc/version reports 25.10.16.12.33, not 25.04.2.6. SSD_Pool and boot-pool rows were not re-verified and are marked as such. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>