POSIX 合规性

以下是 Google Cloud Managed Lustre 不符合 POSIX 标准的例外情况：

• atime 更新：默认情况下，Lustre 中启用了 atime，但出于性能方面的考虑，其更新可能会延迟。这意味着，文件访问时间可能不会在每次读取操作后立即更新。

• flock/lockf：这两个 API 是指两个主要的文件锁定 API：flock(2) 和 fcntl(2)。

  • flock：这是 BSD 风格的整文件建议性锁定，未由 POSIX 定义。默认情况下，Lustre 在整个集群中完全支持 BSD 风格的 flock 语义。
  • fcntl：这是 POSIX 定义的锁定 API，支持字节范围锁定。Lustre 对 fcntl 锁的实现几乎符合 POSIX 标准，并且对于大多数应用而言，其运行方式符合预期。不过，由于 fcntl 最初是为本地文件系统设计的，因此没有分布式文件系统（包括 Lustre）能够 100% 满足 POSIX 的所有 fcntl 要求。例如，fcntl() 指定在所有者进程退出时必须立即释放锁，但如果客户端崩溃，Lustre 锁释放可能会延迟。

如需了解详情，请参阅 Lustre 常见问题解答。

因元数据迁移而导致的 inode 编号变化

Lustre 文件系统中的文件 inode 编号不是不可变的标识符。

元数据重新平衡操作（例如由 lfs migrate 发起的操作）涉及将某些文件的元数据从一个 MDT 迁移到另一个 MDT。由于迁移到新的 MDT，这些文件会被分配新的 inode 编号。

虽然此行为符合 POSIX 标准，但可能会违反许多常见的 Unix/Linux 应用和服务的假设，这些应用和服务在构建时会假设文件在整个生命周期内具有持久的 inode 编号。包括但不限于：

• NFS 和 SMB 前端：这些服务通常会从 inode 编号派生文件句柄。此更改可能会导致客户端出现 Stale file handle 错误。

• 归档和备份实用程序：tar 等工具会按设备 + inode 编号跟踪文件，可能会将迁移的文件视为新文件，从而导致增量备份效率低下。

• 使用 stat() 并存储 st_ino 的日志汇总器、入侵检测系统和自定义应用也可能会受到影响。

在开始任何手动元数据重新平衡之前，管理员应了解此行为及其对应用的潜在影响。

缓解策略

元数据重新平衡应视为计划内的中断性维护事件。

1. 安排维护窗口。向所有用户和应用所有者告知计划中断。如果可能，请勿在实时生产系统上执行大规模 lfs migrate 操作。

2. 如果需要，请在迁移后卸载并重新挂载文件系统。

3. 迁移后，可能需要刷新或重启某些应用。