anchor.diff:  |`imagefs.inodesFree` = `node.stats.runtime.imagefs.inodesFree`
   |===
   
  -The node supports two filesystem partitions when detecting disk pressure.
  -
  -* The `nodefs` filesystem that the node uses for local disk volumes, daemon logs, etc (i.e. the filesystem that provides `/`)
  -* The `imagefs` filesystem that the container runtime uses for storing images and individual container writable layers.
  -
  -The node auto-discovers these filesystems using `cAdvisor`.
  -
  -If you store volumes and logs in a dedicated filesystem, the node will not monitor that filesystem at this time.
  +The node supports two file system partitions when detecting disk pressure.
  +
  +* The `nodefs` file system that the node uses for local disk volumes, daemon logs,
  +and so on (for example, the file system that provides `/`).
  +* The `imagefs` file system that the container runtime uses for storing images and
  +individual container writable layers.
  +
  +The node auto-discovers these file systems using `cAdvisor`.
  +
  +If you store volumes and logs in a dedicated file system, the node will not
  +monitor that file system at this time.
   
   [NOTE]
   ====
  -In this release, the node supports the ability to trigger eviction decisions
  -based on disk pressure.  Operators must opt-in to enable disk based evictions this
  -release.  Prior to evicting pods due to disk pressure, the node will also perform
  -container and image garbage collection.  For more detail on garbage collection, see
  +As of {product-title} 3.4, the node supports the ability to trigger eviction
  +decisions based on disk pressure. Operators must opt in to enable disk-based
  +evictions. Prior to evicting pods due to disk pressure, the node will also
  +perform
   xref:../admin_guide/garbage_collection.adoc#admin-guide-garbage-collection[container
  -and image garbage collection].  In future releases, garbage collection will be deprecated
  -in favor of a pure disk eviction based configuration.
  +and image garbage collection]. In future releases, garbage collection will be
  +deprecated in favor of a pure disk eviction based configuration.
   ====
   
   [[out-of-resource-eviction-thresholds]]
  
positive.code: stability and limits the impact of the unexpected consumption to other
  `Guaranteed` pods.
  
  Local disk is a `BestEffort` resource.  If necessary, the node will evict
  pods one at a time to reclaim disk when `DiskPressure` is encountered.  The node
  ranks pods by quality of service.  If the node is responding to inode starvation, it will
  reclaim inodes by evicting pods with the lowest quality of service first.  If the node
  is responding to lack of available disk, it will rank pods within a quality of service
  that consumes the largest amount of local disk, and evict those pods first.
  
  [NOTE]
  ====
  
negative.code: defaults to *10s*.
  
  [[out-of-resource-reclaiming-node-level-resources]]
  === Reclaiming Node-level Resources
  
  If an eviction criteria is satisfied, the node initiates the process of
  reclaiming the pressured resource until it observes that the signal has gone
  below its defined threshold. During this time, the node does not support
  scheduling any new pods.
  
  The node attempts to reclaim node-level resources prior to evicting end-user
  pods. If disk pressure is observed, the node reclaims node-level resources
  differently if the machine has a dedicated `imagefs` configured for the
  container runtime.
  
  [[reclaiming-with-imagefs]]
  ==== With Imagefs
  
  If the `nodefs` file system meets eviction thresholds, the node frees up disk
  space in the following order:
  
  * Delete dead pods/containers
  
  If the `imagefs` file system meets eviction thresholds, the node frees up disk
  space in the following order:
  
  * Delete all unused images
  
  [[reclaiming-without-imagefs]]
  ==== Without Imagefs
  
  If the `nodefs` file system meets eviction thresholds, the node frees up disk
  space in the following order:
  
  * Delete dead pods/containers
  * Delete all unused images
  