Large Logical Unit Support and Windows Server
This article describes changes in Windows operating systems that will support disk logical unit sizes larger than 2 TB.
In contrast, the file system uses a 64-bit signed byte offset. This means that the absolute file system limit is actually 2⁵⁴ 512-byte blocks. However, NTFS reduces this, because it supports a 32-bit cluster number * 64K per cluster maximum, which equals 256 TB.
Another complicating factor was the use of Master Book Record (MBR) partition types, which can only contain up to 2³² blocks. GUID Partition Tables (GPT) can support a much larger number of blocks, but Windows only supported GPT on Intel Itanium machines.
Note: Microsoft recommends that for Windows Server 2003, basic disks should use 512-byte sectors (dynamic disks will only work with 512-byte sectors). Windows Vista and later operating systems will support up to 4-KB sector sizes.
Windows Support for Logical Units Larger than 2 TB
With Windows Server 2003 Service Pack 1 (SP1) and Windows XP 64-bit Edition (x64), these limits have changed.
Microsoft added support for 64-bit block numbers in the disk/class layer, using the new SCSI Commands included in the SCSI-3 Block Commands-2 command set. Microsoft also enabled GPT support for all Windows Server 2003 SP1 platforms. With this change, for example, a snapshot of a GPT partition on an Itanium-based machine can now be transported to a 32-bit machine for data mining or archiving purposes.
The new limits are as follows:
Basic or dynamic volume size: 2⁶⁴ blocks = 2⁷³ bytes (too big to pronounce)
Maximum NTFS file system size that can be realized on Windows: 256 TB
Note: Disk devices with more than 2 TB of disk space must be converted to GPT format for all of the disk space to be usable. If the device uses MBR format, the disk space beyond 2 TB will be unusable.
Details
If you design and manufacture storage subsystems or PCI RAID devices, you can enable support for this feature by implementing the SCSI Block Commands - 2 16-byte Command Descriptor Blocks (CDBs) for the following commands:
READ CAPACITY (16) 9Eh
READ (16) 88h
WRITE (16) 8Ah
VERIFY (16) 8Fh
Also, you must support the long LBA version of the REASSIGN BLOCKS (07h) command (if you support block reassignment). To avoid confusion, the following describes how Windows implements this support using the commands listed previously.
READ CAPACITY: During disk initialization time, the disk class driver will send a READ CAPACITY (10) to query for the capacity of the device. If this command returns 0xFFFFFFFF as the RETURNED LOGICAL BLOCK ADDRESS a READ CAPACITY (16) command will be sent to get the full disk capacity. If this succeeds, the device will be marked as a 16-byte CDB capable device. Otherwise, it will not be used.
READ/WRITE/VERIFY: If the device is marked as 16-byte capable during initialization, only READ (16), WRITE (16) and VERIFY (16) commands will be used on these devices. The 10-byte version of these commands will not be sent.
REASSIGN BLOCKS: This is a 6-byte CDB that passes a list of logical blocks to the device. For devices that are marked 16-byte capable, the LONGLBA bit will be set and the list will contain 8-byte LBAs.
The New APIs and Interfaces
The disk class driver exposes the following new IOCTLs. Both applications and kernel-mode drivers can call these IOCTLs. If a driver calls one of these IOCTLs, it must do so from a thread running at IRQL < DISPATCH_LEVEL.
IOCTL_DISK_REASSIGN_BLOCKS_EX
This IOCTL is similar to the IOCTL_DISK_REASSIGN_BLOCKS interface documented in the DDK. This IOCTL uses the REASSIGN_BLOCKS_EX structure, which has 8 bytes defined for the LBA.
IOCTL_STORAGE_READ_CAPACITY
This IOCTL can be used to query the disk capacity as returned by the READ CAPACITY command. This also provides the total disk length in bytes. This IOCTL returns the STORAGE_READ_CAPACITY structure, defined below.
Return Values
STATUS_SUCCESS (NO_ERROR)
Output buffer will include the STORAGE_READ_CAPACITY structure.
STATUS_DEVICE_BUSY (ERROR_BUSY)
Unable to get READ CAPACITY data from the device.
STATUS_INSUFFICIENT_RESOURCES (ERROR_NO_SYSTEM_RESOURCES)
Memory allocation failed.
STATUS_BUFFER_OVERFLOW (ERROR_MORE_DATA)
The output buffer size is less than the size of STORAGE_READ_CAPACITY structure.
STORAGE_READ_CAPACITY Structure Definitions
typedef struct _STORAGE_READ_CAPACITY {
// The version number, size of the STORAGE_READ_CAPACITY structure
ULONG Version;
// The size of the date returned.
// Size of the STORAGE_READ_CAPACITY structure
ULONG Size;
// Number of bytes per block
ULONG BlockLength;
// Total number of blocks in the disk
// This will have the last LBA + 1
LARGE_INTEGER NumberOfBlocks;
// Disk size in bytes
LARGE_INTEGER DiskLength;
} STORAGE_READ_CAPACITY, *PSTORAGE_READ_CAPACITY;
Notes
As all things get bigger, all things can also take longer. A huge disk volume can present long delays with Chkdsk and searching, especially with billions of files. There is no substitute for sane layout of storage. The primary applications here will be large database/data warehouses or possibly repositories of very large images such as HD video.
Changes were not made to HBA/controller drivers for SCSI, Fibre Channel, or iSCSI, because in general, none were needed. However, system designers should check with their adapter vendors. Some PCI RAID vendors are now choosing to upgrade their drivers and firmware to also provide this support for PCI RAID cards.
At this time, no changes were made to Windows support for USB, IEEE 1394, or ATA (single spindle; ATA/SATA RAID cards will be able to use this feature).
No changes were made for 32-bit versions of Windows XP SP2.
32-bit versions of Windows Server 2003 Service Pack 1 (SP1) and Windows XP 64-bit Edition (x64) cannot boot from GPT disks.
32-bit versions of previous Windows operating systems (Windows 9x, Windows NT 4.0, Windows 2000, and Windows XP) do not support GPT disks.