我们的项目文件存储在 Windows 2008R2 上。现在，该 4TB 驱动器上的空间正在迅速填满，我们很快就不得不扩展驱动器或将旧文件从驱动器中移出。问题是（我们 IT 团队中的某个人声称这一点）如果我们将共享扩展到 4TB 以上，某些应用程序是否会出现问题。我们的组织使用一些据称有问题的旧应用程序，但没有人能肯定地说是否会出现问题。
那么，超过 4TB 的门槛是否会导致共享驱动器上较旧的应用程序出现问题？ 4TB 一直是旧电脑本地驱动器上的问题，但它会成为客户端应用程序共享驱动器上的问题吗？
技术信息：服务器是虚拟服务器 VMware ESXi 5.1。4TB 驱动器是来自 Dell Equallogic 的直接 iSCSI 驱动器（不是通过 VMware）。
答案1
我唯一担心的是，根据我的经验，4TB 是一个相当大的 NTFS 卷。CHKDSK 在最近的几个 Windows 版本中已经得到了很大的改进，但如果您在这么大的卷上处理文件系统损坏，您仍然可能会遇到长达数小时的中断。（与更多的小文件相比，较少的大文件会使 CHKDSK 运行得更快。）
如果这种中断是可以接受的，那么我认为增加容量是没问题的。Windows 绝对可以处理它。
您可能会考虑将想要保持更多可用性的关键文件重新定位到另一个较小的 NTFS 卷，然后使用挂载点或 DFS-N 将其“粘合”到更大的卷。
见过数小时的 CHKDSK 运行后，我有点不愿意在生产中使用如此大的 NTFS 卷。至少，我尝试将它们用于可以容忍一定程度的可用性损失的“档案”数据。
编辑：我不太关心应用程序。微软的应用程序兼容性工具包（ACT）包含许多功能，可以“强迫”不愿意运行的应用程序运行。例如，EmulateGetDiskFreeSpace 修复可能导致 Windows 伪造一个可用空间数字，从而允许具有 >2GB 可用磁盘空间的整数溢出的旧版应用程序运行。
我有一个很多成功利用 ACT 让棘手的申请顺利进行。
答案2
他们是可能可能会出现问题。问题是您的应用程序在访问文件系统时会处于多低的层次。通常，如果 Windows 可以处理它，那么它们应该没有问题，因为您的应用程序应该使用Windows API来访问较低级别的文件系统。
当然，安全总比后悔好，所以在投入生产之前要进行测试。
答案3
我更关心的是存储的直接 iSCSI 映射（与 vSphere 集群上具有这些保护措施的东西相比）。
您可以增加戴尔的 LUN 大小，这样显然可以使用更多存储资源。但此时，创建一个新的 LUN 并将文件移动到其中是否更有意义？如果这是一个选项，并且您的应用程序不需要单个连续分区，那么我会这样做。这更多的是一个管理建议，而不是技术限制。这已经是一个 GPT 磁盘，而分区大小的魔法障碍是 2.2TB。
答案4
虽然对于大于 4TB 的磁盘，您不应该有任何问题，但您始终可以选择将整个目录移动到其他磁盘并创建指向它们的硬链接。这仅在您拥有文件目录而不是一个巨大的 4TB 文件时才有效。如果您有多个目录，您可以将其中任何一个移动到另一磁盘，并让该另一磁盘上的空间可访问。用于此目的的工具是 mklink。