Windows 8 的命令似乎defrag有一些新的选项，包括：
/K对指定卷执行板块合并。
有人知道这在英语中是什么意思吗？
答案1
此 PDF似乎对此有一个解释，以及新的 NTFS 功能。
它说：
楼板加固
有效地整理文件碎片，以尽量减少分配的碎片数量
slab 是精简配置卷上的分配单位
需要支持
IOCTL_STORAGE_QUERY_PROPERTY请求以下属性 ID：StorageDeviceLBProvisioningProperty
- 检索卷的平板大小
答案2
我找不到任何具体解释这在 Windows 8 碎片整理程序中意味着什么的内容。但“碎片整合”通常是指移动对象，以便将四舍五入到相同分配大小的对象放在一起。
这样做的好处通常很小。但它确实有助于减少访问大量小对象时的平均寻道时间。
答案3
实际上，我不认为 slab 是为了调整许多相同大小的文件的分配来减少平均寻道时间而设计的。
我的观点是，它用于减少大卷上的分配延迟，否则当并行线程需要在卷上分配空间时，会导致过多的并发访问，因为这会锁定卷分配位图的同一部分。为了避免处理大型位图，可以将其细分为“slab”，其位大小表示使用相同位图片段的磁盘上的连续区域（占用至少 1 个或多个簇；如果您的簇大小为 4KB，则位图中的簇代表 4K*8 = 32K 可分配簇，即 128MB 的存储空间；卷中的实际 slab 大小调整为 33 到 64 之间，允许大约 33 个并发线程在磁盘上的位图中分配空间而不会相互阻塞）
因此，slab 用于加速卷上的空间分配，假设创建许多文件的线程将在其自己的 slab 内最常执行此操作，然后解锁它并尝试另一个 slab，或者尝试在当前 slab 中分配较小的量，然后尝试另一个可用的非锁定 slab，然后尝试同时获取对另一个线程当前使用的 slab 的阻塞访问。
这解释了为什么磁盘上的分配会“分散”在整个卷上。这也解释了为什么 NTFS 上的 MFT 至少有 2 个片段，属于其他板块，因为它避免了使用该卷的许多线程之间的严重锁定。您可以对 MFT 进行碎片整理，但它将保留至少一个片段在其“保留区域”中，以进行并发分配，这必须避免在 NTFS 卷上执行阻塞 I/O）。
过去，NTFS 卷未细分为多个 slab，由于许多线程阻塞和内核中等待 I/O 完成的线程切换过多，导致性能大幅下降（即使位图中的分配实际上非常快，只需几纳秒，因为位图中大部分有趣的部分已缓存在内存中）。当卷上的写入被刷新并记录时，由于日志上的分配，会发生另一个锁定，因此日志现在也使用卷上的单独 slab（如果可能）。
但是我不认为 NTFS 会将任何 slab 专门用于特定大小的文件。当数据被删除并且其分配的大小低于某个阈值时，NTFS 内部会稍微对 slab 进行碎片整理，并且可以合并两个这样的 slab。
您可以使用以下方式获取有关板材尺寸的信息文件系统信息：
fsutil fsinfo ntfsinfo c:
显然，slab 是针对性能的调整参数。但许多第三方碎片整理工具会忽略此设置，并且不使用最佳放置位置。理想情况下，卷的每个 slab 中都应该有一些可用空间，除非 slab 中充满了未重新分配且应保持稳定的文件和索引。对于不断创建和回收的许多小型临时文件和事务，您需要根据并发线程数将它们放置在足够的 slab 中，并避免将它们放置在离需要读取的其他群集太远的地方（如果卷是硬盘或 RAID 阵列，这在 SSD 上无关紧要）。
对于远程文件系统，slab 也很有用，但它们的最佳大小很难预测。相反，对于分层虚拟化卷的差异卷，slab 非常小，并且存在非常不同的放置策略，因为分配是虚拟的并重新映射到不同的物理位置。
我们仍然需要 Microsoft 提供有关注册表中以下调整参数的信息：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\SlabifyFunction]
MinimumReclaimSlabsMB = REG_DWORD: 10240
MinimumReclaimSlabsPercent = REG_DWORD: 10
SlabEvictUpperBoundKB = REG_DWORD: 204800
SlabEvictUpperBoundPercent = REG_DWORD: 20
我认为这些是故意不记录的，因为微软仍在考虑改变放置策略，并且可能会随着时间的推移而改变。它们没有通过 API 公开，您只能在注册表和 NTFS 驱动程序的内部源代码实现中找到它们的证据（不确定是否有人可以访问这些源代码，或者它们是否已在微软的帮助下移植到 Linux 的 NTFS“NG”驱动程序中，该驱动程序在实现上可能仍会进行不同的调整，以更好地满足最常见的 Linux 需求；但是，这个 Linux 内核现在由微软赞助，它为 Windows 和微软自己的 Azure 云在 Azure 上提供内核，现在微软与 Linux、基于 Linux 的 Android 和基于 BSD 的 iOS/MacOS 内核进行了大量合作，它希望在这些内核上销售云服务。NTFS 不再仅适用于 Windows，它必须与其他操作系统配合使用，Windows 也必须存在于更大的操作系统中，以满足不同的需求和规模）。
Windows 中也有 NTFS 的替代方案，例如 ReFS（具有附加功能，但也有其自身的局限性）；Windows 以后可能会扩展以接受其他文件系统，包括 Ext4 或 ZFS，或 MacOS 的 HFS+：Windows 内核和 API 中似乎都已准备就绪（而且 Paragon Software 等多家公司已经在 Windows 上支持这些文件系统……但仍然不支持启动操作系统和 Hyper-V 等 Windows 关键组件）。微软不断改变主意，它只是适应市场需求，但微软不再希望仅凭自己的专有解决方案将自己孤立在利基市场中，因为它希望瞄准更多的应用程序和用途。我们所知道的是，/KDEFRAG.EXE 命令行工具的参数会简要显示 slab，但并没有详细介绍它们。但很容易观察到，/K优化在 Windows 初始安装后带来了巨大的性能提升（甚至在 6 次重启和测量后进行 Bootvis 优化之前）。还有与/LSSD 上的修剪相关的参数。