Transferências de dados descarregados do Windows

ODX (Transferência de Dados Descarregados) é um recurso que acelera as operações de cópia e movimentação do servidor. Esse recurso está disponível a partir do Windows Server 2012 e tem suporte em volumes NTFS. Esta página descreve a ODX de uma perspectiva de sistema de arquivos e minifiltro. Para obter informações relacionadas a dispositivos de armazenamento, consulte Transferências de dados descarregadas de armazenamento do Windows.

A transferência de dados entre computadores ou dentro do mesmo computador é uma atividade frequente do sistema de arquivos. O uso das funções padrão ReadFile e WriteFile funciona bem do ponto de vista funcional, mas envolve movimentação pesada de dados em todos os níveis do sistema e, potencialmente, em uma rede. Essa complexidade pode afetar a disponibilidade dos sistemas envolvidos na transferência e a rede que conecta os sistemas. Os recursos avançados disponíveis em muitos subsistemas de armazenamento fornecem um meio mais eficiente de executar a tarefa pesada de movimentação de dados.

Os aplicativos podem aproveitar esses recursos para ajudar a descarregar o processo de movimentação de dados para o subsistema de armazenamento. Os filtros do sistema de arquivos normalmente podem monitorar essas ações interceptando solicitações de leitura e gravação em um volume. Mais ações são necessárias para que os filtros estejam cientes das ODXs.

Transferências de dados típicas

Mover dados em um cenário de aplicativo hoje é mais simples. Envolve a leitura dos dados na memória local e, em seguida, a gravação de volta em um novo local. O diagrama a seguir ilustra esse cenário.

Esse cenário envolve a cópia de um arquivo entre dois locais em dois servidores de arquivos diferentes, cada um com seu próprio disco virtual exposto por meio de um ISA (Intelligent Storage Array). O sistema inicial primeiro precisa ler os dados do disco virtual de origem em um buffer local. Em seguida, ele empacota e transmite os dados por meio de algum transporte e protocolo (como SMB sobre 1 GbE) para o segundo sistema. O segundo sistema recebe os dados e os envia para um buffer local. Em seguida, o sistema de destino grava os dados no disco virtual de destino. Este cenário descreve um método típico de leitura/gravação de transferência de dados que é executado várias vezes por muitos aplicativos diferentes todos os dias.

Embora as leituras e gravações padrão funcionem bem na maioria dos cenários, os dados que pretendem ser copiados podem estar localizados em discos virtuais gerenciados pelo mesmo Intelligent Storage Array. Essa situação significa que os dados são movidos para fora da matriz, para um servidor, através de um transporte de rede, para outro servidor e de volta para a mesma matriz novamente. O ato de mover dados dentro de um servidor e através de um transporte de rede pode afetar significativamente a disponibilidade desses sistemas. Além disso, a taxa de transferência da movimentação de dados é limitada pela taxa de transferência e disponibilidade da rede.

Transferências de dados descarregados (ODX)

Descarregando a transferência de dados

Dois FSCTLs foram introduzidos no Windows 8 que facilitam um método de descarregamento da transferência de dados. Esse descarregamento transfere a carga do movimento de bits dos servidores para o movimento de bits que ocorre de forma inteligente nos subsistemas de armazenamento. A melhor maneira de visualizar a semântica de comando é pensar neles como análogos a uma leitura sem buffer e uma gravação sem buffer.

• FSCTL_OFFLOAD_READ

  Essa solicitação de controle usa um deslocamento dentro do arquivo a ser lido e um comprimento desejado na estrutura FSCTL_OFFLOAD_READ_INPUT. Se houver suporte, o subsistema de armazenamento que hospeda o arquivo recebe o comando de armazenamento de leitura de descarregamento associado. Em seguida, ele gera um token, que é uma representação lógica dos dados destinados a serem lidos no momento do comando de leitura de descarregamento. Essa cadeia de caracteres de token é retornada ao chamador na estrutura FSCTL_OFFLOAD_READ_OUTPUT.

• FSCTL_OFFLOAD_WRITE

  Essa solicitação de controle usa um deslocamento dentro do arquivo a ser gravado, o comprimento desejado da gravação e o token que é uma representação lógica dos dados a serem gravados. Se houver suporte, o subsistema de armazenamento que hospeda o arquivo a ser gravado recebe o comando de armazenamento offload write associado. Primeiro, ele tenta reconhecer o token fornecido e, em seguida, executa a operação de gravação, se possível. A operação de gravação é concluída no Windows e, portanto, os componentes no sistema de arquivos e nas pilhas de armazenamento não veem a movimentação de dados. Depois que a movimentação de dados for concluída, o número de bytes gravados será retornado ao chamador.

Semelhante ao primeiro diagrama, o diagrama a seguir mostra uma cópia de arquivo simples entre dois discos virtuais em dois servidores diferentes.

No entanto, em vez de fazer leituras e gravações normais, descarregamos o trabalho pesado do movimento de bits para a matriz de armazenamento. O primeiro sistema emite a operação de leitura de descarregamento, solicitando que a matriz gere um token que represente uma exibição pontual dos dados a serem lidos na região do primeiro disco virtual. Em seguida, o primeiro sistema transmite o token para o segundo sistema, que, por sua vez, emite uma operação de gravação de descarregamento para o segundo disco virtual com o token. Em seguida, a matriz interpreta o token e tenta executar a movimentação de dados entre os discos virtuais. A transferência de dados real ocorre dentro da matriz de armazenamento inteligente e não entre os dois hosts. Esse design melhora significativamente a disponibilidade dos dois sistemas, eliminando virtualmente o tráfego de rede entre os sistemas.

Integração com o mecanismo de cópia

O mecanismo de cópia principal no Windows é usado por CopyFile e funções relacionadas. A partir do Windows 8, o mecanismo de cópia tenta usar ODX de forma transparente antes do caminho de código de arquivo de cópia tradicional. As APIs de cópia são usadas pela maioria dos aplicativos, utilitários e pelo shell. Esses chamadores podem usar recursos ODX por padrão com pouca ou nenhuma modificação de código ou intervenção do usuário.

As etapas a seguir resumem como o mecanismo de cópia tenta uma ODX:

1. O mecanismo de cópia emite um FSCTL_OFFLOAD_READ no arquivo de origem para obter um token de leitura.
2. Se houver uma falha na recuperação do token de leitura, o mecanismo de cópia retornará às leituras e gravações tradicionais (o caminho de código de arquivo de cópia tradicional). Se a falha indicar que o volume de origem não dá suporte ao descarregamento, o mecanismo de cópia também marcará o volume em um cache por processo. O mecanismo de cópia não tenta mais descarregar os volumes no cache por processo.
3. Se o token tiver sido recuperado com êxito, o mecanismo de cópia tentará emitir comandos FSCTL_OFFLOAD_WRITE no arquivo de destino em grandes partes até que todos os dados representados logicamente pelo token sejam gravados em offload.
4. Quaisquer erros na execução da leitura/gravação de descarregamento resultam no mecanismo de cópia voltando ao caminho de código de leitura/gravação tradicional. Esse fallback começa de onde o caminho do código de descarregamento terminou (onde a leitura ou gravação foi truncada). O mecanismo de cópia atualiza o mesmo cache por processo para que ele não tente descarregar nesses volumes se uma das condições a seguir for verdadeira. Esse cache por processo é redefinido periodicamente.

• A falha indica que o volume de destino não dá suporte ao descarregamento.
• O volume de origem não pode alcançar o volume de destino.

As seguintes funções são compatíveis com ODXs:

• CopyFile
• CopyFileEx
• MoveFile
• MoveFileEx
• CopyFile2

As seguintes funções não são compatíveis com ODXs:

• CopyFileTransacted
• MoveFileTransacted

Cenários de transferência de dados de descarregamento com suporte

O suporte para as operações de descarregamento é fornecido na pilha de armazenamento do Hyper-V e no Servidor de Arquivos SMB do Windows. Quando o armazenamento físico de backup dá suporte a operações ODX, os chamadores podem emitir FSCTL_OFFLOAD_READ e FSCTL_OFFLOAD_WRITE para arquivos que residem em VHDs ou em compartilhamentos de arquivos remotos, seja de dentro de uma máquina virtual ou em hardware físico. O diagrama a seguir ilustra os destinos de origem e destino com suporte mais básicos para ODXs.

Modelo de aceitação do filtro do sistema de arquivos e efeito nos aplicativos

A partir do Windows 8, o Gerenciador de Filtros permite que um filtro especifique a funcionalidade de descarregamento como um recurso com suporte. Os filtros do sistema de arquivos anexados a um volume podem determinar coletivamente se há suporte para uma determinada operação descarregada. Se não houver suporte, a operação falhará com um código de erro apropriado.

Um filtro deve indicar que ele dá suporte a FSCTL_OFFLOAD_READ e FSCTL_OFFLOAD_WRITE por meio de um valor DWORD de registro chamado SupportedFeatures, localizado na definição de serviço de driver no registro em HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\nome do driver do filtro\. Esse valor contém campos de bits em que os bits determinam qual funcionalidade é aceita e devem ser definidos durante a instalação do filtro.

Atualmente, os bits definidos são:

Sinalizador	Significado
SUPPORTED_FS_FEATURES_OFFLOAD_READ 0x00000001	O filtro suporta FSCTL_OFFLOAD_READ
SUPPORTED_FS_FEATURES_OFFLOAD_WRITE 0x00000002	O filtro suporta FSCTL_OFFLOAD_WRITE

O modelo de aceitação de filtro pode ser habilitado ou desabilitado com base no valor presente na chave do Registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\FilterSupportedFeaturesMode, que tem os seguintes valores:

Valor FilterSupportedFeaturesMode	Significado
0 (Padrão)	Realize o processamento normal de aceitação.
1	Nunca aceitar (equivalente a definir SupportedFeatures como 0 em todos os filtros anexados)

Testando

Para verificar os recursos suportados de um filtro da pilha, use o utilitário fltmc. Execute fltmc instances –v [volume]: como um usuário elevado e verifique a coluna SprtFtrs:

• Se o valor de SprtFtrs for 0x00, isso implicará que o filtro está bloqueando o descarregamento nesse volume. Se SprtFtrs estiver definido como 0x03, ambas as operações de descarregamento terão suporte.

Verificando o suporte a recursos no processamento de IRP

Como parte do processamento de IRP, a rotina FsRtlGetSupportedFeatures recupera o estado agregado SupportedFeatures para todos os filtros anexados à pilha de volumes fornecida. Componentes como o Gerenciador de E/S e o SRV (SMB) chamam essa rotina para validar o estado SupportedFeatures para todos os filtros na pilha. Os componentes que rolam seus próprios IRPs de descarregamento devem chamar essa função para validar o suporte de aceitação para essa operação.

Considerações sobre drivers de filtro

ODX é uma maneira de mover dados no data center. Devido à integração da lógica de descarregamento no mecanismo de cópia principal, muitos aplicativos, por padrão, têm a capacidade de executar a movimentação de dados descarregados sem aceitar explicitamente. Como resultado, os desenvolvedores de filtros precisam entender como essas operações afetam os filtros. Não entender totalmente essas operações ou não avaliar a alteração no fluxo de dados pode resultar em cenários em que os dados podem se tornar inconsistentes ou corrompidos. A lista a seguir resume um conjunto de itens de ação para os desenvolvedores de filtros anotarem com o descarregamento:

• Entenda esse fluxo de dados, o efeito no filtro e a capacidade do filtro de dar suporte a essas operações descarregadas.
• Atualize o instalador de filtro para adicionar um valor REG_DWORD para SupportedFeatures à subchave HKLM\System\CurrentControlSet\Services\[filter]. Inicialize-o para especificar a funcionalidade de descarregamento.
• Para filtros que desejam atuar em operações de descarregamento, atualize o registro para IRP_MJ_FILE_SYSTEM_CONTROL para lidar com FSCTL_OFFLOAD_READ e FSCTL_OFFLOAD_WRITE.
• Para filtros que precisam bloquear operações descarregadas, retorne o código de status STATUS_NOT_SUPPORTED de dentro do filtro. Não confie no valor do Registro para impor operações de descarregamento de bloqueio, pois os usuários finais podem alterá-lo. Um filtro deve permitir ou proibir explicitamente operações de descarregamento.

Copiar Tokens

Com operações descarregadas, a pilha de E/S não vê os dados do arquivo. Em vez disso, os dados do arquivo são vistos como um token de 512 bytes que é o proxy lógico para os dados. Esse token é:

• Uma cadeia de caracteres opaca e exclusiva de um formato específico do fornecedor gerada pelo subsistema de armazenamento.
• Um tipo conhecido para representar um padrão de dados (como um intervalo de dados que é logicamente equivalente a zero).

As modificações nos dados do token proxy resultam na invalidação do token ou no subsistema de armazenamento para persistir os dados originais por alguns meios específicos do fornecedor, como por meio de um mecanismo de captura instantânea. As solicitações de leitura de descarregamento subsequentes para um intervalo especificado em um arquivo resultam em tokens exclusivos.

Existem classes de tokens que representam um padrão de dados bem definido. O token mais comum conhecido é o Zero Token, que equivale a zero. Quando um token é definido como um Token Bem Conhecido, o membro TokenType na estrutura STORAGE_OFFLOAD_TOKEN é definido como STORAGE_OFFLOAD_TOKEN_TYPE_WELL_KNOWN. Quando esse campo é definido, o membro WellKnownPattern determina qual padrão de dados é o token.

• Quando o campo WellKnownPattern é definido como STORAGE_OFFLOAD_PATTERN_ZERO ou STORAGE_OFFLOAD_PATTERN_ZERO_WITH_PROTECTION_INFORMATION, ele indica o Token Zero. Quando esse token é retornado por uma operação FSCTL_OFFLOAD_READ, ele indica que os dados contidos no intervalo de arquivos desejado são logicamente equivalentes a zero. Quando esse token é fornecido para uma operação FSCTL_OFFLOAD_WRITE, ele indica que o intervalo desejado do arquivo a ser gravado deve ser zerado logicamente.
• Além do Zero Token, não há outros padrões de Token Bem Conhecidos atualmente definidos. Não é recomendável que os usuários definam seus próprios padrões de Token Bem Conhecido.

Truncation

O subsistema de armazenamento subjacente com o qual o Windows se comunica pode processar menos dados do que os desejados em uma operação de descarregamento. Essa condição é chamada de truncamento. Com a leitura de descarregamento, o token retornado representa um intervalo de dados menor do que os dados solicitados. O membro TransferLength na estrutura FSCTL_OFFLOAD_READ_OUTPUT é usado para indicar esse valor, que é uma contagem de bytes desde o início do intervalo do arquivo a ser lido. Para gravação de descarregamento, um truncamento indica que menos dados foram gravados do que o desejado. O membro LengthWritten na estrutura FSCTL_OFFLOAD_WRITE_OUTPUT indica esse valor, que é uma contagem de bytes desde o início do intervalo do arquivo a ser gravado. Erros no processamento de comandos ou limitações na pilha para intervalos grandes resultam em truncamento.

Há dois cenários em que o NTFS trunca o intervalo a ser descarregado lido ou gravado:

1. O intervalo de cópia será truncado para VDL (Comprimento de Dados Válido) se a VDL estiver antes do EOF (Fim do Arquivo). Essa ação pressupõe que a VDL esteja alinhada a um limite de setor lógico, caso contrário, consulte o cenário.

   

   Durante uma operação FSCTL_OFFLOAD_READ, o sinalizador OFFLOAD_READ_FLAG_ALL_ZERO_BEYOND_CURRENT_RANGE é definido na estrutura FSCTL_OFFLOAD_READ_OUTPUT, indicando que o restante do arquivo contém zeros e o membro TransferLength é truncado para VDL.

2. Semelhante ao Cenário 1, mas quando a VDL não está alinhada a um limite de setor lógico, o NTFS trunca o intervalo desejado para o próximo limite de setor lógico.

   

Limitações

• As operações de descarregamento são suportadas apenas em volumes NTFS.
• As operações de descarregamento são suportadas por meio de servidores de arquivos remotos se as seguintes condições forem verdadeiras:
  • O compartilhamento remoto é um volume NTFS.
  • O servidor está executando o Windows Server 2012 ou versões posteriores (supondo que a pilha remota também dê suporte a operações de descarregamento).
• O NTFS não dá suporte a FSCTLs de descarregamento executados em arquivos criptografados com criptografia Bitlocker ou NTFS (EFS), arquivos com eliminação de duplicação, arquivos compactados, arquivos residentes, arquivos esparsos ou arquivos que participam de transações TxF.
• O NTFS não dá suporte a FSCTLs de descarregamento executados em arquivos em um instantâneo volsnap.
• O NTFS falhará no FSCTL de descarregamento se uma das condições a seguir for verdadeira. Essa abordagem segue a mesma semântica que a E/S não armazenada em cache.
  • O intervalo de arquivos desejado não está alinhado ao tamanho do setor lógico no dispositivo de origem.
  • O intervalo de arquivos desejado não está alinhado ao tamanho do setor lógico no dispositivo de destino.
• O arquivo de destino deve ser pré-alocado (SetEndOfFile e não SetAllocation) antes de FSCTL_OFFLOAD_WRITE.
• Quando o NTFS processa leituras e gravações de descarregamento, ele primeiro chama CcCoherencyFlushAndPurgeCache para confirmar todos os dados modificados no cache do sistema. Essa ação é a mesma semântica que a E/S não armazenada em cache.