# Is it possible to enable \`perpetual\_storage\_wiggle\` at the 'shard' level instead of the 'process' level? **URL:** \ **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:** 2
**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:34pm UTC](https://forums.foundationdb.org/t/is-it-possible-to-enable-perpetual-storage-wiggle-at-the-shard-level-instead-of-the-process-level/4760/2 "2025-01-10T16:34:46Z")
In [Redwood: perpetuum moving data between storage servers - #8 by SteavedHams](https://forums.foundationdb.org/t/redwood-perpetuum-moving-data-between-storage-servers/3624/8) @SteavedHams does say that > These decisions make sense in the context of a production FDB cluster with dedicated data volumes, as giving space back to the filesystem is unnecessary (it will be reused within Redwood) and FDB Data Distribution will move/balance key ranges around between Storage Servers which will effectively remove BTree slack and keep logical space usage roughly balanced. But surely that’s only true when the data being moved/rebalanced sits in the same place in the BTree? If FDB detects a ‘hot range’ or similar and decides to split it into 2 shards, one of which it moves to another storage process, then it’s quite unlikely that anything else will move _onto_ this process and take up the same ‘space’ in the tree? --- _[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)._