Actualización de compatibilidad de disco de formato avanzado (4K)

  • Artículo

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

Descripción

Este artículo es una versión actualizada del artículo titulado Actualización de compatibilidad de disco de 512 bytes (512e) que se publicó para Windows 7 SP1 y Windows Server 2008 R2 SP1. Esta actualización contiene mucha información nueva, algunas de las cuales solo son aplicables a Windows 8 y Windows Server 2012.

Las densidades areales aumentan cada año y, con la reciente llegada de discos de 3 TB, los mecanismos de corrección de errores utilizados para tratar con la disminución de la relación de señal a ruido (SNR) se están convirtiendo en ineficaz del espacio; es decir, se requiere una mayor cantidad de sobrecarga para asegurarse de que los medios se pueden usar. Una de las soluciones del sector de almacenamiento para mejorar este mecanismo de corrección de errores es introducir un formato de medio físico diferente que incluya un tamaño de sector físico mayor. Este nuevo formato de medios físicos se denomina Formato avanzado. Por lo tanto, ya no es seguro realizar ninguna suposición con respecto al tamaño del sector de los dispositivos de almacenamiento modernos, y los desarrolladores tendrán que estudiar las suposiciones subyacentes a su código para determinar si hay un impacto.

En este tema se presenta el efecto de los dispositivos de almacenamiento de formato avanzado en el software, se describe lo que pueden hacer las aplicaciones para ayudar a admitir este tipo de medios y se describe la infraestructura que Microsoft introdujo con Windows Vista, Windows 7 y Windows 8 para permitir que los desarrolladores admitan estos tipos de dispositivos. Aunque el material presentado en este tema proporciona directrices para mejorar la compatibilidad con discos de formato avanzado, la información se aplica generalmente a todos los sistemas con discos de formato avanzado que ejecutan Windows Vista, Windows 7 y Windows 8.

Resumen de las nuevas características relacionadas con el sector grande

En la lista siguiente se resumen las nuevas características que se entregan como parte de Windows 8 y Windows Server 2012 para ayudar a mejorar la experiencia de los clientes y desarrolladores con discos de sector grandes. Una descripción más detallada de cada elemento sigue.

  • Se basa en la compatibilidad de Windows 7 SP1 con discos 4K con emulación (512e) y proporciona compatibilidad completa con la bandeja de entrada para discos con tamaño de sector 4K sin emulación (4K Nativo). Algunas aplicaciones y escenarios admitidos incluyen:
    • Capacidad de instalar Windows en y arrancar desde un disco de sector 4K sin emulación (disco nativo de 4K)
    • VHD y nuevo formato de archivo VHDX
    • Compatibilidad completa con HyperV
    • Copia de seguridad de Windows
    • Compatibilidad completa con el sistema de archivos NT (NTFS)
    • Compatibilidad total con nuevos Espacios de almacenamiento y grupos (SSP)
    • Compatibilidad total con Windows Defender
  • Proporciona una nueva API para consultar el tamaño del sector físico (FileFsSectorSizeInformation):
    • Disponible para volúmenes de red
    • Se puede emitir a cualquier identificador de archivo.
    • Disponible para aplicaciones sin privilegios
    • Modelo de uso más descriptivo
  • Incluye la utilidad de línea de comandos fsutil mejorada para consultar el tamaño del sector lógico y físico del volumen con información de alineación (la versión básica de la utilidad sin información de alineación está disponible para Windows 7 con Microsoft KB 982018 y Windows Server 2008 R2 con Microsoft KB 982018)

Introducción a los discos de formato avanzado (4K)

Uno de los problemas de introducir este cambio en el formato multimedia es la posibilidad de introducir problemas de compatibilidad con el software y el hardware existentes. Como solución de compatibilidad temporal, el sector de almacenamiento introduce inicialmente discos que emulan un disco del sector normal de 512 bytes, pero hacen que la información disponible sobre el tamaño del sector verdadero a través de los comandos ATA y SCSI estándar. Como resultado de esta emulación, hay, en esencia, dos tamaños de sector:

Sector lógico: Unidad que se usa para el direccionamiento de bloques lógicos para los medios. También podemos considerarlo como la unidad de escritura más pequeña que el almacenamiento puede aceptar. Esta es la emulación.
Sector físico: La unidad para la que las operaciones de lectura y escritura en el dispositivo se completan en una sola operación. Esta es la unidad de escritura atómica.
La mayoría de las API de Windows actuales, como IOCTL_DISK_GET_DRIVE_GEOMETRY, devolverán el tamaño del sector lógico, pero el tamaño del sector físico se puede recuperar a través del código de control IOCTL_STORAGE_QUERY_PROPERTY , con la información pertinente contenida en el campo BytesPerPhysicalSector de la estructura STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR . Esto se describe con más detalle más adelante en el artículo.

Tipos iniciales de medios de sector grandes

El sector de almacenamiento está aumentando rápidamente los esfuerzos para realizar la transición a este nuevo tipo de almacenamiento de formato avanzado para los medios con un tamaño de sector físico de 4 KB. Se publicarán dos tipos de medios en el mercado:

4 KB nativo: Este medio no tiene ninguna capa de emulación y expone directamente 4 KB como su tamaño de sector lógico y físico. El problema general con este nuevo tipo de medio es que la mayoría de las aplicaciones y sistemas operativos no consultan y alinean las E/S con el tamaño del sector físico, lo que puede dar lugar a errores inesperados de E/S.
Emulación de 512 bytes (512e): Este medio tiene una capa de emulación como se describe en la sección anterior y expone 512 bytes como su tamaño de sector lógico (similar a un disco normal en la actualidad), pero hace que su información de tamaño de sector físico (4 KB) esté disponible. El problema general con este nuevo tipo de medios es que la mayoría de los sistemas operativos y de aplicaciones no entienden la existencia del tamaño del sector físico, lo que puede dar lugar a una serie de problemas, como se describe a continuación.
Compatibilidad general de Windows con medios de sector grande

En esta tabla se documenta la directiva oficial de soporte técnico de Microsoft para varios medios y sus tamaños de sector notificados resultantes. Consulte este artículo de KB para obtener más información.

Nombres comunes Tamaño del sector lógico notificado Tamaño del sector físico notificado Versión de Windows con soporte técnico
512 bytes nativo, 512n 512 bytes 512 bytes Todas las versiones de Windows
Formato avanzado, 512e, AF, emulación de 512 bytes 512 bytes 4 KB Windows Vista con MS KB 2553708
Windows Server 2008* w/ MS KB 2553708
Windows 7 w/ MS KB 982018
Windows Server 2008 R2* w/ MS KB 982018
Todas las versiones de Windows de Windows 7 SP1 y versiones posteriores.
Todas las versiones de Server de Server 2008 R2 SP1 y versiones posteriores.

*Excepto Hyper-V. Consulte la sección "Requisitos de compatibilidad de aplicaciones para unidades de gran sector ".
Formato avanzado, AF, 4K nativo, 4Kn 4 KB 4 KB Todas las versiones de Windows de Windows 8 y versiones posteriores
Todas las versiones de servidor de Windows Server 2012 y versiones posteriores
Otros No 4 KB o 512 bytes No 4 KB o 512 bytes No compatible

Nota

Aunque no se ha subrayado en la tabla anterior, Windows XP, Windows Server 2003 y Windows Server 2003 R2 no admiten medios 512e o 4Kn. Aunque el sistema puede arrancar y ser capaz de funcionar mínimamente, puede haber escenarios desconocidos de problemas de funcionalidad, pérdida de datos o rendimiento sub óptimo. Por lo tanto, Microsoft advierte encarecidamente contra el uso de medios de 512e con Windows XP u otros productos basados en el código base de Windows XP (como Windows Home Server 1.0, Windows Server 2003, Windows Server 2003 R2, Windows XP 64 bits Edition, Windows XP Embedded, Windows Small Business Server 2003 y Windows Small Business Server 2003 R2).

Funcionamiento de la emulación: read-modify-write (RMW)

Un medio de almacenamiento tiene una determinada unidad dentro de la cual se puede modificar el medio físico. Es decir, los medios solo se pueden escribir o reescribir en unidades del tamaño del sector físico. Por lo tanto, las escrituras que no se realizan en este nivel de unidad requerirían pasos adicionales, que se recorrerán en el ejemplo siguiente.

En este escenario, una aplicación debe actualizar el contenido de un registro de Datastor ubicado en un sector lógico de 512 bytes. En este diagrama se muestran los pasos necesarios para que el dispositivo de almacenamiento complete la escritura:

pasos para que un dispositivo de almacenamiento complete una escritura

Como se ha mostrado anteriormente, este proceso implica algún trabajo por parte del dispositivo de almacenamiento que puede dar lugar a una pérdida de rendimiento. Para evitar este trabajo adicional, las aplicaciones deben actualizarse a:

  • Consulta del tamaño del sector físico
  • Asegúrese de que las escrituras están alineadas con el tamaño del sector físico notificado.

Aunque esto puede parecer inicialmente solo un problema de rendimiento, puede haber un problema más grave. Vamos a analizar esto en la sección siguiente.

Resistencia: el costo oculto de lectura-modificación-escritura

La resistencia habla de la capacidad de una aplicación para recuperar el estado entre sesiones. Hemos visto lo necesario para que un dispositivo de almacenamiento de 512e realice un sector de 512 bytes para escribir el ciclo de lectura y modificación y escritura. Echemos un vistazo a lo que sucedería si se interrumpiera el proceso de sobrescribir el sector físico anterior en los medios. ¿Cuáles serían las consecuencias?

  • Dado que la mayoría de las unidades de disco duro se actualizan en su lugar, el sector físico es decir, la parte de los medios donde se encontraba el sector físico podría haberse dañado con información incompleta debido a una sobrescritura parcial. Por otra parte, puede considerarlo como potencialmente haber perdido todos los 8 sectores lógicos (que el sector físico contiene lógicamente).
  • Aunque la mayoría de las aplicaciones con un almacén de datos están diseñadas con la capacidad de recuperarse de errores multimedia, la pérdida de ocho sectores o de otra manera, la pérdida de ocho registros de confirmación puede hacer posible que el almacén de datos se recupere correctamente. Es posible que un administrador tenga que restaurar manualmente la base de datos a partir de una copia de seguridad o incluso tener que realizar una recompilación larga.
  • Un impacto más importante es que el acto de otra aplicación que provoca un ciclo de lectura modificar y escritura puede hacer que los datos se pierdan incluso si la aplicación no se está ejecutando. Esto es simplemente porque los datos y los demás datos de la aplicación podrían ubicarse en el mismo sector físico.

Teniendo esto en cuenta, es importante que el software de la aplicación vuelva a evaluar las suposiciones tomadas en el código y tenga en cuenta la distinción de tamaño del sector físico lógico, junto con algunos escenarios interesantes de clientes que se describen más adelante en este artículo.

Hacer lo correcto (evitando read-modify-write)

Aunque algunos proveedores de almacenamiento pueden estar introduciendo algunos niveles de mitigación dentro de determinados dispositivos de almacenamiento de 512e para intentar facilitar los problemas de rendimiento y resistencia del ciclo de lectura y modificación y escritura, solo hay tanta mitigación puede controlar en términos de carga de trabajo. Por lo tanto, las aplicaciones no deben depender de esta mitigación como una solución a largo plazo. Además, no hay ninguna garantía de que todas las clases de discos tengan esta mitigación en vigor, ni hay ninguna garantía de que la mitigación esté bien diseñada.

La solución a esto no es la mitigación en unidad, pero para diseñar aplicaciones para hacer el conjunto correcto de cosas para ayudar a admitir este tipo de medios. En esta sección se describen escenarios comunes en los que las aplicaciones pueden tener problemas con discos de sectores grandes y sugieren una vía de investigación para intentar resolver cada problema.

Problema 1: la partición no está alineada con un límite de sector físico

Cuando el administrador o el usuario particiona el disco, es posible que la primera partición no se haya creado en un límite alineado. Esto puede hacer que todas las escrituras posteriores se vuelvan no relacionadas con los límites del sector físico. A partir de Windows Vista SP1 y Windows Server 2008, la primera partición se coloca en los primeros 1024 KB del disco (para los discos de 4 GB o más, de lo contrario, la alineación es de 64 KB) que está alineada con un límite de sector físico de 4 KB. Sin embargo, dada la creación de particiones predeterminada en Windows XP, una utilidad de creación de particiones de terceros o un uso incorrecto de las API de Windows, es posible que las particiones creadas no estén alineadas con un límite de sector físico. Los desarrolladores deberán asegurarse de que se usan las API correctas para ayudar a garantizar la alineación. Las API recomendadas para ayudar a garantizar la alineación de particiones se describen a continuación.

Las API IVdsPack::CreateVolume e IVdsPack2::CreateVolume2 no usan el parámetro de alineación especificado cuando se crea un nuevo volumen, sino que usan el valor de alineación predeterminado para el sistema operativo (Pre-Windows Vista SP1 usará 63 bytes y, después, Windows Vista SP1 usará los valores predeterminados indicados anteriormente). En su lugar, use las API IVdsCreatePartitionEx::CreatePartitionEx o IVdsAdvancedDisk::CreatePartition que usan el parámetro de alineación especificado para las aplicaciones que necesitan crear particiones.

La mejor manera de ayudar a garantizar que la alineación es correcta es hacerlo correctamente al crear inicialmente la partición. De lo contrario, la aplicación tendrá que tener en cuenta la alineación al realizar escrituras o en la inicialización, lo que puede ser un proceso muy complejo.

Problema 2: escrituras sin búfer no alineadas con el tamaño del sector físico

El problema más sencillo es que las escrituras sin búfer no están alineadas con el tamaño del sector físico notificado del medio de almacenamiento. Las escrituras almacenadas en búfer, por otro lado, se alinean con el tamaño de página de 4 KB que coincidentemente es el tamaño del sector físico de la primera generación de medios de sector grandes. Sin embargo, la mayoría de las aplicaciones con un almacén de datos realizan escrituras sin búfer y, por tanto, tendrán que asegurarse de que estas escrituras se realizan en unidades del tamaño del sector físico.

Algunos ejemplos de escenarios en los que la E/S de la aplicación resultante no está desligada:

Los registros de confirmación se rellenan en sectores de 512 bytes: Las aplicaciones con un almacén de datos suelen tener alguna forma de registro de confirmación que mantiene información sobre los cambios de metadatos o mantiene la estructura del almacén de datos. Para garantizar que la pérdida de un sector no afecte a varios registros, este registro de confirmación normalmente se rellena en un tamaño de sector. Con un disco con un tamaño de sector físico mayor, la aplicación tendrá que consultar el tamaño del sector físico, tal como se muestra en la sección anterior, y asegurarse de que cada registro de confirmación se rellena con ese tamaño. Con un disco 4K, esto garantiza que no se produzcan errores en las E/S. Con un disco de 512e, no solo evita el ciclo Lectura-Modificación-escritura, ayuda a garantizar que si se perdiera un sector físico, solo se perdería un registro de confirmación.
Los archivos de registro se escriben en fragmentos no asignados: La E/S sin búfer se usa normalmente al actualizar o anexar a un archivo de registro. Las aplicaciones pueden cambiar a E/S almacenadas en búfer o almacenar internamente en búfer las actualizaciones de registro en unidades del tamaño del sector físico para evitar E/S con errores o desencadenar una lectura-modificación-escritura.
Para ayudar a determinar si la aplicación emite E/S sin búfer, asegúrese de incluir la marca FILE_FLAG_NO_BUFFERING en el parámetro dwFlagsAndAttributes cuando llame a la función CreateFile.

Además, si actualmente está alineando las escrituras con el tamaño del sector, es más probable que este tamaño del sector sea solo el tamaño del sector lógico, ya que la mayoría de las API existentes que consultan el tamaño del sector de los medios simplemente consultan la unidad de direccionamiento, es decir, el tamaño del sector lógico. El tamaño del sector de interés aquí es el tamaño del sector físico, que es la unidad real de atomicidad. Algunos ejemplos de API que recuperan el tamaño del sector lógico son:

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

Aquí se muestra cómo puede consultar el tamaño del sector físico:

Método preferido para Windows 8

Con Windows 8, Microsoft ha introducido una nueva API que permite a los desarrolladores integrar fácilmente la compatibilidad con 4K en sus aplicaciones. Esta nueva API admite un número aún mayor de escenarios que el método heredado para Windows Vista y Windows 7 que se describen a continuación. Esta API habilita estos escenarios de llamada:

  • Llamada desde una aplicación sin privilegios
  • Llamar a cualquier identificador de archivo válido
  • Llamar a un identificador de archivo en un volumen remoto a través de SMB2
  • Modelo de programación simplificado

La API tiene la forma de una nueva clase de información, FileFsSectorSizeInformation, con la estructura asociada FILE_FS_SECTOR_SIZE_INFORMATION, definida de la siguiente manera:

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 heredado para Windows 7 y Windows Vista

Windows Vista y Windows Server 2008 introdujeron API para consultar el tamaño del sector físico del dispositivo de almacenamiento conectado para controladores de almacenamiento basados en AHCI. Con Windows 7 y Windows Server 2008 R2, a partir de SP1 (o Microsoft Knowledge Base 982018), esta compatibilidad se amplía a los controladores de almacenamiento basados en Storport. Microsoft ha proporcionado un ejemplo de código en MSDN que detalla cómo una aplicación puede consultar el tamaño del sector físico del volumen.

Aunque el ejemplo de código anterior le permite obtener el tamaño del sector físico del volumen, debe realizar alguna comprobación básica de la integridad del tamaño del sector físico notificado antes de usarlo, ya que se ha observado que algunos controladores pueden no devolver datos con formato correcto:

  • Asegúrese de que el tamaño del sector físico notificado es >= el tamaño del sector lógico notificado; si no es así, la aplicación debe usar un tamaño de sector físico igual al tamaño del sector lógico notificado.
  • Asegúrese de que el tamaño del sector físico notificado es una potencia de dos; Si no es así, la aplicación debe usar un tamaño de sector físico igual al tamaño del sector lógico notificado.
  • Si el tamaño del sector físico es un valor de potencia de dos entre 512 bytes y 4 KB, debe considerar el uso de un tamaño de sector físico redondeado hacia abajo hasta el tamaño del sector lógico notificado.
  • Si el tamaño del sector físico es un valor de potencia de dos mayores que 4 KB, debe evaluar la capacidad de la aplicación para controlar este escenario antes de usar ese valor; De lo contrario, debe considerar la posibilidad de usar un tamaño de sector físico redondeado a 4 KB.

El uso de este IOCTL para obtener el tamaño del sector físico tiene varias limitaciones. Este:

  • Requiere privilegios elevados; Si la aplicación no se ejecuta con privilegios, es posible que deba escribir una aplicación de servicio de Windows como se indicó anteriormente.
  • No admite volúmenes SMB; También es posible que tenga que escribir una aplicación de servicio de Windows para admitir consultas de tamaño de sector físico en estos volúmenes.
  • No se puede emitir a ningún identificador de archivo (el IOCTL debe emitirse a un identificador de volumen).

Problema 3: formatos de archivo que se basan en sectores de 512 bytes

Algunas aplicaciones con formatos de archivo estándar (como VHD 1.0) pueden tener estos archivos codificados de forma rígida para suponer un tamaño de sector de 512 bytes. Por lo tanto, las actualizaciones y las escrituras en este archivo darían lugar a un ciclo de lectura y modificación y escritura en el dispositivo, lo que podría dar lugar a problemas de rendimiento y resistencia para los clientes. Sin embargo, hay maneras de que una aplicación proporcione compatibilidad con el funcionamiento en este tipo de medios, por ejemplo:

  • Use el almacenamiento en búfer para asegurarse de que las escrituras se realizan en unidades del tamaño del sector físico.
  • Implemente una lectura y escritura interna que pueda ayudar a garantizar que las actualizaciones se realicen en unidades del tamaño del sector físico notificado.
  • Si es posible, el relleno registra en un sector físico, de tal manera que el relleno se interpretaría como espacio vacío.
  • Considere la posibilidad de rediseñar una versión de la estructura de datos de la aplicación con compatibilidad con sectores más grandes

Problema 4: el tamaño del sector físico notificado puede cambiar entre sesiones

Hay muchos escenarios en los que el tamaño del sector físico notificado del almacenamiento subyacente que hospeda datastor puede cambiar. La más común es cuando se migra Datastor a otro volumen, o incluso a través de la red. Un cambio en el tamaño del sector físico notificado puede ser un evento inesperado para muchas aplicaciones y, posiblemente, puede dar lugar a que algunas aplicaciones no se vuelvan a inicializar.

Este no es el escenario más fácil de admitir y se menciona aquí como un aviso. Debe tener en cuenta los requisitos de movilidad de los clientes y ajustar su soporte técnico en consecuencia para ayudar a garantizar que los clientes no se vean afectados negativamente mediante medios nativos de 4K o 512e.

Cómo un usuario puede recuperar el tamaño del sector lógico y físico de un volumen

Integrada con Windows es una utilidad para mostrar la información de tamaño del sector de un volumen. Las versiones de Windows con fsutil compatibles son:

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

Para obtener la información de tamaño del sector, llame a la utilidad de la siguiente manera desde un símbolo del sistema con privilegios elevados:

fsutil fsinfo ntfsinfo <drive letter>

Un disco de sector 4K con emulación de 512 bytes tiene el campo Bytes por sector establecido en 512 y el campo Bytes por sector físico establecido en 4096 de la siguiente manera:

bytes por sector y por sector físico de un disco de 4k con emulación de 512 bytes

Un disco nativo de 4K tiene los campos Bytes por sector y Bytes por sector físico establecidos en 4096 de la siguiente manera:

bytes por sector y por sector físico de un disco nativo de 4 000

Nota

Si el campo Byte por sector físico muestra No compatible, el controlador de almacenamiento no admite IOCTL_STORAGE_QUERY_PROPERTY o se produjo un error al recuperar la información.

Recursos