Every IT professional and advanced user knows that the real formatted capacity of a Terabyte (1 TB) HDD or SSD is just over 931 Gigabytes (GB). The difference is because HDD and SSD manufacturers, without exception, use powers of 10 to claim disk sizes (decimal system), whereas computer file systems are based on powers of 2 (binary system).
Why is it so? Quoting IEC (International Electrotechnical Commission):
Years ago, at a time when computer capacities barely matched the few tens of kilobytes required by this single web “page”, computer engineers noticed that the binary 210 (1024) was very nearly equal to the decimal 103 (1000) and, purely as a matter of convenience, they began referring to 1024 bytes as a kilobyte. It was, after all, only a 2,4 % difference and all the professionals generally knew what they were talking about among themselves.
New units with binary prefixes were needed, and were defined by the IEC in 1998. The binary kilobyte became kibibyte (KiB), binary megabyte mibibyte (MiB), binary gigabyte gibibyte (GiB), and binary terabyte tibibyte (TiB). Over 20 years now, these have been de facto IEC standard binary multiples, units, but we computer users have been slow to adapt the standard. Anyway, according to these internationally accepted IEC standards, 1,000 bytes is a kilobyte, whereas 1,024 bytes is a kibibyte. Therefore, a 1 terabyte HDD is 0.931 tibibytes.
Confused? You are not alone. Even operating systems like Windows use basically wrong, non-standard units. Here’s the size (highlighted) of Windows folder on laptop I am using to write this:
According to agreed standards, the size is actually 27 GB (size in bytes divided by 1,000^3), not 25.1 GB:
26,993,063,993 / (1,000^3) = 26.99
Windows shows the size in GiB (size in bytes divided by 1,024^3), not in GB, using the wrong unit:
26,993,063,993 / (1,024^3) = 25.14
So, the manufacturers use decimal system and calculate a 1,000 GB / 1 TB HDD size as 1,000 * 1,000 * 1,000 = 1,000,000,000 bytes, and announce the size as GB or TB. File system calculates 1 TB (actually TiB) based on powers of 2 as 1,024 * 1,024 * 1,024 = 1,073,741,824 bytes.
To calculate the formatted capacity of any HDD or SSD in units we are used to call gigabytes but what really is gibibytes (“binary gigabytes”), first we need to divide decimal gigabyte (1,000,000,000 bytes) with binary gibibyte (1,073,741,824 bytes):
1,000,000,000 / 1,073,741,824 = 0.931
This gives us the multiplier we can use to calculate the real, formatted capacity of any HDD or SSD in GiB. Some examples:
– 128 GB HDD, formatted capacity 128 * 0.931 = 119.16 GiB
– 256 GB HDD, formatted capacity 256 * 0.931 = 238.34 GiB
– 512 GB HDD, formatted capacity 512 * 0.931 = 476.67 GiB
This is of course totally irrelevant as long as we know and remember it. However, there’s one scenario where this comes important: partitioning with an autounattend.xml answer file. When creating the answer file in Windows System Image Manager (WSIM), or doing it manually in a code editor, there’s no way to tell Windows Setup to use all remaining space on a disk after MBR or GPT system partitions for Windows partition, then shrink it a bit to create the WinRE partition directly after it. That’s where the recovery partition should be located, according to Microsoft’s partitioning guidelines.
To get the WinRE partition located in correct place, we need to know formatted capacity of the disk on which Windows will be installed, and use that as the base when we create partitions in answer file. Using a 512 GB disk with formatted capacity of 476.67 GiB as an example, remembering that recommended minimum size for WinRE partition is 450 MiB, this is how DiskConfiguration’s part of the answer file would look to create EFI, MSR, Windows and WinRE partitions on a GPT disk. Click expand source to see the code:
<DiskConfiguration> <Disk wcm:action="add"> <CreatePartitions> <CreatePartition wcm:action="add"> <Order>1</Order> <Size>100</Size> <Type>EFI</Type> </CreatePartition> <CreatePartition wcm:action="add"> <Order>2</Order> <Size>128</Size> <Type>MSR</Type> </CreatePartition> <CreatePartition wcm:action="add"> <Order>3</Order> <Type>Primary</Type> <Size>487384</Size> </CreatePartition> <CreatePartition wcm:action="add"> <Order>4</Order> <Extend>true</Extend> <Type>Primary</Type> </CreatePartition> </CreatePartitions> <ModifyPartitions> <ModifyPartition wcm:action="add"> <Order>1</Order> <PartitionID>1</PartitionID> <Label>System</Label> <Format>FAT32</Format> </ModifyPartition> <ModifyPartition wcm:action="add"> <Order>2</Order> <PartitionID>2</PartitionID> </ModifyPartition> <ModifyPartition wcm:action="add"> <Order>3</Order> <PartitionID>3</PartitionID> <Letter>C</Letter> <Label>Windows</Label> <Format>NTFS</Format> </ModifyPartition> <ModifyPartition wcm:action="add"> <TypeID>DE94BBA4-06D1-4D40-A16A-BFD50179D6AC</TypeID> <Order>4</Order> <PartitionID>4</PartitionID> <Format>NTFS</Format> <Label>WinRE</Label> </ModifyPartition> </ModifyPartitions> <WillWipeDisk>true</WillWipeDisk> <DiskID>0</DiskID> </Disk> </DiskConfiguration>
I want to give WinRE 500 MiB. The EFI partition uses 100 MiB and the MSR partition 128 MiB. To calculate how much space I can allocate to the Windows partition I now use the formatted capacity of the disk, 476.67 GiB or 488,112 MiB and subtract the space needed for GPT system partitions:
488,112 - 100 - 128 - 500 = 487,384 MB
As partition size is given in MiBs, I use this value for the Windows partition size, then tell Windows Setup to use all remaining space for last partition, WinRe with Extend = true setting. Notice that as long as WinRE gets at least 450 MiB, you can round up the numbers. It’s not an exact science!
One reason I prefer to use Microsoft Deployment Toolkit for deployment, rather than creating answer files manually or in WSIM, is exactly this. In an MDT task sequence, I can just create EFI and MSR partitions with exact sizes, put the Windows partition next using 99% of remaining space, and put WinRE last using whatever space is left.
As long as you are aware about these differences in disk capacity, what manufacturers claim and what the file system sees, there’s no reason to worry. This just is how it works today. If you use an answer file to take care of partitioning in your deployments, you just need some simple calculations to get the WinRE partition in the correct place, after the Windows partition, without leaving any annoying unallocated GBs at the end of the disk.
– Win10.guru: Thank you, Microsoft – An Important Change in Windows Setup
– Win10.guru: New 1909 Disk Layout
– International Electrotechnical Commission IEC
– Wikipedia: Gibibyte
– Wikipedia: Tebibyte
Author: Kari Finn
A former Windows Insider MVP, Kari started in computing in the mid 80’s writing code for VAX / VMS systems. Since then, he’s worked in a variety of IT positions. He specializes in Windows image capture, customization, repair and deployment as well as Hyper-V virtualization. Kari is a proud Team Member at number #1 Windows site TenForums.com.