关于机器学习:七款云上共享文件系统-POSIX-兼容性大比拼

3次阅读

共计 4647 个字符，预计需要花费 12 分钟才能阅读完成。

当用户在进行文件系统选型时，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 共失败 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 共失败 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 未能通过 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 Elastic File System (EFS) 在 pjdfstest 测试中失败内容相似。失败比例大略为 21%，失败用例简直笼罩了所有类别。

两者都反对以 NFS 形式挂载，但对 NFS 个性的反对并不残缺。比方都不反对块设施和字符设施，这间接导致了 pjdfstest 中大量测试用例的失败。排除这两类文件之后，依然有上百项不同类别的失败， 所以在简单场景中利用二者必须慎之又慎 。

而 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✿)

正文完