注意
本文档适用于 Ceph 的开发版本。
处理满载的 Ceph 文件系统
当 RADOS 集群达到其 mon_osd_full_ratio（默认 95%）容量时，它会被标记为 OSD full 标志。此标志会导致大多数正常的 RADOS 客户端暂停所有操作，直到问题解决（例如通过向集群添加更多容量）。
文件系统对 full 标志有一些特殊的处理，如下所述。
Hammer 及更高版本
自 hammer 版本以来，满载的文件系统会导致以下操作返回 ENOSPC 错误：
客户端上的数据写入
删除和截断之外的元数据操作
由于直到数据被刷新到磁盘（在 write 调用返回 0 之后的一段时间）才可能遇到满载条件，因此直到应用程序对文件句柄调用 fsync 或 fclose（或等效函数）时才可能看到 ENOSPC 错误。
调用 fsync 保证可靠地指示数据是否已写入磁盘，如果未写入，则会返回错误。fclose 仅在自上次写入以来缓冲数据恰好被刷新时才返回错误——成功的 fclose 并不能保证数据已写入磁盘，并且在空间不足的情况下，如果无可用空间来持久化缓冲数据，则在 fclose 之后可能会丢弃这些数据。
警告
如果应用程序在满载的文件系统上表现异常，请检查它是否正在按需执行 fsync() 调用，以确保数据在继续操作之前已写入磁盘。
如果 OSD full 标志发送时数据写入正在进行中，客户端可能会取消这些写入。客户端在释放受取消操作影响的文件的功能时更新 osd_epoch_barrier，以确保这些取消的操作不会干扰 MDS 或其他客户端随后对数据对象的访问。有关 epoch barrier 机制的更多信息，请参阅 背景：阻止列表和 OSD epoch barrier。
旧版（pre-hammer）行为
在早于 hammer 版本的 Ceph 中，MDS 会忽略 RADOS 集群的满载状态，并且来自客户端的任何数据写入都会停滞，直到集群不再满载。
使用此行为需要注意两个危险情况：
如果客户端有待处理的文件写入，则客户端无法将文件释放给 MDS 以进行删除：这可能导致在满载的文件系统上难以清理空间
如果客户端继续创建大量空文件，由此产生的来自 MDS 的元数据写入可能导致 OSD 上的空间完全耗尽，以至于无法执行进一步的删除。