Why Is My Mac Writing to Disk After a macOS Update?

A macOS update wakes Spotlight up, and mds_stores can write hard for hours. The panic move is to disable Spotlight. The right move is to measure whether the write rate is settling — because normal catch-up trends down, and only a stuck loop stays flat-high after the work is done.

By CoreGuard · Jul 15, 2026 · 17 min read

Why is my Mac writing to disk after a macOS update?

A macOS update often triggers extensive Spotlight re-indexing or index maintenance. While it catches up, short-lived mdworker and mdworker_shared processes scan files and extract content — heavy on CPU and reads — while mds_stores compresses and writes the results into the per-volume indexes. That store-side work makes mds_stores the prominent disk writer. Normal catch-up then declines toward the old baseline; a stuck loop stays flat-high after the update, migration, restore, or import is over.

That last distinction matters more than the size of one spike. A screenshot of Activity Monitor cannot tell you whether you are seeing hour three of a finite rebuild or day three of a loop that keeps feeding itself. Both can show mds_stores near the top. Both can make an Intel Mac’s fans audible. Both can add a conspicuous amount to an SSD host-write counter.

The right first move is therefore not to disable Spotlight. It is to identify the process family, measure its rate, and see whether that rate is settling. Everything below is the manual way to do exactly that — it is complete, and it uses only tools that ship with macOS.

What actually runs after an update

Spotlight is not one process. It is a pipeline, and the process names expose different parts of that pipeline.

• mds is the metadata server. The macOS mds(8) manual says it serves clients of the metadata APIs, including Spotlight. Think of it as the coordinator, not automatically the process doing every visible write.
• mdworker and mdworker_shared are worker processes. The mdworker(8) manual says they are used by mds to scan and index files when a volume is mounted or a file changes.
• mds_stores maintains the per-volume index stores. Howard Oakley’s measured log traces show workers extracting metadata and content, then mds_stores compressing that material and adding it to the Spotlight indexes. It is often the obvious store-side writer in Activity Monitor. (Howard Oakley, “In the background: Spotlight indexing”)

The workers are deliberately plural. A file has a type; Spotlight selects an importer for that type; a worker extracts searchable metadata or text; and the results have to be incorporated into the volume’s index. Oakley’s traces show multiple short-lived workers being spawned as files change. That makes one worker’s lifetime total less useful than the behavior of the whole mds family.

Updates are not the only trigger. A migration, restore, or large library import presents Spotlight with a large body of new or changed material. Apple explicitly describes Spotlight indexing after migrated data as an intensive task, and calls the resulting fan activity normal. (Apple, “About fans and fan noise”)

Apple also says indexing can take several hours depending on the number of files. It does not publish a universal completion time. (Apple, “If your Mac sleeps or wakes unexpectedly”) Oakley notes that some macOS upgrades have been followed by prolonged indexing reported over several days. That is an observation about specific upgrade behavior, not a rule that every Mac should take days.

One more boundary: a recently updated Mac may also be running photo analysis, security scans, cloud synchronization, and other maintenance. If photoanalysisd, a sync client, or another process owns the rising write counter, “Spotlight did it” is the wrong diagnosis. Start with the name.

Why indexing writes so much

A search index is not just a list of filenames. Spotlight reads attributes and, where supported, extracts searchable content. It creates posting lists, updates journals, merges newer entries into more stable index tables, and performs store maintenance. A full catch-up may repeat that work across a large part of a volume.

That explains the asymmetry people notice: the visible input may have been one macOS installer, but the aftermath touches thousands of files and rewrites index structures derived from them. A restore or photo import is even more direct — large numbers of objects arrive or change, and each eligible change becomes indexing work.

The index itself is also data on the SSD. Reading source files costs mostly reads; constructing, journaling, merging, and synchronizing the resulting stores costs writes. Oakley’s traces show mds_stores compressing extracted content before adding it to the index, plus later journal and store maintenance. This is why rebuilding an index cannot be a write-free remedy.

Do not confuse those writes with physical NAND traffic. NVMe Data Units Written is a host counter: the specification reports it in thousands of 512-byte units, so one raw unit represents 512,000 host bytes. Controller garbage collection and wear levelling happen below that counter. SNIA defines write amplification as NAND writes divided by host writes; without vendor controller data, the NAND side remains invisible. (NVM Express specification archive); (SNIA SSD-endurance paper)

An indexing spike is therefore real host I/O, but it is not, by itself, an SSD-danger signal.

The catch-up signature: high, then declining

Normal catch-up has an end condition. The update finishes. Migration Assistant stops transferring files. The restore completes. The photo library stops ingesting new originals. Spotlight works through the backlog, updates its stores, and the amount left to process shrinks.

The rate will not necessarily descend as a smooth curve. Workers can arrive in waves. Different file types cost different amounts to import. Store maintenance can produce a fresh burst after a quieter interval. A sleeping laptop may pause or defer background work and resume later.

The useful shape is broader:

1. mds_stores and workers are initially conspicuous.
2. Comparable observation windows show less write activity over time.
3. Worker counts and CPU use become intermittent.
4. The Mac returns toward its pre-update write baseline.

Apple’s documented “several hours” is a reasonable expectation for many cases, but not a deadline. A large migration can spill into the next day; Oakley reports that some upgrade-related maintenance has lasted longer. I do not call a job stuck merely because it exceeded somebody else’s stopwatch. I call it catch-up when the backlog is visibly shrinking.

The stuck signature: the input never ends — or the same work repeats

A stuck loop has no effective end condition. The mds family remains in roughly the same elevated write-rate band across comparable windows even though the update, restore, or import has finished. It may be genuinely retrying one failure, or it may be responding correctly to an external source that never stops changing files. Those are different causes, but they produce the same high-level shape: flat-high instead of declining.

Common hypotheses worth testing include:

• A malformed file or failing importer. Oakley documents mdworker or an importer repeatedly crashing on a file, restarting, and trying again. Repeated failure around the same path is much stronger evidence than a high CPU percentage. (Howard Oakley, “Spotlight problems: mds_stores and mdworker in trouble”)
• A damaged or dysfunctional index store. The store may fail to make lasting progress. Missing search results plus repeated store work supports this hypothesis; mds_stores merely being busy does not.
• A folder that changes continuously. Spotlight responds to new and changed files. A log directory, generated build tree, database, or other rapidly mutating content can keep supplying legitimate new work faster than indexing settles.
• Cloud sync or backup churn. A sync client may download, rename, evict, or recreate objects. A backup volume may remain active or repeatedly appear. In that case Spotlight is downstream of the churn, not its origin.
• A third-party “cleaner” or maintenance utility. If one tool repeatedly removes material and another component recreates it, the resulting file changes can keep background services busy. Do not assume every cache is indexed; prove the path and process relationship first.
• A volume that repeatedly disconnects or remounts. The mdworker(8) manual explicitly includes scanning and indexing when a volume is mounted. A flaky external disk can repeatedly present work that looks like one endless indexing job.

The important phrase is “after the underlying work has finished.” A 2 TB photo import that is still copying is not a stuck Spotlight loop, because its rate remains level while the copy runs. Neither is a cloud client that still has a real queue. First establish that the source workload stopped; only then interpret a persistent flat-high index rate as pathological.

The decisive test is the write-rate trend

One snapshot tells you who has accumulated bytes since launch. A trend tells you whether that behavior is converging.

Apple says Activity Monitor’s Disk view reports disk accesses and the amount read or written. Its Bytes Written column is accumulated, not a current rate. Take two readings over a known interval and subtract them. (Apple, “View disk activity in Activity Monitor”)

Do this in comparable windows across several days:

mds_stores write rate =
    change in Bytes Written during the window
    ÷ elapsed time

Use the same class of window: Mac awake, similar foreground workload, and no new import deliberately started midway. A two-reading delta is only meaningful for a stable process, so measure it on mds_stores — the store-side writer that persists across the window — and discard the window if mds_stores itself restarts between readings. The mdworker processes are short-lived: one can spawn and exit between your two snapshots and never appear in an endpoint subtraction, so capture worker activity with the bounded fs_usage trace below rather than differencing worker counters. Compare the mds_stores window rates across days.

The interpretation is deliberately qualitative:

• Declining: day two is clearly below day one, later windows become intermittent, and the total system-write rate returns toward baseline. That supports catch-up.
• Flat-high: comparable windows remain elevated after the source work has stopped, with no meaningful downward drift. That supports a stuck or continuously fed loop.
• Unrelated: whole-drive writes remain high but the mds family does not. Find the actual writer.
• Noisy: sleep, new imports, backups, or foreground work changed between samples. The comparison is not valid yet.

For path evidence during an active window, take a bounded 30-second sample:

sudo fs_usage -w -f filesys -t 30

Apple documents fs_usage as a live stream of filesystem calls, paths, requested byte counts, and process names; it requires elevated privileges. It is evidence about live logical filesystem activity, not a multi-day recorder or a physical NAND counter. (Apple Developer, “Examining File-System Usage”)

The detailed workflow for separating process, path, and device evidence is in the companion guide to finding which app is writing to your Mac’s SSD. If you also bracket whole-drive Data Units Written, remember that it includes every writer and cannot attribute the delta to Spotlight. The companion guide to how much SSD writing is normal on a Mac covers that counter math and baseline method.

The trend is decisive only when joined to attribution. A falling whole-drive rate plus declining mds activity is strong catch-up evidence. A flat whole-drive rate with a quiet mds family is evidence that you are investigating the wrong process.

Why “disable Spotlight to save your SSD” is the wrong reflex

There are three separate problems with that advice.

1. A rebuild is itself a write-heavy job

The mdutil(1) manual says -E erases each indicated local store and lets it be rebuilt where appropriate. The command’s own help describes it more bluntly as “Erase and rebuild index.”

sudo mdutil -E /

That command discards completed index work and creates a new indexing job. The rebuilt store must be written back to disk. Its size and write cost depend on the indexed corpus, so I will not invent a universal GB figure, but it is not free. Oakley specifically warns that forcing a full reindex is likely to take longer than letting prolonged maintenance finish.

Apple’s supported graphical procedure likewise turns indexing off and back on for the affected item, after which Spotlight reindexes it. Apple recommends this for unexpected search results — not as routine treatment for a large write counter. (Apple, “Rebuild the Spotlight index”)

2. Disabling indexing has a real functional cost

The manual says -i on|off changes indexing status and -a applies the command to all stores on all volumes:

sudo mdutil -a -i off

That is a very wide switch. It stops the indexes from being kept current across all volumes. Local search results can become stale or incomplete, and apps or macOS features that query Spotlight metadata lose current index data. Strictly speaking, -i off is not the same option as -d, which the manual assigns to disabling Spotlight searches on a volume; the practical problem is that search backed by an index you no longer update degrades over time.

The command help notes that state-changing local-volume operations should run as root, hence sudo. mdutil -s /, by contrast, is the read-only status check.

3. For normal catch-up, disabling mostly postpones the bill

If Spotlight has a finite backlog and the rate is already declining, stopping it does not remove the need for a current index. When indexing is restored, macOS still has changed files to process — and an explicit erase-and-rebuild creates even more work. You have traded one observable burst for interrupted or repeated indexing plus degraded search in between.

Disabling is defensible only as a last-resort containment step for a proven persistent loop whose cause cannot otherwise be stopped. Even then, scope it to the affected volume or location rather than reflexively using -a, document the search tradeoff, and expect renewed indexing when it is re-enabled.

How to tell normal indexing from a stuck loop

1. Confirm the indexing state, but do not mistake it for progress. Run mdutil -s /. The mdutil(1) manual defines -s as displaying the indexing status of the listed volume. “Indexing enabled” means indexing is allowed; it does not prove that a rebuild is active, complete, healthy, or making progress. If indexing is disabled, a normal catch-up explanation becomes less likely.
2. Verify that the writer is actually the Spotlight process family. Open Activity Monitor, choose View → All Processes, then inspect both CPU and Disk. Look for mds, mds_stores, mdworker, and mdworker_shared. mds_stores is the persistent store-side writer; the mdworker processes are short-lived scanners that drive CPU and reads. Take two Bytes Written readings of mds_stores over a known interval; a worker that spawns and exits between readings will not appear in that delta, so treat workers through the fs_usage trace. If another process’s counter is climbing while the mds family is quiet, stop calling the event Spotlight indexing.
3. Use fs_usage for a short live path sample. Run a bounded sample — sudo fs_usage -w -f filesys -t 30 — while the behavior is occurring. Look for repeated mds-family activity around the same path family, volume, or file type. The output is noisy and contains private paths, so sanitize it before sharing. A broad stream followed by a focused investigation is safer than assuming the first visible path is the cause; the full interpretation method is in the linked per-app disk-writing guide.
4. Take a baseline, then re-read it across several days. Use comparable awake windows and calculate the within-window Bytes Written delta for the stable mds_stores; discard a window if it restarts, and capture transient mdworker processes with a bounded fs_usage trace rather than differencing their counters. Record whether the update, restore, sync, or import was still active. If available, bracket the same windows with whole-device Data Units Written readings, but keep that host counter separate from process attribution and physical NAND writes. Normal catch-up should trend down across the wider sequence, even if individual minutes are lumpy. A flat-high rate after the input workload has stopped is the signal to investigate further.
5. If it is flat-high, identify the thing feeding or repeating the work. Pause only a specific, reversible suspect: quit the cloud client that is visibly churning the same path, stop the third-party maintenance utility involved, finish or pause the import, or disconnect a repeatedly remounting external volume when it is safe to do so. Then repeat the same observation window. If the mds rate falls, you found an upstream contributor. If it does not, restore the paused component and test the next evidence-backed hypothesis. Do not delete caches, indexes, or files merely because their names appeared in a trace.
6. Treat disabling or rebuilding as an explicit last-resort tradeoff. Rebuild only when search or store evidence supports a damaged index and you accept a fresh write-heavy pass. Disable indexing only when the loop is proven, the specific cause cannot be stopped, and degraded search is acceptable. Neither operation is an SSD-protection ritual.

The whole method is free: mdutil, Activity Monitor, and fs_usage ship with macOS. A spreadsheet or plain text file is enough to preserve the daily measurements.

Where CoreGuard fits

The manual method works. Its weakness is timing. Activity Monitor gives you the process while you are looking; fs_usage must be running during the event; and a hand-built multi-day trend exists only if you remember to take comparable readings.

CoreGuard automates that passive observation. In Free, the abnormal-write warning is free and it names the process responsible — for example, that mds_stores is writing abnormally. Basic SSD health and danger warnings remain free. You do not pay to learn that something changed.

Pro adds the detailed multi-day per-app write timeline, longer history, and export. That is the useful view here: a normal post-update mds_stores curve slopes back toward baseline, while a stuck loop remains flat-high across the same span. Pro also includes the deeper SSD-endurance detail and wear trend; those remain estimates and counters, never a failure date.

CoreGuard observes and explains. It never throttles, blocks, disables, or modifies Spotlight — or any other writer. It does not claim to change SSD endurance. The complete no-purchase method is above; Pro is for retaining the detailed timeline and evidence after the moment has passed.

Frequently asked questions