Operator asked whether 512 GB justifies a ramfs for hot models, then
self-corrected toward ARC with a 128 GB cap.
- No ramfs/tmpfs tier. ARC is the same cache done adaptively: no curated
hot-list to rot, no boot-time copy-in, and the memory comes back under
pressure. Neither tier beats the host-to-VRAM PCIe hop anyway, so the
warm-load time is identical.
- 128 GB is below the OpenZFS Linux default of 50% of RAM, so doing
nothing already gives 256 GB. Recommend ~320 GB, not past ~75%.
- Recorded the one honest argument for tmpfs: safetensors mmap gets
double-buffered on ZFS-on-Linux, so a checkpoint can cost ~2x. Sized
for, not architected around.
- Flagged that this is not the idle-VRAM-is-reserved case: arc_max is a
ceiling on an elastic cache, not a preallocation.
- recordsize=1M cannot be won through zfs send, since recv reproduces the
source's block structure. Not worth losing incremental send over; the
128K cost on flash is metadata overhead, not throughput.
Memory-only; no version bump per the SemVer SKIP list.
vh
32fd1dbe4a