JuiceFS v0.17 发布,通过 1270 项 LTP 测试!

原创
09/27 14:25
阅读数 200

小伙伴们大家好,JuiceFS v0.17 在国庆小长假来临之际如期发布了!这是我们在 2021 年秋季推出的第二个版本,让我们直奔主题,看看都有哪些新变化吧。

本次更新累计 80+ 提交,共有 9 位来自 JuiceFS 社区的小伙伴在 GitHub 上贡献代码。在这里,我们向每一位贡献者表示最诚挚的感谢,同时欢迎屏幕前的你也加入到 JuiceFS 开源社区,贡献代码、文档或讨论想法。

通过 LTP 1270 项测试,Linux 系统下兼容性更完美

JuiceFS 的最新版本针对 Linux 系统环境做了进一步的优化,改进了 rename 和 setxattr 读其他参数的支持,顺利通过了 LTP 的 1270 项测试。

LTP(Linux Test Project)是一个由 IBM,Cisco 等多家公司联合开发维护的项目,旨在为开源社区提供一个验证 Linux 可靠性和稳定性的测试集。LTP 中包含了各种工具来检验 Linux 内核和相关特性。

测试结果

Testcase                                           Result     Exit Value
--------                                           ------     ----------
fcntl17                                            FAIL       7
fcntl17_64                                         FAIL       7
getxattr05                                         CONF       32
ioctl_loop05                                       FAIL       4
ioctl_ns07                                         FAIL       1
lseek11                                            CONF       32
open14                                             CONF       32
openat03                                           CONF       32
setxattr03                                         FAIL       6

-----------------------------------------------
Total Tests: 1270
Total Skipped Tests: 4
Total Failures: 5
Kernel Version: 5.4.0-1029-aws
Machine Architecture: x86_64

其中,跳过和失败的项目主要是由于几个尚未支持的功能,详情见此文档

优化存储临时数据的性能

针对 Spark 的 shuffle 文件等临时数据存储需求,社区贡献者祝威廉(@allwefantasy)给 JuiceFS 贡献了数据延迟上传功能,它可以让 JuiceFS 优先将数据写入到本地缓存盘中,如果这些数据在短时间内又被删除,则无需写入对象存储,可以提供接近本地盘的读写性能。而当写入数据很多时,又会自动写到对象存储来释放本地盘空间,再也不用担心 shuffle 数据把磁盘写满了。

这个新功能让 JuiceFS 可以作为一个弹性本地盘使用,为临时数据提供无限存储空间和低延时访问。

为了进一步提升性能,还新增了一个运行在客户端内存中的元数据引擎(MemKV)。与其他元数据引擎一样,MemKV 的作用也是用来保存数据相关的元信息,但它不持久化,客户端 umount 以后,MemKV 的元数据就释放了。MemKV 完全在内存中运行,有着绝对的性能优势,非常适合用作临时文件的存储场景。

TiKV 元数据引擎在 Hadoop 场景中性能提升 5 倍

JuiceFS Java 客户端需要频繁做路径解析,Redis 引擎通过 Lua 实现了服务器端的多级路径解析,而 SQL 和 TiKV 引擎仍然需要多次元数据请求才能解析一个路径,尤其是当路径比较深时对影响有比较大的影响。

为了解决这个问题,本次更新在 JuiceFS Hadoop SDK 客户端中引入了类似于 Linux 内核的元数据缓存机制,可以分别通过参数控制目录、文件和属性的过期时间。可以通过如下的方式启用:

<property>
  <name>juicefs.attr-cache</name>
  <value>3</value>
</property>
<property>
  <name>juicefs.entry-cache</name>
  <value>3</value>
</property>
<property>
  <name>juicefs.dir-entry-cache</name>
  <value>3</value>
</property>

以下是对 9 层目录的元数据性能测试,可以看到启用元数据缓存够大幅提升元数据操作的性能。(数值代表操作的时延,越小越好。)

但需要注意的是,开启元数据缓存后会影响多客户端之间的一致性(有限时间窗口的最终一致性),比如一个客户端删除了某个文件后,其他节点可能因为缓存未到期,仍然认为文件存在。因此,一般建议在查询场景下使用该功能。如果是混合读写的场景,建议适当开启目录和属性的缓存,而关闭文件项的缓存。

1 分钟上手性能测试,结果一目了然

我们为 JuiceFS 内置的性能测试工具 bench 的结果做了进一步的优化,在简洁直观的基础上,进一步的让关键数据高亮显示,如果某项性能数据偏离正常区间,会显示为黄色甚至红色,建议特别关注下。

有关 JuiceFS 新版的更多内容,欢迎访问 GitHub 项目主页了解详情:

推荐阅读:

如何借助 JuiceFS 为 AI 模型训练提速 7 倍

如何利用 JuiceFS 的性能工具做分析和调优

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部