DD OS 5.7: L'accesso al file con CIFS in MTree, la destinazione per la replica MTree, provoca errori o riavvii DDFS o handle di file obsoleti dopo l'aggiornamento

I Data Domain Restorer (DDR) possono essere configurati per replicare il contenuto di singoli MTrees su un sistema su un sistema remoto tramite MTree Replication (MREPL). Anche se l MTree sulla destinazione è read-only, può comunque essere utilizzato per accedere ai file replicati per leggere/ripristinare/creare report o un'ulteriore replica in uscita.

Se il DDR di destinazione esegue DDOS 5.7 e si accede a un MTree utilizzato come destinazione per MREPL tramite CIFS, il processo DD FS potrebbe riscontrare PANIC/riavvii (causando un'interruzione dell'esecuzione di backup/restore/replica) a causa di un difetto nel codice, con possibili firme PANIC come illustrato di seguito:
 

PANICO: fmcl/fm_inode.c: fm_iput_unpin: 468: fm_iput_unpin fallito. Dirents ancora presenti. ERRORE IRREVERSIBILE: ddr/fm/fm_server.c: fms_write_segs: 1891: str == NULL ERRORE IRREVERSIBILE: ddr/fm/fm_dm1_access.c: fm_dm1_access_intern: 203: fms_is_private_file_handle(&attr-fh>) && cred != g_nocred_p

Inoltre, il client CIFS che si connette all MTree tramite CIFS potrebbe visualizzare errori di "handle non valido". Si noti che questo problema riguarda solo i DDR che eseguono DDOS 5.7 e non è applicabile ad altre versioni di DDOS.
 

Inoltre, esiste un'altra possibile manifestazione dello stesso problema che può verificarsi su DDOS 6.x o versioni successive anche quando il difetto descritto è stato risolto (vedere di seguito per le versioni). La correzione originale non è riuscita a identificare un altro percorso di codice per lo stesso difetto (vale a dire, quando il FS di destinazione per l MTree utilizzato per accedere ai file tramite CIFS è pieno al 100%), il che può comportare la stessa stringa PANIC riportata di seguito e che da allora è stata risolta in alcune versioni di DDOS 6.x:

09/12 01:56:30.847 (Tid 0x7f557410ec20): ERROR: MSG-INTRNL-00001: PANICO: fmcl/fm_inode.c: fm_iput_unpin: 469: fm_iput_unpin fallito. Dirents ancora presenti.

DDOS 5.7 e versioni successive (che hanno completamente modificato l'implementazione SMB/CIFS sottostante in DDOS) includono nuove funzionalità che consentono handle di file CIFS stateful. Questo problema è causato da un difetto nel modo in cui questi handle di file CIFS stateful interagiscono con la funzionalità di replica MTree.

Si noti che una correzione per questo problema è stata inclusa nelle seguenti versioni hotfix/patch di DDOS (nota: a partire da settembre 2019, DDOS 5.7 non è più una versione supportata):

• DDOS 5.7.1.10 e versioni successive
• DDOS 5.7.2.0 e versioni successive
• DDOS 5.7.32.0 (questa versione è applicabile solo agli appliance virtuali Data Domain Virtual Edition/DDVE)

A questo punto, i clienti devono eseguire l'upgrade a una versione DDOS 6.x supportata, poiché il 31 gennaio 2019 è terminata il termine del supporto per la famiglia DDOS 5.7.


Per il difetto del caso limite che può verificarsi quando il FS che funge da destinazione per MREPL è pieno al 100%, non esiste alcuna correzione in nessuna versione di DDOS 5.7, ma è presente nelle seguenti versioni successive (e attualmente supportate):

• DDOS 6.0.2.40 e versioni successive
• DDOS 6.1.2.30 e versioni successive
• DDOS 6.2.0.20 e versioni successive

Poiché in questo caso (quando DD FS problematico è al 100%) potrebbe non essere immediatamente possibile aggiornare DDOS a causa della mancanza di spazio FS, una possibile soluzione alternativa potrebbe essere:

• Disabilitare tutta l'acquisizione e i protocolli in uso, nonché la replica
• Eseguire la pulizia (anche se il FS è pieno al 100%, dovrebbe essere completato correttamente) e attendere il completamento
• Ora che il FS non dovrebbe più essere pieno al 100%, dedicare del tempo a rimuovere ulteriori backup, verificare la presenza di istantanee obsolete e così via ed eseguire nuovamente la pulizia
• Quando la quantità di spazio su disco è sufficiente per evitare di riempire nuovamente il FS, riabilitare i protocolli e riprendere i backup
• Pianificare l'aggiornamento a una versione fissa in un secondo momento

Se FS è inattivo o si arresta in modo anomalo ripetutamente, contattare il fornitore di supporto a contratto in modo da poter fornire una soluzione alternativa alternativa.