Describe the feature:
Documentation about [path.data] (https://www.elastic.co/guide/en/elasticsearch/reference/master/path-settings.html) should include a caveat about using this setting for multiple paths unless it's absolutely necessary.
With multiple path.data entries, Elasticsearch does not dynamically load-balance across the different paths, shards are initially allocated based on number of shards per path, shards are never moved between paths once allocated.
In most situations, managing multiple storage paths with a Logical Volume Manager (LVM) might be the recommended option
Elasticsearch version (bin/elasticsearch --version): 7.5
Pinging @elastic/es-docs (>docs)
Pinging @elastic/es-core-infra (:Core/Infra/Packaging)
Another caveat is that high disk usage on one mountpoint marks the whole node under watermark situation. One can end up with a situation when one mountpoint is utilized in 95% and the other is mostly free but still the node cannot take new shards. This behaviour is not intuitive and users looking to expand their storage on a node are surprised that adding more disk space does not help at all.
Most helpful comment
Another caveat is that high disk usage on one mountpoint marks the whole node under watermark situation. One can end up with a situation when one mountpoint is utilized in 95% and the other is mostly free but still the node cannot take new shards. This behaviour is not intuitive and users looking to expand their storage on a node are surprised that adding more disk space does not help at all.