La dimensione del file è meno importante del numero di scritture effettuate tra OPEN e CLOSE chiamate per un file. I file di piccole dimensioni hanno intrinsecamente WRITE meno chiamate, il che li rende meno ideali per la riscrittura. I file di grandi dimensioni potrebbero avere più scritture tra OPEN e CLOSE chiamate, ma ciò non è garantito.

Fare riferimento alla "Linee guida per la riscrittura di FlexCache" pagina per le raccomandazioni più aggiornate relative alle dimensioni massime del file.

Quando si scrive da un client, vengono coinvolte altre chiamate NAS modificanti diverse da quelle in scrittura. Questi includono, ma non sono limitati a:

SETATTR e SET_INFO le chiamate che impostano mtime, atime ctime , owner, , group o size vengono elaborate nella cache. Il resto di queste chiamate deve essere elaborato all'origine e attivare una riscrittura di tutti i dati sporchi accumulati nella cache abilitata alla riscrittura per il file su cui si opera. Io al file verrà interrotto fino al completamento della riscrittura.

Sapendo che queste chiamate devono attraversare la WAN, è possibile identificare i carichi di lavoro adatti per la riscrittura. In genere, maggiore è il numero di operazioni OPEN di scrittura che CLOSE è possibile effettuare tra e chiamate senza che venga emessa una delle altre chiamate elencate sopra, migliore è il guadagno di prestazioni di write-back.

I workload in lettura dopo scrittura hanno storicamente ottenuto performance scarse in FlexCache. Ciò è dovuto alla modalità operativa write-around precedente alla 9.15.1. La WRITE chiamata al file deve essere confermata all'origine e la chiamata successiva READ dovrebbe riportare i dati nella cache. In questo modo, entrambe le operazioni impongono penalizzazioni alla rete WAN. Pertanto, i carichi di lavoro in lettura dopo scrittura sono scoraggiati per FlexCache in modalità write-around. Con l'introduzione del write-back in 9.15.1, i dati vengono ora salvati nella cache e possono essere letti immediatamente dalla cache, eliminando la penalizzazione della WAN. Se il carico di lavoro include la lettura dopo la scrittura nei volumi FlexCache, è necessario configurare la cache in modo che funzioni in modalità write-back.

Quando un file accumula dati sporchi in una cache, la cache li scrive in modo asincrono nell'origine. Ciò porta naturalmente a tempi in cui il client chiude il file con dati sporchi ancora in attesa di essere scaricati di nuovo all'origine. Se si verifica un'altra apertura o scrittura per il file che è stato appena chiuso e contiene ancora dati sporchi, la scrittura verrà sospesa fino a quando tutti i dati sporchi non saranno stati trasferiti all'origine.

Quando FlexCache opera in modalità write-back, i client NAS ottengono maggiori benefici all'aumentare della latenza. Esiste un punto, tuttavia, in cui l'overhead del write-back supera i vantaggi ottenuti negli ambienti a bassa latenza. In alcuni test di NetApp, i vantaggi della riscrittura hanno avuto inizio con una latenza minima tra cache e origine di 8ms ms. Questa latenza varia in base al carico di lavoro, quindi assicurati di verificare il punto di ritorno del tuo carico di lavoro.

Il grafico seguente mostra il punto di ritorno per la riscrittura nei test di laboratorio NetApp. L' x asse è la dimensione del file e l' y asse è il tempo trascorso. Il test ha utilizzato NFSv3, montando con un rsize e wsize di 256KB, e 64ms di latenza WAN. Questo test è stato eseguito utilizzando una piccola istanza di ONTAP Select sia per la cache che per l'origine, e una singola operazione di scrittura con thread. I risultati possono variare.