在 vSphere Replication 中使用 trim/unmap 客户机操作系统命令时，存储和网络带宽需求可能会增加。您可能还会观察到违反 RPO 的情况。
使用客户机操作系统 Trem/Unmap 命令后的增量同步
调用 trim/unmap 命令可能会增加目标站点上的存储消耗。
在源站点磁盘上使用 trim/unmap 命令后，磁盘上的可用空间将添加到 vSphere Replication 在下一个 RPO 周期内传输到目标站点的数据块。因此，源站点磁盘空间不足时，传输到目标站点的已更改块的大小会更大。
例如，如果源站点磁盘为 10 TB，且仅分配了 1 TB，则调用 trim/unmap 命令将导致至少向目标站点传输 9 TB 数据。
如果源站点磁盘为 10 TB，分配了其中的 9 TB，且删除了 2 TB 数据，则调用 trim/unmap 命令将导致至少向目标站点传输 3 TB 数据。
由于增量同步，并且根据目标站点上虚拟机存储策略定义的 RAID 配置，复制虚拟机的存储消耗可能是源虚拟机消耗的两倍以上。
在目标站点上看不到复制虚拟机的存储消耗。您只能查看整个 vSAN 数据存储的总体消耗。因此，您无法在虚拟机磁盘级别跟踪回收的存储空间，但可以通过查看 vSAN 数据存储上剩余的总体可用空间来跟踪该空间。
在源虚拟机上使用 Trim/Unmap 命令后违反恢复点目标
您可以手动调用 trim/unmap 命令，也可以由客户机操作系统在特定时间间隔调用这些命令。在这两种情况下，命令后的同步可能需要很长时间。
使用 trim/unmap 命令回收源虚拟机上未使用的空间时，可能会生成大量更改的磁盘块。同步这些更改可能需要比配置的 RPO 更长的时间，vSphere Replication 将开始报告违反 RPO。
由于复制落后于 RPO 调度，因此为了同步更改的磁盘块，新的增量同步将在前一个实例同步完成后立即开始。此即时后续增量同步过程将继续进行，直到 vSphere Replication 创建满足 RPO 调度的副本实例且不报告违反 RPO。复制状态变为“良好”。
使用 vSphere Replication 筛选器驱动程序的 Unmap 处理模式
在 ESXi 7.0 Update 3 或更高版本上，默认情况下，如果 SCSI Unmap 命令覆盖传输到目标站点的内容，vSphere Replication 筛选器驱动程序在同步操作期间将无法执行这些命令。客户机操作系统稍后将重试该命令，而不会影响在虚拟机中运行的应用程序。某些客户机操作系统不喜欢筛选器驱动程序的这种行为，在同步操作正在进行时可能会变得无响应。
在 ESXi 7.0 Update 2 或更低版本上，hbr_filter 具有不同的 Unmap 处理模式，该模式通过保留传输的内容来执行 Unmap 命令。某些客户机操作系统在此模式下表现更好，但是该方法存在一些缺点：
- 用于保留慢速存储上的重叠区域的额外读取和写入操作可能会导致意外延迟。这些延迟可能会导致某些客户机操作系统在同步操作期间发出设备重置。
- 保留的磁盘内容会暂时增加存储空间消耗。
前提条件
- 在 ESXi 7.0 Update 3 或更高版本上，可以使用 ESXi 高级设置返回到以前的行为
