我们有一个客户系统，删除文件后磁盘长时间无法访问。通常，磁盘无法访问的时间超过 45 分钟。
该系统是一个约 55 TB 的生产系统，配置了 11 个磁盘，采用 RAID 5。所有驱动器均为 7200rpm 的 SAS 驱动器。该系统还有一个备份系统，该系统存在完全相同的问题，因此不太可能出现硬件故障。RAID 阵列中的 100GB 专用于运行 Windows 2019 服务器的操作系统分区，其余部分用于挂起的数据分区。
删除的文件数量接近 5000 个，平均有 47 个碎片。它们都位于同一个文件夹中。分区上的文件总数约为 500k，分布在 90 个文件夹中。文件大小从 1MB 到 1GB 不等。
我们重现此问题的步骤很简单，就是删除一个文件夹。使用我们自己的软件，删除调用可以快速处理；大约需要 1.5 秒。但是，在那之后，整个驱动器会完全挂起，通常超过 45 分钟。在此期间，似乎没有调用（读/写）完成。磁盘显示在文件资源管理器中，但甚至没有显示可用空间和总大小。在此期间，可以访问操作系统磁盘。
删除相同数量的碎片整理文件（手动碎片整理或复制文件后）需要 1-2 分钟，这也是相当长的时间。这强烈表明碎片化是问题所在，但我们不知道原因。即使在碎片化的系统上，删除文件也应该相当简单。还是我们错过了什么？使用文件资源管理器（shitft+delete）删除会导致相同的错误，但删除窗口会在 50% 左右挂起。它在大约相同的时间后完成。
RAID 控制器未报告任何错误。
我们可以通过让我们的软件写入更少的碎片文件来解决这个问题，这是可行的。我们首先想要得到解释，这样其他客户就不会遇到这种情况。
我们能找到的最相关的帖子是：
https://stackoverflow.com/questions/39161241/why-does-file-operations-hangs-after-deleting-folder-on-large-ntfs-volume
它已经有 6 年历史了，但是仍然没有关于到底发生了什么的真实信息。
尝试使用 xperf 在挂起期间收集信息。从操作系统磁盘运行此程序，以便能够写入，但这也挂起，因此我们无法获取报告。
contig64 -f 显示
可用集群空间：35559636795392
可用空间碎片数：1699（这个数字可能很有趣，它看起来很低）
最大可用空间块：13484514672640
Defrag.exe 显示 99%，这显然太高了。
有人有什么见解吗？也许知道一些有关 NTFS 的详细信息，这可以解释为什么删除后会花费很多时间。
进一步调查后进行编辑。
使用 xperf 收集调试数据并使用 WPA 进行分析，我们确认我们的问题与上面的链接完全相同。这是相同的堆栈跟踪和非常相似的症状。这肯定指向一个 ntfs 错误（或至少是漏洞），如果单个线程正在访问同一个驱动器，则单个线程会阻止其余线程。这不是真正的解释，但至少它将问题缩小了不少。
已经有一个修复程序可以修复 Windows 11 中的类似问题，但由于升级可能是不可能的，因此我们可能很难验证。修复的问题在此处描述；
https://github.com/microsoft/Windows-Dev-Performance/issues/64
答案1
首先，我会使用像 ultra defrag 这样的程序，因为它能够对 NTFS 文件系统的 MFT 进行碎片整理。
然后，我将获取 Windows 版本的 smartctl 或类似版本并检查每个驱动器上的 SMART 健康报告。
我怀疑驱动器已经开始磨损，但目前这只是一个猜测。
我曾经历过坏扇区导致驱动器甚至整个计算机冻结数分钟的情况。即使有 9 个坏扇区，也很容易导致系统冻结 45 分钟或更长时间。
另外，在 NTFS 上使用 chkdsk /r 来处理会导致驱动器冻结的坏扇区。坏消息是，它需要在卸载卷时运行。
你可以尝试
chkdsk /r /scan 提供 chkdsk 扫描的在线版本。由于它是在线的，因此它可能会/可能不会修复它们，但它会检测到它们。
/scan 仅限 NTFS：在卷 /forceofflinefix 仅限 NTFS 上运行在线扫描
：（必须与“/scan”一起使用）绕过所有在线修复；发现的所有缺陷都会排队进行离线修复（即“chkdsk /spotfix”）。