Condividi tramite


Trasferimenti di dati offloaded di Windows

ODX (Offloaded Data Transfer) è una funzionalità che velocizza le operazioni di copia e spostamento del server. Questa funzionalità è disponibile a partire da Windows Server 2012 ed è supportata nei volumi NTFS. Questa pagina descrive ODX dal punto di vista del file system e del minifiltro. Per informazioni relative ai dispositivi di archiviazione, vedere Trasferimenti di dati caricati da Archiviazione Windows.

Il trasferimento di dati tra computer o all'interno dello stesso computer è un'attività frequente del file system. L'uso delle funzioni ReadFile e WriteFile standard funziona bene da un punto di vista funzionale, ma comporta un elevato spostamento dei dati attraverso tutti i livelli del sistema e potenzialmente in una rete. Questa complessità può influire sulla disponibilità dei sistemi coinvolti nel trasferimento e nella rete che connette i sistemi. Le funzionalità avanzate disponibili con molti sottosistemi di archiviazione offrono un mezzo più efficiente per eseguire l'attività di sollevamento pesante dello spostamento dei dati.

Le applicazioni possono sfruttare queste funzionalità per semplificare l'offload del processo di spostamento dei dati nel sottosistema di archiviazione. I filtri del file system possono in genere monitorare queste azioni intercettando le richieste di lettura e scrittura in un volume. Sono necessarie altre azioni per consentire ai filtri di essere a conoscenza di ODX.

Trasferimenti di dati tipici

Lo spostamento dei dati in uno scenario applicativo è oggi più semplice. Comporta la lettura dei dati nella memoria locale, quindi la scrittura in una nuova posizione. Il diagramma seguente illustra questo scenario.

Diagramma che mostra un trasferimento dati tipico.

Questo scenario comporta la copia di un file tra due percorsi in due file server diversi, ognuno con il proprio disco virtuale esposto tramite un array di archiviazione intelligente (ISA). Il sistema di avvio deve prima leggere i dati dal disco virtuale di origine in un buffer locale. Quindi crea un pacchetto e trasmette i dati tramite alcuni trasporti e protocolli (ad esempio SMB oltre 1 GbE) al secondo sistema. Il secondo sistema riceve quindi i dati e lo restituisce in un buffer locale. Il sistema di destinazione scrive quindi i dati nel disco virtuale di destinazione. Questo scenario descrive un tipico metodo di lettura/scrittura del trasferimento dei dati che viene eseguito più volte da molte applicazioni diverse ogni giorno.

Anche se le letture e le scritture standard funzionano correttamente nella maggior parte degli scenari, i dati che intendono essere copiati potrebbero trovarsi in dischi virtuali gestiti dallo stesso array di archiviazione intelligente. Questa situazione significa che i dati vengono spostati all'esterno della matrice, in un server, in un trasporto di rete, in un altro server e di nuovo nella stessa matrice. L'azione di spostamento dei dati all'interno di un server e in un trasporto di rete può influire significativamente sulla disponibilità di tali sistemi. Inoltre, la velocità effettiva dello spostamento dei dati è limitata dalla velocità effettiva e dalla disponibilità della rete.

Trasferimenti di dati offloaded (ODX)

Offload del trasferimento dei dati

In Windows 8 sono stati introdotti due file DITLS che facilitano l'offload del trasferimento dei dati. Questo offload sposta il carico di spostamento dei bit dai server allo spostamento dei bit che si verifica in modo intelligente all'interno dei sottosistemi di archiviazione. Il modo migliore per visualizzare la semantica dei comandi consiste nel considerarli come analoghi a una lettura non memorizzata nel buffer e a una scrittura senza buffer.

  • FSCTL_OFFLOAD_READ

    Questa richiesta di controllo accetta un offset all'interno del file da leggere e una lunghezza desiderata nella struttura FSCTL_OFFLOAD_READ_INPUT. Se supportato, il sottosistema di archiviazione che ospita il file riceve il comando di archiviazione in lettura offload associato. Genera quindi un token, ovvero una rappresentazione logica dei dati che devono essere letti al momento del comando di lettura offload. Questa stringa di token viene restituita al chiamante nella struttura FSCTL_OFFLOAD_READ_OUTPUT.

  • FSCTL_OFFLOAD_WRITE

    Questa richiesta di controllo accetta un offset all'interno del file in cui scrivere, la lunghezza desiderata della scrittura e il token che rappresenta una rappresentazione logica dei dati da scrivere. Se supportato, il sottosistema di archiviazione che ospita il file da scrivere riceve il comando di archiviazione di scrittura offload associato. Tenta prima di tutto di riconoscere il token specificato e quindi esegue l'operazione di scrittura, se possibile. L'operazione di scrittura viene completata sotto Windows e pertanto i componenti nel file system e negli stack di archiviazione non vedono lo spostamento dei dati. Una volta completato lo spostamento dei dati, il numero di byte scritti viene restituito al chiamante.

Analogamente al primo diagramma, il diagramma seguente mostra una copia di file semplice tra due dischi virtuali in due server diversi.

Diagramma che mostra il trasferimento dei dati scaricato.

Tuttavia, invece di eseguire letture e scritture normali, si scarica il carico elevato di spostamento dei bit nell'array di archiviazione. Il primo sistema rilascia l'operazione di lettura offload, richiedendo alla matrice di generare un token che rappresenta una visualizzazione temporizzato dei dati da leggere all'interno dell'area del primo disco virtuale. Il primo sistema trasmette quindi il token al secondo sistema, che a sua volta rilascia un'operazione di scrittura offload al secondo disco virtuale con il token. La matrice interpreta quindi il token e tenta di eseguire lo spostamento dei dati tra i dischi virtuali. Il trasferimento effettivo dei dati avviene all'interno dell'array di archiviazione intelligente e non tra i due host. Questa progettazione migliora significativamente la disponibilità dei due sistemi, eliminando praticamente il traffico di rete tra i sistemi.

Integrazione con il motore di copia

Il motore di copia principale in Windows viene usato da CopyFile e dalle funzioni correlate. A partire da Windows 8, il motore di copia tenta in modo trasparente di usare ODX prima del percorso tradizionale del codice del file di copia. Le API di copia vengono usate dalla maggior parte delle applicazioni, delle utilità e della shell. Questi chiamanti sono in grado di usare le funzionalità ODX per impostazione predefinita con poco, se presenti, modifiche del codice o intervento dell'utente.

I passaggi seguenti riepilogano il modo in cui il motore di copia tenta un ODX:

  1. Il motore di copia genera un FSCTL_OFFLOAD_READ nel file di origine per ottenere un token di lettura.
  2. Se si è verificato un errore nel recupero del token di lettura, il motore di copia esegue il fallback alle letture e alle scritture tradizionali (il percorso del codice del file di copia tradizionale). Se l'errore indica che il volume di origine non supporta l'offload, il motore di copia contrassegna anche il volume in una cache per processo. Il motore di copia non prova più a eseguire l'offload per i volumi nella cache per processo.
  3. Se il token è stato recuperato correttamente, il motore di copia tenta di eseguire comandi FSCTL_OFFLOAD_WRITE nel file di destinazione in blocchi di grandi dimensioni fino a quando non vengono scritti tutti i dati rappresentati logicamente dal token.
  4. Eventuali errori nell'esecuzione dell'offload di lettura/scrittura comportano il fallback del motore di copia al percorso di codice di lettura/scrittura tradizionale. Questo fallback inizia da dove è terminato il percorso del codice di offload (dove la lettura o la scrittura è stata troncata). Il motore di copia aggiorna la stessa cache per processo in modo che non tenti l'offload su questi volumi se una delle condizioni seguenti è vera. Questa cache per processo viene reimpostata periodicamente.
  • L'errore indica che il volume di destinazione non supporta l'offload.
  • Il volume di origine non può raggiungere il volume di destinazione.

Le funzioni seguenti supportano ODXs:

  • CopyFile
  • CopyFileEx
  • MoveFile
  • MoveFileEx
  • CopyFile2

Le funzioni seguenti non supportano ODXs:

  • CopyFileTransacted
  • MoveFileTransacted

Scenari di trasferimento dati supportati

Il supporto per le operazioni di offload viene fornito nello stack di archiviazione Hyper-V e nel file server SMB di Windows. Quando l'archiviazione fisica di backup supporta operazioni ODX, i chiamanti possono emettere FSCTL_OFFLOAD_READ e FSCTL_OFFLOAD_WRITE ai file che risiedono nei dischi rigidi virtuali o nelle condivisioni file remote, sia all'interno di una macchina virtuale che su hardware fisico. Il diagramma seguente illustra le destinazioni di origine e destinazione supportate più di base per ODX.

Diagramma che mostra gli scenari di trasferimento dei dati scaricati.

Modello di consenso esplicito del filtro del file system e effetto sulle applicazioni

A partire da Windows 8, Gestione filtri consente a un filtro di specificare la funzionalità di offload come funzionalità supportata. I filtri del file system collegati a un volume possono determinare collettivamente se è supportata una determinata operazione offloaded. Se non è supportato, l'operazione non riesce con un codice di errore appropriato.

Un filtro deve indicare che supporta FSCTL_OFFLOAD_READ e FSCTL_OFFLOAD_WRITE tramite un valore DWORD del Registro di sistema denominato SupportedFeatures, che si trova nella definizione del servizio driver nel Registro di sistema in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\filter driver name\. Questo valore contiene campi di bit in cui i bit determinano quali funzionalità sono accodate esplicitamente e devono essere impostate durante l'installazione del filtro.

Attualmente, i bit definiti sono:

Flag significato
SUPPORTED_FS_FEATURES_OFFLOAD_READ 0x00000001 Il filtro supporta FSCTL_OFFLOAD_READ
SUPPORTED_FS_FEATURES_OFFLOAD_WRITE 0x00000002 Il filtro supporta FSCTL_OFFLOAD_WRITE

Il modello di consenso esplicito del filtro può essere abilitato o disabilitato in base al valore presente nella chiave del Registro di sistema HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\FilterSupportedFeaturesMode, con i valori seguenti:

FilterSupportedFeaturesMode Value significato
0 (Predefinito) Eseguire l'elaborazione del consenso esplicito normale.
1 Non acconsentire esplicitamente (equivalente all'impostazione supportedFeatures su 0 in tutti i filtri collegati)

Test

Per controllare le funzionalità supportate di un filtro dello stack, usare l'utilità fltmc. Eseguire istanze fltmc –v [volume]: come utente con privilegi elevati e controllare la colonna SprtFtrs :

  • Se il valore SprtFtrs è 0x00, implica che il filtro blocca l'offload su questo volume. Se SprtFtrs è impostato su 0x03, sono supportate entrambe le operazioni di offload.

Controllo del supporto delle funzionalità nell'elaborazione IRP

Come parte dell'elaborazione di IRP, la routine FsRtlGetSupportedFeatures recupera lo stato aggregate SupportedFeatures per tutti i filtri collegati allo stack di volumi specificato. I componenti come Gestione I/O e SRV (SMB) chiamano questa routine per convalidare lo stato SupportedFeatures per tutti i filtri nello stack. I componenti che eseguono il rollup di runtime di integrazione offload devono chiamare questa funzione per convalidare il supporto del consenso esplicito per tale operazione.

Considerazioni per i driver di filtro

ODX è un modo per spostare i dati nel data center. A causa dell'integrazione della logica di offload nel motore di copia principale, molte applicazioni per impostazione predefinita hanno la possibilità di eseguire lo spostamento dei dati scaricato senza acconsentire esplicitamente. Di conseguenza, gli sviluppatori di filtri devono comprendere come queste operazioni influiscono sui filtri. Non comprendere completamente queste operazioni o non valutare completamente la modifica al flusso di dati può causare scenari in cui i dati possono diventare incoerenti o danneggiati. L'elenco seguente riepiloga un set di elementi di azione per filtrare gli sviluppatori per prendere nota di con offload:

  • Comprendere questo flusso di dati, l'effetto sul filtro e la capacità del filtro di supportare queste operazioni offloaded.
  • Aggiornare il programma di installazione del filtro per aggiungere un valore REG_DWORD per SupportedFeatures alla sottochiave HKLM\System\CurrentControlSet\Services\[filter]. Inizializzarlo per specificare la funzionalità di offload.
  • Per i filtri che desiderano agire sulle operazioni di offload, aggiornare la registrazione in modo da IRP_MJ_FILE_SYSTEM_CONTROL gestire FSCTL_OFFLOAD_READ e FSCTL_OFFLOAD_WRITE.
  • Per i filtri che devono bloccare le operazioni offloaded, restituire il codice di stato STATUS_NOT_SUPPORTED dall'interno del filtro. Non fare affidamento sul valore del Registro di sistema per applicare operazioni di offload bloccabili perché gli utenti finali possono modificarlo. Un filtro deve consentire o non consentire operazioni di offload in modo esplicito.

Copiare i token

Con le operazioni offloaded, lo stack di I/O non visualizza i dati del file. I dati del file sono invece considerati token a 512 byte che rappresenta il proxy logico per i dati. Questo token è:

  • Stringa opaca e univoca di un formato specifico del fornitore generato dal sottosistema di archiviazione.
  • Tipo noto per rappresentare un modello di dati, ad esempio un intervallo di dati equivalente logicamente a zero.

Le modifiche apportate ai dati del token proxy comportano l'invalidazione del token o il sottosistema di archiviazione per rendere persistenti i dati originali da alcuni mezzi specifici del fornitore, ad esempio tramite un meccanismo di snapshot. Le successive richieste di offload di lettura a un intervallo specificato in un file generano token univoci.

Esistono classi di token che rappresentano un modello di dati ben definito. Il token noto più comune è il token Zero, che equivale a zero. Quando un token viene definito come token noto, il membro TokenType nella struttura STORAGE_OFFLOAD_TOKEN viene impostato su STORAGE_OFFLOAD_TOKEN_TYPE_WELL_KNOWN. Quando questo campo è impostato, il membro WellKnownPattern determina il modello di dati del token.

  • Quando il campo WellKnownPattern è impostato su STORAGE_OFFLOAD_PATTERN_ZERO o STORAGE_OFFLOAD_PATTERN_ZERO_WITH_PROTECTION_INFORMATION, indica il token zero. Quando questo token viene restituito da un'operazione di FSCTL_OFFLOAD_READ , indica che i dati contenuti nell'intervallo di file desiderato sono logicamente equivalenti a zero. Quando questo token viene fornito a un'operazione di FSCTL_OFFLOAD_WRITE , indica che l'intervallo desiderato del file in cui scrivere deve essere azzerato logicamente.
  • Oltre a Zero Token, non sono attualmente definiti altri modelli di token noti. Non è consigliabile che gli utenti definiscino i propri modelli di token noti.

Troncamento

Il sottosistema di archiviazione sottostante con cui Windows comunica può elaborare meno dati desiderati in un'operazione di offload. Questa condizione è denominata troncamento. Con l'offload letto, il token restituito rappresenta un intervallo di dati inferiore ai dati richiesti. Il membro TransferLength nella struttura FSCTL_OFFLOAD_READ_OUTPUT viene utilizzato per indicare questo valore, ovvero un conteggio di byte dall'inizio dell'intervallo del file da leggere. Per la scrittura offload, un troncamento indica che sono stati scritti meno dati di quanto desiderato. Il membro LengthWritten nella struttura FSCTL_OFFLOAD_WRITE_OUTPUT indica questo valore, ovvero un conteggio di byte dall'inizio dell'intervallo del file da scrivere. Gli errori nell'elaborazione dei comandi o le limitazioni all'interno dello stack per intervalli di grandi dimensioni comportano il troncamento.

Esistono due scenari in cui NTFS tronca l'intervallo in modo da eseguire l'offload o la scrittura:

  1. L'intervallo di copia viene troncato a Valid Data Length (VDL) se VDL è prima della fine del file (EOF). Questa azione presuppone che VDL sia allineato a un limite di settore logico. In caso contrario, vedere lo scenario.

    Diagramma che mostra il VDL che si verifica prima di EOF.

    Durante un'operazione di FSCTL_OFFLOAD_READ, il flag OFFLOAD_READ_FLAG_ALL_ZERO_BEYOND_CURRENT_RANGE viene impostato nella struttura FSCTL_OFFLOAD_READ_OUTPUT che indica che il resto del file contiene zeri e il membro TransferLength viene troncato in VDL.

  2. Analogamente allo scenario 1, ma quando VDL non è allineato a un limite di settore logico, NTFS tronca l'intervallo desiderato al successivo limite di settore logico.

    Diagramma che mostra il disallineamento VDL con il limite del settore.

Limiti

  • Le operazioni di offload sono supportate solo nei volumi NTFS.
  • Le operazioni di offload sono supportate tramite file server remoti se le condizioni seguenti sono entrambe vere:
    • La condivisione remota è un volume NTFS.
    • Il server esegue Windows Server 2012 o versioni successive (presupponendo che lo stack remoto supporti anche le operazioni di offload).
  • NTFS non supporta l'offload DITLs eseguito su file crittografati con crittografia Bitlocker o NTFS (EFS), file deduplicati, file compressi, file residenti, file sparse o file che partecipano alle transazioni TxF.
  • NTFS non supporta l'offload DITLs eseguito sui file all'interno di uno snapshot volsnap.
  • NTFS non riesce l'offload FSCTL se una delle condizioni seguenti è vera. Questo approccio segue la stessa semantica dell'I/O non memorizzato nella cache.
    • L'intervallo di file desiderato non è allineato alle dimensioni del settore logico nel dispositivo di origine.
    • L'intervallo di file desiderato non è allineato alle dimensioni del settore logico nel dispositivo di destinazione.
  • Il file di destinazione deve essere preallocato (SetEndOfFile e non SetAllocation) prima di FSCTL_OFFLOAD_WRITE.
  • Quando NTFS elabora letture e scritture offload, chiama prima CcCoherencyFlushAndPurgeCache per eseguire il commit di tutti i dati modificati nella cache di sistema. Questa azione è la stessa semantica dell'I/O non memorizzato nella cache.