Spotlight problems

The index in .Spotlight-V100

Updated 2026-08-08 · 4 min read

Every volume carries a hidden .Spotlight-V100 folder holding its search index. Occasionally it grows enough to be noticed by a disk-space hunt, and deleting it by hand is exactly the wrong reflex.

Where it lives, what it holds

At the root of each indexed volume, /.Spotlight-V100 holds the metadata and content index the mds processes maintain: filenames, attributes, and extracted text from documents. Root-owned; measuring it needs sudo:

sudo du -sh /.Spotlight-V100

Typical sizes run from hundreds of megabytes to several gigabytes, scaling with file count and how much content (mail, PDFs, source) the volume carries. Multi- gigabyte indexes on document-heavy disks are normal, not a malfunction.

When it is genuinely bloated

An index that dwarfs its volume's contents, or keeps churning (visible as constant mds_stores activity), is usually corrupt. The supported reset:

sudo mdutil -E /

erases and rebuilds the index for the volume through the indexer itself. Deleting the folder with rm achieves the same end state minus the guarantees — mdutil exists so you never have to.

Turning it off where it is pointless

Archive drives that mount twice a year restart indexing on every mount and rarely finish. For those:

sudo mdutil -i off /Volumes/Archive
sudo rm -rf /Volumes/Archive/.Spotlight-V100

— the one case where removing the folder is fine, *after* indexing is disabled, to reclaim its space on a drive Spotlight will no longer touch. Note what is lost: no Spotlight results from that volume at all. Index-based third-party tools fill that hole with their own stores, which persist across mounts and live in their own space accounting.

The size question in context

Against modern disks, the index is cheap for what it buys on the boot volume. The space wins live elsewhere — snapshots, caches, forgotten videos — and the index makes a poor scapegoat for a full disk.

Common questions

Is it safe to delete .Spotlight-V100?

Use sudo mdutil -E instead — same rebuild, done properly. Manual deletion is only sensible on volumes where indexing is being disabled.

Why is mds_stores using so much CPU?

The indexer is working — normal after big file changes, suspicious when constant. A rebuild with mdutil -E usually settles a churning index.