POSIX 合规性

以下是 Google Cloud Managed Lustre 的 POSIX 合规性例外情况：

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

• flock/lockf：这两个术语是指两个主要的文件锁定 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 错误。

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

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

管理员应了解此行为及其对应用的潜在影响，然后再启动任何手动元数据重新平衡操作。

缓解策略

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

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

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

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