anchor.diff:  Generally, the recommendation is to not set explicit flush thresholds and let the operating system perform background flush using its default settings.
   Partition replication provides greater data durability than writes to any single disk as a failed broker can recover from its in-sync replicas.
   
  -If you are using application flush management, setting lower flush thresholds might be appropriate if you are looking at ways to decrease latency or you are using faster disks.
  +If you are using application flush management, setting lower flush thresholds might be appropriate if you are using faster disks.
   
   == Partition rebalancing for availability
   
   Partitions can be replicated across brokers for fault tolerance.
  -For a given partition, one broker is elected leader and handles all producer requests (writes to the log).
  +For a given partition, one broker is elected leader and handles all produce requests (writes to the log).
   Partition followers on other brokers replicate the partition data of the partition leader for data reliability in the event of the leader failing.
   
   Followers do not normally serve clients, though xref:type-Rack-reference[`rack` configuration] allows a consumer to consume messages from the closest replica when a Kafka cluster spans multiple datacenters.
  
positive.code: ----
  
  *Do not reduce these settings in production.*
  You can increase the settings in production.
  If you are testing in a single broker environment, you might want to reduce the settings as an exception.
  
  == Improving request handling throughput by increasing I/O threads
  
  
negative.code: # ...
  ----
  
  In other words, a log will typically have approximately _log.retention.bytes/log.segment.bytes_ segments once it reaches a steady state.
  When the maximum log size is reached, older segments are removed.
  
  A potential issue with using a maximum log size is that it does not take into account the time messages were appended to a segment.
  You can use time-based and size-based log retention for your cleanup policy to get the balance you need.
  Whichever threshold is reached first triggers the cleanup.
  
  If you wish to add a time delay before a segment file is deleted from the system, you can add the delay using `log.segment.delete.delay.ms` for all topics at the broker level or `file.delete.delay.ms` for specific topics in the topic configuration.
  
  [source,env]
  ----
  # ...
  log.segment.delete.delay.ms=60000
  # ...
  ----
  
  == Removing log data with cleanup policies
  
  