MacOS 26.3: Thunderbolt RAID disk sleep causes system-wide I/O stalls & hangs apps (Arctic/FCP libraries)

[stevef243]

macOS: Aggressive Disk Sleep on Thunderbolt RAID Causes System-Wide I/O Stalls, Hanging Third-Party Apps (e.g. Arctic/FCLM)

Apple Feedback Assistant ID:

DESCRIPTION OF THE ISSUE

macOS aggressively puts spinning-disk Thunderbolt RAID arrays to sleep after brief periods of inactivity (as short as 30–60 seconds), even with “Put hard disks to sleep when possible” disabled in System Settings.

When any application – including Arctic (Hedge), Final Cut Library Manager, Finder, or Final Cut Pro itself – subsequently attempts to access the RAID volume, the disk spin-up causes a system-wide I/O stall lasting anywhere from 10 seconds to several minutes. During this stall, the requesting application becomes completely unresponsive and often must be force quit.

This is not a network drive issue. The RAID is directly connected via Thunderbolt 4. No network volumes are mounted.

While this is not a Final Cut Pro bug per se, it directly impacts the FCP ecosystem because:

• FCP libraries stored on RAID arrays become inaccessible during spin-up stalls.
• Third-party FCP library management tools (Arctic / Final Cut Library Manager) that periodically scan library metadata are particularly affected.
• Professional FCP workflows depend on large Thunderbolt RAID storage that is disproportionately impacted by this macOS behaviour.

This issue has persisted across multiple macOS versions (at minimum Monterey through Tahoe 26.3) and has been independently documented by numerous users across different RAID hardware.

STEPS TO REPRODUCE

1. Connect a spinning-disk Thunderbolt RAID array (for example a Promise Pegasus unit) to a Mac via Thunderbolt 4.
2. Ensure no network drives are connected or mounted.
3. Open an application that accesses files on the RAID (for example Arctic, Finder, or Final Cut Pro).
4. Use the application normally for a few minutes – it will behave as expected.
5. Switch to another application or leave the Mac idle for 30–60 seconds.
6. Switch back to the application that accesses the RAID.
7. The application hangs / beachballs and becomes unresponsive while the RAID spins up.
8. In many cases, a force quit is required. The cycle repeats and is easily reproducible.

EXPECTED BEHAVIOUR

• macOS should honour the “Put hard disks to sleep when possible” setting when it is disabled.
• Disk I/O requests to a sleeping drive should not stall the entire system; they should be handled asynchronously with a reasonable timeout.
• Applications should not become permanently unresponsive while waiting for a drive to spin up.
• Ideally, macOS should provide APIs or mechanisms for apps to detect that a drive is in a spin-up state and handle this gracefully.

WORKAROUNDS IDENTIFIED

These workarounds reduce or eliminate the stalls, but should not be required for a directly attached Thunderbolt RAID:

• Using the Amphetamine app (Mac App Store) with its “Drive Alive” feature to periodically access the RAID volume and prevent it from sleeping.
• Running “caffeinate -m” in Terminal to create a disk idle sleep assertion while working.

Both approaches keep the RAID awake and largely avoid the freezes, which strongly suggests disk sleep / wake as the underlying cause.

EVIDENCE FROM OTHER USERS

There are multiple independent reports of similar behaviour with different Thunderbolt RAID setups:

• A Promise Pegasus32 R8 owner documented system-wide freezes of 2–15 minutes during RAID spin-up on macOS. During this time, the whole system appears frozen until the RAID finishes waking.
• A G-Drive RAID owner on a Mac Studio described the same pattern: whenever the drive goes idle – for instance when switching from an NLE to a browser for a short time – the entire system slows dramatically or appears to freeze until the RAID spins up again.
• SoftRAID developers have publicly stated that similar spin-up / spin-down cycling and stalls are caused by a macOS power management bug related to energy-saving requirements, noting that even wiped disks with no partition map show the same behaviour.
• Apple Community and other forums contain multiple reports of external drives causing system-wide beachballs or stalls during wake/spin-up, especially on Apple Silicon machines.
• macOS Tahoe 26.x also has additional reports of external drive recognition and ejection problems, which suggests that external storage handling in this OS generation still has rough edges.

(This report is based on my own reproducible behaviour, plus the above kinds of public reports; if useful, I can link specific examples.)

SYSTEM SPECS

• Mac: Mac Studio Ultra (M1 Ultra)
• macOS: Tahoe 26.3
• Storage: Promise Thunderbolt RAID (spinning disks), connected via Thunderbolt 4 (direct attached, no network)
• Volume format: [APFS or HFS+ – fill in your actual format]
• Affected apps:
  • Arctic (Hedge) / Final Cut Library Manager – hangs while scanning libraries on the RAID.
  • Finder and Final Cut Pro are also impacted by the same stalls when attempting to access media or libraries on the RAID during spin-up.
• Final Cut Pro: Latest version installed; libraries and media stored on the RAID.

WHY THIS MATTERS FOR FINAL CUT PRO

This is fundamentally a macOS disk power management and I/O handling issue rather than an application-level bug. However, it severely impacts the professional Final Cut Pro ecosystem:

• Many professional FCP editors use large Thunderbolt RAID arrays for libraries and media.
• When the RAID is allowed to sleep, any app that touches those libraries (FCP itself, or tools like Arctic/FCLM) becomes unreliable, appears frozen, and often must be force quit.
• This leads to data loss risk, user confusion (“this app is buggy”), and significantly reduced trust in FCP-based workflows on modern Macs.

Ideally the fix would be:

1. At the macOS level:

   • Honour the “Put hard disks to sleep when possible” setting.
   • Ensure that I/O to a waking drive is handled asynchronously so it does not stall the entire system or the calling process indefinitely.

2. At the application level (for third parties):

   • Apps like Arctic/FCLM could use asynchronous file access with sensible timeouts and better error handling when a volume is unresponsive.
   • However, these app-level mitigations should not be required if macOS power management and I/O scheduling are robust.

I am filing this here because FCP Cafe is a hub for serious Final Cut Pro users and has a track record of liaising with Apple. This storage behaviour has a direct and negative effect on professional FCP workflows that rely on Thunderbolt RAID.