七款云上共享文件系统 POSIX 兼容性大比拼

当用户在进行文件系统选型时，POSIX 语义兼容性是必不可缺的一项考察指标。JuiceFS 一直非常重视对 POSIX 标准的高度兼容，在持续完善功能、提高性能的同时，尽力保持最大程度的 POSIX 兼容性。

近期，就 POSIX 兼容性，我们对腾讯云 CFS、阿里云 NAS、华为云SFS、 GCP Filestore、Amazon EFS、Azure File shares 以及 JuiceFS 进行了一次测试，便于用户了解这些主流文件系统的兼容性表现。

POSIX 是可移植操作系统接口(Portable Operating System Interface) 的缩写，简单来说是文操作系统包括件存储领域应用最广泛的操作系统接口规范。更多关于POSIX 标准的讨论，可以参考 Quora 上的一个问答 “What does POSIX conformance/compliance mean in the distributed systems world?”

测试方法

针对文件系统 POSIX 兼容性的测试，比较流行的一个测试用例集是 pjdfstest，来源于 FreeBSD，也适用于 Linux 等系统。

测试结果

测试结果如上图显示，JuiceFS 的失败用例是 0，展现出了最好的兼容性。GCP Filestore 次之，有两项失败；华为云 SFS，Amazon EFS 与 Azure File shares 失败的测试用例相比其他产品大了几个数量级，为了方便比较，上图的横坐标使用了对数坐标。

失败用例分析

华为云 SFS，Amazon EFS 与 Azure File shares 的失败用例无论从总数及类别均大大超出其它几种文件系统，无法放入同一图表对比，后面将单独分析。

GCP Filestore

GCP Filestore 共失败 2 项测试，unlink 和 utimensat 这两个类别各一。

第一项是 unlink 测试集中的 unlink/14.t，对应日志如下。

/root/pjdfstest/tests/unlink/14.t ...........
not ok 4 - tried 'open pjdfstest_b03f52249a0c653a3f382dfe1237caa1 O_RDONLY : unlink pjdfstest_b03f52249a0c653a3f382dfe1237caa1 : fstat 0 nlink', expected 0, got 1

该测试集（unlink/14.t）用于验证一个文件在打开状态下被删除时的行为：

desc="An open file will not be immediately freed by unlink"

删除文件的操作在系统层面实际对应于 unlink，即移除该文件名到对应 inode 的链接，对应 nlink 的值减 1，这个测试用例就是要验证这一点。

# A deleted file's link count should be 0
expect 0 open ${n0} O_RDONLY : unlink ${n0} : fstat 0 nlink

文件内容只有在链接数（nlink）减少至 0 并且没有打开的文件描述符（fd）指向该文件时才会被真正删除。如果 nlink 没有被正确更新，可能会导致本该删除的文件仍然残留在系统里。

另一项是 utimensat 测试集中的 utimensat/09.t，对应日志如下：

/root/pjdfstest/tests/utimensat/09.t ........
not ok 5 - tried 'lstat pjdfstest_909f188e5492d41a12208f02402f8df6 mtime', expected 4294967296, got 4294967295

该测试用例要求支持 64 位时间戳。GCP Filestore 支持 64 位时间戳，但是会在此基础上减少1，所以在此这个测试用例上虽然失败但是应该不影响使用。

腾讯云 CFS

腾讯云 CFS 共失败 7 项，来自三个类别：utimensat, symlink 和 unlink。我们选取了一些重要的失败项进行了分析说明。

symlink 失败用例对应测试日志如下：

/root/pjdfstest/tests/symlink/03.t ..........
not ok 1 - tried 'symlink 7ea12171c487d234bef89d9d77ac8dc2929ea8ce264150140f02a77fc6dcad7c3b2b36b5ed19666f8b57ad861861c69cb63a7b23bcc58ad68e132a94c0939d5/.../... pjdfstest_57517a47d0388e0c84fa1915bf11fe4a', expected 0, got EINVAL
not ok 2 - tried 'unlink pjdfstest_57517a47d0388e0c84fa1915bf11fe4a', expected 0, got ENOENT
Failed 2/6 subtests

该测试集（symlink/03.t）用于测试路径超出 PATH_MAX 长度时 symblink 的行为。

desc="symlink returns ENAMETOOLONG if an entire length of either path name exceeded {PATH_MAX} characters"

失败的用例对应代码如下：

n0=`namegen`nx=`dirgen_max`nxx="${nx}x"
mkdir -p "${nx%/*}"
expect 0 symlink ${nx} ${n0}
expect 0 unlink ${n0}

该测试用例是要创建长度为 PATH_MAX (包括结尾的0在内）的符号链接，通不过表明无法在腾讯云 NAS 上创建长度为 PATH_MAX 的符号链接。

阿里云 NAS

阿里云 NAS 未能通过 chmod 、utimensat、unlink 上的几项测试用例。

在 chmod chmod/12.t 这个测试集中，阿里云 NAS 失败了以下几个项目

/root/pjdfstest/tests/chmod/12.t ............
not ok 3 - tried '-u 65534 -g 65534 open pjdfstest_db85e6a66130518db172a8b6ce6d53da O_WRONLY : write 0 x : fstat 0 mode', expected 0777, got 04777
not ok 4 - tried 'stat pjdfstest_db85e6a66130518db172a8b6ce6d53da mode', expected 0777, got 04777
not ok 7 - tried '-u 65534 -g 65534 open pjdfstest_db85e6a66130518db172a8b6ce6d53da O_RDWR : write 0 x : fstat 0 mode', expected 0777, got 02777
not ok 8 - tried 'stat pjdfstest_db85e6a66130518db172a8b6ce6d53da mode', expected 0777, got 02777
not ok 11 - tried '-u 65534 -g 65534 open pjdfstest_db85e6a66130518db172a8b6ce6d53da O_RDWR : write 0 x : fstat 0 mode', expected 0777, got 06777
not ok 12 - tried 'stat pjdfstest_db85e6a66130518db172a8b6ce6d53da mode', expected 0777, got 06777
Failed 6/14 subtests

该测试集（chmod/12.t）用于测试 SUID/SGID 位的行为

desc="verify SUID/SGID bit behaviour"

我们选取其中的第 11 和 12 个测试用例来详细解释一下，同时覆盖了这两个权限位

# Check whether writing to the file by non-owner clears the SUID+SGID.
expect 0 create ${n0} 06777
expect 0777 -u 65534 -g 65534 open ${n0} O_RDWR : write 0 x : fstat 0 mode
expect 0777 stat ${n0} mode
expect 0 unlink ${n0}

此处，我们先以 06777 的权限创建目标文件，然后修改文件内容，检查 SUID 和 SGID 是否被正确清除。文件权限里的 777 大家会比较熟悉，分别对应 owner，group和 other 的 rwx，即可读、可写、可执行。最前面的 0 表示八进制数。

第二位 6 需要着重解释下，这个八位元组（octet）代表特殊权限位，其中前两位分别对应 setuid/setgid（或称 SUID/SGID），可以应用于可执行文件及公共目录。该权限位被设置时，任何用户都会以 owner （或 group）身份来运行该文件。这个特殊的属性允许用户获取通常只对 owner 开放的文件和目录访问权限。例如 passwd 命令就设置了 setuid 权限，这允许普通用户修改密码，因为保存密码的文件是只允许 root 访问的，用户不可直接修改。

setuid/setgid 设计的出发点是提供一种方法，让用户以限定的方式（指定可执行文件）访问受限文件（非当前用户所有）。因此，当文件被非 owner 修改时应自动清除此权限位，以避免用户通过这个途径获取其他权限。

从测试结果中我们可以看到在阿里云 NAS 中，文件被非 owner 修改时，setuid/setgid 均未被清除，这样实际上用户可以通过修改文件内容以该 owner 身份进行任意操作，这将会是个安全隐患。

参考阅读： Special File Permissions (setuid, setgid and Sticky Bit) (System Administration Guide: Security Services)

华为云 SFS 与 Amazon EFS

华为云 SFS 与 Amazon Elastic File System (EFS) 在 pjdfstest 测试中失败内容类似。失败比例大概为21%，失败用例几乎覆盖了所有类别。

两者都支持以 NFS 方式挂载，但对 NFS 特性的支持并不完整。比如都不支持块设备和字符设备，这直接导致了 pjdfstest 中大量测试用例的失败。排除这两类文件之后，仍然有上百项不同类别的失败，所以在复杂场景中应用二者必须慎之又慎。

Azure File shares

而 Azure File shares 失败率达到了 62%，这说明一些基本的 POSIX 场景可能都会有不兼容的问题。比如 Azure File shares 文件与文件夹默认权限 0777，所有者为 root，且都不支持修改，也就是说没有任何权限限制。另外 Azure File shares 也不支持硬链接与符号链接。所以使用 Azure File Shares 需要仔细测试并慎重考虑场景是否足够简单。

总结

JuiceFS 在兼容性方面表现最好，通过了全部的测试项。
Google Filestore 次之，有两类未能通过，其中有一项不影响实际使用。
腾讯云 CFS 与阿里云 NAS 相差不多，皆有 7-8 项未通过。
华为云 SFS ，Amazon EFS 与 Azure File Shares的兼容性较差，有大量的兼容性测试通不过，其中包括有严重安全隐患的若干个测试用例，使用前建议做安全性评估。

如有帮助的话欢迎关注我们项目 Juicedata/JuiceFS 哟！ (0ᴗ0✿)