Zfs: 文件属性

我认为在 FS_*_FL 空间中支持标准 Linux 属性（如不可变、仅附加等）是值得的，即使您后来决定为此导入 Solaris 工具。 Linux 上的许多不同文件系统都支持 lsattr/chattr ioctl() 接口来设置这些标志，尽管一些文件系统将这些标志转换为（几乎）等效的磁盘上的值供自己使用。

如果 FS_*_FL 的新属性通常有用（我不知道 Solaris 有哪些属性而 Linux 没有），则向 FS_*_FL 添加新属性并非不可能，尽管该空间已用完，因此无法随意添加它们.

我同意，几个月前我初步尝试支持标准 Linux 属性。 我当时确定不可变、仅附加和不转储是 Solaris 和 Linux 之间唯一共有的属性。 不幸的是，我无法找到时间完成这项工作，但开发分支可用。 以下是 zfs 属性的完整列表，仅供参考。

 /*
 * 存储的附加文件级属性
 * 在 zp_flags 的上半部分
 */
 #define ZFS_READONLY 0x0000000100000000ull
 #define ZFS_HIDDEN 0x0000000200000000ull
 #define ZFS_SYSTEM 0x0000000400000000ull
 #define ZFS_ARCHIVE 0x0000000800000000ull
 #define ZFS_IMMUTABLE 0x0000001000000000ull
 #define ZFS_NOUNLINK 0x0000002000000000ull
 #define ZFS_APPENDONLY 0x0000004000000000ull
 #define ZFS_NODUMP 0x0000008000000000ull
 #define ZFS_OPAQUE 0x0000010000000000ull
 #define ZFS_AV_QUARANTINED 0x0000020000000000ull
 #define ZFS_AV_MODIFIED 0x0000040000000000ull
 #define ZFS_REPARSE 0x0000080000000000ull
 #define ZFS_OFFLINE 0x0000100000000000ull
 #define ZFS_SPARSE 0x0000200000000000ull

正如我在邮件列表中提到的，我调查了这个，并考虑了映射。 以下是我的想法，供其他人尽可能多地或尽可能少地考虑：

明显的映射：
ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
ZFS_APPENDONLY <-> FS_APPEND_FL
ZFS_NODUMP <-> FS_NODUMP_FL

出于兼容性原因，可能是一个好主意：
如果曾设置 ZFS_IMMUTABLE，则清除 ZFS_NOUNLINK。 这将允许用户使用以下命令清除 ZFS_NOUNLINK： chattr +i FILE ; chattr -i FILE

疯狂的想法1：
将 ZFS_READONLY、ZFS_HIDDEN、ZFS_SYSTEM 和 ZFS_ARCHIVE 以及 crtime 映射到 Samba 兼容的 user.DOSATTRIB xattr。

疯狂的想法2：
在目录上设置 FS_TOPDIR_FL 会设置一个属性，以便该目录中的 mkdir() 操作创建新的 ZFS 数据集。 例如，这对 /home 很有用。 然后您不需要将 ZFS 更改挂钩到 Linux 上的 useradd。 在 ext[234] 上chattr +T /home已经是一个合理的想法。 即使您没有将 FS_TOPDIR_FL 挂钩到它，ZFS 属性对此效果的想法在 /home 上仍然有用。

你好，

这个话题有什么进展吗？ 我最近将我的媒体服务器切换到 ZFS，但我错过了设置不可变标志的可能性。 我想“保护”一些文件，有没有设置标志的解决方法？ 也许通过外部程序？ 这行得通吗？

谢谢！

@cyberius0目前没有人致力于此。 但如果有人愿意，我完全赞成。

如果有人会指出我正确的方向，我想试一试。 我需要这个功能。

+1

@rlaager的 Crazy idea 2 听起来非常有用。 我想请求成为一件事。

+1

需要注意的是，Linux 文件属性接口会遇到在 Solaris 上不会发生的 TOCTOU 竞争。 Solaris 和 Linux 上的用户空间工具将文件属性的修改作为参数，文件属性作为位掩码存储在核心和磁盘上，但相似之处仅此而已。

在 Solaris 上，将更改值的列表连同它们的值将被发送到内核。 然后在 zp->z_lock 下处理获取当前位掩码、修改它并存储它的行为。 这确保所有更改都是原子的，这是做事的正确方法。 在 Linux 上，修改的责任外包给用户空间。 userland 实用程序将获取当前位掩码，进行更改并发送一个新位掩码来替换旧位掩码。 由于用户空间无法锁定文件以防止修改，因此两个并发线程接触同一文件上的不同位可以是两个更改或只有 1 个更改。

zfsonlinux/zfs#1693 通过在 Linux 接口和 Solaris 的 ZFS 接口之间实现一些转换代码，使 ZFSOnLinux 容易受到这个问题的影响。 幸运的是，文件属性的这种快速修改很少见，这可能是为什么在 Linux 上首次实现文件属性时没有检测到这种情况的原因。 当我们实现我们自己的文件属性修改工具时，我们应该弃用 Linux 接口，转而支持原子接口，就像 Solaris 所做的那样。这些将需要公开我们从 Solaris 继承的所有 ZFS 文件属性。

对明显映射的支持已合并，并将成为 0.6.3 的一部分。

• ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
• ZFS_APPENDONLY <-> FS_APPEND_FL
• ZFS_NODUMP <-> FS_NODUMP_FL

这不包括存在于 Linux 上但不包括 Illumos 的属性，反之亦然。 由于我们将不得不逐案处理这些问题，因此我认为关闭此问题是有意义的。 我们可以根据需要为每个属性打开一个新问题，以讨论它应该如何表现的细节。

9d31779 实现文件属性支持
3b4f425 重构 inode_owner_or_capable() 自动工具检查

@behlendorf是否有文档或手册列出了受支持的属性以及它们在 ZFS 系统上的作用？