Atualização de compatibilidade de disco do 512e (emulação de 512 bytes)

  • Artigo

Plataforma

Clientes – Windows Vista, Windows 7, Windows 7 SP1
Servidores – Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1

Impacto do recurso

Severidade - Alta
Frequência – Alta

Descrição

As densidades areais estão aumentando anualmente e, com o advento recente de discos de 3 TB, os mecanismos de correção de erro usados para lidar com a diminuição da SNR (Taxa de Sinal para Ruído) estão se tornando ineficientes no 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 código para determinar se há um impacto.

Este tópico apresenta o efeito dos dispositivos de armazenamento de Formato Avançado no software, discute o que os aplicativos podem fazer para ajudar a dar suporte a esse tipo de mídia e discute a infraestrutura 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. As seguintes versões do Windows dão suporte para consultar o tamanho do setor físico:

  • Windows 7 com o Microsoft KB 982018
  • Windows 7 SP1
  • Windows Server 2008 R2 com Microsoft KB 982018
  • Windows Server 2008 R2 SP1
  • Windows Vista com o Microsoft KB 2553708
  • Windows Server 2008 com Microsoft KB 2553708

Para obter detalhes adicionais, consulte Informações sobre a política de suporte da Microsoft para unidades de grande setor no Windows.

Para obter mais informações sobre discos de Formato Avançado, entre em contato com seu fornecedor de armazenamento.

Tamanho do setor lógico versus físico

Uma das preocupações em introduzir essa alteração no formato de mídia é a compatibilidade com o software e o hardware atualmente disponíveis no mercado. Como uma solução temporária, o setor de armazenamento inicialmente está introduzindo discos que emulam um disco regular do setor de 512 bytes, mas disponibilizam informações sobre o tamanho do setor verdadeiro por meio de comandos padrão do ATA e scsi. Como resultado dessa emulação, há 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. Essa é 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 é discutido mais detalhadamente mais adiante no artigo.

Tipos iniciais de mídia de setor grande

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

  • Nativo de 4 KB: 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. Atualmente, essa mídia não tem suporte do Windows e da maioria dos outros sistemas operacionais. No entanto, a Microsoft está conduzindo uma investigação sobre a viabilidade de dar suporte a esse tipo de mídia em uma versão futura do Windows e emitirá um artigo da Base de Dados de Conhecimento quando apropriado.
  • Emulação de 512 bytes (512e): essa mídia tem uma camada de emulação, conforme discutido 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). Isso é o que vários fornecedores de armazenamento estão introduzindo no mercado no momento. Esse problema geral com esse novo tipo de mídia é que a maioria dos sistemas operacionais e de aplicativos não entende a existência do tamanho do setor físico, o que pode resultar em uma série de problemas, como será discutido abaixo.

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

Um meio de armazenamento tem uma determinada unidade na qual o meio físico pode ser modificado. Ou seja, a mídia só pode ser escrita ou reescrita em unidades do tamanho do setor físico. Portanto, as gravações que não são executadas neste nível de unidade exigiriam etapas adicionais, que veremos 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. O diagrama a seguir ilustra as etapas necessárias para que o dispositivo de armazenamento conclua a gravação:

etapas necessárias para atualizar o registro do datastor em um setor lógico de 512 bytes

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

  • Consultar o tamanho do setor físico.
  • Verifique se as gravações estão alinhadas ao tamanho do setor físico relatado.

O impacto da resiliência de leitura-modificação-gravação

Resiliência fala da capacidade de um aplicativo recuperar o estado entre as sessões. Vimos o que é necessário para um dispositivo de armazenamento 512e executar uma gravação de setor de 512 bytes – o ciclo Read-Modify-Write. Vamos examinar 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 é atualizada no local, o setor físico – ou seja, a parte da mídia em que o setor físico estava localizado – pode ter sido corrompido com informações incompletas devido a uma substituição parcial. Dito de outra forma, você pode pensar nisso como potencialmente tendo perdido todos 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 se recuperar de erros de mídia, a perda de oito setores ou colocar outra maneira, a perda de oito registros de confirmação, pode potencialmente tornar impossível para o armazenamento de dados se recuperar normalmente. Um administrador pode precisar restaurar manualmente o banco de dados de um backup ou pode até precisar executar uma recompilação longa.

  • Um impacto mais importante é que o ato de outro aplicativo que causa um ciclo de Leitura-Modificar-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 do outro aplicativo podem estar localizados no mesmo setor físico.

Com isso em mente, é importante que o software de aplicativo reavalie quaisquer suposições feitas no código e esteja ciente da distinção de tamanho do setor lógico-físico, juntamente com alguns cenários interessantes do cliente discutidos posteriormente neste artigo.

É mais provável que esse problema ocorra se o aplicativo depender de um armazenamento de dados de estrutura de log.

Evitando leitura-modificação-gravação

Embora alguns fornecedores de armazenamento possam estar introduzindo alguns níveis de mitigação em determinados dispositivos de armazenamento 512e para tentar facilitar os problemas de desempenho e resiliência do ciclo de Leitura-Modificar-Gravação, há apenas muito que qualquer mitigação pode lidar em termos de carga de trabalho. Dessa forma, os aplicativos não devem depender dessa mitigação como uma solução de longo prazo.

A solução para isso não é a mitigação no disco, mas fazer com que os aplicativos façam o conjunto certo de coisas para evitar o ciclo de Leitura-Modificar-Gravação. Esta seção discute cenários comuns em que os aplicativos podem ter problemas com discos de grande setor e sugere um caminho de investigação para tentar resolve 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 se tornem desalinhadas para os limites do setor físico. A partir do Windows Vista SP1 e do Windows Server 2008, a primeira partição é colocada no primeiro 1024 KB do disco (para discos de 4 GB ou maiores, caso contrário, o alinhamento é de 64 KB) alinhado a um limite de setor físico de 4 KB. No entanto, dado o 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 que o alinhamento da partição seja descrito abaixo.

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

A melhor maneira de ajudar a garantir que o alinhamento esteja correto é fazer isso corretamente ao criar inicialmente a partição. Caso contrário, seu aplicativo precisará levar em conta o alinhamento ao executar gravações ou na inicialização , o que pode ser uma questão muito complexa. A partir do Windows Vista SP1, isso geralmente não é um problema; no entanto, versões mais antigas do Windows podem criar partições não assinadas que podem potencialmente levar a problemas de desempenho com alguns discos de Formato Avançado.

Problema 2: Gravações não armazenadas em buffer não alinhadas ao tamanho do setor físico

O problema básico é que as gravações não armazenadas em buffer não estão alinhadas ao tamanho do setor físico relatado da mídia de armazenamento, o que dispara um Read-Modify-Write na unidade que pode resultar em problemas de desempenho. As gravações em buffer, por outro lado, são alinhadas ao tamanho da página – 4 KB – que coincidentemente é o tamanho do setor físico da primeira geração de mídia de grande setor. 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.

Para ajudar a determinar se o aplicativo emite E/S sem buffer, marcar para ver se você inclui 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 , pois a maioria das APIs existentes que consultam o tamanho do setor da mídia realmente apenas consultam 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 verdadeira unidade 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

Como consultar o tamanho do setor físico

A Microsoft forneceu um exemplo de código no MSDN detalhando como um aplicativo pode consultar o tamanho do setor físico do volume. O exemplo de código está localizado em https://msdn.microsoft.com/library/ff800831.aspx.

Embora o exemplo de código acima permita obter o tamanho do setor físico do volume, você deve fazer alguma verificação básica de sanidade no 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. Se não estiver, seu aplicativo deverá usar um tamanho de setor físico igual ao tamanho do setor lógico relatado.
  • Verifique se o tamanho do setor físico relatado é uma potência de dois. Se não estiver, 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 o uso de um tamanho de setor físico arredondado para baixo 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 este IOCTL para obter o tamanho do setor físico tem várias limitações:

  • Requer privilégios elevados. Se o aplicativo não estiver em execução com privilégios, talvez seja necessário escrever um Aplicativo de Serviço do Windows, conforme observado acima.

  • Não dá suporte a volumes SMB. Talvez você também precise escrever um Aplicativo de Serviço do Windows para dar suporte à consulta de tamanho do setor físico nesses volumes.

  • Não é possível emitir para nenhum identificador de arquivo (o IOCTL deve ser emitido para um Identificador de Volume).

  • Com suporte apenas em versões do Windows listadas perto do início deste artigo.

Registros de confirmação são adicionados a setores de 512 bytes

Os aplicativos com um armazenamento de dados normalmente têm alguma forma 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 normalmente é acolchoado a 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 adicionado a esse tamanho. Isso não só evita o ciclo Read-Modify-Write, como ajuda a garantir que, caso um setor físico tenha sido perdido, apenas um Registro de Confirmação seja perdido.

Os arquivos de log são gravados em partes não assinadas

A E/S não armazenada em cache normalmente é usada ao atualizar ou acrescentar a um arquivo de log. Há várias maneiras de ajudar a garantir que essas atualizações estejam alinhadas corretamente:

  • Atualizações de log de buffer internamente para o tamanho do setor físico relatado da mídia operacional e gravações de log de problemas somente quando uma unidade do setor físico está cheia
  • Usar E/S em buffer

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

Alguns aplicativos com formatos de arquivo padrão (como o VHD 1.0) podem ter esses arquivos embutidos em código para assumir um tamanho de setor de 512 bytes. Assim, as atualizações e gravações nesse arquivo resultariam em um ciclo read-modify-write no dispositivo, o que potencialmente resultará em preocupações de desempenho e resiliência para seus clientes. No entanto, há maneiras de um aplicativo fornecer suporte para operar nesse tipo de mídia, por exemplo:

  • Usar o buffer para garantir que as gravações sejam executadas em unidades do tamanho do setor físico
  • Implementar um Read-Modify-Write interno que pode ajudar a garantir que as atualizações sejam executadas em unidades do tamanho do setor físico relatado
  • Se possível, o pad registra em um setor físico, de tal forma que o preenchimento seria interpretado como espaço vazio
  • Considere reprojetar uma nova versão da estrutura de dados do aplicativo com suporte para setores maiores

Problema 4: O tamanho relatado do Setor Físico 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 até mesmo para a rede. Uma alteração no tamanho do setor físico relatado pode ser um evento inesperado para muitos aplicativos e pode resultar potencialmente em alguns aplicativos, mesmo não conseguindo inicializar novamente.

Este não é o cenário mais fácil de dar 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 usando a mídia 512e.

Mídia nativa de 4 KB

A mídia de emulação de 512 bytes é feita como uma etapa de transição entre a mídia nativa de 512 bytes e a mídia nativa de 4 KB, e esperamos ver a mídia nativa de 4 KB lançada logo após o lançamento do 512e. Há várias implicações importantes com esta mídia que devem ser observadas:

  • Os tamanhos do setor lógico e físico são de 4 KB
  • Como não há nenhuma camada de emulação, as gravações não assinadas serão reprovadas pelo armazenamento
  • Nenhuma ocorrência de resiliência oculta – os aplicativos funcionam ou não funcionam

Embora a Microsoft esteja investigando atualmente o suporte para esses tipos de mídia em uma versão futura do Windows e emitirá um artigo de KB quando apropriado, os desenvolvedores de aplicativos devem considerar fornecer suporte preventivamente para esses tipos de mídia.

Fechamento

Neste artigo, discutimos os efeitos que a mídia de grande setor apresenta com muitos cenários comuns de implantação. Vimos o impacto de desempenho e resiliência de Read-Modify-Write, alguns dos cenários interessantes que essa mídia pode introduzir e o conjunto de problemas que eles podem causar potencialmente com o software, o que, em última análise, afeta o usuário final. O setor de armazenamento está fazendo a transição rápida para a mídia com tamanhos de setor maiores e, muito em breve, os clientes não poderão comprar discos com tamanhos tradicionais do setor de 512 bytes.

Este é um documento em vida e serve como um auxílio para os desenvolvedores ajudarem a entender essa transição. Você deve iniciar uma conversa com suas respectivas organizações, com clientes, profissionais de TI e seus fornecedores de hardware para falar sobre a transição de grande setor e como ela afeta os cenários que são importantes para você.