处理满的Ceph文件系统

当一个RADOS集群达到它的mon_osd_full_ratio（默认

文件系统对满标志有一些特殊的处理，下面将解释。

Hammer及以后版本

自从hammer版本发布以来，满的文件系统会导致从以下操作产生ENOSPC结果：

客户端的写入数据

删除和截断以外的元数据操作

因为满的条件可能直到数据被刷新到磁盘（在某个调用已经返回0之后）时才会遇到，ENOSPC错误可能直到应用程序在文件句柄上调用write call has already returned 0), the ENOSPC error may not be seen until the application calls fsync或fclose（或等效）时才会看到。

调用fsync保证可靠地指示数据是否到达了磁盘，如果没有，将返回错误。fclose将只在缓冲数据自上次写入以来恰好被刷新时返回错误——成功的fclose并不保证数据到达了磁盘，并且在满空间的情况下，缓冲数据可能在fclose如果没有空间来持久化它，之后可能会被丢弃。

警告

如果应用程序在满的文件系统上似乎行为不正常，检查它是否在必要时执行fsync()调用来确保数据在继续之前已经在磁盘上。

如果在发送OSD满标志时写入数据正在飞行中，客户端可能会取消写入数据。客户端在释放受取消操作影响的文件的权限时更新osd_epoch_barrier，以确保这些取消的操作不会干扰MDS或其他客户端对数据对象的后续访问。有关epoch屏障机制的更多信息，请参阅背景：Blocklisting和OSD epoch屏障.

旧版（Hammer之前）行为

在hammer之前的Ceph版本中，MDS会忽略RADOS集群的满状态，来自客户端的任何数据写入都会停滞，直到集群不再满。

对于这种行为，需要注意两个危险的情况：

如果客户端有一个待处理的文件写入，那么客户端不可能将文件释放给MDS以供删除：这可能导致难以在满的文件系统上清理空间
如果客户端继续创建大量空文件，MDS产生的元数据写入可能会导致OSD上的空间完全耗尽，以至于无法执行进一步的删除。

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.