How do i reclaim space?

Questions
1

Your question

i detele and recreate an account with 27gb(to delete emails) and i need to reclaim space. server is on 98% usage. rocksdb blob has not changed

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Let’s get the tasks-actions/tasks.md doc which describes how to trigger this from WebUI.

I now have what’s needed to explain this. Deleting an account doesn’t immediately shrink RocksDB blob storage; the space is only reclaimed when a maintenance task purges the blob store (and expired data). This happens automatically on the blobCleanupSchedule (daily by default), but you can trigger it manually right away.

Manually trigger a purge:
Create a StoreMaintenance task with maintenanceType: "purgeBlob" (and optionally "purgeData" for the data store too). You can do this either:

  • Via CLI: stalwart-cli create task/store-maintenance with the maintenance type set to purgeBlob
  • Via WebUI: Management → Tasks → Scheduled, create a new task
  • Via JMAP API using Task/set with:
{
  "@type": "StoreMaintenance",
  "maintenanceType": "purgeBlob"
}

Since you also deleted an account, run AccountMaintenance with maintenanceType: "purge" (or the built-in DestroyAccount task should already have removed it, but a manual purgeBlob run on the store ensures orphaned blobs referenced by the deleted account’s messages are actually removed from disk).

Note that blob store cleanup runs on its own schedule (blobCleanupSchedule, default daily at 04:00) separate from the data cleanup schedule, so if you deleted the account very recently, unused blobs may simply be waiting for that next scheduled run. Triggering purgeBlob manually forces it immediately.

Reference: Tasks | Stalwart and Maintenance | Stalwart

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Deleting the account removes the references to the messages, not the objects themselves. Those go when the blob clean-up task runs, which is a scheduled maintenance task set by blobCleanupSchedule on the DataRetention object and defaults to daily at 04:00. You can trigger the purge task on demand instead of waiting for it. Check that it has actually run since you deleted the account, and that it didn’t error, before chasing anything else; a failed purge would explain the whole thing on its own.

The second half is RocksDB rather than us. Deletes are written as tombstones and the space comes back when compaction rewrites the affected files, so the directory won’t shrink the moment the purge finishes. At 98% that’s likely to be self-blocking, since compaction has to write the new files before it can drop the old ones. Free up headroom somewhere else first, shorten telemetry retention or move logs off that volume, and let it work through a few compaction cycles.

There’s no force-compact command today, so it’s worth setting expectations that the space returns gradually rather than all at once. If you can post the version and the sizes of the subdirectories under the RocksDB path, I can tell you whether the space is actually in the blob store or somewhere else like the search index.