I did some asking, and it appears I can override this, but it will amount to much the same thing as a reindex, 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.