Esempi di blocchi opportunistici
Negli esempi seguenti vengono mostrati i movimenti dei dati e dei messaggi SMB quando vengono eseguiti e interrotti blocchi opportunistici. Si noti che i client possono memorizzare nella cache i dati degli attributi dei file e i dati dei file.
Si noti anche che questi esempi si basano su situazioni in cui le applicazioni client richiedono blocchi opportunistici dai server remoti. Questi processi vengono avviati automaticamente dal redirector di rete e dal server remoto, senza alcun coinvolgimento diretto da parte dell'applicazione client o delle applicazioni. I processi descritti da questi esempi possono essere generalizzati in situazioni in cui le applicazioni client locali richiedono direttamente blocchi opportunistici dal file system locale, con l'eccezione che non è coinvolto alcun scambio di dati in rete.
Blocco opportunistico di livello 1
Il diagramma seguente mostra una visualizzazione del traffico di rete di un blocco opportunistico di livello 1 in un file. Le frecce indicano la direzione dello spostamento dei dati, se presente.
| Evento | Client X | Server | Client Y |
|---|---|---|---|
| 1 | Apre il file, il blocco di livello 1 delle richieste ==> | ||
| 2 | <== Concede il blocco opportunistico di livello 1 | ||
| 3 | Esegue operazioni di lettura, scrittura e altre operazioni ==> | ||
| 4 | <== Richieste di apertura del file | ||
| 5 | <== Interrompe il blocco opportunistico | ||
| 6 | Elimina i dati read-ahead | ||
| 7 | Scrive dati ==> | ||
| 8 | Invia il messaggio "close" o "done" ==> | ||
| 9 | Okays open operation ==> | ||
| 10 | Esegue operazioni di lettura, scrittura e altre operazioni ==> | <== Esegue operazioni di lettura, scrittura e altre operazioni |
Nell'evento 1, il client X apre un file e come parte dell'operazione di apertura richiede un blocco opportunistico di livello 1 nel file. Nell'evento 2, il server concede il blocco di livello 1 perché non è aperto alcun altro client. Il client procede per accedere al file nel modo consueto nell'evento 3.
Nel caso 4, il client Y tenta di aprire il file e richiede un blocco opportunistico. Il server rileva che il client X ha il file aperto. Il server ignora la richiesta di Y mentre il client X scarica tutti i dati di scrittura e abbandona la cache di lettura per il file.
Il server forza X a eseguire la pulizia inviando a X un messaggio SMB che causa l'interruzione del blocco opportunistico, evento 5. Client X "invisibile all'utente" elimina tutti i dati read-ahead; in altre parole, questo processo non genera traffico di rete. Nel caso 7, il client X scrive tutti i dati di scrittura memorizzati nella cache nel server. Al termine della scrittura di dati memorizzati nella cache nel server, il client X invia un messaggio "close" o "done" al server, evento 8.
Dopo che il server ha comunicato che il client X ha completato lo scaricamento della cache di scrittura nel server o ha chiuso il file, il server può aprire il file per il client Y, nel caso 9. Poiché il server dispone ora di due client con lo stesso file aperto, concede un blocco opportunistico a nessuno dei due client. Entrambi i client passano alla lettura dal file e uno o nessuna delle due scritture nel file.
Blocco opportunistico batch
Il diagramma seguente mostra una visualizzazione del traffico di rete di un blocco opportunistico batch. Le frecce indicano la direzione dello spostamento dei dati, se presente.
| Evento | Client X | Server | Client Y |
|---|---|---|---|
| 1 | Apre un file, richiede il blocco batch ==> | ||
| 2 | <== Concede il blocco opportunistico batch | ||
| 3 | Legge il file ==> | ||
| 4 | <== Invia dati | ||
| 5 | Chiude il file | ||
| 6 | Apre il file | ||
| 7 | Cerca dati | ||
| 8 | Legge i dati ==> | ||
| 9 | <== Invia dati | ||
| 10 | Chiude il file | ||
| 11 | <== Apre il file | ||
| 12 | <== Interrompe il blocco opportunistico | ||
| 13 | Chiude il file ==> | ||
| 14 | Okays open operation ==> | ||
| 15 | <== Esegue operazioni di lettura, scrittura e altre operazioni |
Nel blocco opportunistico del batch, client X apre un file, l'evento 1 e il server concede al client X un blocco batch nell'evento 2. Il client X tenta di leggere i dati, evento 3, a cui il server risponde con i dati, evento 4.
L'evento 5 mostra il blocco opportunistico batch sul lavoro. L'applicazione in Client X chiude il file. Tuttavia, il redirector di rete filtra l'operazione di chiusura e non trasmette un messaggio di chiusura, eseguendo così una chiusura "invisibile all'utente". Il redirector di rete può eseguire questa operazione perché il client X ha la sola proprietà del file. Successivamente, nell'evento 6, l'applicazione riapre il file. Anche in questo caso, nessun flusso di dati attraverso la rete. Per quanto riguarda il server, questo client ha avuto il file aperto dall'evento 2.
Gli eventi 7, 8 e 9 mostrano il normale corso del traffico di rete. Nell'evento 10, si verifica un'altra chiusura invisibile all'utente.
Nell'evento 11, il client Y tenta di aprire il file. La visualizzazione del file del server è che il client X lo ha aperto, anche se l'applicazione sul client X l'ha chiusa. Pertanto, il server invia un messaggio che interrompe il blocco opportunistico al client X. Client X invia ora il messaggio di chiusura attraverso la rete, evento 13. L'evento 14 segue quando il server apre il file per il client Y. L'applicazione sul client X ha chiuso il file, quindi non esegue più trasferimenti da o verso il server per tale file. Il client Y avvia i trasferimenti di dati come di consueto nell'evento 15.
Tra l'ora in cui il client X viene concesso il blocco sul file nell'evento 2 e la chiusura finale all'evento 13, tutti i dati di file memorizzati nella cache del client sono validi, nonostante le operazioni di apertura e chiusura dell'applicazione intermedie. Tuttavia, dopo l'interruzione del blocco opportunistico, i dati memorizzati nella cache non possono essere considerati validi.
Filtro blocco opportunistico
Il diagramma seguente mostra una visualizzazione del traffico di rete di un blocco opportunistico del filtro. Le frecce indicano la direzione dello spostamento dei dati, se presente.
| Evento | Client X | Server | Client Y |
|---|---|---|---|
| 1 | Apre il file senza diritti di accesso ==> | ||
| 2 | <== Apre il file | ||
| 3 | Filtro richieste lock==> | ||
| 4 | <== Concede il blocco | ||
| 5 | Apre il file per la lettura ==> | ||
| 6 | <== Riapre il file | ||
| 7 | Legge i dati usando l'handle di lettura ==> | ||
| 8 | <== Invia dati | ||
| 9 | <== Invia dati | ||
| 10 | <== Invia dati | ||
| 11 | <== Apre il file | ||
| 12 | Apre il file ==> | ||
| 13 | <== Blocco filtro richieste | ||
| 14 | Nega il filtro lock==> | ||
| 15 | <== Legge i dati | ||
| 16 | Invia dati ==> | ||
| 17 | Legge i dati (memorizzati nella cache) | ||
| 18 | Chiude il file ==> | ||
| 19 | <== Chiude il file |
Nel blocco opportunistico del filtro, il client X apre un file, l'evento 1 e il server risponde nell'evento 2. Il client richiede quindi un blocco opportunistico di filtro nell'evento 3, seguito dal server che concede il blocco opportunistico nell'evento 4. Client X apre di nuovo il file per la lettura nell'evento 5, a cui il server risponde nell'evento 6. Il client tenta quindi di leggere i dati, a cui il server risponde con dati, evento 8.
L'evento 9 mostra il blocco opportunistico del filtro sul luogo di lavoro. Il server legge prima del client e invia i dati in rete anche se il client non lo ha richiesto. Il client memorizza nella cache i dati. Nell'evento 10, il server prevede inoltre una richiesta futura di dati e invia un'altra parte del file per il client nella cache.
Nell'evento 11 e 12, un altro client, Y, apre il file. Il client Y richiede anche un blocco opportunistico del filtro. Nell'evento 14, il server lo nega. Nel caso 15, il client Y richiede i dati inviati dal server nell'evento 16. Nessuno di questi effetti influisce sul client X. In qualsiasi momento, un altro client può aprire questo file per l'accesso in lettura. Nessun altro client influisce sul blocco filtro del client X.
L'evento 17 mostra i dati di lettura del client X. Tuttavia, poiché il server ha già inviato i dati e il client lo ha memorizzato nella cache, nessun traffico attraversa la rete.
In questo esempio, client X non tenta mai di leggere tutti i dati nel file, quindi il read-ahead indicato dagli eventi 9 e 10 è "sprecato"; ovvero, i dati non vengono mai effettivamente usati. Si tratta di una perdita accettabile perché read-ahead ha accelerato l'applicazione.
Nel caso 18, il client X chiude il file. Il reindirizzamento di rete del client abbandona i dati memorizzati nella cache. Il server chiude il file.