Hi CryoSPARC team,
Our CryoSPARC master’s database recently filled its local disk (98 % of 431 GB) and nearly locked up the server. We traced it to image data in GridFS that no longer belongs to any file. We cleaned it up by hand, but since it seems to keep building up, we wanted to report it and ask whether there is a supported fix.
**Setup**
- CryoSPARC v5.0.2 (master + workers on one server), MongoDB 4.0.28
- Mostly Live sessions plus regular processing, project UIDs up to P144 since March 2026; old projects are deleted or detached through the web interface.
**What we found**
- The database folder was 302 GB. Almost all of it was `fs.chunks`: 293 GB of data.
- `fs.files` listed only 2.05 million files totaling 60.7 GB (`$sum` of `length`), but `fs.chunks` had 10.2 million chunks.
- 8,180,487 chunks (in 8,176,348 distinct `files_id`s), about 230 GB, had no matching `fs.files` document (found with `$group` on `files_id` + `$lookup` into `fs.files`).
- By their ObjectIds, those orphaned chunks were written steadily from 9 March to 30 October 2026. So this doesn’t look like one failed operation; it looks like chunks are left behind every time something is deleted or cleared.
- `athena_cleanup_requests` was empty, so no cleanup was pending.
- Deleting projects in the UI followed by `cryosparcm compact` freed only about 2 %.
**Two related observations**
1. **Detached projects keep their GridFS images.** 23 detached projects still held 52.7 GB of images in the database (`fs.files` with their `project_uid`). Is that intended? We expected detaching to move a project’s images out of the database.
2. **The default MongoDB cache (`–wiredTigerCacheSizeGB 4`) is too small to compact a large collection.** `cryosparcm database compact` failed on `fs.chunks` with `Compaction interrupted … due to cache eviction pressure` (code 11601). It succeeded after we set `CRYOSPARC_MONGO_CACHE_GB=64` (the server has 1 TB of RAM). It may be worth mentioning in the “Reduce Database Size” guide.
**What we did** (CryoSPARC stopped, database only, after `cryosparcm backup`)
1. Deleted the 8.18 M orphaned chunks (only chunks whose `files_id` has no `fs.files` document).
2. Deleted the `fs.files` + `fs.chunks` of the detached projects.
3. Ran `cryosparcm database compact`.
The database went from 302 GB to 14 GB. Live sessions and job plots in the attached projects all still display correctly.
**Questions**
1. Is the orphaned-chunk build-up a known issue in v5, and is a fix planned?
2. Is there a supported way to remove orphaned GridFS data (a `cryosparcm` command or similar), so we don’t need to edit the database directly?
3. Is it safe and intended to delete the GridFS images of detached projects? Would re-attaching such a project restore its images from the project directory?
Happy to send counts, logs or run diagnostics if useful.
Thanks!
David Bulkley, UCSF EM Core