Atualização de compatibilidade de disco de formato avançado (4K)

Plataformas

Clientes Windows XP, Windows Vista, Windows 7, Windows 7 SP1, Windows 8
Servidores Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016

Descrição

Este artigo é uma versão atualizada do artigo intitulado Atualização de compatibilidade de disco de emulação de 512 bytes (512e), que foi lançada para Windows 7 SP1 e Windows Server 2008 R2 SP1. Esta atualização contém muitas informações novas, algumas das quais são aplicáveis apenas ao Windows 8 e ao Windows Server 2012.

As densidades de área estão aumentando anualmente e, com o recente advento dos discos de 3 TB, os mecanismos de correção de erros usados para lidar com a diminuição da relação sinal-ruído (SNR) estão se tornando ineficientes em termos de espaço; ou seja, uma quantidade maior de sobrecarga é necessária para garantir que a mídia seja utilizável. Uma das soluções do setor de armazenamento para melhorar esse mecanismo de correção de erros é introduzir um formato de mídia física diferente que inclua um tamanho de setor físico maior. Esse novo formato de mídia física é chamado de Formato Avançado. Portanto, não é mais seguro fazer suposições sobre o tamanho do setor de dispositivos de armazenamento modernos, e os desenvolvedores precisarão estudar as suposições subjacentes ao seu código para determinar se há algum impacto.

Este tópico apresenta o efeito dos dispositivos de armazenamento de Formato Avançado no software, aborda o que os aplicativos podem fazer para ajudar a oferecer suporte a esse tipo de mídia e aborda a infraestrutura que a Microsoft introduziu com o Windows Vista, Windows 7 e Windows 8 para permitir que os desenvolvedores ofereçam suporte a esses tipos de dispositivos. Embora o material apresentado neste tópico forneça diretrizes para melhorar a compatibilidade com discos de Formato Avançado, as informações geralmente se aplicam a todos os sistemas com discos de Formato Avançado que executam Windows Vista, Windows 7 e Windows 8.

Resumo dos novos recursos relacionados ao setor grande

A lista abaixo resume os novos recursos fornecidos como parte do Windows 8 e do Windows Server 2012 para ajudar a melhorar a experiência do cliente e do desenvolvedor com discos de setor grande. Segue uma descrição mais detalhada de cada item.

• Baseia-se no suporte do Windows 7 SP1 para discos de 4K com emulação (512e) e fornece suporte completo à caixa de entrada para discos com tamanho de setor de 4K sem emulação (4K nativo). Alguns aplicativos e cenários com suporte incluem:
  • Capacidade de instalar o Windows e inicializar a partir de um disco de setor 4K sem emulação (disco nativo de 4K)
  • VHD e novo formato de arquivo VHDX
  • Suporte completo ao HyperV
  • Backup do Windows
  • Suporte completo no sistema de arquivos NT (NTFS)
  • Suporte completo com novos SSP (Espaços de Armazenamento e pools)
  • Suporte completo com o Windows Defender
• Fornece uma nova API para consultar o tamanho do setor físico (FileFsSectorSizeInformation):
  • Disponível para volumes de rede
  • Pode ser emitido para qualquer identificador de arquivo
  • Disponível para aplicativos sem privilégios
  • Modelo de uso mais amigável
• Inclui o utilitário de linha de comando fsutil aprimorado para consultar o tamanho do setor lógico e físico do volume com informações de alinhamento (a versão básica do utilitário sem informações de alinhamento está disponível para Windows 7 com Microsoft KB 982018 e Windows Server 2008 R2 com Microsoft KB 982018)

Introdução aos discos de formato avançado (4K)

Um dos problemas de introduzir essa mudança no formato de mídia é o potencial de introduzir problemas de compatibilidade com software e hardware existentes. Como uma solução de compatibilidade temporária, o setor de armazenamento está introduzindo inicialmente discos que emulam um disco de setor regular de 512 bytes, mas disponibilizam informações sobre o tamanho real do setor por meio de comandos ATA e SCSI padrão. Como resultado dessa emulação, há, essencialmente, dois tamanhos de setor:

Setor lógico: a unidade usada para endereçamento de bloco lógico para a mídia. Também podemos pensar nisso como a menor unidade de gravação que o armazenamento pode aceitar. Esta é a emulação.
Setor físico: a unidade para a qual as operações de leitura e gravação no dispositivo são concluídas em uma única operação. Esta é a unidade de gravação atômica.
A maioria das APIs atuais do Windows, como IOCTL_DISK_GET_DRIVE_GEOMETRY, retornará o tamanho do setor lógico, mas o tamanho do setor físico pode ser recuperado por meio do código de controle IOCTL_STORAGE_QUERY_PROPERTY, com as informações relevantes contidas no campo BytesPerPhysicalSector na estrutura STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR. Isso será abordado em mais detalhes posteriormente no artigo.

Tipos iniciais de mídia de setor grande

O setor de armazenamento está intensificando rapidamente os esforços para fazer a transição para esse novo tipo de armazenamento de formato avançado para mídia com um tamanho de setor físico de 4 KB. Dois tipos de mídia serão lançados no mercado:

4 KB nativo: essa mídia não tem camada de emulação e expõe diretamente 4 KB como seu tamanho de setor lógico e físico. O problema geral com esse novo tipo de mídia é que a maioria dos aplicativos e sistemas operacionais não consulta e alinha as E/S ao tamanho do setor físico, o que pode resultar em E/S com falha inesperada.
Emulação de 512 bytes (512e): essa mídia tem uma camada de emulação, conforme abordado na seção anterior, e expõe 512 bytes como seu tamanho de setor lógico (semelhante a um disco normal hoje), mas disponibiliza suas informações de tamanho de setor físico (4 KB). O problema geral com esse novo tipo de mídia é que a maioria dos aplicativos e sistemas operacionais não entende a existência do tamanho do setor físico, o que pode resultar em vários problemas, conforme abordado a seguir.
Suporte geral do Windows para mídia de setor grande

Esta tabela documenta a política oficial de suporte da Microsoft para diversas mídias e seus tamanhos de setor relatados. Consulte este artigo da base de dados para obter detalhes.

Como funciona a emulação: leitura-modificação-gravação (RMW)

Um meio de armazenamento tem uma determinada unidade dentro da qual o meio físico pode ser modificado. Ou seja, a mídia só pode ser gravada ou regravada em unidades do tamanho do setor físico. Portanto, as gravações que não são executadas nesse nível de unidade exigiriam etapas adicionais, que abordaremos no exemplo a seguir.

Nesse cenário, um aplicativo precisa atualizar o conteúdo de um registro do Datastor localizado em um setor lógico de 512 bytes. Este diagrama ilustra as etapas necessárias para que o dispositivo de armazenamento conclua a gravação:

Conforme ilustrado acima, esse processo envolve algum trabalho do dispositivo de armazenamento que pode resultar em perda de desempenho. Para evitar esse trabalho adicional, os aplicativos devem ser atualizados para:

• Consulta o tamanho do setor físico
• Certifique-se de que as gravações estejam alinhadas ao tamanho do setor físico relatado

Embora isso possa inicialmente parecer apenas um problema de desempenho, pode haver um problema mais sério. Vamos falar sobre isso na próxima seção.

Resiliência: o custo oculto de leitura-modificação-gravação

A resiliência fala da capacidade de um aplicativo de recuperar o estado entre as sessões. Vimos o que é necessário para um dispositivo de armazenamento 512e executar um ciclo de leitura-modificação-gravação de um setor de 512 bytes. Vamos ver o que aconteceria se o processo de substituição do setor físico anterior na mídia fosse interrompido. Quais seriam as consequências?

• Como a maioria das unidades de disco rígido são atualizadas no local, o setor físico, ou seja, a parte da mídia onde o setor físico estava localizado, pode ter sido corrompido com informações incompletas devido a uma substituição parcial. Em outras palavras, você pode pensar nisso como se tivesse potencialmente perdido os 8 setores lógicos (que o setor físico contém logicamente).
• Embora a maioria dos aplicativos com um armazenamento de dados seja projetada com a capacidade de recuperação de erros de mídia, a perda de oito setores ou, em outras palavras, a perda de oito registros de confirmação pode potencialmente impossibilitar a recuperação adequada do armazenamento de dados. Um administrador pode precisar restaurar manualmente o banco de dados a partir de um backup ou até mesmo executar uma recompilação demorada.
• Outro impacto importante é que o ato de outro aplicativo causar um ciclo de leitura-modificação-gravação pode potencialmente fazer com que seus dados sejam perdidos, mesmo que seu aplicativo não esteja em execução! Isso ocorre simplesmente porque seus dados e os dados de outros aplicativos podem estar localizados no mesmo setor físico.

Pensando nisso, é importante que o software do aplicativo reavalie quaisquer suposições feitas no código e esteja ciente da distinção de tamanho do setor lógico e físico, juntamente com alguns cenários interessantes do cliente abordados mais adiante neste artigo.

Fazer a coisa certa (evitar ler-modificar-gravar)

Embora alguns fornecedores de armazenamento possam estar introduzindo alguns níveis de mitigação em certos dispositivos de armazenamento 512e para tentar aliviar os problemas de desempenho e resiliência do ciclo de leitura-modificação-gravação, há um limite para o que qualquer mitigação pode lidar em termos de carga de trabalho. Dessa forma, os aplicativos não devem contar com essa mitigação como uma solução de longo prazo. Além disso, não há garantia de que todas as classes de discos terão essa mitigação em vigor, nem há garantia de que a mitigação seja bem projetada.

A solução para isso não é a mitigação de problemas na unidade, mas criar aplicativos que façam o conjunto certo de coisas para ajudar a oferecer suporte a esse tipo de mídia. Esta seção aborda cenários comuns em que aplicativos podem ter problemas com discos de setores grandes e sugere um caminho de investigação para tentar resolver cada problema.

Problema 1: a partição não está alinhada a um limite de setor físico

Quando o administrador/usuário particiona o disco, a primeira partição pode não ter sido criada em um limite alinhado. Isso pode fazer com que todas as gravações subsequentes fiquem desalinhadas aos limites do setor físico. Desde o Windows Vista SP1 e Windows Server 2008, a primeira partição é colocada nos primeiros 1024 KB do disco (para discos de 4 GB ou mais, caso contrário, o alinhamento será de 64 KB) que está alinhado a um limite de setor físico de 4 KB. Entretanto, devido ao particionamento padrão no Windows XP, um utilitário de particionamento de terceiros ou uso incorreto de APIs do Windows, as partições criadas podem não estar alinhadas a um limite de setor físico. Os desenvolvedores precisarão garantir que as APIs corretas sejam usadas para ajudar a garantir o alinhamento. As APIs recomendadas para ajudar a garantir o alinhamento da partição são descritas a seguir.

As APIs IVdsPack::CreateVolume e IVdsPack2::CreateVolume2 não usam o parâmetro de alinhamento especificado quando um novo volume é criado, mas usam o padrão de valor de alinhamento para o sistema operacional (o Windows Vista SP1 anterior usará 63 bytes e o Windows Vista SP1 usará os padrões indicados acima). Em vez disso, use as APIs IVdsCreatePartitionEx::CreatePartitionEx ou IVdsAdvancedDisk::CreatePartition que usam o parâmetro de alinhamento especificado para os aplicativos que precisam criar partições.

A melhor forma de ajudar a garantir que o alinhamento esteja correto é fazê-lo corretamente ao criar inicialmente a partição. Caso contrário, seu aplicativo precisará levar em consideração o alinhamento ao executar gravações ou na inicialização, o que poderá ser um processo muito complexo.

Problema 2: gravações sem buffer não alinhadas ao tamanho do setor físico

O problema mais simples é que as gravações sem buffer não estão alinhadas ao tamanho do setor físico relatado da mídia de armazenamento. Por outro lado, as gravações em buffer são alinhadas ao tamanho de página de 4 KB, que coincidentemente é o tamanho do setor físico da primeira geração de mídia de setor grande. No entanto, a maioria dos aplicativos com um armazenamento de dados executa gravações sem buffer e, portanto, precisará garantir que essas gravações sejam executadas em unidades do tamanho do setor físico.

Alguns exemplos de cenários em que a E/S do aplicativo resultante não está alinhada:

Os registros de confirmação são preenchidos em setores de 512 bytes: os aplicativos com um armazenamento de dados geralmente têm algum tipo de registro de confirmação que mantém informações sobre alterações de metadados ou mantém a estrutura do armazenamento de dados. Para garantir que a perda de um setor não afete vários registros, esse registro de confirmação geralmente é preenchido para um tamanho de setor. Com um disco com um tamanho de setor físico maior, o aplicativo precisará consultar o tamanho do setor físico, conforme mostrado na seção anterior, e garantir que cada registro de confirmação seja preenchido com esse tamanho. Com um disco 4K, isso garante que as E/S não falhem. Com um disco 512e, isso não apenas evita o ciclo de leitura-modificação-gravação, como também ajuda a garantir que, se um setor físico for perdido, apenas um registro de confirmação será perdido.
Os arquivos de log são gravados em partes não alinhadas: a E/S sem buffer normalmente é usada ao atualizar ou anexar a um arquivo de log. Os aplicativos podem alternar para E/S em buffer ou armazenar internamente em buffer as atualizações de log para unidades do tamanho do setor físico para evitar falhas de E/S ou acionar uma leitura-modificação-gravação.
Para ajudar a determinar se o aplicativo emite E/S sem buffer, inclua o sinalizador FILE_FLAG_NO_BUFFERING no parâmetro dwFlagsAndAttributes ao chamar a função CreateFile.

Além disso, se você estiver alinhando as gravações ao tamanho do setor, esse tamanho de setor provavelmente será apenas o tamanho do setor lógico, já que a maioria das APIs existentes que consultam o tamanho do setor da mídia consultam apenas a unidade de endereçamento, ou seja, o tamanho do setor lógico. O tamanho do setor de interesse aqui é o tamanho do setor físico, que é a unidade real de atomicidade. Alguns exemplos de APIs que recuperam o tamanho do setor lógico são:

• GetDiskFreeSpace, GetDiskFreeSpaceEx
• FileFsVolumeInformation
• IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
• IVdsDisk::GetProperties, IVdsDisk3::GetProperties2

Veja como você pode consultar o tamanho do setor físico:

Método preferencial para Windows 8

Com o Windows 8, a Microsoft introduziu uma nova API que permite aos desenvolvedores integrar facilmente o suporte a 4K em seus aplicativos. Essa nova API oferece suporte a um número ainda maior de cenários do que o método herdado para Windows Vista e Windows 7 abordado abaixo. Essa API permite os seguintes cenários de chamada:

• Chamada de um aplicativo sem privilégios
• Chamada para qualquer identificador de arquivo válido
• Chamada para um identificador de arquivo em um volume remoto por SMB2
• Modelo de programação simplificado

A API está na forma de uma nova classe de informações, FileFsSectorSizeInformation, com estrutura associada FILE_FS_SECTOR_SIZE_INFORMATION, definida da seguinte forma:

typedef struct _FILE_FS_SECTOR_SIZE_INFORMATION {  
    ULONG LogicalBytesPerSector;  
    ULONG PhysicalBytesPerSectorForAtomicity;  
    ULONG PhysicalBytesPerSectorForPerformance;  
    ULONG FileSystemEffectivePhysicalBytesPerSectorForAtomicity;  
    ULONG Flags;  
    ULONG ByteOffsetForSectorAlignment;  
    ULONG ByteOffsetForPartitionAlignment;  
} FILE_FS_SECTOR_SIZE_INFORMATION, *PFILE_FS_SECTOR_SIZE_INFORMATION;

Método herdado para Windows 7 e Windows Vista

O Windows Vista e o Windows Server 2008 introduziram APIs para consultar o tamanho do setor físico do dispositivo de armazenamento anexado para controladores de armazenamento baseados em AHCI. Com o Windows 7 e o Windows Server 2008 R2, a partir do SP1 (ou Base de Dados de Conhecimento da Microsoft 982018), esse suporte é estendido aos controladores de armazenamento baseados em Storport. Para obter um exemplo de código que mostra como um aplicativo pode consultar o tamanho do setor físico do volume, consulte estrutura STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR.

Embora o exemplo de código acima permite obter o tamanho do setor físico do volume, você deverá fazer algumas verificações básicas de integridade do tamanho do setor físico relatado antes de usá-lo, pois foi observado que alguns drivers podem não retornar dados formatados corretamente:

• Verifique se o tamanho do setor físico relatado é >= o tamanho do setor lógico relatado. Caso não seja, seu aplicativo deverá usar um tamanho de setor físico igual ao tamanho do setor lógico relatado
• Certifique-se de que o tamanho do setor físico relatado seja uma potência de dois. Caso contrário, seu aplicativo deverá usar um tamanho de setor físico igual ao tamanho do setor lógico relatado.
• Se o tamanho do setor físico for um valor de potência de dois entre 512 bytes e 4 KB, você deverá considerar usar um tamanho de setor físico arredondado para o tamanho do setor lógico relatado
• Se o tamanho do setor físico for um valor de potência de dois maior que 4 KB, você deverá avaliar a capacidade do aplicativo de lidar com esse cenário antes de usar esse valor. Caso contrário, você deverá considerar o uso de um tamanho de setor físico arredondado para 4 KB

Usar esse IOCTL para obter o tamanho do setor físico tem várias limitações. It:

• Requer privilégio elevado. Se o aplicativo não estiver sendo executado com privilégios, talvez seja necessário escrever um aplicativo de serviço do Windows, conforme observado acima
• Não suporta volumes SMB. Talvez também seja necessário escrever um aplicativo de serviço do Windows para oferecer suporte à consulta de tamanho de setor físico nesses volumes
• Não pode ser emitido para nenhum identificador de arquivo (o IOCTL deve ser emitido para um identificador de volume)

Problema 3: formatos de arquivo que dependem de setores de 512 bytes

Alguns aplicativos com formatos de arquivo padrão (como VHD 1.0) podem ter esses arquivos codificados para assumir um tamanho de setor de 512 bytes. Assim, atualizações e gravações nesse arquivo resultariam em um ciclo de leitura-modificação-gravação no dispositivo, o que potencialmente resultará em problemas de desempenho e resiliência para seus clientes. No entanto, existem formas de um aplicativo fornecer suporte para operar nesse tipo de mídia, por exemplo:

• Use o buffer para garantir que as gravações sejam executadas em unidades do tamanho do setor físico
• Implemente uma leitura-modificação-gravação interna que possa ajudar a garantir que as atualizações sejam executadas em unidades do tamanho do setor físico relatado
• Se possível, preencha os registros em um setor físico, de forma que o preenchimento seja interpretado como espaço vazio
• Considere reformular uma versão da estrutura de dados do aplicativo com suporte para setores maiores

Problema 4: o tamanho do setor físico relatado pode mudar entre as sessões

Há muitos cenários em que o tamanho do setor físico relatado do armazenamento subjacente que hospeda o Datastor pode mudar. O mais comum deles é quando você migra o Datastor para outro volume, ou mesmo pela rede. Uma alteração no tamanho do setor físico relatado pode ser um evento inesperado para muitos aplicativos e potencialmente pode resultar na reinicialização de alguns aplicativos.

Este não é o cenário mais fácil de oferecer suporte e é mencionado aqui como um aviso. Você deve considerar os requisitos de mobilidade de seus clientes e ajustar seu suporte de acordo para ajudar a garantir que os clientes não sejam afetados negativamente pelo uso de mídia 4K nativa ou 512e.

Como um usuário pode recuperar o tamanho do setor lógico e físico de um volume

O pacote do Windows inclui um utilitário para exibir informações sobre o tamanho do setor de um volume. As versões do Windows com suporte para fsutil são:

• Windows 8
• Windows Server 2012
• Windows 7 SP1 com Microsoft KB 982018
• Windows 7 com Microsoft KB 982018
• Windows Server 2008 R2 SP1 com Microsoft KB 982018 (v3)
• Windows Server 2008 R2 com Microsoft KB 982018 (v3)
• Windows Vista com Microsoft KB 2553708
• Windows Server 2008 com Microsoft KB 2553708

Para obter as informações de tamanho do setor, chame o utilitário da seguinte forma em um prompt de comando com privilégios elevados:

fsutil fsinfo ntfsinfo <drive letter>

Um disco de setor de 4K com emulação de 512 bytes tem o campo Bytes por setor definido como 512 e o campo Bytes por setor físico definido como 4096 da seguinte forma:

Um disco nativo de 4K tem os campos Bytes por setor e Bytes por setor físico definidos como 4096 da seguinte forma:

Recursos

• Instrução de suporte geral Windows
• Microsoft KB 982018
• Hotfix para Windows 7 e Windows Server 2008 R2
• Instrução de suporte do HyperV
• Informações gerais sobre o código de controle IOCTL_STORAGE_QUERY_PROPERTY
• Código de controle IOCTL_STORAGE_QUERY_PROPERTY
• Informações gerais sobre a estrutura STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR
• Descrição da terminologia padrão usada para descrever as atualizações de software da Microsoft
• Código de exemplo WDK com detalhes sobre como extrair as informações de alinhamento de acesso ao armazenamento relatadas da estrutura STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR ao fazer uma chamada para o código de controle IOCTL_STORAGE_QUERY_PROPERTY
• Informações gerais sobre as opções de linha de comando do ImageX
• Requisitos do driver do chipset Intel para oferecer suporte a unidades de setor de 4 KB