Data Domain: BoostFS raakt in paniek of koppelpunt reageert niet meer

Symptomen:

• BoostFS crasht en raakt willekeurig in paniek. Dit gebeurt wanneer de werkdruk hoog is.
• De back-upapplicatie presteert vertraagd READ als WRITE bewerkingen op het BoostFS-koppelpunt.
• Wanneer er vertragingen zijn in READ als WRITE bewerkingen van de back-upapplicatie, blijkt dit uit BoostFS-logboeken error 5057 File handle is stale from Data Domain server.

BoostFS logboeken:

###### 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)

Triage:

1. Controleer de DDFS-logboeken van BoostFS en serverzijde op de hierboven beschreven fout.
2. Let op de vertraging in READ als WRITE bewerkingen vanuit de back-upapplicatie. Overweeg BoostFS API-invoer- en uitgangslogboeken.
3. Controleer de waarde die is ingesteld voor OST_ABANDON_TIMEOUT (standaard drie uur).
4. Controleer of de time-out van de RPC groter is dan de waarde die is ingesteld voor OST_ABANDON_TIMEOUT.

1. Het probleem is te wijten aan een vertraging in de READ als WRITE bewerkingen door de back-upapplicatie. Hierdoor wordt de DDFS geactiveerd om time-outs te negeren. Dit leidt ertoe dat de bijbehorende bestandshandle na drie uur wordt gesloten (standaardwaarde)
2. Dit is de standaard verwijderingstime-outperiode die door DDFS wordt gebruikt om inactieve bestandshandle te identificeren. Uiteindelijk kunnen nieuwe schrijfbewerkingen paniek ervaren aan de kant van de klant.

Neem contact op met Dell Support om de time-out te verlengen waarvoor toegang tot bash is vereist.

Wijzig de OST_ABANDON_TIMEOUT parameter aan de serverzijde met behulp van de onderstaande stappen. De waarde kan worden ingesteld op een grotere waarde met een maximum van 12 uur.

1. Meld u aan bij Data Domain met toegang tot de beheerdersrol . Support gaat naar bash-modus en gaat vervolgens naar se modus met ddsh -s
2. Controleer het origineel OST_ABANDON_TIMEOUT Waarde.

SE@dd## se sysparam show OST_ABANDON_TIMEOUT

3. Verhoog de OST_ABANDON_TIMEOUT Waarde. De waarde is standaard 10800 (drie uur).

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. Start het bestandssysteem opnieuw op na de bovenstaande parameterwijziging. Neem contact op met de klant om na te gaan of deze herstart is toegestaan. Zo niet, plant u een onderhoudsperiode om de volgende opdracht uit te voeren:

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