anchor.diff:  
   One advantage of this setup is
   <<getting-started-index-lifecycle-management,automatic rollover>>, which creates
  -a new write index when the current one meets a defined `max_age`, `max_docs`, or
  -`max_size` threshold. You can use these thresholds to create indices based on
  -your retention intervals. When an index is no longer needed, you can use
  -{ilm-init} to automatically delete it and free up resources.
  +a new write index when the current one meets a defined `max_primary_shard_size`,
  +`max_age`, `max_docs`, or `max_size` threshold. When an index is no longer
  +needed, you can use {ilm-init} to automatically delete it and free up resources.
   
   {ilm-init} also makes it easy to change your sharding strategy over time:
   
  
positive.code: 
  [discrete]
  [[shard-size-recommendation]]
  ==== Aim for shard sizes between 10GB and 50GB
  
  Shards larger than 50GB may make a cluster less likely to recover from failure.
  When a node fails, {es} rebalances the node's shards across the data tier's
  remaining nodes. Shards larger than 50GB can be harder to move across a network
  and may tax node resources.
  
  [discrete]
  [[shard-count-recommendation]]
  
negative.code: you can use one or more of the following methods to fix them.
  
  [discrete]
  [[create-indices-that-cover-longer-time-periods]]
  ==== Create indices that cover longer time periods
  
  If you use {ilm-init} and your retention policy allows it, avoid using a
  `max_age` threshold for the rollover action. Instead, use
  `max_primary_shard_size` to avoid creating empty indices or many small shards.
  
  If your retention policy requires a `max_age` threshold, increase it to create
  indices that cover longer time intervals. For example, instead of creating daily
  indices, you can create indices on a weekly or monthly basis.
  
  [discrete]
  [[delete-empty-indices]]
  