Домен даних: ПАНІКА DDFS: dmbt_update_entry_nolock

Уражений домен даних (DD) повідомляє про паніку з таким повідомленням для систем із підтримкою автоматичного блокування утримання (ARL), які використовуються для реплікації:

PANIC: ddr/dm/dmbt_iface.c: dmbt_update_entry_nolock

• Домени даних PowerProtect з увімкненим автоматичним блокуванням утримання (ARL).

• Збій файлової системи домену даних
• Нестабільність системи 
• Журнали, що вказують на вищезазначене повідомлення паніки безпосередньо перед збоєм системи

Ця проблема виникає, коли між відкритими та закритими викликами DDBOOST відбувається знімок реплікації mtree.

• The nfsproc3_ddcp_open_file_3_svc() функція ідентифікує файл блокування утримання (Retention Lock, RL), що змінюється в межах періоду охолодження ARL (COP), і скидає значення тегу до 0 (DM_TAG_DEFAULT).
• Наступні nfsproc3_ddcp_close_file_3_svc() Функція зазвичай скидає тег до дійсного значення.
• Однак, якщо файл створено з розширеним атрибутом і змінюється в межах ARL COP, і між відкриттям і закриттям DDBOOST відбувається знімок, ця послідовність може спровокувати PANIC.

Це відбувається на 7.7.x та 7.10.x, а тригер виникає, коли на mtree увімкнено блокування утримання (зазвичай ARL).

Щоб вирішити цю проблему, зробіть наступне: 

1. Розірвати будь-який контекст реплікації оригінального джерела та цільового mtree.

• Це створює нову, чисту копію mtree без проблемного контексту.

• Це запобігає повторенню проблеми.

4. Перенаправляйте резервні копії до новоствореного швидкого mtree на Source the DD.
(Оновіть усі резервні завдання, щоб вони націлилися на нове mtree.)

• Переконайтеся, що нова система реплікації повністю синхронізована.
• Тримайте цей mtree ARL вимкненим, щоб запобігти повторенню PANIC. 
  • Керуйте старими mtrees:
  • Залиште оригінальні mtree на обох системах джерела та призначення.
    • Після синхронізації нової реплікації та закінчення терміну збереження старих mtree-файлів, видаліть файли зі старих mtree.
    • Потім видаліть старе mtree як на джерелі, так і на цільовому місці.

• Вкрай важливо контролювати систему на наявність подальших аномалій після виконання вищезазначених кроків.
• Переконайтеся, що всі політики резервного копіювання та контексти реплікації коректно оновлені відповідно до змін.