Hi there, I'm a bit confused about the right settings. I searched the Forum and read the FAQ.

 

My scenario:

• Unraid 7.0.0
• Two ZFS pools, no traditional array:
  • "Pioneer" with one 2TB NVME
  • "Vault" with two mirrored 20 TB HDD and one 1TB (L2ARC) cache SSD
• Both pools hold ZFS datasets of the same name
• Both pools have a pre-allocated 20% dataset for keeping space usage below 80% 
• Mover has the following setting:
  • Move from primary ("Pioneer") to secondary ("Vault")
• All shares are user shares
• All shares are accessed via NFS, with the user share mounted by the consumers
• The plugin Mover tuner has the following settings (the current version as of this posting has no effect on achieving this goal, hence this post):
  • Move when primary is above 75%
  • Move until primary is below 60%
  • Don't move based on age
  • Move to secondary based on size
    • Size is set to 242GB
  • Sync primary to secondary (for "parity")

 

The goal

1. Keep files below a size threshhold on primary until a limit of allocated volume space is used, only move bigger files until that limit is reached
2. Use mover tuner to move files based on size (this is a feature offered by the plugin Mover tuner, but I feel the issue at hand is independent of the plugin)
   1. Mover tuner is not a must, in fact I would rather achieve this with a vanilla install of Unraid
3. Keep the HDDs of "Vault" spun down when
   1. Files below a certain size threshhold are accessed
   2. Files which are too big for "Pioneer" pool but reside on the L2ARC device of "Vault"
4. Spin the disk up to access big files which have been moved to secondary and don't reside on the L2ARC device

 

What I see

1. All files, even small ones, are immediately moved to secondary - this is independent of whether or not the move tuner plugin is active
2. The disks never spin down

 

Are there some crucial settings I might be missing or have wrong?

datengrab-diagnostics-20250227-1011.zip

Edited February 27, 20251 yr by Gymnae
add clarification that mover tuner is not the lone reason

11 minutes ago, Gymnae said:

All files, even small ones, are immediately moved to secondary

You would need to ask for help in the mover tuning plugin thread, since it's not working or configured correctly.

I did that as well, but the behavior described also appears without this plugin, hence this post

I guess the question (which I am not sure of the answer to) is whether ZFS pools allow disks to spun down in the first place?  If not then this may be a limitation of using ZFS.

2 hours ago, Gymnae said:

but the behavior described also appears without this plugin

The normal mover will move all files, that is normal, there's no option to not move small files.

 

1 hour ago, itimpi said:

I guess the question (which I am not sure of the answer to) is whether ZFS pools allow disks to spun down in the first place?

They do, as long as the pools are not used:

 

 

 

I know its an old thread but it was bugging me for sol long, after 2 full days with AI on the task this is what it came up with, the below is written by the AI so take it with a pinch of salt but it works for me apparently.

ZFS Pool HDD Spindown Fix — Unraid 7.x

Platform: Unraid 7.2.4 (ZFS pools on HDDs)  |  Problem: ZFS pool HDDs wake from standby within 30s of hdparm -y, despite zero user I/O

✅All 4 root causes identified and fixed — drives now stay spun down indefinitely.

The Problem

After setting up a ZFS mirror pool on two HDDs in Unraid 7.x, the drives refused to stay spun down. Manual spindown via hdparm -y /dev/sdX would put them in standby, but they'd wake within 15–30 seconds every time. Array disks (XFS) had no issues spinning down — only the ZFS pool was affected.

Root Causes (4 Found)

1ZFS Master Plugin — 30-Second Polling Loop

The ZFS Master plugin (zfs.master) runs an nchan poller in an infinite loop. The default refresh_interval is 30 seconds — it calls zpool status, zfs list, and related commands which access the pool's vdevs, waking any spun-down drives.

🔍 Diagnosis: After killing the ZFS Master poller process, drives still woke (proving additional culprits existed), but this was confirmed as one source.

✅ Fix: Set refresh to manual-only:

# /boot/config/plugins/zfs.master/zfs.master.cfg
[general]
refresh_interval=0

The plugin stays installed and fully functional — it just only polls when you manually open the ZFS Master page in the WebUI.

2SMART Polling (poll_attributes) — 30-Second Default

Unraid's emhttpd polls SMART attributes on all disks at the interval set by poll_attributes in /boot/config/disk.cfg. The default is 30 seconds. SMART queries send ATA commands that wake spun-down drives.

Array disks appear to have standby-aware skip logic, but ZFS pool disks do not benefit from this — they get polled regardless of power state.

🔍 Diagnosis: /proc/diskstats monitoring showed drives waking with zero write sectors — pointed to ATA-level commands (SMART) rather than filesystem I/O. The wake interval perfectly matched the 30-second polling.

✅ Fix: Change from 30 to 7200 (2 hours):

# /boot/config/disk.cfg
poll_attributes="7200"

Requires reboot to take effect. Drives will wake once every 2 hours for a SMART check, then spin back down after the configured idle timeout (e.g., 15 minutes). A value of 0 disables SMART polling entirely (not recommended).

3ZFS Transaction Group Timeout (txg_timeout) — 5-Second Default

ZFS flushes transaction groups every zfs_txg_timeout seconds (default: 5), even when there's zero pending data. This causes periodic metadata writes that keep drives active.

✅ Fix: Set to 300 seconds (5 minutes) via /boot/config/go so it persists across reboots:

# Add to /boot/config/go (before the last line)
echo 300 > /sys/module/zfs/parameters/zfs_txg_timeout

This is safe for a backup/archive pool. For pools with active writes, a lower value (30–60) may be more appropriate.

4Cache Dirs Plugin (dynamix.cache.dirs) — Periodicfind

The Dynamix Cache Dirs plugin runs periodic find commands to warm directory listings in RAM. If any share on your ZFS pool is in the plugin's include list, it will periodically walk the entire directory tree, generating heavy read I/O on the pool disks.

In our case, a backup share containing thousands of nested iCloud directories was in the include list — each scan read extensively from the ZFS pool drives.

🔍 Diagnosis: Used kernel ftrace to catch the exact process:

echo 1 > /sys/kernel/debug/tracing/events/block/enable
cat /sys/kernel/debug/tracing/trace_pipe | grep "sd[gh]"
# Caught: find-91408 reading blocks from sdg

✅ Fix: Remove ZFS pool shares from the cache_dirs include list:

# /boot/config/plugins/dynamix.cache.dirs/dynamix.cache.dirs.cfg# Remove your ZFS pool share names from both 'include=' and 'options=' lines

Then kill and restart the cache_dirs process:

pkill -f "scripts/cache_dirs"
# It will auto-restart, or reboot

Additional Fixes (May Also Help)

• Disable autotrim for HDD pools: zpool set autotrim=off <pool> — TRIM is useless for HDDs

• Set atime=off: zfs set atime=off <pool> — prevents access time updates on reads

• Check for btrfs cron jobs on ZFS pools: Unraid's Scheduler may generate btrfs balance/scrub cron jobs for ZFS pools (wrong filesystem type). Check /boot/config/plugins/dynamix/balance_*.cron and scrub_*.cron — delete any that reference your ZFS pool. Also check /etc/cron.d/root for active entries.

How to Diagnose Spindown Issues

Step 1: Baseline Test

hdparm -y /dev/sdX        # Spin down
sleep 30
hdparm -C /dev/sdX        # Check: "standby" = good, "active/idle" = something woke it

Step 2: Monitor Block I/O

# Watch /proc/diskstats for your drives (e.g., sdg)
while true; do
  grep "sdg " /proc/diskstats | awk '{print strftime("%H:%M:%S"), "reads:"$4, "writes:"$8, "read_KB:"$6/2, "write_KB:"$10/2}'
  sleep 15
done

If drives wake with zero write sectors, the cause is likely ATA commands (SMART polling, power management queries), not filesystem I/O.

Step 3: Pool Export Test (Definitive)

zpool export <pool>        # Detach pool from ZFS
hdparm -y /dev/sdX         # Spin down
sleep 120                  # Wait 2 minutes
hdparm -C /dev/sdX         # If standby: ZFS/related processes are the cause
zpool import <pool>        # Re-import when done

If drives stay in standby with the pool exported, the wake source is definitely something interacting with ZFS — not hardware or BIOS.

Step 4: Kernel Ftrace (Catch the Exact Process)

# Enable block-level tracing (no extra tools needed on Unraid)
echo 1 > /sys/kernel/debug/tracing/events/block/enable
cat /sys/kernel/debug/tracing/trace_pipe | grep "sdX"
# Output shows: processname-PID reading/writing blocks# Press Ctrl+C when done, then:
echo 0 > /sys/kernel/debug/tracing/events/block/enable

Step 5: Check zpool I/O

zpool iostat <pool> 5      # 5-second intervals# If all zeros but drives still wake → ATA-level commands, not I/O

BIOS Considerations

⚠️ Note: If you've disabled CPU C-States, Deep Sleep, or ASPM (e.g., for HBA/JBOD card compatibility), be aware these keep SATA controllers fully active at all times. While they don't directly wake drives, they remove the power-saving buffer that might otherwise mask brief wake events.

Summary

#	Culprit	Default	Wake Interval	Fix
1	ZFS Master plugin	30s refresh	Every 30s	refresh_interval=0
2	SMART polling	30s poll	Every 30s	poll_attributes="7200"
3	ZFS txg_timeout	5s flush	Every 5s	Set to 300 via /boot/config/go
4	cache_dirs plugin	Varies	Periodic	Remove ZFS pool shares from include list

Available Diagnostic Tools on Unraid

❌ Don't Work on Unraid

blktrace, strace, auditctl, fatrace, iotop

✅ Do Work on Unraid

hdparm -C, /proc/diskstats, zpool iostat, kernel ftrace, inotifywait

---

Tested on Unraid 7.2.4 with ZFS mirror pool (2×2TB HDDs) on a QNAP QXP-800eS JBOD card. After applying all 4 fixes, drives confirmed staying in standby for 5+ minutes (previously woke within 15–30 seconds every time).