# Curator fails to shrink index

**URL:** <https://discuss.elastic.co/t/curator-fails-to-shrink-index/100010>\
**Category:** Elasticsearch\
**Created:** [September 11, 2017, 7:29am UTC](https://discuss.elastic.co/t/curator-fails-to-shrink-index/100010 "2017-09-11T07:29:38Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![theuntergeek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/theuntergeek/32/44961_2.png) [@theuntergeek](https://discuss.elastic.co/u/theuntergeek)\
**Post date:** [September 11, 2017, 2:08pm UTC](https://discuss.elastic.co/t/curator-fails-to-shrink-index/100010/3 "2017-09-11T14:08:25Z")

</div>

I did some asking, and it appears I can override this, [but it will amount to much the same thing as a reindex](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-shrink-index.html), in the end (emphasis added):

> Shrinking works as follows:
> 
> - First, it creates a new target index with the same definition as the source index, but with a smaller number of primary shards.
> - Then it hard-links segments from the source index into the target index. ( **If the file system doesn’t support hard-linking, then all segments are copied into the new index, which is a much more time consuming process.** )
> - Finally, it recovers the target index as though it were a closed index which had just been re-opened.

The problem with trying to get Curator to do this is that it _still_ requires a guarantee that _one of the data paths_ has sufficient space for 2x the index space because shards cannot span filesystems—they must exist entirely on a single filesystem. Curator would have no control over which filesystem is chosen, or how to ensure that there is sufficient space on that filesystem. It is possible to test and enforce that _all_ data paths have sufficient space to accommodate the 2x index space needed, but is that the right solution? I don't know. I do know that a shrink will fail if an attempt is made and the filesystem the single shard is targeting does not have sufficient space, even if the sum total of other filesystems does add up to sufficient.

Shrink is exceptionally complicated, and this is just one more reason it is difficult. I will have to consider and consult with some others here at Elastic and see what, if any, solution there should be to shrink on a node with multiple data paths.

---

_[View the full topic](https://discuss.elastic.co/t/curator-fails-to-shrink-index/100010)._