Hard disk drives are commonly based on 512-byte sectors, and all access to the physical media is addressed based on this unit. Hard disks vendors now manufacture Advanced Format disks that have a sector size of 4096 bytes (4 KB). These disks can perform only physical media updates in the granularity of the 4 KB physical sector. Therefore, a 512-byte write that is directed to the disk requires some additional work to be completed. This additional work affects performance and reliability, depending on the workload and hardware implementation. To avoid this additional work, applications must be updated to natively support write operations in the 4-KB sector size.
This article discusses a hotfix rollup package that introduces a new storage infrastructure that lets you query the physical sector size of a storage device. Additionally, the hotfix rollup package updates the Fsutil.exe tool to report the correct sector size.
Developers must make special considerations when these kinds of disks are used. However, a more detailed technical discussion of these considerations is beyond the scope of this article and will be detailed in another article on MSDN.
Issues that this hotfix rollup package resolves
This hotfix rollup package resolves the following issues that involve Advanced Format disk and that are not previously documented in a Microsoft Knowledge Base article.
Issue 1
Storport is a storage driver model that is used by many storage controller manufacturers and that is in Windows Vista and in Windows Server 2008. Storport does not support the
IOCTL_STORAGE_QUERY_PROPERTY request that has the
STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR structure to retrieve the storage access alignment descriptor data for an attached disk. This structure contains physical and logical sector size information. Without this information, NTFS and other applications cannot perform aligned writes to a disk. This may affect performance and reliability.
Without this hotfix rollup package, applications cannot query the physical sector size of the storage device.
This hotfix has an updated Storport driver (Storport.sys) that supports the
IOCTL_STORAGE_QUERY_PROPERTY request that has the
STORAGE_ACCESS_ALGINMENT_DESCRIPTOR structure.
Note A
IOCTL_STORAGE_QUERY_PROPERTY request results in a translation to the
SCSI SBC3 READ_CAPACITY(16) command. The miniport driver that plugs into the Storport driver model must support the
SBC3 READ_CAPACITY(16) command. Additionally, the disk drive must correctly report the sector size information by using the
SBC3 READ_CAPACITY(16) command.
For more information about the
IOCTL_STORAGE_QUERY_PROPERTY control code, visit the following MSDN website:
For more information about the
STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR structure, visit the following MSDN website:
Issue 2
This update also updates the Fsutil.exe tool. The updated tool generates a new
Bytes Per Physical Sector field in the output. For example, you receive an output that resembles the following when you run the
fsutil fsinfo ntfsinfo C: command to obtain information about drive C:
NTFS Volume Serial Number: 0xfe6e5dcc6e5d7e79Version: 3.1Number Sectors: 0x000000001d1927ffTotal Clusters: 0x0000000003a324ffFree Clusters: 0x0000000001f8bae8Total Reserved: 0x00000000000007f0Bytes Per Sector: 512Bytes Per Physical Sector: 4096Bytes Per Cluster: 4096Bytes Per FileRecord Segment: 1024Clusters Per FileRecord Segmen: 0Mft Valid Data Length: 0x0000000020980000Mft Start Lcn: 0x00000000000c0000Mft2 Start Lcn: 0x0000000000000002Mft Zone Start: 0x000000000109c060Mft Zone End: 0x00000000010a8880RM Identifier: 974AD058-3B3D-11DE-9300-000FFEE93BEF
Note The
Bytes Per Physical Sector field has one of the following values:
- 512
A value of 512 means the drive is a legacy 512 native drive. - 4096
A value of 4096 means the drive is for Advanced Format drive. - Not Supported
A value of Not Supported means the hardware or driver does not support the IOCTL_STORAGE_QUERY_PROPERTY control code.
Issue 3These storage devices that have various software and hardware components have increased support. However, the support may remain unstandardized. For example, support for accurate reporting of the physical sector size for these storage devices remains unstandardized. Therefore, applications must handle scenarios where the reported physical sector size of the storage device they use may change.
Applications that are built on ESENT may not work correctly after the reported physical sector size of the storage device changes.
In the following scenarios, Windows may report that the physical sector size of a storage device has changed:
- You move the storage device to a RAID controller from a direct-attached controller, and vice-versa. In this scenario, the reported physical sector size may change because RAID controllers may not report the physical sector size of the storage device. Therefore, the system may identify 4 KB in one session and 512 bytes in another session, and vice-versa.
- You upgrade your primary storage device that has a 512-byte physical sector size to a storage device that has a 4-KB physical sector size, or vice-versa. Additionally, you use an application such as Windows backup to perform a block-level backup and restore. Consider the following scenario:
- You perform a block-level backup of your system that is running on a storage device that reports a 512-byte physical sector size.
- You replace this storage device by using a storage device that reports a 4-KB physical sector size.
- You perform a block-level restore of your system to the new storage device.
In this scenario, the reported physical sector size is changed from 512 bytes to 4 KB when the system starts.
Note This scenario can also be reversed where you replace a storage device that uses a 4-KB physical sector size to a storage device that uses a 512-byte physical sector size. - You upgrade the storage controller in the system where the current storage controller has support for physical sector size reporting, and the new storage controller that does not have support for physical sector size reporting, or vice-versa. When the storage controller changes, Windows must load the appropriate driver to support the new storage controller. For example, this issue occurs most frequently when you are upgrading from the Microsoft Inbox ATA driver (MSAHCI) to a third-party Storport-based driver, or vice-versa.
- You change the mode of the storage controller in the BIOS of the system. This issue may occur in all combinations of modes such as AHCI, Legacy, IDE, Compatible, RAID, and so on. Each mode requires a different storage driver to be loaded by Windows. In this case, some drivers may have support, and other drivers may not have support.
The following are examples of applications that are built on the Extensible Storage Engine API (ESENT):
- Windows Update
- Active Directory
- Windows Desktop Search
- Certification authority (CA)
- Windows Internet Name Service (WINS)
- Dynamic Host Configuration Protocol (DHCP)
- Windows Live Mail
For example, you may receive the following error message in Windows Update when this issue occurs:
FATAL: Failed to initialize datastore, error = 0xC8000222.
Additionally, an event that resembles the following is logged in the Application log:
Log Name: Application
Source: ESENT
Date: <date & time>
Event ID: 412
Task Category: Logging/Recovery
Level: Error
Keywords: Classic
User: N/A
Computer: <computer name>
Description:
wuaueng.dll (936) SUS20ClientDataStore: Unable to read the header of logfile C:\Windows\SoftwareDistribution\DataStore\Logs\edb.log. Error -546.