Compartir a través de

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

  • Artículo

Platforms

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 discos con emulación 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, parte de la cual solo es aplicable a Windows 8 y Windows Server 2012.

Las densidades de área aumentan cada año y, con la reciente aparición de los discos de 3 TB, los mecanismos de corrección de errores utilizados para hacer frente a la disminución de la relación señal/ruido (SNR) se están volviendo ineficaces en términos de espacio; es decir, se requiere una mayor cantidad de sobrecarga para garantizar que el soporte sea utilizable. Una de las soluciones del sector del almacenamiento para mejorar este mecanismo de corrección de errores es introducir un formato de medios físicos 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 qué aplicaciones pueden hacer 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 los discos de gran tamaño

La siguiente lista resume las nuevas funciones incluidas en Windows 8 y Windows Server 2012 para ayudar a mejorar la experiencia de los clientes y desarrolladores con discos de gran tamaño. A continuación se proporciona una descripción más detallada de cada elemento.

  • 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 compatibles incluyen:
    • Capacidad para instalar Windows y arrancarlo desde un disco de sector 4K sin emulación (disco nativo 4K).
    • Formato de archivo VHD y nuevo VHDX
    • Compatibilidad completa con HyperV
    • Copias de seguridad de Windows
    • Compatibilidad completa en el sistema de archivos NT (NTFS)
    • Compatibilidad completa con nuevos grupos y espacios de almacenamiento (SSP)
    • Compatibilidad completa 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 sencillo
  • 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 del almacenamiento presenta inicialmente discos que emulan un disco de sector normal de 512 bytes, pero hacen que la información 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 archivos multimedia. También podemos considerarlo como la unidad más pequeña de escritura que puede aceptar el almacenamiento. Esta es la emulación.
Sector físico: unidad para la que se completan las operaciones de lectura y escritura en el dispositivo 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. Esta opción se describe con más detalle más adelante en el artículo.

Tipos iniciales de medios de sector grandes

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

Nativo de 4 KB: este medio no tiene capa de emulación y expone directamente 4 KB como su tamaño de sector lógico y físico. El problema general que plantea este nuevo tipo de soporte es que la mayoría de las aplicaciones y sistemas operativos no consultan y alinean I/Os con el tamaño del sector físico, lo que puede provocar fallos inesperados en I/Os.
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 accesible la información sobre el tamaño del sector físico (4 KB). El problema general que plantea este nuevo tipo de medios es que la mayoría de los sistemas operativos y 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 la Base de conocimientos 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* con MS KB 2553708
Windows 7 con MS KB 982018
Windows Server 2008 R2* con MS KB 982018
Todas las versiones de Windows de Windows 7 SP1 y versiones posteriores.
Todas las versiones de servidor 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 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 resaltado en la tabla anterior, Windows XP, Windows Server 2003 y Windows Server 2003 R2 no admiten medios 512e o 4Kn. Aunque el sistema pueda arrancar y funcionar mínimamente, puede haber escenarios desconocidos de problemas de funcionalidad, pérdida de datos o rendimiento subóptimo. Por ello, Microsoft desaconseja encarecidamente el uso de soportes 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-bit 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 analizarán en el ejemplo siguiente.

En este escenario, una aplicación debe actualizar el contenido de un registro 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 provocar una pérdida de rendimiento. Para evitar este trabajo adicional, las aplicaciones deben actualizarse para:

  • Consultar el tamaño del sector físico
  • Garantizar que las escrituras estén alineadas con el tamaño del sector físico notificado

Aunque en un principio esto puede parecer solo un problema de rendimiento, puede haber problemas más graves. Vamos a hablar de ello en la siguiente sección.

Resistencia: el coste oculto de read-modify-write

La resistencia habla de la capacidad de una aplicación para recuperar el estado entre las sesiones. Hemos visto lo necesario para que un dispositivo de almacenamiento 512e realice una escritura de sector de 512 bytes (ciclo Read-Modify-Write). 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 del medio donde se encuentra el sector físico podría haberse dañado con información incompleta debido a una sobrescritura parcial. Dicho de otro modo, se puede considerar que se han perdido potencialmente los 8 sectores lógicos (que contiene lógicamente el sector físico).
  • Aunque la mayoría de las aplicaciones con un almacén de datos están diseñadas con la capacidad de recuperarse de los errores de los medios, la pérdida de ocho sectores, o dicho de otra forma, la pérdida de ocho registros de commit, puede hacer potencialmente imposible que el almacén de datos se recupere con elegancia. Es posible que un administrador tenga que restaurar manualmente la base de datos a partir de una copia de seguridad o incluso tenga que realizar una recompilación larga.
  • Otra repercusión importante es que el hecho de que otra aplicación provoque un ciclo Read-Modify-Write puede provocar la pérdida de sus datos aunque su aplicación no se esté ejecutando. Esto se debe simplemente a que sus datos y los de la otra aplicación podrían estar ubicados en el mismo sector físico.

Teniendo esto en cuenta, es importante que el software de la aplicación reevalúe cualquier suposición adoptada en el código y sea consciente de la distinción entre el tamaño del sector lógico y el físico, junto con algunos escenarios de clientes interesantes que se comentan más adelante en este artículo.

Hacer lo correcto (evitar read-modify-write)

Aunque algunos proveedores de almacenamiento pueden estar introduciendo algunos niveles de mitigación en ciertos dispositivos de almacenamiento 512e para tratar de aliviar los problemas de rendimiento y resistencia del ciclo Read-Modify-Write, cualquier mitigación tiene un límite 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 garantía de que todas las clases de discos cuenten con esta mitigación, ni de que la mitigación esté bien diseñada.

La solución no es la mitigación en la unidad, sino diseñar aplicaciones que hagan lo necesario para ayudar a este tipo de medios. En esta sección se analizan las situaciones habituales en las que las aplicaciones pueden tener problemas con los discos de sectores grandes y se sugiere 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/usuario particiona el disco, es posible que la primera partición no se haya creado en un límite alineado. Esto puede provocar que todas las escrituras posteriores se desalineen 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 se alinea con un límite de sector físico de 4 KB. Sin embargo, debido al particionado predeterminado de Windows XP, a una utilidad de particionado de terceros o a 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 indican 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, su 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. Por otro lado, las escrituras en búfer se alinean con el tamaño de página de 4 KB, que casualmente es el tamaño del sector físico de la primera generación de soportes de gran tamaño. Sin embargo, la mayoría de las aplicaciones con un almacén de datos realizan escrituras sin búfer y, por tanto, habrá que asegurarse de que estas escrituras se realizan en unidades del tamaño del sector físico.

Algunos ejemplos de escenarios en los que I/O de la aplicación resultante no está alineada:

Los registros de confirmación se rellenan en sectores de 512 bytes: Las aplicaciones con un almacén de datos suelen tener algún tipo 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 como se muestra en la sección anterior y asegurarse de que cada registro de confirmación se ajuste a ese tamaño. Con un disco 4K, esto garantiza que I/O no produzcan errores. Con un disco de 512e, no solo se evita el ciclo Read-Modify-Write, sino que además 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 alineados: I/O sin búfer se usa normalmente al actualizar o anexar a un archivo de registro. Las aplicaciones pueden cambiar a I/O con búfer o almacenar internamente las actualizaciones del registro en unidades del tamaño del sector físico para evitar I/O con errores o activar una Read-Modify-Write.
Para ayudar a determinar si la aplicación emite I/O sin búfer, asegúrese de incluir el indicador 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, lo más probable es 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 del soporte solo 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 describe a continuación. Esta API habilita estos escenarios de llamada:

  • Llamar 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 se presenta en forma de una nueva clase info, FileFsSectorSizeInformation, con la estructura asociada FILE_FS_SECTOR_SIZE_INFORMATION, definida como sigue:

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 las API para consultar el tamaño del sector físico del dispositivo de almacenamiento conectado para los 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 extiende a los controladores de almacenamiento basados en Storport. Para ver un ejemplo de código que muestra cómo una aplicación puede consultar el tamaño del sector físico del volumen, consulte STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR estructura.

Aunque el ejemplo de código anterior le permite obtener el tamaño del sector físico del volumen, debe realizar una 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 indicado es una potencia de dos; si no lo es, su aplicación deberá utilizar un tamaño de sector físico igual al tamaño del sector lógico indicado.
  • Si el tamaño del sector físico es un valor de potencia de dos entre 512 bytes y 4 KB, debe considerar la posibilidad de usar 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 superiores a 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 su aplicación no se está ejecutando con privilegios, es posible que tenga que escribir una aplicación de servicio de Windows como se indica más arriba.
  • 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 cualquier identificador de archivo (el IOCTL debe emitirse a un identificador de volumen).

Problema 3: Formatos de archivo basados en sectores de 512 bytes

Algunas aplicaciones con formatos de archivo estándar (como VHD 1.0) pueden tener estos archivos codificados para asumir 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 Read-Modify-Write en el dispositivo, lo que podría dar lugar a problemas de rendimiento y resistencia para los clientes. Sin embargo, hay formas de que una aplicación ofrezca soporte para operar en este tipo de soportes, por ejemplo:

  • Utilizar búfer para garantizar que las escrituras se realicen en unidades del tamaño del sector físico.
  • Implementar un Read-Modify-Write interno que pueda ayudar a garantizar que las actualizaciones se realicen en unidades del tamaño del sector físico notificado.
  • Si es posible, rellene los registros hasta un sector físico, de forma que el relleno se interprete 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 informado del almacenamiento subyacente que aloja el Datastor puede cambiar. El más común es cuando se migra el 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 apoyar, y se menciona aquí como una advertencia. Debe tener en cuenta los requisitos de movilidad de sus 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 puede recuperar un usuario el tamaño del sector lógico y físico de un volumen

Windows incluye una utilidad para mostrar información sobre el tamaño de los sectores de un volumen. Las versiones de Windows con fsutil compatible 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 del tamaño del sector, llame a la utilidad como se indica a continuación desde un símbolo del sistema con privilegios elevados:

fsutil fsinfo ntfsinfo <drive letter>

Un disco de sector de 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 sector 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 como se indica a continuación:

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

Nota:

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

Recursos