Домен даних: BoostFS панікує або Mount Point стає нечутливим

Симптоми:

• BoostFS випадково вилітає і панікує. Це трапляється, коли навантаження велике.
• Резервне копіювання виконує затримку READ та WRITE операції на точці кріплення BoostFS.
• Коли виникають затримки READ та WRITE операції з резервного додатку, журнали BoostFS показують це error 5057 File handle is stale from Data Domain server.

BoostFS Logs:

###### WRITE operation FAILED due to STALE FILE HANDLE error ######
Sep 11 00:36:29.635 7884 10740 [E] [ddp log] [1ECC:29F4] ddcl_ddcp_send_file_loop: Call to recv
refs2 failed. [ERR=5057] Sep 11 00:36:29.635 7884 10740 [E] [ddp log] [1ECC:29F4] ddcl_ddcp_pwrite: Call to send file loop2 failed. [ERR=5057]
Sep 11 00:36:29.635 7884 10740 [E] [ddp log] [1ECC:29F4] ddcl_ddcp_pwrite: Error in ddcl ddcp
pwrite. [ERR=5057] Sep 11 00:36:29.635 7884 10740 [E] [ddp log] [1ECC:29F4] ddp_write() failed Offset 11010048, BytesToWrite 1048576, BytesWritten 0 Err: 5057-File handle is stale
Sep 11 00:36:29.635 7884 10740 [E] bfs_cache_flush: failed: 5057 File handle is stale (0 bytes written)
Sep 11 00:36:29.651 7884 11292 [E] [ddp log] [1ECC:2C1C] ddcl_ddcp_send_file_loop: Call to recv
refs2 failed. [ERR=5057]
####### PANIC occurred HERE #######
Sep 11 00:36:29.667 7884 11292 [E] [ddp log] [1ECC:2C1C] PANIC: ..\ddcl\ddcl_ddcp.c:
ddcl_ddcp_commit: 4541: !(c->send_offset == c->write_offset)

Сортування:

1. Перевірте логи BoostFS та серверної DDFS (Data Domain file system) на наявність помилки, про яку згадували вище.
2. Зверніть увагу на затримку в READ та WRITE операції з резервного додатку. Розгляньте журнали введення та виходу з API BoostFS.
3. Перевірте встановлене значення для OST_ABANDON_TIMEOUT (за замовчуванням три години).
4. Перевірте, чи тайм-аут RPC більший за встановлене значення для OST_ABANDON_TIMEOUT.

1. Проблема пов'язана із затримкою READ та WRITE операції за допомогою резервного додатка. Це запускає DDFS на скидання тайм-ауту. Це призводить до закриття відповідного дескриптора файлу через три години (значення за замовчуванням)
2. Це період тайм-ауту за замовчуванням, який DDFS використовує для ідентифікації неактивного дескриптора файлу. Зрештою, нові автори можуть відчувати паніку з боку клієнта.

Зверніться до служби підтримки Dell , щоб збільшити тайм-аут, що вимагає доступу до bash

.Змініть OST_ABANDON_TIMEOUT Параметр на стороні сервера, використовуючи кроки нижче. Його значення можна встановити на більше значення з максимальним тривалістю 12 годин.

1. Увійдіть у домен даних з доступом до ролі адміністратора . Підтримка переходить у режим bash, а потім у режим se режим з ddsh -s
2. Перевірте початкове значення OST_ABANDON_TIMEOUT . Примітка: Стандартне значення — 10800 секунд (3 години). Мінімальне значення становить 1800 секунд (30 хвилин), а максимальне — 259200 секунд (72 години).

SE@DD## se sysparam show OST_ABANDON_TIMEOUT
Name                  Description                         Current   Default   Override
-------------------   ---------------------------------   -------   -------   --------
OST_ABANDON_TIMEOUT   DDCP abandon context timeout(sec)   10800     10800     none
-------------------   ---------------------------------   -------   -------   --------

3. Збільшити OST_ABANDON_TIMEOUT значення до максимального значення = 259200 секунд (72 години).

SE@DD## se sysparam set OST_ABANDON_TIMEOUT=259200
SE@DD## se sysparam show OST_ABANDON_TIMEOUT
Name                  Description                         Current   Default   Override
-------------------   ---------------------------------   -------   -------   --------
OST_ABANDON_TIMEOUT   DDCP abandon context timeout(sec)   259200    10800     rpc
-------------------   ---------------------------------   -------   -------   --------
SE@DD##

4. Перезапустіть файлову систему після зміни вищезазначених параметрів. Підтвердіть у клієнта, чи дозволено таке перезапуск. Якщо ні, заплануйте період технічного обслуговування для виконання наступної команди:

SE@dd## filesys disable
SE@dd## filesys enable