meaning

@mmm77 good question, and thanks for the screenshots — they confirm exactly what I found when I dug into this. The honest answer: most of that 79% "Other activity" is time where nothing was working on your disks at all. Disk Talkers was counting every sample window where a disk was awake but had no identifiable activity as "Other activity". So when a disk spins up and then just stays awake until the spin-down delay kicks in, all those idle hours got labeled "Other activity" — which makes it look like some mystery app is hammering the disk. That was misleading, and it should be fixed in 2026.08.24b. Two changes: First: windows where the disk was awake but did (almost) no real I/O are now labeled "Idle (spun up)". The interesting question then becomes what woke the disk up — that is what the spin-up sessions table under each disk is for. Second: when there IS real disk I/O but no identified app, the plugin now makes a last attempt to name the process/container holding the disk before falling back to "Other activity". So the remaining "Other activity" should shrink a lot. Existing history will not be relabeled, but new samples after updating should mostly show "Idle (spun up)", real app names, and only a small "Other activity" remainder. Could you update, let it run for a day, and tell me how the split looks? If you still see big genuine "Other activity" blocks after that, a fresh state.json would help me dig further. By the way, I also took the opportunity to tidy up the charts while I was in there: the timeline and the usage donut now render properly at any resolution — no more giant axis labels on wide monitors, and the layout stays proportioned on ultra-wide screens.

@hollowimage thanks for the detailed report, much appreciated — all three points were real issues, and I've just pushed 2026.08.20a that should address them: Tools menu: you were right — Disk Talkers relied on the "System Information" section being defined by another plugin (that's why installing File Activity made it appear). The plugin now ships its own section definition, so it should show up on a stock system. Light theme: the page was guessing the theme from the page background color, and on some themes that guess failed, leaving dark-theme colors on a light host. It now reads the actual Unraid theme server-side, and I moved the remaining hardcoded colors to theme variables. I mostly run dark themes myself, so if you spot anything still hard to read after updating, a screenshot would help me a lot. Truncated names: names can now wrap to two lines instead of being cut off, and hovering any name shows the full text — so the last octet of the address should be visible now. Could you update the plugin, hard-refresh the page, and let me know if all three look right on your side? I could only fully test 1:1 on my own box, so your confirmation on 7.3.1 with the light theme would be really valuable. @hollowimage thanks for the detailed report, much appreciated — all three points were real issues, and I've just pushed 2026.08.20a that should address them: Tools menu: you were right — Disk Talkers relied on the "System Information" section being defined by another plugin (that's why installing File Activity made it appear). The plugin now ships its own section definition, so it should show up on a stock system. Light theme: the page was guessing the theme from the page background color, and on some themes that guess failed, leaving dark-theme colors on a light host. It now reads the actual Unraid theme server-side, and I moved the remaining hardcoded colors to theme variables. I mostly run dark themes myself, so if you spot anything still hard to read after updating, a screenshot would help me a lot. Truncated names: names can now wrap to two lines instead of being cut off, and hovering any name shows the full text — so the last octet of the address should be visible now. Could you update the plugin, hard-refresh the page, and let me know if all three look right on your side? I could only fully test 1:1 on my own box, so your confirmation on 7.3.1 with the light theme would be really valuable.

Hm, ok, it looks like on your system Disk Talkers is running again, but still cannot attach the activity to a named app/container/process. Could you please share the output of this command after one of those disks has spun up and still shows unattributed activity? cat /tmp/disk.talkers/state.json Also useful: - your Unraid version - whether the apps use /mnt/user/... or /mnt/diskX/... paths - any syslog lines around the spin-up time That should show me where the attribution is being lost.

Hey mmm77, Thanks for the report. This should be fixed in Disk Talkers 2026.06.03a. The error means that one of the Unraid mount paths Disk Talkers was watching briefly disappeared or changed while the collector was running. Disk Talkers was handling that too aggressively and could disable fanotify permanently until restart, which then made historical attribution fall back to “Other activity”. This is not, by itself, proof of a failing disk. But if you keep seeing similar mount-related warnings after updating, it would be worth checking your Unraid syslog, disk/pool mount state, and SMART reports for any recurring disk, controller, or filesystem issues. Existing historical “Other activity” entries will not be retroactively fixed, but new samples after updating should keep fanotify active and preserve attribution much better. Let me know if it's allright now ! :)

Yes, you were right. I profiled it and Disk Talkers was doing too much work every 5 seconds, mainly repeated fuser scans and history recalculation. This is fixed in 2026.05.03a; on my test server it dropped from about 15.6% of one CPU to about 1.25%, while keeping the 5s UI refresh.

Thanks for the report. This was caused by Disk Talkers starting after reboot with a reduced service PATH, so it could not find Unraid’s mdcmd binary. This should be fixed in 2026.04.26a: update/reinstall the plugin and it should recover after reboot without needing an uninstall/reinstall. let me know if the problem is fixed at your next reboot ;)

Thanks, you were right: on Unraid 6.12+ exclusive pool-only shares can make /mnt/user/<share> resolve directly to the pool and bypass shfs/FUSE. Disk Talkers 2026.04.21a now treats those mounts as safe, while non-exclusive pool-only /mnt/user mounts remain low-severity informational warnings.

I’ve pushed a light-theme compatibility fix. :)

can you update and let me know if this would be ok ?

Fixed in 2026.04.17c. The historical summary panels were using a layout combination that could visually overflow the parent card. I’ve corrected the panel sizing/containment and published the update. Please update the plugin and hard-refresh the page and let me know ;)

Hey there, can you update the plugin and see how it looks now ?

Disk Talkers adds a dedicated Unraid page to show what is actively keeping array disks and pools spun up. The goal is simple: make it easier to understand which apps, containers, VMs, or host-side activity are touching your storage, and help reduce unnecessary array spin-ups. What it shows - Per-disk live status spun up / spun down) - Current read/write throughput - Live disk users, including: - Docker containers - VMs - host services - user-share access through shfs - Array-wide summary of apps currently keeping HDDs spun up - Historical usage views across: - Daily - Weekly - Monthly - Yearly - Historical attribution estimates showing which apps were most involved in keeping disks active - Estimated HDD energy usage and electricity cost based on configurable watt ranges and tariffs - Mount audit to highlight containers using /mnt/user or array-backed paths where a direct pool/cache path may help avoid unnecessary spin-ups Why this exists On many Unraid systems, disks stay spun up and it is not always obvious why. Sometimes the cause is direct array access. Sometimes it is a container using /mnt/user/... instead of a direct cache or pool path. Sometimes it is a service or background scan that keeps touching files often enough to prevent spindown. Disk Talkers is meant to make that visible. ## Main features - Dedicated Unraid WebUI page - Live refresh - Disk-by-disk visibility - Historical usage overview - Mount-path audit for Docker containers - Estimated power and cost visibility - Quick actions and configuration inside the plugin UI Install Until Community Applications listing is live, the plugin can already be tested with the direct plugin URL. WebUI method 1. Open your Unraid WebUI 2. Go to Plugins 3. Click Install Plugin 4. Paste this URL: https://raw.githubusercontent.com/silkyclouds/unraid-disk-talkers/main/disk.talkers.plg CLI method installplg https://raw.githubusercontent.com/silkyclouds/unraid-disk-talkers/main/disk.talkers.plg GitHub Source and releases: https://github.com/silkyclouds/unraid-disk-talkers Notes - Attribution is best-effort. Very short-lived activity may still appear as residual or unattributed activity in history views. - Energy and electricity cost values are estimates based on HDD uptime history plus user-configured watt and tariff settings. - This plugin is intended to help identify real-world storage behavior, not to claim perfect block-level forensic attribution. Feedback Bug reports, screenshots, edge cases, and UI/UX feedback are very welcome, especially for: - shfs / user-share attribution - incorrect container attribution - historical attribution gaps - cases where cache/pool mounts should be preferred over array-backed paths - installs and upgrades across different Unraid versions

Hey, I’m running into the same headaches with S3 sleep on Unraid, so I figured I’d share my setup and ask for advice. Main server with a big array + HBA → ~95 W idle Base system alone (CPU/RAM/fans, no HBA/array) → ~25 W idle So ~70 W are literally wasted 24/7 just to keep the array/HBA alive Electricity here is ~0.38 €/kWh → that’s expensive over a year So, I've built a low-power N100 box at ~12 W idle to host all Dockers/VMs and be the “master” Idea: keep the array sleeping and only wake it with WOL + autofs/NFS when files are needed The problem: one wake ended up with a disabled/emulated disk and a full rebuild. That scared the hell out of me, and honestly I don’t trust S3 sleep anymore with this setup. So I’m thinking: instead of sleep, maybe just fully shutdown the array server when idle and WOL it when needed. Downside: boot time ~1–2 minutes, which is annoying. But this box does nothing except serve the array (no Dockers, no VMs). But the idea of waiting 2 minutes before I can start a movie or listen to a music album ain't nice... Question: is there a way to make Unraid boot in a really “lightweight” mode just for the array? Like, disable every unnecessary service/plugin so the boot + array mount is as fast as possible? Has anyone here tuned Unraid this way? Or, is anyone here actually happy and safely using S3 using a great pre-sleep script ?

Done. Thanks !