During post-deployment checks on a Windows Server 2019 file server, you discover that a brand-new 4 TB SATA disk shows a single NTFS primary partition that is exactly 2 TB. About 1.8 TB of capacity appears as Unallocated, and the Extend Volume option is unavailable even though SMART and controller diagnostics report no faults. Which action will correct the underlying partition error and let the server use the disk's full capacity?
Replace the disk because sectors beyond the 2 TB boundary are physically defective.
Update the drive firmware so the disk reports 4 KB native sectors instead of 512-byte emulation.
Reformat the existing 2 TB partition with a larger (64 KB) NTFS cluster size to correct the bitmap and then extend the volume.
Back up the data, delete the current partition table, initialize the disk as GPT, recreate the volume, and then restore the data.
The administrator accepted Disk Management's default Master Boot Record (MBR) style when the disk was first initialized. MBR can address only 2 199 023 255 552 bytes (≈ 2.2 TB) because its 32-bit LBA field tops out at 4 294 967 295 sectors. Everything beyond that limit shows up as unallocated and cannot be added to an existing MBR volume. Re-initializing the disk with the GUID Partition Table (GPT) removes the 2 TB ceiling. Because Windows cannot convert a non-system MBR disk to GPT in-place, the safest remediation is to back up the data, delete the partition table, initialize the disk as GPT, recreate the volume(s), and restore the data. Changing NTFS cluster size or sector format does not bypass the 32-bit addressing limit, and there is no indication that the hardware is defective, so those options would not resolve the problem.