By spec, NTFS partitions can have up to 263 - 1 logical clusters. But when I tried to calculate what size drive I'd need to test values greater than 32bits, I ran into a problem.

Doing the math, a 4k cluster size with 0xFFFFFFFF + 1 clusters results in 17,592,186,044,416 bytes. That's large, but not impossibly so.

However, according to this, 16TB drives can't use a 4k cluster size, but must use 8k.

Re-running the math, 8192 * (0xffffffff + 1) gives 35,184,372,088,832. However that page tells me 32TB drives can't use 8k clusters, but must use 16k.

You begin to see my problem. If this page is correct, then despite what the specs for NTFS say, Windows doesn't really allow LCNs to exceed 32bits.

Perhaps that page is out of date? It specifically says it Applies To: Windows 10, but maybe it's just flat wrong? I don't think I'm misreading it.

Since "reading the docs" isn't getting me a reliable answer, does anyone actually have a 16TB (or larger) drive to experiment with (NB: Must have at least 17,592,186,048,512 usable bytes)? What happens if you try to format it with a 4k cluster size? Or maybe even 2k?

Is moving to 8k clusters just the "recommended" setting for 16TB drives? Or is it required/enforced?

Edit: I'm guessing the answer revolves around MBR partitions (which DO have these limitations) vs GPT partitions (which apparently don't), but I haven't been able to prove it yet.

Edit: So, I don't appear to be making much progress here. Yes, MBR is limited to 32bit LCNs. Yes, the specs for GPT support 263 clusters.

However, when I attempt to format a GPT partition in a way that would exceed 0xffffffff clusters, I just get a (weird) error:

C:\Windows\system32>format f: /q /fs:ntfs /a:512 /v:vn
The type of the file system is NTFS.
Enter current volume label for drive F: New Volume

Proceed with Format (Y/N)? y
QuickFormatting 4.8 TB
Allocation unit size changed to 1000 bytes.   <------------------
Creating file system structures.
Format complete.
       4.8 TB total disk space.
       4.8 TB are available.

C:\Windows\system32>fsutil fsinfo ntfsinfo f:
NTFS Volume Serial Number :        0x1808cec808cea3da
NTFS Version   :                   3.1
LFS Version    :                   2.0
Number Sectors :                   0x0000000262596fff
Total Clusters :                   0x000000004c4b2dff
Free Clusters  :                   0x000000004c49e59f
Total Reserved :                   0x0000000000000400
Bytes Per Sector  :                512
Bytes Per Physical Sector :        512
Bytes Per Cluster :                4096
Bytes Per FileRecord Segment    :  1024
Clusters Per FileRecord Segment :  0
Mft Valid Data Length :            0x0000000000040000
Mft Start Lcn  :                   0x00000000000c0000
Mft2 Start Lcn :                   0x0000000000000002
Mft Zone Start :                   0x00000000000c0000
Mft Zone End   :                   0x00000000000cc820
Max Device Trim Extent Count :     0
Max Device Trim Byte Count :       0x0
Max Volume Trim Extent Count :     62
Max Volume Trim Byte Count :       0x40000000
Resource Manager Identifier :      8B803C36-14BE-11EA-A11E-0800276F6C4C

Why the heck is it saying Allocation unit size changed to 1000 bytes? 1000 bytes is not a valid clustersize. And besides, it changed it to 4096.

In the interests of full disclosure, I'll mention that this test was conducted using VirtualBox, but I see no reason that should matter.

So I'm still stuck with my original question: What's the largest possible Logical Cluster Number (LCN) on an NTFS volume? And despite what the specs for both NTFS and GPT might lead me to expect, I'm still limited to 32bits.

1 Answer 1


I wasn't able to find a definitive source, but I believe that there's sufficient evidence to support a conclusion.

The code for formatting NTFS (located in uNTFS.dll) uses the "legacy" method of reading partition information (IOCTL_DISK_GET_DRIVE_GEOMETRY) and so is unable to see partitions larger than what MBR supports (ie 32bit LCNs).

The fact that this behavior is consistent with the published limits for the size of NTFS volumes leads me to conclude that this limitation is by design.

From a coding point of view, updating uNTFS.dll to support up to 263 BYTES (not clusters) seems like a straight-forward task, and that would require supporting more than 32bits worth of LCNs. But since ReFS is MS's preferred file system for extremely large volumes going forward, I'm not expecting that will ever happen.

So based on what I've seen, there is no (supported) way to test NTFS volumes with more than 32bits worth of LCNs. Theoretically this could change in the future, but it probably won't.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .