OCPBUGS-10640: Added clarification point to disk partition BM doc

modules/installation-user-infra-machines-advanced.adoc

@@ -73,31 +73,25 @@ The `--copy-network` option only copies networking configuration found under `/e
 [id="installation-user-infra-machines-advanced_disk_{context}"]
 == Disk partitioning
 
-// This content is not modularized, so any updates to this "Disk partitioning" section should be checked against the module created for vSphere UPI parity in the module file named `installation-disk-partitioning.adoc` for consistency until such time as this large assembly can be modularized.
-
 The disk partitions are created on {product-title} cluster nodes during the {op-system-first} installation. Each {op-system} node of a particular architecture uses the same partition layout, unless the default partitioning configuration is overridden. During the {op-system} installation, the size of the root file system is increased to use the remaining available space on the target device.
 
-There are two cases where you might want to override the default partitioning when installing {op-system} on an {product-title} cluster node:
-
-* Creating separate partitions: For greenfield installations on an empty
-disk, you might want to add separate storage to a partition. This is
-officially supported for mounting `/var` or a subdirectory of `/var`, such as `/var/lib/etcd`, on a separate partition, but not both.
-+
 [IMPORTANT]
 ====
-For disk sizes larger than 100GB, and especially disk sizes larger than 1TB, create a separate `/var` partition. See "Creating a separate `/var` partition" and this link:https://access.redhat.com/solutions/5587281[Red Hat Knowledgebase article] for more information.
-====
-+
-[IMPORTANT]
-====
-Kubernetes supports only two file system partitions. If you add more than one partition to the original configuration, Kubernetes cannot monitor all of them.
+The use of a custom partition scheme on your node could result in {product-title} not monitoring or alerting on some node partitions. If you override the default partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)] for more information about how {product-title} monitors your host file systems.
 ====
 
-* Retaining existing partitions: For a brownfield installation where you are reinstalling {product-title} on an existing node and want to retain data partitions installed from your previous operating system, there are both boot arguments and options to `coreos-installer` that allow you to retain existing data partitions.
+{product-title} monitors the following two filesystem identifiers:
+
+* `nodefs`, which is the filesystem that contains `/var/lib/kubelet`
+* `imagefs`, which is the filesystem that contains `/var/lib/containers`
+
+For the default partition scheme, `nodefs` and `imagefs` monitor the same root filesystem, `/`.
 
-[WARNING]
+To override the default partitioning when installing {op-system} on an {product-title} cluster node, you must create separate partitions. You might want to add a separate storage partition for your containers and container images. For example, by mounting `/var/lib/containers` in a separate partition, the kubelet separately monitors `/var/lib/containers` as the `imagefs` directory and the root file system as the `nodefs` directory.
+
+[IMPORTANT]
 ====
-The use of custom partitions could result in those partitions not being monitored by {product-title} or alerted on. If you are overriding the default partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)] for more information about how {product-title} monitors your host file systems.
+If you resized your disk size to host a larger file system, consider creating a separate `/var/lib/containers` partition. This is important for a disk formatted to `xfs`, where a high number of allocation groups might cause CPU time issues.
 ====
 
 [id="installation-user-infra-machines-advanced_vardisk_{context}"]