# Shards are not splitted into smaller ones

**URL:** https://forums.foundationdb.org/t/shards-are-not-splitted-into-smaller-ones/815
**Category:** Using FoundationDB
**Created:** [October 29, 2018, 10:43am UTC](https://forums.foundationdb.org/t/shards-are-not-splitted-into-smaller-ones/815 "2018-10-29T10:43:52Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![ajbeamon](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/ajbeamon/32/13_2.png) [@ajbeamon](https://forums.foundationdb.org/u/ajbeamon)
#### Post date: [October 29, 2018, 6:34pm UTC](https://forums.foundationdb.org/t/shards-are-not-splitted-into-smaller-ones/815/4 "2018-10-29T18:34:20Z")

</div>

A range clear is typically a very quick operation to perform from a user perspective. In the `ssd` storage engine, it basically just detaches the affected data from the b-tree and defers the cleanup work. In the `memory` storage engine, it removes the data from the memory data structure and logs the mutation to disk with no deferred work.

The cleanup work in the `ssd` storage engine is actually a fairly slow process, and it consists of two phases. The first phase processes the detached pages and makes them available for reuse within the file. The second phase removes them from the file. As long as the first phase keeps up with your write load, then there shouldn’t be an issue. If it doesn’t, increasing the size of your cluster should help. See [Used disk space dramatically increases while sum of key-value sizes is constant](https://forums.foundationdb.org/t/used-disk-space-dramatically-increases-while-sum-of-key-value-sizes-is-constant/644) for some additional discussion on this.

---

_[View the full topic](https://forums.foundationdb.org/t/shards-are-not-splitted-into-smaller-ones/815)._