NTFS 卷上最大的逻辑簇号 (LCN) 是多少？

Question

根据规范，NTFS 分区最多可以有 263 ^- 1 个逻辑簇。但是当我尝试计算测试大于 32 位的值所需的驱动器大小时，我遇到了一个问题。

计算一下，4k 簇大小加上 0xFFFFFFFF + 1 个簇，结果为 17,592,186,044,416 字节。这个数字很大，但并非不可能。

然而，根据这，16TB 驱动器不能使用 4k 簇大小，而必须使用 8k。

重新计算一下，8192 * (0xffffffff + 1) 得出 35,184,372,088,832。但是该页面告诉我 32TB 驱动器不能使用 8k 集群，而必须使用 16k。

您开始明白我的问题了。如果此页面正确，那么无论 NTFS 的规范如何规定，Windows 实际上都不允许 LCN 超过 32 位。

也许该页面已经过时了？它明确地说明了这一点Applies To: Windows 10，但也许它完全是错误的？我不知道思考我误读了。

由于“阅读文档”无法给我提供可靠的答案，是否有人真的有 16TB（或更大）的驱动器可供实验（注意：必须至少有 17,592,186,048,512 个可用字节）？如果您尝试使用 4k 簇大小对其进行格式化会发生什么？或者甚至是 2k？

迁移到 8k 集群是否只是 16TB 驱动器的“推荐”设置？还是必须/强制执行？

---

编辑：我猜答案围绕 MBR 分区（确实有这些限制）与 GPT 分区（显然没有），但我还无法证明这一点。

---

编辑：所以，我似乎没有取得太大进展。是的，MBR 仅限于 32 位 LCN。是的，GPT 的规格支持 263 个^群集。

但是，当我尝试以超过 0xffffffff 簇的方式格式化 GPT 分区时，我只收到一个（奇怪的）错误：

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

WARNING, ALL DATA ON NON-REMOVABLE DISK
DRIVE F: WILL BE LOST!
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

它为什么会这样说Allocation unit size changed to 1000 bytes？1000 字节不是有效的簇大小。此外，它将其更改为 4096。

为了全面披露，我会提到这次测试是使用 VirtualBox 进行的，但我认为这没什么关系。

所以我仍然坚持我最初的问题：NTFS 卷上最大的逻辑簇号 (LCN) 是多少？ 尽管 NTFS 和 GPT 的规格可能符合我的预期，但我仍然被限制在 32 位。

Answer 1

我找不到确凿的来源，但我相信有足够的证据来支持结论。

格式化 NTFS 的代码（位于 uNTFS.dll 中）使用读取分区信息的“传统”方法（IOCTL_DISK_GET_DRIVE_GEOMETRY），因此无法看到大于 MBR 支持的分区（即 32 位 LCN）。

这种行为与已发布的 NTFS 卷大小限制一致，这一事实使我得出结论，这种限制是设计使然。

从编码的角度来看，更新 uNTFS.dll 以支持最多 2 ^{63 个}字节（不是簇）似乎是一项简单的任务，并且需要支持超过 32 位的 LCN。但由于 ReFS 是 MS 未来用于超大卷的首选文件系统，因此我并不认为这种情况会发生。

因此，根据我的观察，目前没有（受支持的）方法来测试 LCN 超过 32 位的 NTFS 卷。理论上，这种情况将来可能会改变，但可能不会。