Назад | Перейти на главную страницу

Паника ядра во время rsync

Я использую 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 (локальный, а не кластерный). Передаваемые файлы являются файлами резервных копий для виртуальных машин, и они не используются во время передачи: это копии «reflink», взятые исключительно для целей rsync. В ОС установлены обновления.

Паника ядра может быть вызвана несколькими факторами, например:

  • демон ssh
  • конфликт между обновляемыми файлами / другой службой, использующей их
  • Интерфейс NIC ...

Чтобы определить источник проблемы, я бы попробовал несколько rsync --dry-run (который ничего не копирует).

Кроме того, недавно я прочитал, что может быть проблема с FS, установленным с noatime вариант относительность быть лучше.

Также я бы попробовал rsync с --delay-updates опция, которая сводит к минимуму фактическое время обновления файлов.

Это то, что сейчас приходит в голову, я обновлю ответ, если что-то еще прозвенит ..