.Spotlight-V100 grows to 130+ GB on macOS 15/26 — IVFVectorIndex fails to unlink stale vectors (logs + temporal fix inside)

Try using the -X option to delete the folder instead of just vacuuming the database with -E. You’ll need to restart or log out/in after enabling indexing (-i on /).

ZigmaSdirigeant wrote:

Hi guys!

tsk...tsk...gendered language

On node_modules and Docker: these are essentially on every developer's machine. Nothing odd there. Mine runs a normal development workload, React projects and a couple of local databases, nothing exotic. I listed them because they're common culprits for index bloat and worth excluding regardless of the IVFVectorIndex bug.

They're not on my machine and I'm a developer. What you describe is most definitely odd and exotic for a Mac.

But as I said, it's a fragile system. Even though I don't have any of that, my Spotlight is still broken. It's not generating huge index files, but Spotlight can't successfully perform its core mission - finding files. But I know where my files are and what they contain, so it's not that big of a deal.

The `-E -a` erase recovered the 132 GB immediately, no more errors, no more freezes. The mitigations (disabling Apple Intelligence and excluding volatile folders) are intended to prevent recurrence. I'd call it a workaround rather than a fix; the underlying IVFVectorIndex unlink failure is still in the OS.

That's a shame. Now you'll have to wait. It's always better to debug while you have an artifact handy.

That's the point of the post.

No. The point of the post is to fix your specific problem. Spotlight can't be fixed. If you're unfortunate enough to experience a major problem that impacts your day-to-day use, it's your responsibility to fix it. You can, of course, claim that it should be Apple's responsibility to fix Apple's bugs. And you'd be absolutely correct. But that's simply not going to happen. You have to identify how your usage is different from Apple's intended usage and work around that. Apple most definitely doesn't support Docker, node, VMs, local databases, etc. And please don't quote any Apple support documents at me that say otherwise. Been down that road before many times.

The unified log shows `IVFVectorIndex::unlink failed` and `oid mismatch` on every reindex, indicating the subsystem is leaking vectors on each reindex.

The unified log is useless for any purpose. Apple itself calls it "Log Noise" and tells developers to ignore it. Every time I run in Xcode, I have to add a filter to Xcode console (recently rewritten to use that nasty unified log system) so that it doesn't show me 300 lines of meaningless gibberish.

But I do need to regularly look at that to make sure there isn't some message that I shouldn't ignore.

Even if those log messages are a definitive smoking gun, they're still useless because you can't turn off the privacy redactions for Apple processes. You know exactly what the problem is. The log doesn't tell you anything you didn't already know. That's why I said it was a shame that you had deleted the actual artifact. That might have had useful information in it.

That's a bug in mds_stores, not a user misconfiguration, and the log signatures are why I posted them, so they can reach someone who can act on them.

There are absolutely bugs in mds_stores. No mystery there. But it might also be a user misconfiguration. There are many, many, many reports of people experiencing unusual and uncontrollable storage use. What you describe is a relatively unusual instance. And you're relatively unusual in your ability to track it down. So I strongly suspect that, in your case, it is a fixable problem.

But if you're trying to reach Apple itself and file a bug report, you'll have to use the Feedback Assistant app for that. And there too, it would have been much more useful if you hadn't deleted the actual index files first. While you can reach someone who can act on them, I guarantee they won't. They don't have enough information.

If you wait and the problem reproduces, then you can file a useful bug report. If you're exceptionally lucky, then someone at Apple might then read your report, and the index files you included in your submission, and tell you what the problem might be. But that'll take a few months at best. Most likely, they'll just ask you to test in a beta version to see if it still happens.

So my recommendation is to look at those index files yourself and see if you can find something that's repeated a few hundred thousand times. Maybe you can expand your exclusions. Or maybe the problem is a flaky 3rd party Spotlight importer that you can disable. But you don't ever want to try to "mitigate" anything. Let it ride, that way, you can try to make these kinds of fixes and see if they fix the problem. Then you can erase the huge index files and reset, knowing that you've already fixed what caused it in the first place.

ZigmaSdirigeant wrote:

a 460 GB SSD

That's an odd size.

node_modules parents, Docker/VM data

Those are odd things too.

Anything over ~10 GB for a normal-use machine is a red flag.

Are you saying that your mitigations fixed the problem then?

What you're describing is not normal use. My guess is that just excluding any directory that contains node or Docker/VM data would be effective. Spotlight is quite fragile.

I've got an M2 MacBook Pro that has a 549MB Spotlight index and an M4 Mini with a 993MB Spotlight index.

I'm not sure it's not something on your system causing the problem you have found. Could still be a problem with Spotlight exacerbated by what you have installed.

restoring ~132 GB of free space instantly.

I'm not sure that is possible on an SSD. Maybe after a day or so, but not instantly.