# Cloned/Split Indexes Take Double Disk Space When Increasing Shards

**URL:** https://discuss.elastic.co/t/cloned-split-indexes-take-double-disk-space-when-increasing-shards/254342
**Category:** Elasticsearch
**Created:** [November 5, 2020, 1:45am UTC](https://discuss.elastic.co/t/cloned-split-indexes-take-double-disk-space-when-increasing-shards/254342 "2020-11-05T01:45:53Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)
#### Post date: [November 5, 2020, 9:35am UTC](https://discuss.elastic.co/t/cloned-split-indexes-take-double-disk-space-when-increasing-shards/254342/4 "2020-11-05T09:35:39Z")

</div>

Are you asking about the total disk consumption as reported by the OS (e.g. using `df`) or do you mean just for the cloned/split index (e.g. using `GET _cat/indices`)? The latter double-counts the actual disk space used because of the use of hard links.

`GET _cat/indices` should report the size of a clone to be identical to the size of the original index.

Splitting the index works by cloning all the shards (multiple times) and then effectively running a delete-by-query on them, which certainly increases the reported size until merging cleans up the deleted docs. If you're still writing to this index then that'll happen in time; if you're not still writing to this index then you can try force-merging to make it happen sooner. There's also some per-shard disk space overhead -- particularly the terms dictionary tends to be large and not to get much smaller after a split since most shards contain roughly the same set of terms.

---

_[View the full topic](https://discuss.elastic.co/t/cloned-split-indexes-take-double-disk-space-when-increasing-shards/254342)._