deepseek-ai/3FS
1
0
Fork 0
mirror of https://github.com/deepseek-ai/3FS.git synced 2026-11-05 00:47:47 +00:00
Code Issues 166 Projects Packages Wiki Activity

[GH-ISSUE #292] 3FS_usrbio在FIO海量小文件测试场景中的最大打开文件数不断增加的问题，导致测试用例失败：修改措施以及相关问题 #179

New issue
Open
opened 2026-10-26 09:46:39 +00:00 by bsakaguchi · 2 comments
bsakaguchi commented 2026-10-26 09:46:39 +00:00
Owner
Copy link

Originally created by @Funny-Boy-Max on GitHub (Jun 3, 2025).
Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/292

近期在利用FIO测试3FS在海量小文件场景（例如1w个文件，每个文件160KB）中，发生“Bad file descriptor”问题，测试脚本如下图所示：

Image

经查看源码，定位到3FS/benchmarks/fio_usrbio/hf3fs_usrbio.cpp代码中函数hf3fs_usrbio_open的一个错误，具体代码如图所示：

Image

代码中在每次open一个文件时都会修改IO线程的最大openfiles数量，可能导致超出操作系统内最大可打开文件数量以及无法触发close文件操作，进而导致FIO测试失败。

目前，本人的解决方案是将上图中hf3fs_usrbio_open函数中的“td->o.open_files++;”注释掉，可以完整执行测试用例，但是目前测试结果，带宽损失严重，原因尚不可知。

相较于同配置采用libaio的ioengine，具体配置如下图，其带宽可达222MB/s（物理RDMA[mellanox cx5]带宽上限100Gb/s，磁盘合并带宽远大于网络），测试结果如下。

Image Image

然而，现在使用修改后的usr_bio ioengine，带宽只能达到50.1MB/s，如下图所示。

Image

请问此结果是否符合预期。

需要说明的是，在采用官方提供的测试单文件内随机/顺序读，libaio和usrbio的带宽释放最大可分别达到1560MB/s和9144MB/s。

Originally created by @Funny-Boy-Max on GitHub (Jun 3, 2025). Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/292 近期在利用FIO测试3FS在海量小文件场景（例如1w个文件，每个文件160KB）中，发生“Bad file descriptor”问题，测试脚本如下图所示： <img width="521" alt="Image" src="https://github.com/user-attachments/assets/34742941-3aba-4e33-811f-6d4d3ccc9feb" /> 经查看源码，定位到3FS/benchmarks/fio_usrbio/hf3fs_usrbio.cpp代码中函数hf3fs_usrbio_open的一个错误，具体代码如图所示： <img width="640" alt="Image" src="https://github.com/user-attachments/assets/5cfb0de6-cdd6-4d00-835e-a4f747588ca2" /> 代码中在每次open一个文件时都会修改IO线程的最大openfiles数量，可能导致超出操作系统内最大可打开文件数量以及无法触发close文件操作，进而导致FIO测试失败。 目前，本人的解决方案是将上图中hf3fs_usrbio_open函数中的“td->o.open_files++;”注释掉，可以完整执行测试用例，但是目前测试结果，带宽损失严重，原因尚不可知。 相较于同配置采用libaio的ioengine，具体配置如下图，其带宽可达222MB/s（物理RDMA[mellanox cx5]带宽上限100Gb/s，磁盘合并带宽远大于网络），测试结果如下。 <img width="317" alt="Image" src="https://github.com/user-attachments/assets/0b0b31bd-5575-4504-b391-f4d7daf4287d" /> <img width="734" alt="Image" src="https://github.com/user-attachments/assets/03b4a268-6bd9-4fb6-a5f4-9f8edfd7ae04" /> 然而，现在使用修改后的usr_bio ioengine，带宽只能达到50.1MB/s，如下图所示。 <img width="758" alt="Image" src="https://github.com/user-attachments/assets/afc2dd49-21a4-4da1-a998-aa5d0d70d483" /> 请问此结果是否符合预期。 需要说明的是，在采用官方提供的测试单文件内随机/顺序读，libaio和usrbio的带宽释放最大可分别达到1560MB/s和9144MB/s。
bsakaguchi commented 2026-10-26 09:46:41 +00:00
Author
Owner
Copy link

@Funny-Boy-Max commented on GitHub (Jun 3, 2025):

目前本人疑惑的点在于3FS在海量小文件场景的随机读取场景，其带宽无法追平libaio，是否是因为本人的代码修改所导致。如果想利用3FS的高性能接口，有哪些建议

<!-- gh-comment-id:2936216010 --> @Funny-Boy-Max commented on GitHub (Jun 3, 2025): 目前本人疑惑的点在于3FS在海量小文件场景的随机读取场景，其带宽无法追平libaio，是否是因为本人的代码修改所导致。如果想利用3FS的高性能接口，有哪些建议
bsakaguchi commented 2026-10-26 09:46:42 +00:00
Author
Owner
Copy link

@Zenghao-CQ commented on GitHub (Aug 6, 2025):

3FS的元信息服务在FoundationDB的基础上提供，JuiceFS等使用redis(社区版)、自研服务(企业版)，3FS的lookup等操作延迟应该会显著高于JuiceFS，可能吃亏在元信息服务上。。。方便的话可以压测上meta的lookup操作的延迟及iops

Image

<!-- gh-comment-id:3157926995 --> @Zenghao-CQ commented on GitHub (Aug 6, 2025): 3FS的元信息服务在FoundationDB的基础上提供，JuiceFS等使用redis(社区版)、自研服务(企业版)，3FS的lookup等操作延迟应该会显著高于JuiceFS，可能吃亏在元信息服务上。。。方便的话可以压测上meta的lookup操作的延迟及iops ![Image](https://github.com/user-attachments/assets/3a691951-81af-444f-b478-8a83b09fec1f)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
SF-Zhou-patch-1
No results found.
Labels
Clear labels   
pull-request
Mirrored from GitHub Pull Request

No labels
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/3FS#179
No description provided.