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

Симптоми:

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

Журнали BoostFS:

###### 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 на наявність помилки, про яку повідомляли вище.
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 цінність.

SE@dd## se sysparam show OST_ABANDON_TIMEOUT

3. Збільшити OST_ABANDON_TIMEOUT цінність. За замовчуванням значення — 10800 (три години).

SE@dd## se sysparam set OST_ABANDON_TIMEOUT=129600
SE@dd## se sysparam show OST_ABANDON_TIMEOUT

Name Description Current Default Override
------------------- --------------------------------- ------- ------- -----
---
OST_ABANDON_TIMEOUT DDCP abandon context timeout(sec) 129600 10800 rpc
------------------- --------------------------------- ------- ------- -----
---

SE@dd##priv set admin

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

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