预配精简卷

为精简型预配保留的容量是系统开销的一部分，Oracle FS System 管理器 (GUI) 报告的可用容量包括这部分容量。由于系统已将这部分保留容量计算在内，因此 GUI 报告的可用容量可完全用于预配逻辑卷。

对于 SAN LUN，LUN 精简预配的程度取决于访问 LUN 的主机应用程序的性质。如果应用程序始终访问 LUN 的特定部分，则该卷的精简程度保持不变。但是，随着应用程序访问的 LUN 区域越来越多样化，Oracle FS System 将为 LUN 分配额外的物理空间，从而导致卷的精简程度降低。

某些应用程序访问卷的大部分或全部可寻址空间。在这些情况下，当应用程序执行时，卷将从精简型预配转变为完全预配。此类应用程序的一个示例是 mkfs 实用程序，它可在分区上创建文件系统。当 mkfs 实用程序格式化文件系统时，该实用程序将写入大部分或全部分区，导致 Oracle FS System 上的底层卷变成完全预配。在这些情况下，使用精简型预配创建底层卷没有什么价值。

Microsoft Windows 操作系统为格式化为新技术文件系统 (New Technology File System, NTFS) 卷的文件系统保留大量的元数据。该元数据的布局会导致预先分配精简型预配的空间。主 NTFS 元数据由以下对象组成：

引导记录－写到卷的开头和结尾
主文件表 (master file table, MFT)－写到卷的开头和卷的中间

为了防止 MFT 成为碎片，Windows 为 MFT 保留了一个缓冲区。该缓冲区的大小可配置为驱动器空间的 12.5%、25%、37.5% 或 50%。在未使用的空间用尽之前，Windows 不会在该缓冲区中创建新文件。每当驱动器空间的剩余部分变满时，缓冲区大小都会减半。这种策略为额外的写入操作提供了新空间。

如果在首次填充时占用的容量超过最大容量的 90%，尤其是在使用 NTFS 时，Oracle 不建议创建精简型预配 LUN。NTFS 写入遍及 LUN，从而导致分配与写入的数据量不匹配。

使用率很高但运行时没有很多空闲容量的 NTFS 文件系统最终会用尽所有容量，除非文件系统定期进行碎片整理。NTFS 偏向于写入新分配的空间，而不是重复使用以前写入的空间。可以在最初采用精简型预配的情况下使用 NTFS，但是使用的分配量很快就会超过文件系统显示为已使用的数据量。

由于精简型预配使用控制器资源并且影响性能，因此最好将精简型预配用于具有以下特征的 LUN：

初始分配等于现有数据量加上 10%。该值将成为已分配的逻辑容量。
可寻址逻辑容量与您预计 LUN 需要的一样大。

例如，假设有 420 GB 的文件数据，管理员应该将 LUN 的已分配逻辑容量配置为大约 470 GB，并将可寻址逻辑容量配置为大约 1 TB。

注： NTFS 使用多少容量取决于许多因素，包括写入操作中涉及的数据量、执行写入操作的位置以及其他因素，例如存储池中使用的存储类型。

在 Linux 平台上，EXT2 和 EXT3 文件系统会在 LUN 的整个逻辑块地址 (logical block addresses, LBA) 范围内写入元数据。驱动器划分为块组，元数据存在于每个块组的开头。这种配置通常会导致管理员在创建文件系统时预配整个 LUN。之所以发生这种完全预配，是因为元数据写入低于 Oracle FS System 使用的最小分配单元。这种情况会导致系统将每个分配区扩展到最大大小。

总之，精简型预配的使用是否成功取决于文件系统或使用 LUN 的应用程序。