Post-Install: Storage

Optimize ZFS ARC size

The Adaptive Replacement Cache (ARC) is ZFS's in-memory read cache. Without explicit tuning, ZFS happily grabs up to half the host RAM for itself, which is excessive on a Proxmox host that also needs memory for VMs and LXCs. This option caps ARC to a sane fraction of total RAM based on the size of the machine.

Sizing rules

On a 64 GB host, that means an 8 GB cap for ARC. The file /etc/modprobe.d/99-zfsarc.conf contains a single directive — options zfs zfs_arc_max=…. Every other ZFS module parameter (zfs_arc_min, L2ARC prefetch/write throttle, TXG timeout) is left at its OpenZFS default. After writing the file, ProxMenux runs update-initramfs -u -k all and, when applicable, proxmox-boot-tool refresh, so the cap also lands in the initramfs used by ZFS-on-root setups.

Verification and manual rollback

# Check the config file is in place
cat /etc/modprobe.d/99-zfsarc.conf

# After reboot, check actual ARC limits (in bytes)
cat /sys/module/zfs/parameters/zfs_arc_min
cat /sys/module/zfs/parameters/zfs_arc_max

# Manual rollback
rm /etc/modprobe.d/99-zfsarc.conf
update-initramfs -u -k all
# (reboot for ZFS to load with defaults again)

Install ZFS auto-snapshot

Installs the zfs-auto-snapshot package and rewrites its cron schedules so snapshots are taken automatically at several intervals. A great no-effort safety net on top of your regular vzdump backups.

Snapshot cadence ProxMenux configures

Verification and manual rollback

# List existing auto-snapshots across all ZFS datasets
zfs list -t snapshot | grep zfs-auto-snap

# Check the schedules
grep . /etc/cron.d/zfs-auto-snapshot /etc/cron.hourly/zfs-auto-snapshot \
       /etc/cron.daily/zfs-auto-snapshot /etc/cron.weekly/zfs-auto-snapshot \
       /etc/cron.monthly/zfs-auto-snapshot

# Manual rollback (removes the package + destroys no snapshots)
apt purge zfs-auto-snapshot
# Existing snapshots remain on your pools unless you destroy them explicitly

Enable ZFS autotrim (SSD/NVMe pools)

Enables the autotrim property on every ZFS pool that is backed exclusively by SSDs or NVMe drives with TRIM support. Pools that include a single HDD vdev are skipped automatically — TRIM on rotational drives is meaningless and ZFS will refuse it. Pools that were already set to autotrim=on are left as they are.

What TRIM does, and why it matters on ZFS

SSDs / NVMe drives manage internal storage in fixed-size erase blocks that are much larger than the logical sectors the filesystem talks to. When a filesystem deletes a file, the drive doesn't know — it still thinks those sectors are in use, so its internal garbage collector keeps shuffling stale data around to free new erase blocks. TRIM is the standard command the OS uses to tell the drive "these sectors are now free, you can erase them ahead of time".

Without TRIM, SSD performance degrades over time as the drive runs out of pre-erased blocks and has to do erase-on-write, and write amplification increases — both shortening the drive's useful life. With TRIM enabled, the drive can keep a healthy pool of empty blocks ready to write into.

On ZFS, autotrim=on is the modern equivalent of the periodic zpool trim <pool> command — instead of having to remember to run a trim manually (or schedule one), the pool issues TRIM commands automatically and continuously as blocks become free. It's low-overhead and the recommended setting for SSD-backed pools.

Why is this practical to enable?

• Sustained write performance. SSDs that never see TRIM commands slow down measurably over months. Autotrim keeps the controller's job easier.
• Drive longevity. Lower write amplification means fewer total NAND writes for the same amount of data — measurable in years of useful life for the disk.
• No scheduled cron job to remember. Unlike a periodic zpool trim, autotrim is fire-and-forget — the pool handles it on its own.

When is this necessary?

• You should enable it on any ZFS pool whose vdevs are all SSD or NVMe with TRIM support — the typical Proxmox install on consumer or enterprise SSDs.
• The script skips it automatically on:
  • Pools containing any HDD (rotational) vdev — TRIM is meaningless there.
  • Drives without discard_granularity exposed in sysfs — usually old SSDs without TRIM, or pass-through paths where the OS can't see the underlying device.
  • Pools where ZFS itself reports the property unsupported (rare; very old pools).
  • Pools already set to autotrim=on (no-op).
• Not relevant on ext4-only hosts — there's nothing for ZFS to trim. The function exits with a friendly message in that case.

Manual equivalent (run on your server)

The full sequence the script runs against each pool is replicable by hand. This is what you would type if you wanted to do the same thing on a single pool without ProxMenux:

# 1. List your ZFS pools
zpool list -H -o name

# 2. Check the current autotrim setting on a pool
zpool get autotrim <pool>

# 3. Verify the pool is backed by SSD/NVMe with TRIM support
#    For each vdev (use the device path you see in 'zpool status -P <pool>'):
DEV=sda      # replace with the actual short name (sda, nvme0n1, ...)
cat /sys/block/${DEV}/queue/rotational           # must be 0 (SSD/NVMe, not HDD)
cat /sys/block/${DEV}/queue/discard_granularity  # must be > 0 (TRIM supported)

# 4. Turn it on
zpool set autotrim=on <pool>

# 5. Confirm
zpool get autotrim <pool>

Verification and manual rollback

# Verify autotrim is active on every pool ProxMenux touched
cat /usr/local/share/proxmenux/zfs_autotrim_pools
while read -r p; do
  zpool get autotrim "$p"
done < /usr/local/share/proxmenux/zfs_autotrim_pools

# Manual rollback — disable autotrim on a specific pool
zpool set autotrim=off <pool>

# Or revert all pools ProxMenux changed (manual equivalent of the Uninstall option)
while read -r p; do
  zpool set autotrim=off "$p"
done < /usr/local/share/proxmenux/zfs_autotrim_pools

Increase vzdump backup speed

By default, Proxmox vzdump throttles backups to protect running VMs/CTs from IO starvation. On many setups that throttle is more conservative than needed. This option removes the bandwidth cap and lowers the I/O priority so vzdump can saturate the storage path during backup windows.

What gets changed in /etc/vzdump.conf

bwlimit: 0      # No bandwidth limit (was capped by default)
ionice:  5      # Lower I/O priority (5 = best-effort class, lowest priority in that class)

Verification and manual rollback

# Check current vzdump config
grep -E "^(bwlimit|ionice):" /etc/vzdump.conf

# Manual rollback (comment out the two lines — restores Proxmox defaults)
sed -i 's/^bwlimit: 0/#bwlimit: KBPS/' /etc/vzdump.conf
sed -i 's/^ionice: 5/#ionice: PRI/' /etc/vzdump.conf

Related

• ZFS Management commands — zpool / zfs reference for ARC, snapshots, scrub.
• Storage and Disks commands — generic block-device and Proxmox storage reference.
• Backup and Restore commands — vzdump CLI reference (now without the legacy bwlimit / ionice caps).
• Uninstall Optimizations — revert ARC / vzdump changes.
• Log2RAM — reduces SSD/NVMe wear by ramdisk-backing /var/log; documented under Optional.
• Customizable Post-Install — back to the parent menu.