我在两个远程位置之间运行 MARS（多版本异步复制存储），并且大多数情况下它的运行都可以满足我的需求。
作为监控的一部分，我定期发出命令
marsadm view maildata
最初，这个问题会在几秒钟内恢复，但几个月后，需要将近 5 分钟才能恢复，并告诉我一切正常。这个时间范围逐渐变长 - 这似乎是自设置复制以来时间的函数，而不是与负载或一天中的时间有关。此问题在主服务器和辅助服务器上都会发生。
我尝试添加--timeout = 90，但这似乎没有任何区别。
服务器的数据传输量非常低（大约 1 兆位），但通过延迟为 200 毫秒的连接传输，该连接具有超过 10 兆位的可用带宽。我的服务器在 8 核或更多核 CPU 上的负载徘徊在“1”左右。
/mars 显示两侧的空间利用率均为 1%。我正在镜像的卷大小小于 1TB，位于 SSD 上。
我手动运行marsadm 定时任务在两台服务器上都执行了此命令，然后重新发出了该命令。结果并无明显差异。
我的主要状态如下
LocalDevice /dev/mars/maildata [Opened, 4 IOPS]
maildata [2/2] UpToDate Replicating DCASFR Primary marsvmserver1
同样，在我的第二
maildata [2/2] UpToDate Replaying dCASFR Secondary marsvmserver1
我确实不知道该看哪里，但我没有找到任何表明任何问题的日志条目。
我从源代码编译了一个基于5.4.20的内核，可以看到mars模块已经被加载。
我该如何修改以便能够在几秒钟内（或至少在 2 分钟内）获取 marsadm 状态信息？
更新
（仍然不知道发生了什么）
/mars/resource-maildata 有大量空的符号链接文件，格式如下：
version-000005492-marsvmserver2 -> b2ae552972debb9835fe7510ef059430,log-000005492-marsvmserver1,23019520:247d0e2c5721f303cc46da3ba7ab51e5,log-000005491-marsvmserver1,18510436
在对我的数据采取足够的预防措施后，我尝试删除这些文件，但它们立即又出现了。（它们也存在于辅助设备上）。
有趣的是，我在辅助服务器上运行了“marsadm invalidate”，这似乎确实在做某物- 重新验证似乎需要几个小时。符号链接文件的数量已减少了约一半，但正在逐渐增加。执行 marsadm view maildata 的时间也减少了约一半。
更新 2（部分修复）
毫无疑问，这是非常错误的，对我的数据来说也很危险。我对此并不完全满意 - 但这是进步
如果有人能正确/更好地解决我的问题，我将不胜感激。
数据重新同步后，我仍然剩下 5000 多个版本文件 - 似乎来自辅助节点的版本文件已经消失，但来自主节点的版本文件被保留了下来。
我尝试了 marsadm log-purge-all，但没有任何效果。
无奈之下，我尝试了以下方法，大大加快了响应速度（几秒钟） - 但我不知道副作用是什么 -
我确保磁盘基本同步。
在 SECONDARY 上，我发出了“rmmod mars”，然后继续删除几天前的版本文件。它们没有自动重新创建。然后，我在主服务器上删除了相同的文件，然后在辅助服务器上发出了“modprobe mars”。几秒钟后，它显示它已过期并在辅助服务器上同步，它就成为了主服务器。
然后，我在主服务器上写入了更多数据，在辅助服务器上创建了 MARS 复制底层磁盘的 LVM 快照，挂载了该快照，然后看到我在主服务器上写入的新数据出现在辅助服务器上。（然后我卸载并销毁了快照）
我注意到每 10 分钟就会添加一次新版本文件 - 经过检查，我每 10 分钟运行一次“marsadm cron”。我将其改为每 1 分钟运行一次，果然这些文件的创建速度增加到每分钟 1 个 - 因此问题可能与 marsadm cron 作业有关。