# Is it possible to enable \`perpetual\_storage\_wiggle\` at the 'shard' level instead of the 'process' level?

**URL:** <https://forums.foundationdb.org/t/is-it-possible-to-enable-perpetual-storage-wiggle-at-the-shard-level-instead-of-the-process-level/4760>\
**Category:** Using FoundationDB\
**Created:** [January 10, 2025, 1:16pm UTC](https://forums.foundationdb.org/t/is-it-possible-to-enable-perpetual-storage-wiggle-at-the-shard-level-instead-of-the-process-level/4760 "2025-01-10T13:16:54Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![danm](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/danm/32/1393_2.png) [@danm](https://forums.foundationdb.org/u/danm)\
**Post date:** [January 10, 2025, 4:37pm UTC](https://forums.foundationdb.org/t/is-it-possible-to-enable-perpetual-storage-wiggle-at-the-shard-level-instead-of-the-process-level/4760/3 "2025-01-10T16:37:05Z")

</div>

Aah, from [Maximum file size on ext4 - #3 by SteavedHams](https://forums.foundationdb.org/t/maximum-file-size-on-ext4/4420/3)

> One reason for this is that FDB shuffles data around a good bit in response to writes, and any time the cluster relocates a data range from one Redwood instance to another it is effectively “compacted” as the destination will have a condensed low-slack (or even _negative_ slack) subtree of that data and the source will delete the subtree completely which frees all of its blocks.

So if a shard is moved the entire subtree moves, so disk space _can_ be (and is) reclaimed on the origin process?

---

_[View the full topic](https://forums.foundationdb.org/t/is-it-possible-to-enable-perpetual-storage-wiggle-at-the-shard-level-instead-of-the-process-level/4760)._