我刚刚了解到（谢谢你 Kevh）Windows 上的 GPT 驱动器可以容纳 256 TB
与 MBR 将每个分区的大小限制为 2TB 不同，GPT 中的每个分区最多可以容纳 2^64 个块（因为它使用 64 位），这相当于 512 字节块的 9.44ZB（1 ZB 为 10 亿兆字节）。在 Microsoft Windows 中，该大小限制为 256TB。来源
按照最佳实践，我根据 CPU 使用多个数据库文件。在较小的安装中，我过去一直将它们放在同一个 MBR 驱动器上。我还使用不同的驱动器，用于 tempdb、数据文件、日志文件、备份和操作系统，因此一个实例至少需要 5 个驱动器。
现在有了 GPT，理论上我可以在一块磁盘上放 256TB，所以也许挂载磁盘来突破 26 个驱动器号限制的日子已经一去不复返了。(使用 MBR 且只有 26 个字母的驱动器，如果不使用已安装的驱动器，则限制为 52TB）
256TB 乘以 26 个字母驱动器 = 6.6ZB
仅仅因为你可以并不意味着你应该...
问题：
当考虑将 SQL 实例中的 256TB 数据文件放在单个字母磁盘上时，我应该考虑什么？
答案1
简短回答：否，我不会使用单个 256 TB 的 NTFS 文件系统。
长答案：NTFS 不是池文件系统，也不是基于数据集的存储系统。换句话说，卷包含整个文件系统。这意味着特定操作（即：chkdsk、vssadmin snapshot等）适用于整个文件系统。
想象一下，修复一个接近满的 256 TB NTFS 卷需要多少时间chkdsk：虽然你可以争辩说最近的 NTFS/chkdsk 版本可以在线纠正越来越多的问题（无需卸载卷），一些问题需要离线扫描 - 在此期间您无法使用该卷，或者如果它是系统驱动器，甚至无法启动操作系统。
或者想想如何vssadmin snapshot create恢复一个小文件，将导致巨大的性能损失全部您的 SQL 数据库。
边注：我唯一会使用的文件系统考虑使用如此大的卷（撇开非常专有的、不是“现成的”东西，如 WAFL）是 ZFS：池化、基于数据集且具有完全在线性zfs scrub，它在设计上适合如此大的存储空间。但即使使用 ZFS，在这些大小下，创建多个池的选项也不能自动丢弃。