我们的NetApp文件pipe理器为snapvault操作显示了巨大的延迟。 可能导致这么大的快照滞后的原因是什么？
Snapvault is ON. Source Destination State Lag Status home:/vol/home/ vault1:/vol/home_backup/ Source 1602:06:04 Idle home:/vol/h_root/- vault1:/vol/home_backup/h_root Source 1578:07:40 Idle .snapshot目录的清单显示了12月2日的mtime，即使在那个date以来，活文件系统已经修改了文件的目录也是如此。
drwx--x--x 13 user staff 8192 Dec 2 17:35 Feb-01
snapvault status -l显示以下信息：
Snapvault is ON. Source: home:/vol/home/ Destination: vault1:/vol/home_backup/ Status: Idle Progress: - State: Source Lag: 1602:15:24 Mirror Timestamp: Fri Dec 2 00:01:56 PST 2011 Base Snapshot: sv.7 Current Transfer Type: - Current Transfer Error: could not read from socket Contents: - Last Transfer Type: - Last Transfer Size: 28618316 KB Last Transfer Duration: 04:02:46 Last Transfer From: - Source: home:/vol/h_root/- Destination: vault1:/vol/home_backup/h_root Status: Idle Progress: - State: Source Lag: 1578:17:00 Mirror Timestamp: Sat Dec 3 00:00:20 PST 2011 Base Snapshot: sv.7 Current Transfer Type: - Current Transfer Error: could not read from socket Contents: - Last Transfer Type: - Last Transfer Size: 1488 KB Last Transfer Duration: 00:00:04 Last Transfer From: -
在目标端，我们有这个输出为snapvault status ：
Source Destination State Lag Status home:/vol/home/ vault1:/vol/home_backup/ Snapvaulted 1602:24:40 Quiescing home:/vol/h_root/- vault1:/vol/home_backup/h_root Snapvaulted 1578:26:16 Quiescing
源文件和目标文件都在运行NetApp版本8.0.2。
目的地的状态说它停顿了，这意味着它试图干净地停止转移……很明显，这很长一段时间，除非你最近试图阻止转移。
首先，我将尝试使用虚拟卷创build一个新的传输，看看是否可以得到一个新的传输正确，这将有助于排除故障一些…假设的作品，我会打破snapvault转移，然后尝试重新初始化他们之一一次。
您可能还想检查是否设置了任何节stream，因为有时节气门configuration可能会造成混淆，并且您可能意外地将其设置得比预期的要低得多。
您的networking中是否发生了任何可能阻止源代码与目的地通话的事情？ 我遇到了一个Cisco代码错误，导致我们的snapmirrorstream量显示为asynchronous路由，我们的防火墙不停地丢弃数据包。
系统上的CPU是否高？ 一个3050是一个非常古老的系统，它可能会超载，并且无法跟上服务用户数据时的snapvault开销。 如果你始终保持在90以上，那么你只能看到这个，这不是一个很常见的问题。