TL;DR
Media management apps (Radarr, Sonarr, Bazarr, Lidarr, TDarr, Plex/Jellyfin scans) constantly wake HDD pools because they traverse directory trees during scans. By exposing those libraries to apps through SSD-backed bind mounts, you can keep HDDs spun down during idle and routine scans while still storing the actual media on HDDs.
This does not move, duplicate, or break paths. It simply changes where apps look.
The Problem
On many TrueNAS SCALE systems, users notice that:
• HDD pools refuse to stay spun down
• Media apps wake disks even when nothing is streaming
• Power draw stays high despite idle workloads
The root cause is not reading large media files.
It’s metadata traversal.
Apps like Radarr, Sonarr, Bazarr, and Plex:
• Recursively scan directory trees
• Stat files, enumerate folders, read filenames
• Do this frequently and aggressively
Even with a ZFS special metadata vdev, directory traversal still touches the main pool enough to prevent disk sleep.
The Key Insight
Linux separates path resolution from data storage.
If an application walks a directory tree on an SSD-backed filesystem, the kernel can handle most of those operations without touching HDDs.
When the app actually opens a media file (for playback or import), then the HDD pool is accessed.
So the trick is simple:
Expose the library paths to applications from an SSD, but let those paths transparently point to the real HDD data.
This is done with bind mounts.
What a Bind Mount Does
A bind mount makes one directory appear at another path.
Example:
/mnt/hdd_pool/media/movies (real data, HDD)
/mnt/ssd_pool/scan/movies (empty directory on SSD)
Bind mount:
mount --bind /mnt/hdd_pool/media/movies /mnt/ssd_pool/scan/movies
Now:
• Apps scan /mnt/ssd_pool/scan/movies
• Linux resolves directory entries on the SSD path
• Actual file contents still live on HDD
• HDDs are only accessed when a file is opened
No symlinks. No copies. No duplication.
Why This Reduces HDD Spin-Ups
Before:
App scan → HDD pool → disks spin up
After:
App scan → SSD filesystem → HDD stays asleep
Only these actions wake HDDs:
• Playing a movie
• Importing a completed download
• Verifying file integrity
Idle scans and library refreshes no longer thrash the HDD pool.
Example Layout (Generic Paths)
Datasets
/mnt/ssd_pool/scan/
├── movies
├── series
├── music
└── books
/mnt/hdd_pool/media/
├── movies
├── series
├── music
└── books
Bind Mount Commands
mount --bind /mnt/hdd_pool/media/movies /mnt/ssd_pool/scan/movies
mount --bind /mnt/hdd_pool/media/series /mnt/ssd_pool/scan/series
mount --bind /mnt/hdd_pool/media/music /mnt/ssd_pool/scan/music
mount --bind /mnt/hdd_pool/media/books /mnt/ssd_pool/scan/books
Verify:
mount | grep scan
You should see the HDD paths mounted on the SSD locations.
Container Configuration
Point all media apps only at the SSD paths:
/movies → /mnt/ssd_pool/scan/movies
/series → /mnt/ssd_pool/scan/series
/music → /mnt/ssd_pool/scan/music
/books → /mnt/ssd_pool/scan/books
Download directories can remain on HDD or SSD as desired.
Plex/Jellyfin libraries should also reference the SSD scan paths.
What to Expect
• First rescan will still spin up HDDs (initial traversal)
• After that, routine scans stay on SSD
• HDD pool can finally enter standby
• Noticeable idle power drop
• No impact on playback or imports
This works alongside ZFS special metadata vdevs; it does not replace them.
Caveats
• Bind mounts are not persistent across reboot unless automated
• Use systemd mount units or init scripts to restore them
• Be careful not to mount over non-empty directories unintentionally
Why This Isn’t Widely Documented
This sits at the intersection of:
• Linux VFS behavior
• ZFS dataset design
• Container bind mounts
Each layer is documented individually, but the combined effect is rarely discussed.
Closing Thought
If your goal is:
• Quiet disks
• Lower idle power
• Less wear on HDDs
• Zero data duplication
This approach is surprisingly effective.
I’d be very interested to hear whether others see similar reductions in HDD spin-ups using this method.
ai helped format and grammar