注意
本文档适用于 Ceph 的开发版本。
分布式文件系统的应用程序最佳实践
CephFS 兼容 POSIX，因此应该适用于任何需要 POSIX 文件系统的现有应用程序。然而，由于它是一个网络文件系统（不像 XFS 等），并且具有高一致性（不像 NFS 等），所以有一些后果是应用程序作者可能需要了解的。
以下章节描述了一些分布式文件系统与本地文件系统相比，性能表现可能明显不同的领域。
ls -l
当你运行“ls -l”时，ls 程序首先执行目录列表，然后对目录中的每个文件调用 stat。
这通常远远超出了应用程序实际需要的范围，对于大型目录来说可能会很慢。如果你真的不需要每个文件的所有这些元数据，那么就使用普通的 ls。
对正在扩展的文件执行 ls/stat
如果另一个客户端当前正在列出的目录中扩展文件，那么 ls -l 可能需要特别长的时间才能完成，因为列表程序必须等待写入程序刷新数据才能对每个文件的大小进行有效读取。因此，除非你*确实*需要知道目录中每个文件的确切大小，否则不要这样做！
这也适用于任何直接对正在从另一个节点追加写入的文件发出 stat 系统调用的应用程序代码。
超大目录
你真的需要那个包含 10,000,000 个文件的目录吗？虽然目录分片使得 CephFS 能够处理它，但它总是比将文件分成更适度大小的目录效率低。
即使是标准的用户空间工具，在操作超大目录时也会变得相当慢。例如，ls 的默认行为是给出按字母顺序排列的结果，但是 readdir 系统调用不会给出有序结果（这通常是正确的，不只是 CephFS）。所以当你在一个包含一百万个文件的目录上执行 ls 时，它会将一百万个名称列表加载到内存中，对列表进行排序，然后将其输出到显示器。
硬链接
硬链接在文件系统内部进行管理以保持对同一数据的两个引用时会产生固有的成本。在 CephFS 中有一个特定的性能成本，因为对于普通文件，inode 是嵌入在目录中的（即查找路径后无需额外获取 inode）。
工作集大小
MDS 充当存储在 RADOS 中的元数据的缓存。对于元数据适合该缓存的工作负载，元数据性能非常不同。
如果你的工作负载中的文件数量超过了缓存所能容纳的数量（使用 mds_cache_memory_limit 设置配置），那么请确保你进行了适当的测试：不要用少量文件测试你的系统，然后期望在你转移到大量文件时获得相同的性能。
你需要文件系统吗？
请记住，Ceph 还包括一个对象存储接口。如果你的应用程序需要存储巨大的扁平文件集合，并且你只是按原样读取和写入整个文件，那么你可能最好使用 对象网关