JuiceFS v0.17 发布,通过 1270 项 LTP 测试
小伙伴们大家好,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 项目主页了解详情。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Linux 5.15-rc3 发布,修复性能问题
Linux 内核 5.15 的第三个 RC 版本已发布。 Linus Torvalds 在发布公告写道,在经历了一个有点坎坷的合并窗口和第二个 rc 后,现在 rc3 的情况实际上看起来很正常。他还补充表示,此版本修复了不少错误,而且所统计的数字看起来十分有规律——驱动程序占主导地位(因为它们是代码树的主要部分),在驱动程序之外则是相当常见的变化组合——架构修复、网络、文件系统和工具(后者 主要是 kvm 自测)。 在 Linux 5.15-rc3 中,值得注意的变化还有对影响 Linux 5.15 开发至今的各种工作负载的性能退步的修复。 最后,Linux 5.15 将于 11 月初正式发布稳定版。
- 下一篇
联发科计划为 nanoMIPS 带来上游 GCC 编译器支持
联发科正致力于为 nanoMIPS 带来上游 GCC 编译器支持,不过官方并未透露其这样做的原因。Phoronix猜测称,或许与该公司的调制解调器的控制处理器中仍然依赖的指令集架构(ISA)有关。 MIPS Technologies 于 2018 年宣布了面向嵌入式设备的 nanoMIPS 架构,旨在降低功耗并实现更小的代码空间占用。但自 MIPS I7200 之后,与 nanoMIPS 相关的消息已经很久没有出现更新了。直至近日,联发科再次开始寻求要将该指令集架构并入上游 GCC。 事实上,MIPS 架构本身现在已经被上游放弃。MIPS Technologies 曾于今年年初表示将不再设计 MIPS 芯片,转而开发基于 RISC-V 架构的处理器。该公司此前也曾试图将 nanoMIPS 支持引入上游 GCC 编译器,但从未成功过;而是一直在依靠于他们的out-of-tree工具链。 这在某种程度上是之前将 nanoMIPS 支持引入上游的努力的延续。我们希望将我们的工具链发布转移到更接近于上游 GCC 的地方。作为其中的一部分,我们希望得到社区的反馈,目前 nanoMIPS 和 MI...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS关闭SELinux安全模块
- CentOS7设置SWAP分区,小内存服务器的救世主
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- 设置Eclipse缩进为4个空格,增强代码规范
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长