我们有一个RAID卷的服务器。 Windows DEFRAG在卷上显示非常高的碎片（90％）。 我的首席人员问DEFRAG是否报告碎片是正确的（或接近正确）。
我们长时间没有进行碎片整理（至less，不是在过去的四个月里，我在这里工作的时间）。 这是一个生产服务器，我们非常担心。
碎片整理将报告碎片的逻辑磁盘：这意味着你的数据是如何分散在arrays的物理磁盘取决于什么样的RAID（0,1,5等），并在内部的一点点你的控制器。
一般来说，你可以像对待任何其他硬盘一样对待它（即“90％爱狗碎片”），尽pipe在90％，这可能是一个痛苦的经验。
另外值得注意的是：碎片整理显然非常耗费磁盘空间。 如果这些磁盘是原始磁盘，则可能需要确保备份在碎片整理之前保持良好状态，以防万一磁盘碎片整理程序让RAID控制器确信一个或多个驱动器“失败”。
是的，它报告正确。
我应该指出，我唯一一次看到在卷卷上存在如此严重的碎片时，Shadow Copies被存储在卷上。
在未完全分区的驱动器上查找一些空间，并将卷影副本存储区域移动到新创build的卷中，该卷专门用于保存卷影副本，并查看碎片是否大量下降，甚至无法对当前卷进行碎片整理显示〜90％的碎片。
假设您正在使用卷影副本，它们不应该与它们正在复制的源文件在同一个驱动器上。
如果您没有使用卷影副本，则最有可能的罪魁祸首是备份应用程序，如Backup Exec将备份文件存储在太小块中。
虽然真的任何创build大中型文件的程序，然后在regluar的基础上删除它们可能会创造相同的情况。
RAID系统不应该对windows中的碎片计数有任何影响。 raid系统提供了一个窗口的磁盘。 文件系统（计算碎片的位置）build立在此之上。
Windows碎片整理只是使用一个碎片整理API，它build立在一个逻辑文件系统的顶层，而逻辑文件系统又将位于HAL之上的某个位置; 在这个层面上，底层硬件并不重要：只要你的设备驱动程序正确地完成他们的工作，所报告的碎片在最坏的情况下将保持一致，而与应用程序无关。