我们有我们的项目文件存储在Windows 2008R2上。 现在，这个4TB硬盘上的空间正在迅速充满，我们很快就要么强制扩展硬盘，要么将旧硬盘从硬盘中移出。 问题是（我们的IT团队有人声称）如果我们将这个份额扩展到4TB以上，那么在某些应用程序中会出现问题。 我们的组织使用一些声称有问题的旧应用程序，但没有人可以肯定地说是否会有问题。
那么，越过4TB阈值是否会导致共享驱动器上的旧应用程序出现问题？ 4TB在旧电脑的本地驱动器上出现了问题，但是在客户端应用程序的共享驱动器上会出现问题吗？
技术信息：服务器是虚拟服务器VMware ESXi 5.1。 4TB驱动器是Dell Equallogic的直接iSCSI驱动器（不通过VMware）。
我唯一担心的就是根据我的经验，4TB是一个非常大的NTFS卷。 在过去的几个Windows版本中，CHKDSK已经得到了很多改进，但是如果在一个很大的卷上进行文件系统损坏，您可能仍然会有一个多小时的中断。 （与较多数量的小文件相比，较less的大文件会使CHKDSK运行更快）。
如果这样的停电是可以接受的，那么我认为你可以很好地增加音量。 Windows绝对可以处理它。
您可能会考虑将要为其保留更多可用性的关键文件重定位到另一个较小的NTFS卷，并使用挂载点或DFS-N将其“粘合”到较大的卷。
看到多小时CHKDSK运行，我有点沉默，使用生产中如此之大的NTFS卷。 至less，我尝试将它们用于可以容忍可用性损失的“归档”数据。
编辑：我不太关心应用程序。 微软的应用程序兼容性工具包 （ACT）包含了许多function来“强迫”不愿意运行的应用程序。 例如， EmulateGetDiskFreeSpace修复程序可以使Windows 构build一个空闲空间编号，允许遗留应用程序具有大于2GB的可用磁盘空间的整数溢出。
我已经获得了很多成功使用ACT的挑剔的应用程序工作。
他们可能是问题。 问题是访问文件系统时，应用程序分层的程度有多低。 通常情况下，如果Windows可以处理它，应该不会有问题，因为应用程序应该使用Windows API访问较低级别的文件系统。
当然最好是安全的，不要抱歉，所以在投入生产之前先进行testing。
我更关心存储的直接iSCSI映射（与vSphere群集上的某些function相比，并具有这些保护function） 。
您可以增加戴尔的LUN大小，因此显然有更多的存储资源可供您使用。 但是在这一点上，创build一个新的LUN并将文件移动到其上更有意义吗？ 如果这是一个选项，你的应用程序不需要一个连续的分区，那就是我所要做的。 这更多的是一个pipe理build议，而不是一个技术限制。 这已经是GPT磁盘了，分区大小上的魔术屏障是2.2TB。
由于chkdsk问题，我个人不喜欢如此巨大的NTFS卷。 请参阅Evan Andersons的答案。
另外要记住的是，chkdsk不仅会花费时间，如果它实际上，但也可能需要更多的RAM比虚拟机可用。
根据经验，每个1TB的磁盘空间大概需要1 GB的内存，安全起见。 （特别是在有很多小文件的卷上。）
传统应用程序的一个主要担心就是他们无法检查可用的磁盘空间。
只是读/写文件通常是可以的，因为这是通过Windows系统调用，应用程序本身不会创build任何比它能处理的东西更大（希望…）。
但是，如果它问Windows“有多less可用的磁盘空间？ （在写一个新文件之前的一般做法），它可能会得到一个没有准备好的答案。
例如老的Borland C / C ++，Pascal，Object-Pascal和Delphi程序有点臭名昭着。 这些程序共享的Borland运行时库在这方面有点片面。 而且还有很多这些。 Visual Basic 4也是一个众所周知的问题。
当然也可能是你的遗留应用程序永远不会触发这种行为。 没有办法预测会发生什么。
我将在此虚拟机上安装一个额外的单独驱动器，大小不超过1 TB。 将旧文件的文件夹移动到这个驱动器上。 然后，您可以安全地扩展原始磁盘，而不必担心这一点。
如果传统应用通过共享接近数据，他们甚至不会注意到他们现在正在与另一个磁盘通话。
如果传统的东西在服务器上运行，依赖于特定的磁盘布局，并且不能很好地处理path变化，则可以将额外的卷挂载在较大的磁盘上的原始文件夹之上。 有点杂乱，但有效。
虽然你不应该有任何大于4TB的磁盘的问题，你总是可以select将整个目录移动到其他磁盘，并创build硬连接。 这只会有效，如果你有文件的目录，而不是一个巨大的4TB文件。 如果您有多个目录，则可以将这些目录中的任何一个移动到另一个磁盘，并使该另一个磁盘上的空间可访问。 这个工具是mklink。