Data Domain. BoostFS дает сбой или точка монтирования перестает отвечать

Признаки:

• 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. Войдите в Data Domain с правами доступа администратора . Служба поддержки переходит в режим bash, а затем входит в se mode с 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