我有一个运行 Windows Server 的文件服务器，并且我正在使用存储池技术来创建存储文件的卷。
我尝试将一些文件从一个卷移动到另一个卷，但收到一条奇怪的消息，提示没有可用空间来复制 37MB 的文件，但显示仍有 1.60TB 的可用空间
。
在 Linux 上，如果遇到类似情况，我会检查一些 inode 问题，但我找不到复制失败的正确原因。请注意，我甚至检查了权限错误（这里不是问题），并尝试使用 robocopy 进行复制（错误 112，因为目标上缺少可用空间）。
该卷或新目录没有应用配额策略，并且卷是 NTFS。
有什么提示或建议吗？
谢谢！
答案1
这不仅与可用空间有关，还与 a) 可用簇的数量和 b) 簇大小有关。假设，如果您有较大的簇大小（这里指的是兆字节）和许多小簇，但不是很小，因为这些簇写在 NTFS 文件系统的 MFT 内，例如元数据 + 数据在同一个位置，文件... 您可能会很快用完空间！这时 Windows 中的 FSUtil 可能会派上用场。
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil
您需要做的是 a) 打开 PowerShell cmd，b) 运行带有“fsinfo”和“ntfsinfo”参数的“fsutil”，后跟目标驱动器号或路径（如果由于某种原因没有分配驱动器号）。
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-fsinfo
像这样：
fsutil fsinfo ntfsinfo YourDestinationCopyDriveLetter:
在输出中，您可以检查“可用簇”和“每簇字节数”报告的值。如果将它们相乘，您将得到驱动器可以接受的不是非常小（小文件存储在 MFT 中，并且从未触及实际簇，就像我之前提到的那样）文件的近似最大值。
希望这有帮助:)