我正在运行 OEL 6.4（RHEL 克隆），并且每晚通过 ssh 同步大型文件。在 rsync 期间，我经常（大多数晚上）遇到内核恐慌：
Message from syslogd@cheshire at Mar 24 00:39:01 ...
kernel:Oops: 0000 [#1] SMP
Message from syslogd@cheshire at Mar 24 00:39:01 ...
kernel:Stack:
Message from syslogd@cheshire at Mar 24 00:39:01 ...
kernel:Call Trace:
Message from syslogd@cheshire at Mar 24 00:39:01 ...
kernel:Code: 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 64 24 08 66 66 66 66 90 41 89 d4 48 89 f3 e8 cf 23 fe ff 41 83 fc 01 48 89 c2 75 1a
Message from syslogd@cheshire at Mar 24 00:39:01 ...
kernel:CR2: 0000000000000000
Message from syslogd@cheshire at Mar 24 00:39:01 ...
kernel:Kernel panic - not syncing: Fatal exception
上面的信息是否有可能为我提供原因线索，还是都是一般性信息？在/var/log/messages坠机时似乎没有什么异常。
编辑：
我应该提到我使用的是 ocfs2（本地而非集群）。正在传输的文件是虚拟机的备份文件，在传输时未使用：它们是纯粹为了 rsync 而获取的“reflink”副本。操作系统已安装最新补丁。
答案1
内核崩溃可能由多种因素引起，例如
- ssh 守护进程
- 正在更新的文件与使用这些文件的其他服务之间存在冲突
- NIC 接口...
为了帮助识别问题的根源，我尝试了一些rsync --dry-run（但没有复制任何内容）。
此外，我之前读到过，使用以下方式安装的 FS 可能会出现一些问题诺亚泰选项，相对时间变得更好。
我也会尝试同步该--delay-updates选项可以最小化实际文件更新时间跨度。
这是我现在想到的，如果有其他想法，我会更新答案。