# Disk watermarks appear not to be applied correctly

**URL:** <https://discuss.elastic.co/t/disk-watermarks-appear-not-to-be-applied-correctly/24194>\
**Category:** Elasticsearch\
**Created:** [June 23, 2015, 12:08pm UTC](https://discuss.elastic.co/t/disk-watermarks-appear-not-to-be-applied-correctly/24194 "2015-06-23T12:08:36Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![tomdc](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tomdc/32/3441_2.png) [@tomdc](https://discuss.elastic.co/u/tomdc)\
**Post date:** [June 23, 2015, 12:08pm UTC](https://discuss.elastic.co/t/disk-watermarks-appear-not-to-be-applied-correctly/24194/1 "2015-06-23T12:08:36Z")

</div>

It looks like the high disk watermark setting is compared to all available disk space on the machine and not only to the partition where ES writes its data. In our case we have a /data mount point and Elastic is running from /data/elasticsearch. The /data mount point exceeds the high water mark, but ES does not start relocating any shards from the server and we actually see the used space increasing further.

After looking at the code it looks like the free\_in\_bytes value of the fs stats is used and when comparing the watermark. On this specific server free\_in\_bytes appears to contain all available disk space on the machine (including / and /home). available\_in\_bytes on the other hand appears to contain the correct value of free disk space on the /data partition.

Can anyone confirm free\_in\_bytes is used for the watermarks and if it is expected to contain free disk space from irrelevant partitions?  
And what is the exact difference between available\_in\_bytes and free\_in\_bytes?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 12:05am UTC](https://discuss.elastic.co/t/disk-watermarks-appear-not-to-be-applied-correctly/24194/2 "2017-07-06T00:05:55Z")

</div>

Closed on July 6, 2017, 12:05am UTC


