实施配额和预留空间的最简单方式是以每个项目或每个文件系统为单位。配额和预留空间不应用于 LUN，尽管对它们的使用被计入了总的项目配额或预留空间。
数据配额对文件系统或项目可使用的空间量施加限制。默认情况下，它将包括文件系统以及所有快照中的数据。当文件系统已满时，尝试写入新数据的客户机会因为配额或因为存储池的空间不足而收到一个错误。如了解快照中所述，此行为并非在所有情况下都很直观，尤其是当存在快照时。如果数据块被快照所引用，则删除文件可能会导致文件系统写入新数据，因此，在这种情况下，销毁现有快照可能是降低空间使用率的唯一方法。
如果未设置 "include snapshots"（包含快照）属性，则配额仅应用于文件系统引用的即时数据，不应用于任何快照。快照使用的空间受项目级别的配额限制，但不受其他限制。在这种情况下，删除快照引用的文件将导致文件系统的被引用数据减少，尽管系统作为整体正使用更多的空间。如果存储池已满（与文件系统达到预设的配额相对），则销毁快照可能是释放空间的唯一方法。
数据配额是严格实施的，这意味着在空间使用率接近限制时，必须对可写入的数据的量进行限制，因为只有在确认了写入操作后才能获知要写入的精确数据量。当在已达到配额或将要达到配额的情况下运行时，这可能会影响性能。因此，在正常运行过程中，保持在配额以下通常是明智的。
配额通过 BUI 在 "Shares"（共享资源）> "General"（常规）> "Space Usage"（空间使用情况）> "Data"（数据）下进行管理。它们在 CLI 中作为 quota 和 quota_snap 属性进行管理。
数据预留空间用于确保文件系统或项目至少有一定量的可用空间，即使文件系统中的其他共享资源尝试使用更多的空间。此未使用的预留空间被视为文件系统的一部分，因此，如果池（或项目）的其余部分已达到容量，该文件系统仍可以写入新数据，即使其他共享资源可能已经空间不足。
默认情况下，预留空间包括文件系统的所有快照。如果未设置 "include snapshots"（包含快照）属性，则预留空间仅应用于文件系统的即时数据。获取快照的行为并不一定总是直观的。如果实施了用于文件系统数据（但不是快照）的预留空间，则每次创建快照时，系统都必须预留足够的空间以便该快照完全分化，即使从不发生此操作。例如，如果没有快照时，一个 50G 的文件系统有 100G 的预留空间，则在创建第一个快照时将预留 50G 的额外空间，该文件系统最终将总共预留 150G 空间。如果没有足够的空间来确保数据的完全分化，则创建快照将失败。
预留空间通过 BUI 在 "Shares"（共享资源）> "General"（常规）> "Space Usage"（空间使用情况）> "Data"（数据）下进行管理。它们在 CLI 中作为 reservation 和 reservation_snap 属性进行管理。
创建 LUN 时，系统会预留您为 LUN 配置的全部物理空间，并且这些空间无法被其他文件系统使用（除非进行了瘦置备）。对于复制，如果创建了任何给定规模的 LUN 的快照，则还会预留最多两倍于 LUN 的大小，具体取决于使用的 LUN 空间。
以下列表显示复制 LUN 时所需的最大开销空间：
在更新之间在源上最多 100%
更新过程中在源上最多 200%
在目标上最多 200%